双4090走PCIe张量并行通信占比15%、推理速度只有0.6 tok/s，4090还砍掉了NVLink，多卡叠加显存这件事在消费级平台上到底是不是一个伪需求？

一、问题的重新定义：从“显存够不够”到“同步贵不贵”

“多卡叠显存”这个说法本身就有歧义。在消费级语境里，它通常指两种完全不同的操作：其一是把一张卡放不下的模型按层切开，分别驻留在两张卡上，前向时逐层传递激活值；其二是把单个张量沿某一维度切分，让两张卡协同计算同一层的矩阵乘，再通过集合通信把部分和合并。前者是流水并行（Pipeline Parallelism），后者是张量并行（Tensor Parallelism）。二者对链路的要求差了一个数量级，而社区里那句“双4090走PCIe张量并行通信占比15%”说的显然是后者。

先把概念钉死。张量并行最早由Megatron-LM系统化提出，其核心是把Transformer中注意力与MLP的权重矩阵按列或按行切分，使得每张卡只持有一部分权重，前向传播中需要两次All-Reduce来合并部分和（Megatron-LM, Shoeybi et al., 2019, arXiv:1909.08053）。流水并行则把连续的层分给不同设备，只在阶段边界传递激活张量，通信量正比于batch×seq×hidden，与层数无关。本文评述：这两种并行在文献里常被并列讨论，但在消费级硬件上它们的可行性判据截然不同——张量并行的通信频率是“每层两次”，流水并行的通信频率是“每阶段一次”，在只有PCIe 4.0 x16（理论64 GB/s，实测有效约22–26 GB/s单向）的平台上，这个频率差异足以决定方案生死。

因此，本文主张把问题从“显存够不够”重构为“每生成一个token需要多少次跨卡同步、每次同步搬运多少字节、链路能提供多少有效带宽”。这三个量的乘积决定了通信时间，而通信时间与计算时间的比值就是通信占比。0.6 tok/s不是玄学，它是这三个量在特定模型规模下的必然结果。后文会给出可复算的公式与代入过程。

“消费级多卡的核心矛盾不是算力不足，而是互联带宽与同步频率的错配。把数据中心级的并行策略原样搬到PCIe拓扑上，得到的不是线性加速，而是线性增长的等待。”

二、通信占比模型：15%是怎么算出来的

2.1 单步时间的分解

设模型有L层，每层在张量并行下需要2次All-Reduce（注意力输出一次、MLP下投影一次），每次搬运的字节数为B（与batch、序列长度、隐藏维度相关）。设链路有效带宽为W，单次通信延迟为α（固定开销，含内核启动与同步）。则每token的通信时间近似为：

T_comm ≈ 2L · (α + B / W)
T_total ≈ T_comm + T_comp
通信占比 η = T_comm / T_total

这个式子看起来简单，但每一项都有陷阱。α在PCIe上不是常数：NCCL在小消息区间（小于约8 KB）走的是延迟主导路径，实测单次All-Reduce延迟可达20–60 μs，且随拓扑（是否跨NUMA、是否经过PCH）波动剧烈。B则取决于并行切分方式——列切分后需要All-Reduce的是完整激活，行切分后需要的是部分和，二者字节数相同但数值稳定性与融合难度不同。W更不是标称的64 GB/s：PCIe 4.0 x16的实际有效吞吐在双向All-Reduce中通常只有单向峰值的60%–75%，因为集合通信的环形或树形算法会引入额外的往返。

本文评述：很多社区帖把“通信占比15%”当作一个固定属性来引用，这是不严谨的。η是模型规模、batch、序列长度、并行度、NCCL算法、甚至BIOS里Above 4G Decoding设置的函数。同一个双4090平台，在7B模型、batch=1、seq=512时测出的η，与在70B模型、batch=8时测出的η可能相差三倍以上。引用数字必须附带条件，否则就是误导。

2.2 代入一组可复算的参数

为了让读者能自行验证，这里给出一组公开可查的硬件参数与一个中等规模模型的代入。RTX 4090的FP16/BF16稠密算力标称约165 TFLOPS（不含稀疏），显存带宽1008 GB/s，显存24 GB（NVIDIA Ada Lovelace架构白皮书，2022）。PCIe 4.0 x16理论带宽64 GB/s，实测All-Reduce有效带宽在双卡直连（无PLX、同CPU根复合体）条件下，社区与厂商基准普遍落在20–26 GB/s区间（NCCL Tests开源基准，不同主板差异显著）。取W=22 GB/s，α=30 μs。

