AI在家第二部分：多GPU技术

# 家用AI实践（下篇）：多GPU并行配置 来源：https://jdagostino.github.io/ai-pt2-multi-gpu-drifting/index.html ## 家里的AI设备 ### 第二章：多GPU并行方案 ##### 2026年8月20日 --- 在上一章节中，我利用电子垃圾级别的GPU组装了一台运行AI语言模型的离谱家用服务器。（https://jdagostino.github.io/ai-pt1-box-o-scraps/index.html）本文将探讨如何在这种配置下榨取合理的性能表现。（本篇将基于现有代码与技术进行优化，通过调整llama.cpp等参数实现；编写新型ROCm内核不在此章节讨论范围） 先进行些背景介绍。若你已了解Transformer模型的工作原理，可直接跳转至第2节（https://jdagostino.github.io/ai-pt2-multi-gpu-drifting/index.html#s2）。若熟悉多GPU并行原理且只想查看测试环节，则跳转至第3节（httpsjdagostino.github.io/ai-pt2-multi-gpu-drifting/index.html#s3）。 #### 第1节：注意力机制 目前广泛应用的AI文本生成软件基本都属于"Transformer模型"或"大语言模型"。其核心设计思想源自论文《Attention is All You Need》（https://arxiv.org/abs/1706.03762），这可能是近二十年来计算机科学领域最重要的论文。本文可读性在同类论文中已属上乘，相信每位阅读本文的软件工程师都已拜读过，对吧？（对吧？） 简言之，本文将从实际应用角度出发，聚焦如何在低端硬件上实现高效推理，不过多深入张量运算或模型训练细节——毕竟本文篇幅已注定过长。 大语言模型通过"Token"工作。Token本质上是词片段，相比逐字母输入输出，将文本切分为字母序列由模型处理效率更高。（这也解释了早期AI模型为何常答错"raspberry里有几个R字母？"这类问题）不同模型采用不同的分词方式，可视为某种频率编码。每次模型生成新Token时，实际是生成概率分布后从中随机采样，因为相比始终选择最高概率项，这种方式更符合语言生成规律。 语言模型是分层的神经网络，包含输入层、输出层以及多层不与输入输出直接交互的"隐藏层"。输入层接收完整提示文本，各层依次对前一层输出进行数学运算。模型同时观察整个输入序列并建立不同位置Token间关联的机制，称为"注意力机制"。若你关注AI语言模型，或许听过有人断言"这些AI模型只是像马尔可夫链一样的次词生成器"，随后可能注意到AI模型输出与马尔可夫链截然不同，疑惑其谬误所在。实际上，马尔可夫链缺乏注意力机制，仅基于序列前一个Token生成新词。 因此，生成下一个Token时，模型需要读取完整分词提示，构建嵌入矩阵（每个Token转化为长度等于隐藏维度的向量），在每层执行注意力运算（对每个Token进行巨型矩阵乘法运算），采样新Token添加到提示中，循环直至生成终止符。 （图1来自《Attention Is All You Need》Vaswani等，2017） 对我们而言，这意味着每次生成Token时，计算机都需读取现有上下文和模型全部权重以完成矩阵运算生成Token。上一章提到的Gemma4-31B模型拥有310亿权重（分60层），所有权重需载入GPU计算下一个Token。加载这些权重所需时间远超实际注意力运算；Token生成速度通常受限于内存带宽而非计算能力。这就是为何我组装的服务器配备大量高显存GPU——模型权重和KV缓存需存储在能快速访问GPU的显存中，相比之下CPU内存速度慢得多。（这也是当前整个行业转向优先生产数据中心GPU用高带宽内存导致内存短缺的原因） 显然这种方式扩展性不佳。随模型规模增大，Token生成速度急剧下降；此类方案实际已触天花板。因此出现了命名误导的"混合专家模型"架构¹（https://jdagostino.github.io/ai-pt2-multi-gpu-drifting/index.html#fn1）。其思路是：前几层始终用于处理整个输入嵌入矩阵，随后将计算路由到模型的某个子集。在中间层，每个输入Token被路由到部分权重集，因此每个Token仅需加载部分权重。这些子集被称为"专家"，我非常反感这种表述，因为它会让人误以为某分支精通Python、另一分支熟悉火箭引擎、还有一分支掌握德语，从而可以裁剪不关心的模块。事实绝非如此！"专家"基本是随机或至少不可预测的，对大多数混合专家模型而言，不同Token基本均匀路由到不同专家。例如Deepseek V4 Flash拥有2840亿权重，但每个Token仅激活130亿。（简写为"284B-A13B"，仅130亿被"激活"）但我无法预先知道具体哪130亿被激活，且每个生成Token都会变化，因此仍需将全部2840亿权重存储在高速显存中以维持生成速度。混合专家模型以增加显存需求为代价提升了Token生成速度。 #### 第2节：并行方案 当使用大量显存时，需在多个GPU间分配。我的服务器配备四张32GB显卡；企业级方案会采用八张192GB显卡，并将超大模型拆分到多个计算节点，但原理相通。GPU可快速读取自身显存，访问其他GPU显存较慢，访问其他计算节点内存则更慢。拆分方式多样，对我这种车库自用服务器场景，主要考虑两种： **层并行** —— 将模型不同层分配至不同GPU。生成新Token时，GPU1处理若干层后将中间状态转移至GPU2处理后续层，依此类推。这种方式简单直观，可将所有模型权重装入显存。但各层需串行处理（因每层依赖前一层输出），理论最佳速度基本等同于单GPU拥有全部显存时的速度。（实际会略慢）AMD V620显存带宽为512GB/s，若四卡层并行，单次提示可获得...512GB/s带宽，扣除GPU间数据传输开销。 **张量并行** —— 将每层拆分到多GPU。每层中各GPU计算部分矩阵乘积，汇总到另一GPU同步计算最终结果后进入下一层。理论上这能并行化显存带宽：四张512GB/s带宽的显卡，张量并行理论上应达2TB/s带宽！当然需扣除GPU间数据传输开销。但实际开销巨大！每层需多次传输数据，而层并行每GPU每Token仅传一次。这可能（且在我的服务器上必然）抵消显存带宽增加带来的速度提升。 还会涉及更适合多用户并发场景的其他并行方式： **数据并行** —— 在多GPU运行相同模型，并行路由传入查询。我未来可能为多子代理同时运行时尝试此方案，但除非大规模应用否则非必需，因GPU已能批处理推理。（如前所述，推理流程受限于显存带宽，可免费插入额外矩阵运算，直到计算再次成为瓶颈） **专家并行** —— 将共享张量置于各GPU，非共享"专家"（或其子组）分配至不同GPU，多用户查询在推理流程中多数阶段路由至不同GPU。此方案主要适用于高并发商业场景，对我无实际帮助。 总之，我的服务器主要服务单次请求。未来可能尝试并行子代理，或有几位访客同时使用，但因无多用户需求，暂不针对这些场景优化。 #### 第3节：实验测试 现在讨论我的服务器配置。 我配备四块AMD Radeon Pro V620显卡，连接共享PCIe总线。GPU间通信速度本就较慢，而实际比预期更糟——因主板采用较老的PCIe 3.0标准，且多数显卡仅用8通道而非16通道。 ``` jacob@daedalus:~$ sudo lspci -vvv [...] LnkCap: Port #2, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <64us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM L1 Enabled; Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 8GT/s (downgraded), Width x8 (downgraded) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- ``` `lspci`显示8通道且速度慢，堪比洛杉矶高速路 因此我推测张量并行效果有限。专为AI设计的显卡通常配备高速低延迟GPU间连接（除PCIe外），且均为厂商专有方案：NVIDIA有NVLink，AMD有Infinity Fabric，Intel有Xe Link等。我的显卡无此类设计。同期AMD为云游戏计划制造这些显卡时，曾推出AI专用AMD Instinct MI210，其显存带宽约三倍，可通过Infinity Fabric专用桥接器连接最多四块。但单块二手价格已超我整套设备，因此此方案不切实际，我只能因地制宜。 我的四块显卡单卡性能尚可但互联性差，这意味着必须采用层并行，再设法优化流程。即便是层并行也会带来性能损耗，后续将具体说明。 本研究使用两个模型：Gemma4-31B和Deepseek V4 Flash。 **Gemma4 31B**拥有310亿参数，4位量化后权重约18GiB，可完全装入单张32GB显存显卡。这是稠密模型；每个Token需处理全部18GiB权重。 **Deepseek V4 Flash**拥有2840亿参数，属混合专家模型，每个Token激活130亿参数。Deepseek官方量化将路由专家权重设为4位，总大小162GiB，超出服务器容量！我运行的是2位量化版（81GiB）。仅路由专家权重深度压缩，共享权重保持全精度；磁盘总文件约3.5位/权重，但每个Token加载约5点几倍位权重。这恰好压满四卡阵列显存。（还需注意需在显存中存储当前上下文"KV缓存"，因其是每层矩阵运算的另一要素）2位量化通常口碑不佳，但我发现此版本效果惊人，可能因共享权重保持高精度所致²（https://jdagostino.github.io/ai-pt2-multi-gpu-drifting/index.html#fn2）。 上一章组装该机器时，我立即尝试在四卡默认层并行模式下运行此Deepseek V4 Flash量化版，其他参数保持默认。生成速度约9-10 Token/秒。虽足以编写风扇控制脚本，但慢得令人烦躁。我深知尚有性能潜力未挖掘。 首先回退用Gemma测试技巧。较小模型更易操作，不易出现显存不足错误。 我直接对比了层并行与单卡运行的性能损耗。使用4位量化Gemma，锁定上下文长度65536 Token，基础默认参数测试结果如下： - 单卡性能：19-20 Token/秒 - 双卡层并行：15-16 Token/秒 - 四卡层并行：12-13 Token/秒 基础命令参考： ``` lama-server --host 0.0.0.0 --model /mnt/storage/llm/Gemma-4-31B/gemma-4-31B-it-qat-q4_0.gguf --ctx-size 98304 --fit off --n-gpu-layers all ``` 单卡附加参数： ``` --device ROCm0 --split-mode none ``` 双卡测试： ``` --device ROCm2,ROCm3 --split-mode layer ``` 四卡测试： ``` --device ROCm0,ROCm1,ROCm2,ROCm3 --split-mode layer ``` 因该模型可完全装入单卡，实现了真正同等条件对比：相同模型权重与上下文长度下，将层分配到不同GPU会因同步操作产生性能损耗。当然对配备专用互联链路的GPU而言，此损耗会小得多。但目前我得出的结论是，要提升速度...