NexGPU-算力租赁,GPU服务器,GPU云算力,AI服务器租用-新闻博客 - GPU成本优化
多卡推理优化怎么做？加卡前先算通信税的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）Prefill 与 Decode 均适用，但对带宽敏感每层前向/反向都需要 All-Reduce卡间互联带宽，跨节点时急剧恶化流水线并行（PP）适合模型层数深、显存压力大的场景仅层间传递激活，通信量小流水线气泡（bubble）导致利用率下降序列维切分长上下文、共享前缀场景按序列块切分，稀疏注意力下通信减少序列切分与注意力计算的调度开销张量并行和流水线并行怎么选？简单来说：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 卡推理吞吐上不去时，按下面的次序逐项排查，比乱调参数有效得多：先看各卡利用率是否均衡：是否存在某张卡跑满、其他卡闲置的情况，这通常指向负载不均或同步等待。再看通信占比与同步点：用 profiler 统计 NCCL 通信耗时，若通信占比过高，考虑降低 TP 或改用 PP/序列维切分。调整 batch、并发与上下文上限：在显存允许范围内增大 batch 或上下文，提升计算密度。最后才动并行切分与引擎版本：一次只改一个变量，避免相互干扰。卡间通信瓶颈怎么定位？最直接的方法是跑一段固定负载，对比不同 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 是否溢出导致跨机取数，那是隐形的通信税。