张量并行、流水线并行和数据并行怎样选择？

Distributed serving process architecture。用于辅助理解本题的数据流或工程结构。

图：用于辅助理解本题的数据流或工程结构。来源：Distributed serving process architecture，作者 vLLM Project contributors，许可 Apache-2.0。

考察意图

面试官希望确认候选人能否解释“张量并行、流水线并行和数据并行怎样选择”中的因果关系，并把公式或流程落实到可测量的工程结果。

60–90 秒口述答案

张量并行把单层矩阵切到多卡，每层都有集合通信，适合单卡放不下或需要降低单请求延迟且节点内互联快；流水线并行按层切分，通信量较小但有气泡，适合跨节点和超大模型；数据并行复制模型处理不同请求，最利于吞吐和故障隔离。实践常组合 TP×PP×DP。

深入解释

总 GPU 数=TP×PP×DP。TP 通信频繁且随层数累积；PP 的利用率受 microbatch 与 stage 平衡影响；DP 需要每副本完整模型或与 TP/PP 组合。

白板回答时先声明输入规模、张量或请求状态，再推到输出与瓶颈；不要只罗列术语。

工程权衡

先由权重+KV+workspace 判断最小切分，再按 NVLink/PCIe/IB 拓扑选择。Decode 小矩阵下通信占比更高；跨节点盲目加 TP 可能更慢。容量规划还需考虑副本故障域和 KV Cache 的会话粘性。

关键指标包括：TTFT、TPOT/ITL、端到端 P50/P95/P99、tokens/s、并发、队列时间、显存水位与单位 token 成本。

完整复习答案

先拆开一次请求

围绕“张量并行、流水线并行和数据并行怎样选择”，推理题需要把排队、Prefill 和逐 token Decode 分开。GPU 算力、显存容量、内存带宽与调度空槽可能同时成为约束，一个总体吞吐数字无法定位瓶颈。

用数量级定位瓶颈

70B FP16 权重约 140GB，单张 80GB GPU 放不下。两卡 TP 可以容纳，但每层需要高速集合通信；若跨节点只有较慢网络，可考虑节点内 TP、节点间 PP，再用 DP 复制整组服务提高吞吐和故障隔离。

这个估算给出量级。代入项目参数时需要写明忽略项，并保持单位一致。

压测应回答什么

围绕“张量并行、流水线并行和数据并行怎样选择”，压测写明模型、dtype、并行度、硬件、输入输出长度分布和到达方式，同时报告 TTFT、TPOT、端到端尾延迟、tokens/s 与显存水位。容量取满足 SLO 的安全点。

追问参考

吞吐提升但 P99 变差，调度器可能做了什么？

对“张量并行、流水线并行和数据并行怎样选择”而言，吞吐提高而 P99 变差通常来自更大批次、更长等待窗口或 Prefill 抢占 Decode；查看 queue time、batch token 数和每阶段时间即可区分。

OOM 是权重、激活、临时 workspace 还是 KV Cache 导致？

回到“张量并行、流水线并行和数据并行怎样选择”，需要区分：OOM 要按权重、KV、激活、workspace 与碎片拆账，并用输入/输出长度、并发和块水位复现，不能只归因于“模型太大”。

怎样判断方案已经达到上线条件？

“张量并行、流水线并行和数据并行怎样选择”进入发布方案前，性能结论需绑定硬件、dtype、模型、并行度、长度分布、并发模型和 SLO；离线峰值不能直接当线上容量。

常见错误回答

只复述“张量并行、流水线并行和数据并行怎样选择”涉及的术语，没有说明输入、运算和输出之间的关系。
讨论分布式推理时省略模型规模、数据分布或硬件条件，使结论失去适用范围。
只讲收益，没有检查 Tensor Parallel、Pipeline Parallel 带来的精度、资源或可靠性代价。

连续追问

若改变 Tensor Parallel 的关键配置，哪些中间量会先发生变化？
如何设计对照，检验观察到的差异是否来自分布式推理？
哪类输入或负载最容易使这一方案失效？

项目结合

准备一个与分布式推理直接相关的测量或排障案例。讲清基线、异常指标、被排除的假设和最终判定；没有亲历时，说明会采集哪些数据，不虚构结果。

复习自测

能否脱离笔记解释张量并行、流水线并行和数据并行怎样选择的关键运算？
能否把文中的数量级例子换成自己的模型或业务参数？
能否指出一种不适用场景，并给出可观测的判定条件？