很多人一提到大模型多卡推理第一反应就是把tensor_parallel_size调大觉得卡越多、模型切得越细吞吐就越高。但真实线上系统里Tensor ParallelTP往往首先带来的不是“免费加速”而是更频繁的卡间通信、更敏感的硬件拓扑、更复杂的调度边界以及更难处理的长尾延迟。尤其在 vLLM、TensorRT-LLM、SGLang 这类推理引擎里TP 的问题从来不只是“模型能不能放下”而是“放下之后值不值得这样跑”。本文从工程视角系统拆解TP 在推理阶段到底切了什么、通信发生在哪、为什么单机 NVLink 和 PCIe 机器的体感完全不同、为什么很多场景下TP8反而不如TP2 × 4 副本以及如何把 TP 和 KV Cache、Continuous Batching、请求路由、性能分析串成一套可落地的方法论。目录为什么多卡推理优化经常一上来就走偏先建立一个判断框架TP 解决什么又牺牲什么Tensor Parallel 在 Transformer 里到底切了什么通信发生在哪Attention、FFN 和集合通信原语通信量怎么估别只说有 AllReduce为什么训练里的 TP 经验不能直接照搬到推理Prefill 和 DecodeTP 收益模型完全不同硬件拓扑NVLink、PCIe、跨机 RDMA 的差异为什么 TP 开大后吞吐不一定升P99 反而变差TP 与 KV Cache、Continuous Batching 的耦合关系vLLM、TensorRT-LLM、SGLang 中如何理解 TP工程选型TP1、TP2、TP4、TP8 到底怎么选部署矩阵不同模型规模和硬件条件怎么落地压测方法不能只拿固定短 prompt 跑 tokens/s性能分析如何判断瓶颈已经从显存变成通信排障案例TP8 为什么不如 TP2 × 4 副本工程落地最容易踩的坑面试里如何讲清楚 TP 的价值和边界学习路线与实践建议总结1. 为什么多卡推理优化经常一上来就走偏很多人刚接触大模型多卡推理时脑内模型通常很简单单卡显存不够。所以需要多卡。多卡就开 Tensor Parallel。卡越多并行度越高吞吐应该越好。这个推理链条最大的问题是它把“模型能部署”和“服务跑得好”混成了一件事。在工程里这两个问题完全不同。模型能部署关注的是权重能不能放进 GPUruntime buffer 是否足够CUDA graph、workspace、临时 activation 是否还有余量KV Cache 是否有基本空间服务跑得好关注的是用户首 token 延迟是否低每 token 生成速度是否稳定并发上来以后 P95/P99 是否可控GPU 是否真的在做有效计算通信是否吞掉了原本的计算收益调度器是否还有空间接新请求TP 的作用主要是让模型“能切开、能放下、能并行计算一部分层内矩阵”。但它不是一个纯收益开关。TP 一打开你立刻引入了跨 GPU 同步TP 开得越大参与同步的 rank 越多通信路径越复杂长尾越容易被放大。所以在多卡推理里一个更准确的判断方式是TP 是用通信换显存、用同步换单卡压力、用拓扑约束换模型规模。如果你只看到了显存下降没有看到通信上升就很容易把系统从一个瓶颈推到另一个瓶颈。2. 先建立一个判断框架TP 解决什么又牺牲什么在深入细节之前先建立一个简单的工程判断框架。TP 主要解决三类问题。第一类是权重显存问题。例如 70B 模型用 BF16 权重大约需要 140GB 量级显存单张 80GB 卡放不下就必须切到多卡。第二类是单层计算规模问题。Transformer 中 QKV、输出投影、FFN 升维/降维矩阵都很大。TP 可以把这些大矩阵切到多张卡上让每张卡只负责其中一部分。第三类是 KV 和 runtime 空间问题。TP 降低每卡权重占用以后每张卡可能有更多显存留给 KV Cache、batch、临时 buffer。这一点对长上下文推理尤其关键。但 TP 也带来三类代价。第一类是通信代价。每个 Transformer Block 中Attention 和 FFN 的某些位置需要汇总各卡结果。这个通信不是偶尔发生而是每层、每次前向都会发生。第二类是同步代价。通信通常是后续计算的依赖点。某张卡慢一点、某条链路抖一下整个 TP group 都可能一起等。第三类是部署代价。TP group 最好落在同一高速互联域内。你需要考虑 GPU 拓扑、NUMA、PCIe switch、NVLink、NIC 亲和性甚至 Kubernetes 或 Ray 的调度策略。所以 TP 的核心问题可以抽象成一句话TP 的收益来自显存和局部计算压力下降TP 的成本来自高频通信和同步长尾。只要你围绕这句话分析大多数多卡推理问题都能讲清楚。3. Tensor Parallel 在 Transformer 里到底切了什么很多文章说 TP 是“把模型切到多张卡上”这句话太粗。真正要理解 TP需要看 Transformer Block 内部。一个典型 Decoder-only Transformer Block 可以简化成x - RMSNorm / LayerNorm - QKV Projection - Attention - Output Projection - Residual - RMSNorm / LayerNorm - FFN up / gate - activation - FFN down - ResidualTP 最主要处理的是里面的线性层也就是大矩阵乘法QKV ProjectionAttention Output ProjectionFFN up / gate ProjectionFFN down Projection3.1 Column Parallel LinearColumn Parallel Linear 可以理解为按输出维度切权重。假设原始线性层是Y XW X: [tokens, hidden] W: [hidden, output] Y: [tokens, output]如果按列切 WW [W0, W1, W2, W3]每张 GPU 只算一部分输出Y0 XW0 Y1 XW1 Y2 XW2 Y3 XW3这时每张卡得到的是输出向量的一段。只要后续操作也能按这一段独立处理就可以暂时不通信。这个策略非常适合 QKV 投影和 FFN 的 up/gate因为这些操作之后往往还能继续在分片维度上做本地计算。3.2 Row Parallel LinearRow Parallel Linear 可以理解为按输入维度切权重。假设输入已经被切成X [X0, X1, X2, X3]权重也对应按行切W [W0; W1; W2; W3]每张卡算一个局部贡献Y0 X0W0 Y1 X1W1 Y2 X2W2 Y3 X3W3最终完整输出是Y Y0 Y1 Y2 Y3这里就需要一次归约通常是 AllReduce 或等价变体。3.3 为什么 Attention 和 FFN 都适合 TPAttention 适合 TP是因为多头结构天然可拆。不同 head 在 attention 计算的前半段基本独立可以把不同 head 分给不同 GPU。FFN 适合 TP是因为它通常是“先升维、再降维”的结构。中间维度很大参数量占比高。通过 column parallel row parallel 的组合可以让中间激活在本地分片上计算最后再归约。这就是为什么 TP 经常和 Transformer 结构绑定在一起讨论。它不是随便把张量切开而是利用了模型结构中的可并行点。4. 通信发生在哪Attention、FFN 和集合通信原语TP 真正难的地方不是“切”而是“切完之后怎么合”。在一个 Transformer Block 中常见通信点可以粗略理解为Attention 输出投影后需要汇总FFN down projection 后需要汇总某些实现中还会在输入、输出或序列并行切换位置出现 AllGather / ReduceScatter不同框架会有不同的融合和调度实现但工程直觉基本一致每个 Block 前向通常会出现若干次激活相关的集合通信。4.1 AllReduceAllReduce 的含义是每张卡都有一个局部结果大家做归约最后每张卡都拿到完整归约结果。在 TP 中它经常用于把 row parallel linear 的局部输出求和。可以粗略理解为rank0: partial_out_0 rank1: partial_out_1 rank2: partial_out_2 rank3: partial_out_3 AllReduce(sum) rank0/1/2/3 all get: partial_out_0 partial_out_1 partial_out_2 partial_out_3这个操作的特点是同步性强。后续层需要完整输出所以不能随便跳过。4.2 AllGatherAllGather 是把每张卡的一部分数据收集起来让所有卡都拿到完整数据。在一些并行策略里如果某个阶段需要从分片状态回到完整状态就可能用到 AllGather。AllGather 的直觉是rank0: shard_0 rank1: shard_1 rank2: shard_2 rank3: shard_3 AllGather rank0/1/2/3 all get: [shard_0, shard_1, shard_2, shard_3]4.3 ReduceScatterReduceScatter 可以看作 AllReduce 的一半先归约再把结果分片给不同 rank。它常用于一些更细的并行策略比如序列并行或为了减少激活冗余的场景。理解这三个原语不是为了背 API而是为了在看 profile 时能判断到底哪类通信在耗时通信的数据量大概来自哪个张量是否有机会通过切分策略、batch 策略或拓扑绑定降低成本5. 通信量怎么估别只说有 AllReduce面试和工程讨论中一个常见问题是大家只说“TP 有通信”但说不清通信量跟什么有关。在推理前向里TP 通信通常和激活大小相关而激活大小大致由下面几个因素决定activation bytes ≈ batch_tokens × hidden_size × dtype_bytes其中batch_tokens在 prefill 和 decode 阶段含义不同。5.1 Prefill 阶段的 batch_tokensPrefill 处理的是 prompt所以batch_tokens可能是一个 batch 内所有 prompt token 的总数。例如batch 内有 8 个请求 每个 prompt 平均 4096 token batch_tokens ≈ 32768这时激活张量很大但 GEMM 也很大。通信量大计算量也大通信有机会被大计算摊薄。5.2 Decode 阶段的 batch_tokensDecode 每步通常只处理每个请求的新 token。例如当前活跃请求数 64 每个请求本步只生成 1 个 token batch_tokens ≈ 64这时激活张量比 prefill 小很多但 GEMM 也小很多。通信延迟、kernel launch、同步等待会变得更明显。5.3 一个简化估算假设hidden size 8192dtype BF162 bytesdecode 活跃 batch 64单次通信张量大小约为64 × 8192 × 2 bytes ≈ 1MB1MB 看起来不大但问题是它会在很多层、很多步里反复发生。如果模型有 80 层每层两个主要通信点那么每个 decode step 可能有上百次通信相关同步。实际框架会做融合、调度和优化但这个估算能说明一个事实decode 里的 TP 通信不一定大但非常频繁而且同步敏感。这也是为什么小消息延迟、rank 抖动、PCIe 拓扑会影响 TPOT 和 P99。6. 为什么训练里的 TP 经验不能直接照搬到推理训练里也用 TP为什么到了推理就要更谨慎核心原因是训练和推理的目标函数不一样。6.1 训练更关心长期吞吐训练常见目标是每秒处理更多 token更高 MFU多卡长时间稳定运行用更大的 global batch 提高硬件利用训练通常 batch 更大计算图更完整forward backward 的时间更长通信也更有机会和计算 overlap。6.2 推理同时关心吞吐和交互体验推理的目标更复杂TTFT 要低TPOT 要稳P99 不能炸高并发下不能频繁排队流式输出要平滑用户不会只关心系统总共生成了多少 token。用户更关心“什么时候开始返回”和“返回过程中有没有卡顿”。6.3 Decode 阶段放大了同步问题自回归 decode 是一步一步生成 token。每一步都依赖上一步输出每一步都要读历史 KV每一步都要过完整模型。如果 TP 在每一步都引入跨卡同步那么它就不是一次性成本而是每个 token 都要支付的成本。训练可以用大 batch 和长图摊薄很多通信推理里的 decode 更容易把同步开销暴露出来。所以更准确的说法是训练中的 TP 主要服务于模型规模和训练吞吐推理中的 TP 同时受模型规模、时延目标、请求分布和拓扑条件约束。7. Prefill 和 DecodeTP 收益模型完全不同LLM 推理必须拆成 prefill 和 decode 两个阶段看。很多 TP 误判都来自把这两个阶段混在一起。7.1 Prefill 阶段Prefill 做的是处理输入 prompt计算整段上下文的 KV Cache。它的特点是序列长度可能很长GEMM 更大Attention 计算更密集TTFT 受它强烈影响对于长 prompt 场景prefill 的计算量很大。TP 可以把大矩阵计算拆到多卡上某些情况下收益比较明显。例如 RAG 请求带了 32K token 文档prefill 会处理大量 token。此时如果单卡计算压力很高TP 可能有效降低 TTFT。7.2 Decode 阶段Decode 做的是每次生成一个新 token。它的特点是每步 token 数少强依赖历史 KVHBM 访问和 KV 管理很重要TPOT 和流式输出体验受它影响Decode 阶段的单步计算规模小TP 通信更容易成为显性成本。尤其当请求输出很长时每个 token 都支付一次 TP 同步成本总成本会被放大。7.3 三类业务的差异不同业务对 TP 的态度应该不同。第一类是长 prompt、短输出。例如文档问答输入 32K token输出 300 token。瓶颈更偏 prefillTP 可能改善首 token 延迟但要注意 KV 容量。第二类是短 prompt、长输出。例如写作、代码生成、推理链较长的任务。瓶颈更偏 decodeTP 通信税会持续累积。第三类是短 prompt、高并发短输出。例如普通聊天、分类、简单问答。这类场景如果模型单卡能放下多副本往往比大 TP 更稳定。所以做 TP 选型时不能只说“这个模型多大”还要问prompt 长度分布是什么样output 长度分布是什么样prefill 占总时间多少decode 占总时间多少业务更敏感 TTFT 还是 TPOT8. 硬件拓扑NVLink、PCIe、跨机 RDMA 的差异TP 是层内高频通信所以对硬件拓扑极度敏感。同样是TP4在不同机器上的表现可能完全不同。8.1 NVLink / NVSwitch 环境NVLink / NVSwitch 是 TP 比较理想的环境。特点是GPU 间带宽高通信路径稳定多 GPU 间拓扑更均衡高频 AllReduce 更容易承受很多 H100、A100 高端服务器上的 TP 经验默认是在这种环境下成立的。此时TP4、TP8的通信成本虽然存在但更容易被强互联和大计算掩盖。8.2 PCIe 环境PCIe 环境下做 TP 要谨慎很多。常见问题包括GPU 间带宽明显低于 NVLink不同 GPU pair 之间路径可能不同可能跨 PCIe switch可能跨 NUMAGPU 到 NIC 的亲和性会影响跨机通信在这种环境里TP 更像是“为了放下模型不得不做”而不是“天然提升吞吐”。例如 L20、L40S、部分消费级或工作站级 GPU 集群如果没有 NVLink盲目开大 TP 很容易让通信变成瓶颈。8.3 跨机 RDMA / IB / RoCE 环境跨机 TP 最需要慎重。它不是不能做而是成本和稳定性要求都更高。跨机 TP 意味着每层内部通信可能经过网络一旦网络抖动P99 会被直接放大。跨机 TP 需要考虑RDMA 链路是否稳定RoCE 是否有丢包、重传、PFC/ECN 配置问题NCCL 拓扑识别是否正确每个 TP group 是否固定在网络条件较好的节点组合上是否有更好的替代方案比如节点内 TP 跨节点 DP工程上更常见的原则是节点内做 TP节点间做请求级 DP 或 pipeline/PD 等其他架构尽量避免把高频层内同步放到跨机网络上。9. 为什么 TP 开大后吞吐不一定升P99 反而变差很多线上压测会出现这样的结果TP1 - TP2吞吐提升显存压力下降 TP2 - TP4吞吐提升变小P99 开始变差 TP4 - TP8平均吞吐没明显提升P99 明显上升这并不奇怪。9.1 收益递减TP 越大每张卡负责的权重越少单卡计算压力会下降。但下降不是无限线性的。到了某个点单卡计算已经不是主要瓶颈继续增加 TP size节省的计算时间很少新增的通信和同步时间却变得更明显。这就是收益递减。9.2 通信参与者增加TP group 越大参与集合通信的 rank 越多。即使总通信量公式看起来还可以实际系统里也会受到拓扑不均衡小消息延迟rank 间负载差异NCCL 算法选择其他进程干扰这些因素影响。9.3 长尾被同步放大TP group 是一个同步共同体。某个 rank 慢了其他 rank 也要等。这对 P99 很不友好。平均值可能看起来还可以但长尾会明显变差。9.4 副本弹性变差假设有 8 张 GPU。部署方案 ATP8 × 1 replica部署方案 BTP2 × 4 replicas方案 A 只有一个服务副本所有请求都进入同一个大 TP group。调度弹性差任何局部抖动都会影响整体。方案 B 有 4 个副本。每个副本的通信范围更小请求可以在副本之间分散。即使某个副本排队router 还可以把请求打到其他副本。这就是为什么在不少业务里TP2 × 4比TP8 × 1更稳。10. TP 与 KV Cache、Continuous Batching 的耦合关系TP 不是一个孤立参数。它和 KV Cache、Continuous Batching、请求调度强耦合。10.1 TP 会改变每卡显存结构不开 TP 时每张卡放完整权重。开 TP 后每张卡只放一部分权重。这会释放一部分显存用于KV Cacheruntime buffer更大的 batch更长上下文所以 TP 可能间接提高并发能力。但要注意TP 释放的是“权重占用”不是无限释放所有显存。长上下文场景下KV Cache 仍然可能成为主要显存大户。10.2 TP 会影响 Continuous Batching 的有效收益Continuous Batching 的目标是让 GPU 持续有活干动态加入和移除请求。但如果 TP 通信成为瓶颈那么 batch 拼得再好也可能被同步成本限制。一个典型现象是batch size 看起来不小GPU utilization 看起来也不低但 decode tokens/s 上不去NCCL time 占比明显上升这时问题可能已经不是调度器不够聪明而是 TP 通信在吃掉收益。10.3 TP 会影响 KV Cache 的部署边界TP 下 KV Cache 通常也会按并行方式分布在不同 GPU 上。不同框架具体实现不同但工程上需要关注KV 是否按 head 分片GQA/MQA 对 KV 分片有什么影响prefix cache 是否能在当前 TP 配置下复用更换 TP size 后 KV 是否兼容PD 解耦或 KV transfer 是否要求相同并行配置这类细节在简单 demo 里不明显在线上系统和多副本调度中会变得很重要。11. vLLM、TensorRT-LLM、SGLang 中如何理解 TP不同推理框架对 TP 的封装不同但底层 trade-off 是一样的。11.1 vLLMvLLM 里常见配置包括vllm serve /models/Qwen \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --gpu-memory-utilization 0.88 \ --enable-prefix-caching \ --enable-chunked-prefill这里--tensor-parallel-size只是多卡推理的一部分。vLLM 的强项在于PagedAttentionContinuous BatchingPrefix CachingChunked PrefillOpenAI API 兼容生态但这些能力不能让 TP 通信消失。你仍然要评估TP group 是否在合理拓扑内TP size 是否过大decode 阶段 NCCL 时间是否过高多副本是否比大 TP 更稳11.2 TensorRT-LLMTensorRT-LLM 更强调高性能推理路径kernel 融合图优化quantization 支持多 GPU execution mapping更低层的优化空间它能把很多执行路径做得更极致但仍然受限于通信与拓扑。如果你在一个 PCIe 互联较弱的环境里强开大 TPTensorRT-LLM 也不能把物理带宽变成 NVLink。所以 TensorRT-LLM 的 TP 选型同样要看mapping 是否合理rank 是否绑定在高速互联域是否可以通过更低精度权重或 KV 降低 TP 需求是否可以用多 engine 副本替代过大的 TP group11.3 SGLangSGLang 更容易让人关注复杂请求和前缀复用radix cachelongest prefix matchstructured generation更灵活的调度策略长上下文和 Agent 场景在 SGLang 场景里TP 还要和 prefix reuse 一起看。如果业务中有大量共享前缀例如相同 system prompt相同工具 schema相同 RAG 文档多轮 Agent 共享上下文那么路由策略比单纯 TP size 更重要。请求打到哪个 worker会影响 prefix cache 命中率prefix cache 命中率又会影响 prefill 压力prefill 压力又会影响 TP 的收益判断。这也是推理系统复杂的地方引擎参数、缓存命中、路由策略、硬件拓扑是一起工作的。12. 工程选型TP1、TP2、TP4、TP8 到底怎么选下面给一套比较实用的判断流程。12.1 第一步先问单卡能不能跑如果单卡能跑而且还有足够 KV 空间优先考虑TP1 × 多副本原因是没有 TP 通信副本调度简单P99 更容易控制横向扩展更清晰适合7B / 8B量化后的 14B / 32B短上下文高并发服务普通聊天类服务12.2 第二步单卡跑不稳再考虑 TP2TP2 是很多工程场景里的第一档折中。它的优点是显存压力下降明显通信范围仍然较小更容易绑定在同一 PCIe switch 或 NVLink pair 内多副本组合仍然灵活适合单卡放不下但两卡能放下的模型BF16 质量优先的 32B 类模型需要保留较大 KV 空间的长上下文服务12.3 第三步TP4 用于更大模型或更强显存需求TP4 常用于70B 级模型单机 4 卡或 8 卡内分组较强 NVLink / NVSwitch 环境对模型质量要求高不能过度量化但在 PCIe 环境中TP4 就需要认真压测。12.4 第四步TP8 要非常谨慎TP8 通常只有在下面条件满足时才更合理模型规模确实需要单机 8 卡高速互联良好NVLink / NVSwitch 拓扑稳定业务能接受更复杂的长尾风险压测证明 TP8 比 TP4 × 2 或 TP2 × 4 更好如果只是为了“看起来用满 8 卡”TP8 很容易变成吞吐和稳定性的负担。12.5 一个简单选型表场景优先方案原因7B/8B短上下文TP1 多副本避免不必要通信14B单卡可放TP1 多副本或量化调度弹性好32BBF16 质量优先TP2 或 TP4平衡显存与通信32B接受量化TP1/TP2 多副本减少 TP 依赖70B单机 NVLinkTP4/TP8主要解决承载问题70BPCIe 机器TP4 起步压测通信风险较大跨节点部署节点内 TP 跨节点 DP避免高频跨机 TP13. 部署矩阵不同模型规模和硬件条件怎么落地为了更工程化可以把模型规模、硬件拓扑和业务类型放到一个部署矩阵里。13.1 单机 8 卡 NVLink / NVSwitch这类机器适合较激进的 TP。可选策略7B/14BTP1 多副本32BTP2 × 多副本或 TP470BTP4 / TP8长上下文TP FP8 KV Chunked Prefill Prefix Cache注意点即使 NVLink 很强也要看 decode P99不要只看峰值 tokens/s如果 TP8 收益不明显优先拆成多个小 TP 副本13.2 单机 8 卡 PCIe这类机器要保守。可选策略能单卡放下就单卡多副本32B 优先 TP2而不是直接 TP4/TP870B 可以 TP4 起步但必须压测 P99TP group 尽量绑定在拓扑相近的 GPU 上注意点先跑nvidia-smi topo -m关注 PCIe switch 与 NUMA避免把 TP group 放在跨 socket 路径上13.3 多机多卡多机环境更推荐单机内 TP 跨机器 DP / routing / service replica也就是说每台机器内部跑一个或多个 TP group跨机器通过 router 分发请求不把每层 TP 通信放到跨机网络上只有在模型极大、硬件网络极强、团队有成熟 NCCL/RDMA 运维能力时才考虑跨机 TP。14. 压测方法不能只拿固定短 prompt 跑 tokens/s很多错误结论来自错误压测。如果你只拿固定 128 token prompt、固定 128 token output 跑平均 tokens/s很容易得出“TP 越大越好”的片面结论。真实压测应该覆盖请求分布。14.1 至少分四类请求短 prompt 短输出 短 prompt 长输出 长 prompt 短输出 长 prompt 长输出原因是短 prompt 短输出更考验调度和低延迟长 prompt 短输出更考验 prefill短 prompt 长输出更考验 decode长 prompt 长输出会同时压 prefill、KV 和 decode14.2 要测混合负载线上请求不会排队等你按类别发。真实服务里长短请求会混在一起。所以压测要模拟80% 短聊天 20% 长 RAG50% 普通问答 50% 代码生成高峰时少量超长上下文请求插入多租户优先级不同这类混合负载最容易暴露 TP 和调度之间的问题。14.3 指标要分层看用户层TTFTTPOTE2E latencyP95 / P99timeout rate引擎层prefill tokens/sdecode tokens/sactive sequenceswaiting queue lengthKV cache usageprefix cache hit rate系统层GPU memorySM utilizationHBM bandwidthNCCL timePCIe / NVLink / RDMA traffic业务层prompt length distributionoutput length distributiontenant-level latencyshared prefix ratio只有这些指标一起看才能判断 TP 是否真的有效。15. 性能分析如何判断瓶颈已经从显存变成通信TP 常见的一个现象是它解决了显存问题但引入了通信瓶颈。怎么判断15.1 看显存变化如果开 TP 后每卡权重下降KV 余量增加OOM 减少最大并发上升说明 TP 确实缓解了显存瓶颈。但这只是第一步。15.2 看 decode 延迟如果同时出现TPOT 上升P99 上升decode tokens/s 没有按预期提升说明 TP 可能开始拖慢 decode。15.3 看 NCCL 时间如果 profile 里看到NCCL kernel 时间占比上升AllReduce / AllGather 等待明显rank 间耗时不均GPU 计算 kernel 中间出现很多通信空洞那就基本可以判断通信瓶颈已经显性化。15.4 看拓扑相关性如果换一组 GPU结果明显变化说明拓扑影响很大。例如GPU 0,1 做 TP2P99 正常 GPU 0,7 做 TP2P99 明显变差这通常意味着两张卡之间路径不同可能跨 switch 或跨 NUMA。15.5 看副本拆分是否改善一个非常实用的验证方法是对比TP8 × 1 TP4 × 2 TP2 × 4如果 TP size 变小、副本变多后 P99 明显改善而总吞吐不降甚至上升说明之前大 TP 的通信和同步成本过高。16. 排障案例TP8 为什么不如 TP2 × 4 副本下面构造一个典型案例。16.1 背景硬件单机 8 张 PCIe GPU 每张 48GB 显存 无 NVLink模型32B Instruct BF16 质量优先 上下文 16K业务普通聊天 RAG 混合 P95 prompt 8K P95 output 1K初始部署TP8 × 1 replica16.2 初始现象压测发现模型能跑OOM 很少平均 tokens/s 看起来还可以但 P99 很差流式输出偶尔卡顿NCCL 时间占比高GPU utilization 不稳定这说明模型承载问题解决了但服务体验不稳定。16.3 排查路径第一步看 prefill 和 decode 分段指标。发现TTFT 在长 prompt 下高TPOT 在高并发下抖动decode 阶段 NCCL 时间占比明显第二步看拓扑。发现 8 张卡之间并不是完全等价部分 GPU pair 路径跨 PCIe switch。第三步改部署组合。尝试TP4 × 2 replicas TP2 × 4 replicas第四步对比混合负载。结果可能是部署平均吞吐TTFTTPOTP99稳定性TP8 × 1中等一般抖动差差TP4 × 2较好较好较稳中等中等TP2 × 4好好稳好好这不是说 TP2 永远最好而是说明在这类硬件和负载下大 TP 的通信成本超过了它带来的收益。16.4 最终方案可能采用TP2 × 4 replicas router 按请求长度分发 长 prompt 单独限流 启用 chunked prefill 启用 prefix cache 监控 NCCL time、TTFT、TPOT、P99如果 32B 模型可以接受权重量化也可以进一步尝试TP1 × 更多副本这就是工程里的真实取舍不是让某个参数最大而是让整体系统最稳。17. 工程落地最容易踩的坑17.1 只看模型是否能加载模型能加载只是开始。真正要看服务是否能在目标并发和目标上下文下稳定运行。17.2 只看平均吞吐平均 tokens/s 很容易掩盖 P99 问题。用户体验经常先坏在长尾。17.3 不看 prefill / decode 分段如果不拆分 TTFT 和 TPOT就不知道问题到底在长 prompt prefill还是 decode 通信。17.4 不做拓扑绑定TP group 随机落卡是很多性能抖动的来源。尤其 PCIe 机器上要尽量让 TP group 落在拓扑更近的 GPU 上。17.5 盲目跨机 TP跨机 TP 对网络质量、NCCL 配置、运维能力要求很高。大多数业务优先考虑节点内 TP 跨节点 DP。17.6 忽略 KV CacheTP 释放权重显存以后不代表 KV 问题消失。长上下文、高并发、多轮对话仍然可能被 KV Cache 卡住。17.7 不做真实业务压测固定长度 prompt 的 benchmark 不能代表线上负载。真实业务的长尾分布才是系统稳定性的关键。18. 面试里如何讲清楚 TP 的价值和边界如果面试官问“大模型推理里为什么要用 Tensor Parallel”可以这样答TP 主要是为了解决单卡承载不了模型或单层矩阵太大的问题。它把 Attention 和 FFN 里的大矩阵按维度切到多张 GPU 上每张卡计算一部分结果然后在关键位置通过 AllReduce 或 AllGather 汇总。这样可以降低每卡权重显存和局部计算压力也能给 KV Cache 留出更多空间。如果面试官继续问“那为什么不能直接把 TP 开得越大越好”可以继续答因为 TP 的代价是层内高频通信。每个 Transformer Block 的前向里Attention 和 FFN 后面通常都会有通信点。推理阶段尤其 decode 阶段每生成一个 token 都要过完整模型所以这些通信会反复发生。TP size 越大参与同步的 rank 越多对拓扑越敏感P99 越容易被最慢链路或最慢 rank 放大。如果问“你会怎么选 TP size”可以答我会先判断单卡能不能稳定放下模型、runtime buffer 和目标 KV 空间。如果单卡能跑优先多副本 DP如果单卡放不下从最小可行 TP 开始比如 TP2。然后结合硬件拓扑尽量把 TP group 放在单机高速互联域内。最后用真实请求分布压测 TP1、TP2、TP4、TP8 的组合不只看平均吞吐还要看 TTFT、TPOT、P99、NCCL 时间和 KV 使用率。如果问“为什么跨机 TP 风险大”可以答因为 TP 是层内高频同步跨机意味着每层的部分通信要经过网络。网络延迟、抖动、丢包、RDMA 配置都会直接放大到推理 P99。除非模型规模和硬件条件确实要求否则我更倾向于节点内 TP跨节点做请求级 DP 或服务副本扩展。一个更完整的总结话术是我理解的 TP 不是一个单纯的加速参数而是一种用通信换显存和模型规模的并行策略。它的收益在于让模型放得下、让单卡计算压力下降、让 KV 有更多空间它的代价在于每层通信、decode 同步和拓扑敏感。工程选型时不能只问 TP 开多大而要结合模型规模、硬件互联、prompt/output 分布、TTFT/TPOT 目标和多副本调度能力综合判断。19. 学习路线与实践建议如果想系统掌握 TP 推理优化可以按下面路线走。19.1 先学 Transformer 结构重点不是背公式而是理解Attention 的 QKV 投影Multi-Head Attention 为什么能按 head 切FFN 为什么参数量大SwiGLU 中 gate/up/down 的矩阵结构Residual 和 Norm 对并行边界有什么影响19.2 再学集合通信至少搞懂AllReduceAllGatherReduceScatterRing AllReduceTree AllReduceNCCL 的基本作用能画出数据流能说清通信量大概和什么相关。19.3 再看 Megatron 风格 TP重点看Column Parallel LinearRow Parallel LinearAttention head 切分FFN 切分每个 Block 的通信插入点这部分是理解推理 TP 的基础。19.4 再看推理系统重点看Prefill / DecodeKV CachePagedAttentionContinuous BatchingPrefix CacheChunked Prefill因为推理 TP 不只是模型并行还和调度、缓存、请求生命周期强相关。19.5 最后做实验建议做一个小实验选一个支持多卡的开源推理框架。固定模型和机器。分别跑 TP1、TP2、TP4。准备短 prompt、长 prompt、混合并发三类 workload。记录 TTFT、TPOT、P99、GPU 利用率、NCCL 时间。分析什么时候 TP 变大开始收益递减。这个实验比单纯背概念有价值很多。因为它能让你真正看到 TP 的 trade-off。20. 总结Tensor Parallel 是 LLM 多卡推理里的核心技术但它不是“卡越多越快”的简单按钮。从工程角度看TP 的本质是用卡间通信换单卡显存压力用同步成本换模型规模用拓扑约束换部署可能性。它的收益主要体现在大模型能放下单卡权重压力下降局部矩阵计算被拆分KV Cache 可能获得更多显存空间它的代价主要体现在每层高频通信decode 阶段同步成本明显对 NVLink / PCIe / RDMA 拓扑敏感P99 容易被最慢 rank 或最慢链路放大部署和排障复杂度上升成熟的推理系统不会只问tensor_parallel_size 应该设多大而是会问在当前模型规模、硬件拓扑、请求长度分布、KV 压力和时延目标下 TP 带来的显存与计算收益是否足以覆盖它引入的通信和同步成本如果单卡能放下优先考虑多副本如果必须 TP从最小可行值开始如果要跨机先证明网络和 P99 扛得住如果 TP 开大后吞吐不升反降就回头看 NCCL 时间、decode TPOT、拓扑绑定和副本拆分。这才是 TP 在 LLM Serving 里的真实工程问题。