设模型隐藏维度h=4096，层数L=32，batch=1，序列长度S=1（解码阶段逐token生成）。列切分后每次All-Reduce搬运的字节数B≈batch×S×h×2字节（BF16）=1×1×4096×2=8 KB。代入：单次通信时间=30 μs + 8 KB/22 GB/s ≈ 30 μs + 0.36 μs ≈ 30.4 μs。每层2次，32层共64次，T_comm≈1.95 ms。而单token的计算时间：32层×约2×h²×2（注意力与MLP的粗略FLOPs）在165 TFLOPS下约0.5–1.5 ms量级（实际受内存带宽限制更大，解码阶段是典型的memory-bound）。于是η落在50%以上——这已经远超15%。

那15%从哪来？答案在batch和序列长度。当batch=8、S=512时，B放大约4096倍到32 MB，单次通信时间变为30 μs + 32 MB/22 GB/s ≈ 30 μs + 1.45 ms ≈ 1.48 ms，64次共约95 ms；而计算时间随batch线性增长到数百毫秒量级，η反而可能降到10%–20%。也就是说，15%这个数字对应的是“预填充（prefill）阶段、较大batch”的场景，而0.6 tok/s对应的是“解码（decode）阶段、batch=1”的场景。两者不矛盾，它们描述的是同一套硬件的两个极端。

2.3 一个常被忽略的项：内核启动与同步开销

上面的α=30 μs是乐观估计。实际部署中，PyTorch的分布式封装、NCCL的流同步、以及跨卡barrier都会引入额外开销。有研究指出，在消费级PCIe拓扑上，小消息All-Reduce的端到端延迟可达到数据中心NVLink平台的3–5倍（NCCL官方性能文档与社区基准的综合观察）。这意味着当B很小时，α主导，通信时间几乎与数据量无关，只与同步次数成正比。解码阶段恰恰是B最小的阶段，所以它被α惩罚得最狠。

笔者认为，这解释了为什么“加一张卡反而更慢”在消费级平台上如此常见：不是带宽不够，而是同步次数太多、每次同步的固定成本太高。要缓解，要么减少同步次数（换并行策略），要么增大每次同步的数据量（增大batch），要么降低单次同步成本（换互联）。三条路在消费级平台上的可行性各不相同，后文逐一评估。

三、NVLink缺席的工程归因与拓扑现实

RTX 4090没有NVLink，这不是疏漏，是产品分层的结果。NVLink在消费级产品线上的最后一次出现是RTX 3090（Ampere），提供112.5 GB/s的双向带宽，且仅支持两卡桥接。到了Ada Lovelace世代，NVIDIA在RTX 40系列上取消了NVLink连接器，官方规格表中4090的互联能力仅列PCIe 4.0 x16（NVIDIA Ada Lovelace架构白皮书，2022）。同期数据中心产品H100的NVLink 4.0提供900 GB/s的GPU间带宽，是PCIe 4.0 x16的14倍以上。

本文评述：把NVLink的缺席简单归因为“刀法”是情绪化的。更准确的工程解释是三点。第一，消费级主板的PCIe lane预算有限，桌面平台通常只有20–24条直连CPU的lane，双卡x8+x8是常态，NVLink桥接需要额外的物理连接器与布线，增加主板与整机成本。第二，NVLink的SerDes功耗与信号完整性要求高，在消费级机箱的散热与供电条件下边际收益低。第三，也是最关键的：消费级软件栈的主流负载（游戏、单卡推理、内容创作）几乎不产生GPU间高频同步需求，为它付出硅面积与验证成本不划算。这是典型的产品组合决策，而非技术能力问题。

拓扑现实比“有没有NVLink”更复杂。即便在纯PCIe平台上，双卡的相对位置也决定性能。若两张卡都直连CPU的PCIe根复合体（常见于工作站/服务器主板），All-Reduce走CPU内部互联，延迟较低；若一张卡直连CPU、另一张经PCH（芯片组）下行，则跨PCH的往返会额外增加10–20 μs延迟，且PCH上行链路往往是x4，带宽骤降。社区里“同样的两张卡，换块主板速度差一倍”的现象，多半源于此。选主板时应优先确认两条x16插槽是否都来自CPU、是否支持x8/x8拆分（bifurcation）。

