多卡推理优化怎么做？加卡前先算通信税的6个判据

多卡推理优化的正确做法，是先按 Prefill 与 Decode 两段负载分别算账，再决定切分方式与加卡时机。很多团队直接翻倍卡数，结果 8 卡反而比单卡慢，归根结底是加的卡越多，通信税越重。

这句话不是空谈。2026 年 8 月，vLLM 发布 v0.27.0，深入集成 FlashAttention 4，为 Blackwell SM100 提供 FP8 KV Cache 与 256 headdim 原生支持，并消除空 c128 启动、优化 Top-K 路由来降低 DeepSeek 模型的首包延迟（TTFT）；同期，SGLang 在 Blackwell 上推进 NVFP4 预填/解码分离（PD Disaggregation），并跟进 FlashInfer 的 NSA 与 DSA 稀疏注意力算子。这两条官方更新都指向同一个方向：把多卡推理的优化从“盲目加卡”转向“分段治理”。

先分清两段负载：Prefill 吃算力，Decode 吃带宽与通信

多卡推理优化要做的第一件事，是把推理过程拆成两段：Prefill（预填）阶段，处理输入 prompt 并生成首个 token，高度依赖 GPU 算力与并行计算能力；Decode（解码）阶段，逐 token 生成输出，主要受显存带宽与卡间通信速度制约。

如果你不加区分地把两段混在一起谈，就会陷入“加卡之后延迟反而变高”的误区：比如 Decode 阶段卡间通信开销巨大，增加卡数反而拖慢单 token 生成。

业界的最新实践正是沿着“分段治理”这条路径走。vLLM v0.27.0 针对 DeepSeek 架构强化了序列并行优化，SGLang 则在 Blackwell 上落地 NVFP4 PD 分离，让 Prefill 与 Decode 跑在不同实例上，各自按负载特征选择最优的硬件与切分方式。

判据一：单卡显存装不装得下——你加卡是为了容量还是为了速度

动手加卡之前，先问自己一个问题：你加卡是为了容量还是为了速度？

• 容量型加卡：模型权重加上 KV Cache 超出单卡显存，需要多卡分摊显存。这种场景下，吞吐通常不会随卡数线性增长，因为卡间通信会吃掉一部分并行收益——这本来就是预期结果，不必焦虑。
• 速度型加卡：目标是把吞吐拉高、把延迟压低，这时候切分方式与通信开销才是关键。

一个容易被忽略的事实：671B 参数的模型即使做 4-bit 量化，依然需要超过 300GB 的显存，单张消费级 GPU 根本放不下，只能跑 32B 或 70B 的蒸馏版本。所以对超大模型来说，容量型加卡几乎是必然选择。参考已有的部署经验：GPU显存怎么选 可以帮你更快确定显存基线。

判据二：切分维度选错，吞吐就不会线性增长（TP / PP / 序列维切分的适用边界）

并行切分方式直接决定卡间通信的模式与吞吐表现。下表对比了三种常见切分维度：

张量并行和流水线并行怎么选？简单来说：TP 切分权重与激活，适合单机内高速互联的环境；PP 按层切分，通信量小，但存在流水线气泡。对于 8 卡推理吞吐上不去的问题，往往不是卡数不够，而是 TP 过大导致通信占比过高。

引擎版本会影响切分策略的最佳解。vLLM v0.27.0 对序列并行与 TTFT 做了专项优化，同样卡数下，更新引擎版本可能让 TP 的可用范围变大。因此，切分方式的选择必须结合你所用的引擎版本来实测，不能照搬旧结论。

判据三：卡间互联决定 TP 的上限，什么时候单机内切、什么时候必须跨节点

张量并行对卡间带宽极度敏感：单机内的高速互联（如 NVLink）能支撑较大的 tensor parallel size，跨节点走以太网或 InfiniBand 时，通信延迟和带宽都会明显劣化。

因此，tensor parallel size 设多少合适，取决于卡间互联质量。在单机 8 卡内，TP=8 通常可行；一旦跨节点，TP 的通信税会急剧上升，这时应优先考虑 PP 或序列维切分来降低跨节点通信量。涉及集群规划时，可以参考 GPU集群规划 获取更多思路。

一个经常被忽视的成本项是：KV Cache 溢出导致跨机通信的“通信税”，这会直接抵消加卡收益。

判据四：KV Cache 精度会改写显存账，FP8 KV Cache 腾出的余量该怎么用

vLLM v0.27.0 在 SM100 上原生支持 FP8 KV Cache 与 256 headdim。KV Cache 从 FP16 切到 FP8，理论上每 token 缓存字节数减半，实际余量还要看实现与对齐开销，需以自己的负载实测为准。

腾出的显存余量，优先应该用来扩大 batch 大小或上下文长度，以提升单卡吞吐；还是用来减少卡数、降低通信开销？这取决于你的负载特征：如果请求并发高、上下文长，扩大 batch 和上下文通常更划算；如果卡数多但通信已吃紧，减少卡数反而可能提升整体效率。但要注意，精度优化可能引入精度损失，需要根据模型对误差的敏感度权衡。

另外，vLLM 版本升级后，FP8 KV Cache 的具体配置可参考 vLLM部署 的实际操作。

判据五：Prefill/Decode 分离适合什么样的请求分布，不适合什么样的

