多 GPU 推理：Tensor Parallel、Pipeline Parallel 与 Data Parallel 怎么选

多 GPU 推理:Tensor Parallel、Pipeline Parallel 与 Data Parallel 怎么选TL;DR场景:LLM serving 时遇到模型太大单卡放不下或请求太多单卡打不满两类问题时,如何在 TP / PP / DP / EP 之间做选择。结论:按问题排序而不是按名词排序——能单卡放下先 DP 多副本,单卡放不下才考虑 TP,TP 不够再评估 PP/EP,MoE 单看 expert 热点。产出:一张决策顺序清单 一份覆盖短/长 prompt、TTFT/TPOT/P95/P99 的压测矩阵。版本矩阵功能 / 框架状态说明vLLM Tensor Parallel (--tensor-parallel-size)✅ 已验证vLLM 文档明确支持,通过切分单层矩阵到多卡并行计算,每层需 all-reducevLLM Pipeline Parallel (--pipeline-parallel-size)✅ 已验证vLLM 0.5 稳定支持,按层切分到不同卡,推理存在 stage 气泡vLLM Data Parallel(--data-parallel-size)✅ 已验证vLLM 0.7 引入多副本 serving,Router 把请求分发到不同副本TensorRT-LLM Expert Parallelism✅ 已验证NVIDIA 官方文档明确支持 MoE 的 expert 切分,token dispatch / combine 通信SGLang 多卡并行✅ 已验证SGLang 文档支持 TP/PP/DP,提供 RadixAttention 与 prefix cachingHugging Face Transformers Tensor Parallelism✅ 已验证HF Transformers 文档支持层内矩阵切分与分布式推理MoE expert 路由 热点均衡⚠️ 业务相关框架支持,但 expert 负载均衡需按真实 workload 压测,不能默认P/D 分离(Disaggregated Serving)✅ 已验证vLLM、TensorRT-LLM 均支持 prefill / decode 分离,需 KV Cache 传输多 GPU 推理最容易被讲复杂。参数很多,名词很多,框架也很多:Tensor Parallel、Pipeline Parallel、Data Parallel、Expert Parallel、KV Cache、continuous batching、prefix caching、chunked prefill、disaggregated serving。每个词都像一个可选项,但真正做系统设计时,第一步其实很朴素。先判断你面对的是哪一个问题:模型太大,单卡放不下。请求太多,单卡吞吐不够。如果模型太大,就需要把一个模型切到多张 GPU 上,这属于模型并行。Tensor Parallel、Pipeline Parallel、Expert Parallel 都在这个范畴里。如果模型单卡能放下,只是请求量太大,就更应该复制多个完整模型副本,让不同 GPU 或不同 GPU 组处理不同请求。这通常就是推理场景里的 Data Parallel,也可以理解为 replica 扩展。很多系统性能差,不是因为团队不知道这些名词,而是因为一开始就把两个问题混在一起了。明明模型单卡能放下,却过早做 Tensor Parallel,结果每层多了通信,单请求延迟上升,故障域变大;明明模型单卡放不下,却幻想靠多副本解决,最后只是发现每个副本都启动不了。这篇文章不追求把所有并行策略讲成论文综述,而是给一个工程上可执行的选择框架:什么时候复制模型,什么时候切矩阵,什么时候切层,什么时候才需要考虑 MoE 的 expert 切分,以及在 A6000 这类常见多卡机器上,怎样避免把系统做复杂却没有换来真实收益。一、先问两个问题:模型太大,还是请求太多多 GPU 推理的第一原则是:能单卡稳定跑通,就不要急着把一个模型切到多张卡上。单卡部署有几个很朴素的优势。没有跨 GPU 通信,调试路径短,延迟更稳定,故障域更小,压测也更容易解释。一个请求从进入引擎到返回 token,中间少了一层分布式协作,出问题时也更容易判断是调度、显存、KV Cache,还是模型本身。只有两类情况会把你推向多 GPU:第一,模型权重、激活峰值、KV Cache 加起来超过单卡显存。尤其是长上下文、高并发、大 batch、较高精度部署时,KV Cache 可能成为真正的显存压力来源。模型权重是固定的,但 KV Cache 会随着并发、上下文长度和输出长度增长。第二,模型单卡能放下,但单卡的吞吐、延迟或并发能力已经无法满足业务。比如单卡可以跑 14B 模型,但线上请求量较高,单个副本排队时间太长,P95 TTFT 被队列拉高。这时需要扩展的是请求处理能力,而不是把同一个模型拆得更碎。这两个问题对应的解法完全不同。如果是模型太大,核心动作是模型并行:Tensor Parallel 把层内矩阵切开,Pipeline Parallel 把层切到不同 GPU,Expert Parallel 把 MoE expert 分布到不同 GPU。如果是请求太多,核心动作是副本并行:每张 GPU 或每组 GPU 放一个完整副本,Router 把请求分发到不同副本。只要单副本能承载目标上下文和并发,多副本往往比更高的 TP 并行度更稳。所以多 GPU 推理的第一个决策,不是我要用 TP 几,而是我到底是在解决显存问题,还是吞吐问题。二、Data Parallel:推理里最简单、也最容易被低估的扩展方式训练语境里的 Data Parallel 常常意味着每张卡有一份模型副本,处理不同数据,反向传播时同步梯度。但在推理服务里,Data Parallel 更常见的形态就是多副本 serving。每张 GPU 或每组 GPU 部署一个完整模型副本。请求进来后,Router 根据副本状态把请求分发到其中一个副本。副本之间不需要为同一个请求做逐层通信,也不需要每步 all-reduce。每个请求只落在一个副本里完成 prefill 和 decode。它的优点很直接:第一,系统简单。每个副本像一个独立服务,启动、停止、摘流、健康检查都清晰。第二,扩展请求量更自然。如果一个副本能处理一定 QPS,多个副本就可以横向扩展。虽然真实扩展不会永远线性,但在模型能单卡放下的前提下,多副本通常是最容易拿到稳定收益的方式。第三,故障隔离更好。某个副本显存碎片严重、延迟异常或进程崩溃,可以把它从路由池摘掉,不影响其他副本继续服务。第四,请求之间没有跨 GPU 通信。对于低延迟在线推理,这一点非常重要。通信不是免费成本,尤其是在只有 PCIe、没有 NVLink,或者跨机器部署时。Data Parallel 的缺点也同样明确:每个副本都要完整占用一份模型权重显存。如果模型单卡放不下,纯 DP 就没法解决问题。即使模型能放下,KV Cache 也要给每个副本单独预算,不能只看权重大小。一个典型例子是 8 张 A6000 跑 7B 或 14B 模型。如果模型在目标精度、上下文长度、并发和 KV Cache 预算下可以单卡稳定运行,那么 8 个单卡副本通常比一个 8 卡切分模型更容易得到可解释的吞吐和延迟。你也可以对不同副本做滚动升级、灰度、租户隔离和负载均衡,工程自由度更高。因此,Data Parallel 不是低级方案。对大量真实服务来说,它是最优先考虑的生产方案。三、Tensor Parallel:切矩阵,但每层通信会来找你Tensor Parallel 的核心思路是把模型中的大矩阵切到多张 GPU 上并行计算。比如一个线性层的权重矩阵很大,可以按列或按行切分,每张 GPU 负责其中一部分计算,然后通过通信把结果合并。它解决的第一个问题是显存:当模型权重单卡放不下时,把权重分片到多张 GPU 上,模型才有可能启动。它解决的第二个问题是计算并行:大矩阵计算可以被多张 GPU 同时处理,理论上缩短某些计算阶段的时间。但 Tensor Parallel 的关键陷阱在于:并行度越高,不一定越快。每张 GPU 分到的计算减少了,但 GPU 之间的通信增加了。很多层需要 all-reduce、all-gather 或类似通信。如果通信链路足够快,比如同机高带宽互联,TP 的收益会更明显;如果只有 PCIe,或者跨机器通信条件一般,收益可能被通信开销抵消,甚至让延迟变差。这也是为什么 TP 不应该被当成默认加速开关。在推理场景里,TP 对 TTFT 和 TPOT 都可能产生影响。Prefill 阶段有大块矩阵计算,TP 可能提高大计算的并行度,但每层通信也会参与进来。Decode 阶段每次只生成一个或少量 token,计算粒度更小,通信开销在单步延迟里占比可能更明显。对于流式输出,TPOT 和 inter-token latency 的稳定性比平均 tokens/s 更容易被用户感知。所以选择 TP 时要看三件事:单卡是否真的放不下。GPU 间互联是否足够好。不同 TP 并行度下的 TTFT、TPOT、吞吐和显存是否真的更优。如果模型单卡能放下,并且吞吐不够,优先考虑更多 DP 副本,而不是盲目把 TP 从 1 提到 2、4、8。更高的 TP 会让单个副本占用更多 GPU,副本数量减少,路由池变小,故障域变大。只有当显存或计算瓶颈明确指向 TP,且通信条件支持时,它才是合理选择。四、Pipeline Parallel:切层,代价是流水线气泡和单请求路径变长Pipeline Parallel 把模型不同层放到不同 GPU 上。比如一个 40 层模型,GPU0 放前 10 层,GPU1 放 11 到 20 层,GPU2 放 21 到 30 层,GPU3 放 31 到 40 层。一个请求会像流水线一样依次经过各张 GPU。它的优势是进一步降低单卡显存压力。对于层数很多、权重很大、单纯 TP 不够或不合适的模型,PP 可以把模型按层拆开。但 Pipeline Parallel 在在线推理里要谨慎。它天然存在流水线气泡。单个请求从第一段走到最后一段,中间有依赖关系。如果 micro-batch 或并发不够,某些 GPU 会等待。即使吞吐在足够 batch 下能够提高,单请求延迟也可能因为跨阶段路径更长而增加。PP 在训练中更常见,因为训练可以通过 micro-batch 填满流水线,也更容易容忍较长的批处理路径。推理尤其是在线流式推理,更关心 TTFT、TPOT 和尾延迟。一个用户请求如果必须穿过多个 pipeline stage,每个 stage 的排队、计算和通信都会进入端到端延迟。这并不意味着 PP 不能用于推理。对于超大模型,尤其是单机多卡仍然显存紧张的情况,PP 可能是必要手段。只是它通常不是第一选择。更合理的路径是:先看单卡能否部署;不能则考虑 TP;TP 后仍然显存或并行结构不合适,再考虑 PP;如果是 MoE,再单独考虑 Expert Parallel。PP 的压测也不能只看整体 tokens/s。你要看每个 stage 的利用率,是否有 stage 成为瓶颈,batch 变化时气泡是否明显,P95/P99 TTFT 是否被某个 stage 队列拉高,流式输出阶段是否稳定。如果一个 PP 配置在平均吞吐上看起来不错,但 P99 首 token 很差,或者用户看到流式输出持续抖动,那么它不一定是好配置。五、Expert Parallel:MoE 模型才需要重点考虑的并行方式Dense 模型里,每个 token 大致会经过相同的前馈层和注意力结构。MoE 模型不同。它有多个 expert,每个 token 通常只激活其中一部分 expert。Expert Parallel 就是把不同 expert 分布到不同 GPU 上,让 token 根据 router 被发送到对应 expert。这类策略适合 DeepSeek、Mixtral 等 MoE 模型。因为 MoE 的总参数量可能很大,但每个 token 激活的参数量相对较少。把 expert 分布出去,可以承载更大的专家集合,也能让专家计算并行。Expert Parallel 的困难在于通信和负载均衡。token 需要被 dispatch 到对应 expert,计算后再 combine 回来。如果某些 expert 被频繁选中,就会产生热点。不同请求、不同 prompt、不同业务场景会让 expert 负载分布发生变化。对于推理服务来说,这种动态性会影响尾延迟。对普通 Dense 模型,Expert Parallel 通常不是你需要优先考虑的问题。对 MoE 模型,它才是核心 serving 问题之一。生产部署里更常见的不是单独选一种并行,而是组合:TP × DP,必要时再叠加 PP 或 EP。比如你有 8 张 GPU:如果模型单卡能放下,可以做 8 个副本,每个副本 TP1。这是 DP8。如果模型需要 2 张 GPU 才能放下,可以做 4 个副本,每个副本 TP2。这是 DP4、TP2。如果模型需要 4 张 GPU 才能放下,可以做 2 个副本,每个副本 TP4。这是 DP2、TP4。如果模型必须 8 张卡才能跑起来,那么你只有 1 个副本,TP 或 TPPP 占满整机。这时吞吐扩展和故障隔离都会更难,路由层也没有太多副本可调度。这个选择直接影响吞吐、延迟、故障域和运维复杂度。在满足显存的前提下,TP 越小,单副本越简单;DP 副本越多,请求扩展和故障隔离越自然。六、多 GPU 的隐藏成本:通信、KV Cache、路由和故障域多 GPU 推理的瓶颈经常不是有没有更多卡,而是这些卡怎么连、请求怎么调、缓存怎么放、失败怎么恢复。不同并行策略有不同通信成本:Tensor Parallel 每层可能需要 all-reduce 或 all-gather。Pipeline Parallel 需要在层之间传 activation。Expert Parallel 需要 token dispatch 和 combine。Prefill/Decode 分离需要传 KV Cache。如果 GPU 之间有 NVLink 或高带宽互联,通信成本相对可控。如果只有 PCIe,通信可能成为明显瓶颈。如果跨机器部署,就要看 InfiniBand、高性能以太网、网络拥塞和拓扑。跨机器不是不能做,但绝对不能只按GPU 数量估算性能。KV Cache 是另一个容易被低估的成本。长上下文、多并发、长输出都会让 KV usage 上升。即使模型权重能放进单卡,KV Cache 也可能让可服务并发下降。多副本系统里,每个副本都有自己的 KV 空间;P/D 分离或跨节点迁移时,KV 还涉及传输和一致性。Serving 层也不能只做简单轮询。轮询看起来公平,但一个 20K prompt 请求和一个 50 token 请求不是同样负载。更合理的路由要看 running requests、waiting requests、输入 token、max_tokens、KV Cache 使用率、最近 TTFT、最近 TPOT、健康状态,必要时还要结合租户优先级和配额。故障域同样重要。一个 8 卡 TP 副本中任何一张卡异常,整个副本都可能受影响;8 个单卡副本里,一个副本异常可以摘流,剩下 7 个继续服务。并行度越高,单个请求依赖的 GPU 越多,故障传播面越大。所以多卡不是免费加速。每一次并行度提升,都应该换来明确收益:能放下更大的模型,或者在业务指标下更便宜地达到吞吐和延迟目标。七、A6000 多卡机器怎么做更务实A6000 48GB 显存很大,在很多中小模型推理场景里非常实用。但它不是 H100,也不是带完整高端数据中心互联的集群。用 A6000 做多卡推理时,需要更务实地看显存、带宽、互联和业务 SLO。对于 7B、14B 模型,优先评估单卡多副本。只要目标上下文、并发、KV Cache 和精度能放下,单卡副本通常是更稳的方案。它简单、可横向扩展、容易定位问题。对于 32B 模型,先评估量化、max_model_len、KV Cache 预算和真实 workload。能单卡则继续单卡;单卡显存紧张时,再考虑 TP2。不要只用模型权重大小判断,因为上线后的 KV Cache 可能才是决定并发的关键。对于 70B 或 100B 模型,大概率需要多卡切分,常见是 TP2、TP4,或者配合量化。此时要压测不同 TP 并行度下的 TTFT、TPOT、tokens/s、显存、通信带宽和错误率。能启动只是第一步,能稳定服务才是目标。对于 MoE 模型,要单独关注 expert 路由、热点和跨 GPU token dispatch。MoE 的总参数很大、激活参数较少会让推理成本结构和 Dense 模型不同,不能简单套用 Dense 模型的经验。对于语音链路,ASR、LLM、TTS 最好不要随意混在同一张 GPU 上。它们的延迟特征不同,互相干扰后问题很难排查。语音场景尤其关心首字延迟和 token streaming 稳定性,平均吞吐好看并不代表用户体验稳定。更务实的路线通常是:单卡跑通,先把 serving、监控、prompt、KV 预算打稳。模型能单卡放下时,优先多副本扩展。模型放不下时,再引入 TP。TP 不够或模型结构需要时,再评估 PP、EP。每一步都用压测数据验证,而不是靠并行度想象性能。八、压测方法:别只测短 prompt多 GPU 配置最终不是理论题,而是压测题。你不能只测固定短 prompt,也不能只看平均 tokens/s。至少要构造几类 workload:短 prompt 短输出:模拟普通问答。短 prompt 长输出:模拟写文章、代码生成。长 prompt 短输出:模拟 RAG 问答。长 prompt 长输出:模拟文档总结、复杂 Agent。混合 workload:模拟真实线上流量。每类 workload 都要看 TTFT、TPOT、P95/P99、tokens/s、GPU util、显存、KV usage、通信带宽、错误率。对于多副本,还要看副本间负载是否均衡。对于 TP/PP/EP,还要看通信和阶段热点。对于语音或实时助手,还要额外关注 token 间隔的抖动,而不是只看整段完成时间。一个实用判断清单是:如果模型权重加 KV Cache 能放进单卡,并且单卡吞吐够用,就优先单卡。如果模型能放进单卡,但请求太多,就优先 Data Parallel 多副本。如果模型放不进单卡,就考虑 Tensor Parallel。如果 Tensor Parallel 后单卡显存仍然不够,或者层切分更适合模型结构,再考虑 Pipeline Parallel。如果是 MoE 模型,再重点评估 Expert Parallel、专家热点和 token dispatch。如果 TPOT 高,要看 decode batch、KV Cache 访问、通信开销和 GPU 显存带宽。如果 TTFT 高,要拆 prefill 排队、prefill 执行、长 prompt、路由、TP 通信和 prefix caching 命中率。如果 GPU util 不高但吞吐低,可能是 batch 不够、调度不合理、CPU 或网络喂不饱。如果 GPU util 高但吞吐仍低,可能是显存带宽、KV Cache、通信或模型结构成为瓶颈。最终选择不是并行度最大,而是在业务 SLO 下成本最低、故障域可控、监控可解释的方案。结论:多卡选择的顺序,比名词更重要多 GPU 推理的核心不是背并行策略,而是按问题排序。模型单卡能放下,请求太多,优先 Data Parallel 多副本。模型单卡放不下,再考虑 Tensor Parallel。Tensor Parallel 仍不够或模型结构需要,再考虑 Pipeline Parallel。MoE 模型再重点看 Expert Parallel。并行度越高,通信、路由、KV Cache、监控和故障域越复杂。对多数工程团队来说,最稳的路线是:单卡跑通,serving 稳定;再做多副本;最后才做复杂模型切分和分布式调度。不要让多卡本身成为目标。真正的目标是:在明确的 TTFT、TPOT、吞吐、成本和可运维性约束下,用最简单的结构把服务跑稳。参考资料vLLM Documentation: https://docs.vllm.ai/vLLM Documentation, Parallelism and Scaling: https://docs.vllm.ai/en/stable/serving/parallelism_scaling/vLLM Blog,Anatomy of a High-Throughput LLM Inference System: https://vllm.ai/blog/2025-09-05-anatomy-of-vllmHugging Face Transformers, Distributed Inference: https://huggingface.co/docs/transformers/en/perf_infer_gpu_multiHugging Face Transformers, Tensor Parallelism: https://huggingface.co/docs/transformers/en/perf_infer_gpu_multi#partitioning-a-modelNVIDIA TensorRT-LLM Documentation: https://nvidia.github.io/TensorRT-LLM/NVIDIA TensorRT-LLM Performance Best Practices: https://nvidia.github.io/TensorRT-LLM/performance/perf-best-practices.htmlNVIDIA TensorRT-LLM Expert Parallelism: https://nvidia.github.io/TensorRT-LLM/advanced/expert-parallelism.htmlSGLang Documentation: https://docs.sglang.ai/错误速查卡症状根因定位修复单卡明明能放下,却一上来就 TP4,延迟反而变差把流量问题当容量问题处理,层内 all-reduce 通信吃掉了并行收益跑 TP1 / 2 / 4 对比 TTFT / TPOT;看每步通信耗时占比回退到 TP1 DP 多副本,把通信变成副本间独立TPOT 高 / 抖动大Decode 阶段计算粒度小,通信占比敏感;或 KV Cache 访问 / 显存带宽成瓶颈关闭 TP 对比 TPOT;看 GPU 显存带宽、KV usage、nvidia-smi 通信计数器降 TP 平行度 / 升 NVLink / 优化 KV 访问;或回到多副本PP 配出来了,但 P99 TTFT 很差流水线气泡 最慢 stage 拉高尾延迟,平均吞吐看着好拆每个 stage 的排队 / 计算 / 通信时间;看 P95/P99 拉高来自哪一段调整 micro-batch / 改 TP 为主 / 拆 stage 平衡负载MoE 服务尾延迟不稳热点 expert 被频繁命中,部分 GPU 排队严重监控 expert 路由分布、token dispatch / combine 耗时启用 expert 负载均衡策略;按业务路由分散 prompt 类型;必要时升 EP 平行度短 prompt 压测漂亮,长 prompt 上来就 OOMKV Cache 在长上下文 高并发下暴涨,显存预算按权重估的跑长 prompt workload 看 KV usage 峰值;对比 prefill 阶段显存曲线降 max_model_len / 升量化 / 拉高并发上限;或 TP2 切分跨机部署吞吐不随卡数线性增长PCIe / 网络互联带宽成瓶颈,通信等计算对比同机 vs 跨机 TTFT / TPOT;看 InfiniBand 带宽利用率改同机部署 / 升级到 NVLink 或更高带宽网络;或重新设计并行拓扑8 卡 TP 副本里一张卡掉线,整个服务不可用故障域随 TP 平行度放大,单点故障 整副本失效看副本编排是否支持 sub-replica failover;模拟卡故障改用 TP2 × DP4 拆成多个小副本,提升隔离性Router 轮询看似公平,但 P95 TTFT 仍然差20K prompt 与 50 token 请求在轮询下被同等对待,长 prompt 拖慢副本看 running requests / waiting requests / KV usage 路由指标Router 接入 token-aware KV-aware 健康状态调度GPU util 不高但吞吐低batch 喂不饱 / CPU 预处理慢 / 网络 IO 阻塞拆 GPU util / CPU util / IO util,看瓶颈环节升并发 / 优化 prompt 预处理 / 检查 tokenize 与网络 pipeline量化后能放下,但生成质量明显退化量化策略与模型 / 部署不匹配(如 INT4 配 MoE)A/B 对比同 prompt 输出的稳定性与一致性升 INT8 / GPTQ-AWQ 切换 / 仅 KV 量化 / 关键路径保留高精度作者:武子康的个人博客