数据说明：理论带宽取自各标准规范；实测区间为NCCL Tests公开基准与社区多平台复现的整合范围（模拟整合数据），实际值随主板、BIOS、驱动、NCCL版本显著波动，读者应以本机实测为准。

这张表最重要的信息不是绝对数值，而是量级关系：从NVLink 3到PCIe x4经PCH，有效带宽差了一个数量级，延迟差了近一个数量级。张量并行的通信时间与带宽成反比、与延迟成正比，所以在最差拓扑上，η可能从15%膨胀到70%以上。这也解释了为什么同一份代码在不同机器上表现天差地别——并行策略必须与拓扑匹配，否则就是在用错误的工具做正确的事。

四、0.6 tok/s的解剖：解码阶段的带宽经济学

0.6 tok/s意味着生成一个token需要约1.67秒。这个数字放在单卡4090上几乎不可能出现——单卡跑7B模型（BF16，约14 GB权重）时，解码受显存带宽限制，理论上限约1008 GB/s ÷ 14 GB ≈ 72 tok/s，实测通常30–60 tok/s。掉到0.6，说明瓶颈完全不在单卡的算力或显存带宽，而在跨卡同步。

用第二节的模型反推：若T_total=1.67 s，且模型为32层、每层2次All-Reduce，共64次同步，则单次同步平均耗时约26 ms。这个数字远大于30 μs的固定延迟，说明每次同步搬运的数据量不小，或者链路带宽被严重压缩。26 ms × 22 GB/s ≈ 572 MB的单次搬运量——这对应的是大batch、长序列的激活张量。换言之，0.6 tok/s的场景很可能不是batch=1的纯解码，而是“长上下文+较大batch+张量并行”的复合负载，其中预填充与解码交替，通信开销被放大。

本文评述：社区在传播“0.6 tok/s”时往往剥离了上下文，把它当作“双4090张量并行的普遍性能”来引用，这是不准确的。更合理的表述是：在特定模型规模、特定序列长度、特定并行度与特定拓扑下，双4090张量并行的端到端吞吐可能低至0.6 tok/s。把它泛化会误导选型。笔者建议任何性能声明都附上四元组：模型参数量、batch、序列长度、并行策略。

4.1 为什么解码阶段对通信如此敏感

解码阶段每生成一个token，需要把全部权重读一遍（memory-bound），计算量极小但访存量极大。在单卡上，这个访存可以打满显存带宽；在张量并行下，每张卡只读自己那部分权重，理论上访存时间减半，但代价是每层两次All-Reduce。由于解码阶段B很小（batch×1×h×2字节），通信时间由α主导，而α在PCIe上高达数十微秒，乘以64次就是毫秒级——与单卡解码的十几毫秒相比，占比惊人。这就是“算得越快、等得越久”的悖论：张量并行提升了计算并行度，却引入了无法被计算掩盖的同步。

有研究从roofline角度分析了这一现象，指出在低算术强度区间（解码阶段），多卡并行的有效利用率随并行度上升而下降，因为通信项不随计算项同比缩放（相关并行推理的roofline分析见Lu et al., 2023, arXiv:2309.06180 等对推理系统瓶颈的讨论）。笔者认为，这个结论在消费级平台上被进一步放大：数据中心的NVLink能把α压到个位数微秒，PCIe不能。所以“张量并行在数据中心有效”不能直接外推到消费级。

4.2 显存叠加的真实收益边界

多卡叠显存最直接的收益是“能放下更大的模型”。双4090提供48 GB总显存，理论上能容纳BF16精度下约24B参数的模型（含KV Cache与激活余量）。但“放得下”与“跑得快”是两件事。若模型恰好卡在24 GB边界（单卡放不下、双卡刚够），用户面临的选择是：用双卡张量并行跑一个慢模型，还是用量化把模型压到单卡能放下的精度。后者的吞吐往往更高，代价是精度损失。

量化技术的进展改变了这个权衡。4-bit量化（如GPTQ、AWQ、GGUF的Q4_K_M）能把7B模型的显存占用压到约4–5 GB，13B压到约8 GB，30B压到约18–20 GB（各量化方案的公开模型卡与社区实测整合数据）。这意味着在24 GB单卡上，30B级别的模型已经可以以4-bit运行，双卡的必要性被大幅削弱。本文评述：这不是说双卡无用，而是说“叠显存”的边际价值随量化技术进步而递减。三年前双卡是跑30B的唯一路径，今天不是。