prefill decode 分离是什么意思？简单说，就是把 Prefill 和 Decode 阶段拆到不同的 GPU 实例上运行，各自独立扩缩容。这样 Prefill 实例可以专注吃算力，Decode 实例专注吃带宽，避免两类负载互相干扰。

PD 分离的收益取决于请求分布：当请求上下文很长、共享前缀较多、Prefill 与 Decode 负载比例失衡时，分离能明显降低整体时延与通信开销。SGLang 2026 年在 Blackwell 上落地 NVFP4 PD 分离，并支持 FlashInfer 的 NSA 与 DSA 稀疏注意力算子，针对长上下文场景提升性能。

但 PD 分离不适合所有场景：请求短、并发低、卡数少时，分离反而引入额外调度成本，是否启用需结合请求分布实测。

判据六：把吞吐换算成每百万 Token 成本，再判断加卡值不值

加卡的最终目的是降低单位产出成本，而不是单纯提升吞吐。决策时应该用“每百万 Token 产出成本”来对比：

• 获取同负载下的吞吐（tokens/s）与总时租成本；
• 计算每百万 Token 成本 = 单位时间成本 ÷ 单位时间吞吐 × 1,000,000。

注意，对比不同代际卡型时，务必在同一精度下进行。某些宣传数据混淆了 FP4 与 FP8 精度下的吞吐倍率：同为 FP8 精度，B200 比 H200 提升约 1.5-1.8 倍；只有启用 Blackwell 专属的 Native FP4 量化，吞吐提升才接近 3 倍。所以不能把 FP4 与 FP8 的数据混为一谈。按同精度折算每百万 Token 成本时，Hopper 代际的 H200租用 仍常是对照基线。

一份排查顺序：从利用率、通信占比到 batch 与上下文参数的调整次序

8 卡推理吞吐上不去时，按下面的次序逐项排查，比乱调参数有效得多：

1. 先看各卡利用率是否均衡：是否存在某张卡跑满、其他卡闲置的情况，这通常指向负载不均或同步等待。
2. 再看通信占比与同步点：用 profiler 统计 NCCL 通信耗时，若通信占比过高，考虑降低 TP 或改用 PP/序列维切分。
3. 调整 batch、并发与上下文上限：在显存允许范围内增大 batch 或上下文，提升计算密度。
4. 最后才动并行切分与引擎版本：一次只改一个变量，避免相互干扰。

卡间通信瓶颈怎么定位？最直接的方法是跑一段固定负载，对比不同 TP 配置下的吞吐与通信耗时。如果 TP=4 与 TP=8 的吞吐几乎持平，说明通信已饱和，继续增大 TP 没有意义。

用按量多卡资源做一次同负载对照实测：记录哪些指标才有对比意义

理论分析终究要落地。在决定加卡之前，建议用按量计费的多卡资源做一轮同负载对照实测：固定模型、请求分布与并发数，分别跑不同 TP/PP 组合、是否启用 PD 分离，记录以下指标：

• TTFT（首 token 延迟）
• 各卡利用率与均衡度
• 通信耗时占比
• 每百万 Token 成本

这类对照实验非常适合在按量计费的云 GPU 上进行：同模型同请求跑一轮，跑完即释放，比长期锁定 8 卡节点再试错的成本低得多。像 NexGPU 这类平台提供多种 GPU 型号选择、按量使用与预制模型模板，正好用于快速起停的对照实验。

四个常见误判：卡数越多越快、利用率高就等于跑满、只看单卡显存、把 FP4 与 FP8 数据混谈

• 卡数越多越快：通信开销随卡数增长，存在拐点。
• 利用率高就等于跑满：可能计算在等通信，利用率虚高。
• 只看单卡显存：忽略 KV Cache 与通信需求，导致跨机通信税压过收益。
• 把 FP4 与 FP8 数据混谈：代际倍率必须同精度比较。

加卡前，先按排查顺序跑一轮同负载对照，再折算每百万 Token 成本，才不会凭感觉做决定。NexGPU 提供的按量使用与预制模型模板，正好适合这类快速起停的对照实验，跑完即释放，成本可控。

常见问题

多卡推理为什么比单卡还慢？

因为卡间通信开销抵消了并行收益。尤其是 Decode 阶段对带宽敏感，TP 过大或跨节点时，每次生成 token 都要等待 All-Reduce 完成，导致延迟不降反升。检查通信占比，适度降低 TP，或改用流水线并行。

tensor parallel size 设多少合适？

没有固定值，取决于卡间互联与负载。单机内高速互联可尝试 TP=8，跨节点建议不超过 TP=4，并用 PP 或序列维切分补充。实测对比不同 TP 下的吞吐，选择通信占比低且吞吐最高的配置。

prefill decode 分离是什么意思？

把 Prefill 和 Decode 拆到不同的 GPU 实例上运行，各自独立扩缩容。适合长上下文、共享前缀多的场景，可降低整体时延与通信开销；短请求、低并发时不建议，反而增加调度成本。

8卡推理吞吐上不去，先查什么？

先查各卡利用率是否均衡，再看通信耗时占比。若某卡利用率低而通信高，多半是 TP 过大或跨机通信。然后调整 batch 与上下文参数，最后再动并行切分与引擎版本，一次只改一个变量。

卡间通信瓶颈怎么定位？

用 profiler 统计 NCCL 通信耗时，对比不同 TP 下的吞吐与通信占比。若 TP 增大但吞吐不再提升，说明通信已饱和。同时关注 KV Cache 是否溢出导致跨机取数，那是隐形的通信税。