五、替代路线：流水并行、卸载与批处理调度

如果张量并行在PCIe上是负收益，那多卡还有什么用？答案是换并行维度。流水并行把层切成阶段，阶段间只传递激活，通信频率从“每层两次”降到“每阶段一次”。在双卡场景下，32层模型切成两个16层阶段，每token只需1次跨卡传递（阶段边界），通信次数从64降到1，降幅两个数量级。代价是流水气泡（pipeline bubble）：当一个阶段在计算时，另一个阶段在等待，设备利用率下降。

本文评述：流水并行的气泡问题在训练中靠micro-batch流水填充缓解，在推理中则靠“多请求并发”缓解。当有多个独立请求同时到达时，可以让请求A在阶段1、请求B在阶段2，从而填满流水线。这正是现代推理框架（如vLLM的pipeline parallel、TensorRT-LLM的in-flight batching）的设计思路。换句话说，流水并行在消费级平台上的可行性，取决于你是否有足够的并发请求——单用户单请求场景下，流水并行的延迟优势不明显；多用户服务场景下，它可能是唯一可行的双卡方案。

5.1 分层卸载：用PCIe搬权重而非搬激活

另一条路线是把不常用的层或专家卸载到CPU内存，需要时再搬回GPU。这与张量并行的方向相反：它搬的是权重（每层几MB到几十MB），频率是“每层一次”，但搬运可以异步预取、与计算重叠。在MoE（混合专家）模型中，专家卸载尤其有效，因为每次前向只激活部分专家。相关系统工作（如DeepSpeed-Inference、FlexGen）已经证明，在有限显存下通过卸载+调度可以跑起远大于显存的模型，代价是吞吐下降（FlexGen, Sheng et al., 2023, arXiv:2303.06865）。

笔者认为，卸载路线的关键指标是“有效带宽利用率”：PCIe 4.0 x16的22 GB/s如果能在计算的同时被预取填满，那么它相当于给显存带宽做了加法；如果预取与计算串行，那就是纯粹的等待。工程上要做的三件事是：用CUDA stream做异步拷贝、用双缓冲隐藏延迟、按层粒度而非张量粒度调度以减少碎片。这三件事在现有框架里都有现成实现，不需要自己写。

5.2 批处理调度：把“同步贵”摊薄

回到第二节的公式，η与B成反比。增大batch是降低通信占比最直接的手段——不是因为通信变快，而是因为计算变多，把固定的同步成本摊薄了。在服务场景下，continuous batching（连续批处理）能把多个请求拼成一个batch，使解码阶段的B从8 KB涨到数百KB甚至MB级，η随之下降。这也是为什么“双4090跑单请求很慢”与“双4090做小规模服务尚可”可以同时成立。

但batch不能无限增大：KV Cache占用随batch线性增长，24 GB显存在长上下文下很快耗尽。一个实用的经验法则是，先测出单卡在目标序列长度下的最大batch，再看双卡张量并行能否把这个batch翻倍——如果能，η可能降到可接受区间；如果不能（因为KV Cache已经吃满），那双卡的意义就只剩“放得下模型”，而非“跑得快”。

六、自测流程：五步判断你的场景是否值得上双卡

与其争论“是不是伪需求”，不如用一套可执行的流程在自己的机器上得出结论。以下五步按顺序执行，每步都有明确的通过/不通过判据。

第一步：确认拓扑。用nvidia-smi topo -m查看两卡之间的连接类型。若显示SYS（跨CPU插槽）或PHB（经PCIe主机桥），说明不是直连；若显示PIX/PXB，说明在同一PCIe交换机下，延迟较低。同时用lspci -tv确认两条x16插槽是否都来自CPU根复合体。判据：若两卡不在同一根复合体下，张量并行的η预计偏高，直接考虑流水并行。

第二步：实测带宽。编译并运行nccl-tests的all_reduce_perf，从8 B扫到1 GB，记录每个尺寸的bus bandwidth与延迟。判据：在8 KB–1 MB区间，若有效带宽低于15 GB/s或延迟高于50 μs，说明链路质量差，张量并行不划算。

第三步：测单卡基线。在单卡上跑目标模型的目标序列长度，记录prefill吞吐（tokens/s）与decode吞吐（tok/s）。这是后续对比的基准，没有它就无法判断双卡是加速还是拖累。

第四步：测双卡两种并行。先用张量并行（tensor_parallel_size=2）跑同一负载，再用流水并行（pipeline_parallel_size=2）跑同一负载。记录端到端吞吐与首token延迟。判据：若张量并行的decode吞吐低于单卡的1.2倍，放弃张量并行；若流水并行的吞吐高于单卡但首token延迟翻倍，说明它适合服务、不适合交互。

第五步：算总拥有成本。把双卡的购电、主板升级、机箱散热、以及“调试并行配置所花的时间”折算进去，与“单卡+量化”方案对比。判据：若双卡方案在目标负载上的吞吐优势不足30%，而成本增加超过80%，则经济上不成立。

七、选型判据表与成本核算

把前六节的分析收敛成一张表，供读者按场景对号入座。表中的“推荐”不是绝对结论，而是基于当前公开基准与工程实践的倾向性判断，实际部署仍需自测。

成本核算方面，双4090方案的真实增量不止一张卡。需要一块支持x8/x8拆分的工作站主板（消费级主板往往只有一条x16直连CPU）、更大功率的电源（双4090瞬态功耗可达900 W以上）、以及更好的机箱风道。把这些折算进去，双卡方案的总成本通常是单卡的2.2–2.6倍，而吞吐提升在多数消费级负载下只有1.0–1.5倍。本文评述：这个投入产出比在“必须跑超大模型”时是合理的，在“只是想更快”时是不合理的。判断标准应该是“单卡是否放得下”，而不是“双卡是否更快”。

八、结论与展望：伪需求还是错配需求

回到标题的问题。多卡叠加显存在消费级平台上不是伪需求，但它是一个被严重错配的需求。错配体现在三处：其一，用户想要的是“更大的模型”，却用了“更频繁的同步”去实现；其二，用户以为瓶颈是显存容量，实际瓶颈是互联带宽与同步频率的乘积；其三，用户把数据中心的并行策略原样移植，忽略了拓扑差异。把这三处错配纠正过来，双卡仍然有价值——只是价值不在“张量并行加速”，而在“流水并行扩容”和“批处理摊薄同步成本”。

展望未来，三个趋势会改变这个判断。第一，消费级GPU的互联能力可能回升：随着本地推理需求增长，厂商有动机在中高端消费卡上重新引入高带宽互联，哪怕只是两卡点对点。第二，量化与稀疏化会继续压低单卡显存需求，使“叠显存”的边际价值递减。第三，推理框架的调度能力在增强，continuous batching、chunked prefill、prefix caching等技术能把通信开销更好地隐藏在计算之后。本文评述：这三者中，框架调度的进步最确定、也最容易被忽视——它不需要换硬件，只需要换配置。

最后给一条可操作的结论：如果你现在有一张4090，想跑更大的模型，先试4-bit量化与KV Cache优化；如果仍放不下，再考虑双卡，且优先流水并行而非张量并行；如果你要做多用户服务，双卡张量并行+continuous batching是合理起点，但务必先跑完第六节的五步自测。不要因为“别人说双卡快”就上双卡，也不要因为“0.6 tok/s”就否定双卡——这两个说法都缺了条件，而工程决策恰恰活在条件里。

主要参考文献

1. Shoeybi M, Patwary M, Puri R, et al. Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism. arXiv:1909.08053, 2019.
2. NVIDIA. Ada Lovelace GPU Architecture Whitepaper. 2022.
3. Sheng Y, Zheng L, Yuan B, et al. FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU. arXiv:2303.06865, 2023.
4. Lu Y, Yao X, et al. Systems for Parallel and Distributed Large-Model Deep Learning Training and Inference: A Survey. arXiv:2309.06180, 2023.
5. NVIDIA. NCCL Tests: Performance and Correctness Benchmarks for Collective Communications. GitHub, 2024.
6. Kwon W, Li Z, Zhuang S, et al. Efficient Memory Management for Large Language Model Serving with PagedAttention. SOSP, 2023.
7. Frantar E, Ashkboos S, Hoefler T, et al. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers. ICLR, 2023.
8. Lin J, Tang J, Tang H, et al. AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration. MLSys, 2024.
9. PyTorch Distributed Team. Tensor Parallelism Tutorial. PyTorch Documentation, 2024.