Parallelization Strategies for Dense LLM Deployment: Navigating Through Application-Specific Tradeoffs and Bottlenecks

该论文通过实证研究 Llama-3.1 系列稠密大语言模型，揭示了张量并行（TP）与流水线并行（PP）在降低延迟与提升吞吐量方面的不同优势，并指出通过灵活配置两者的混合策略可有效平衡延迟与吞吐量的权衡，从而满足特定的服务等级协议需求。

要点

这篇论文探讨了一个非常现实的问题：当我们运行像 Llama 3.1 这样巨大的“超级大脑”（大语言模型）时，如何最快地回答问题，同时又能同时处理最多的请求？

想象一下，你开了一家超级繁忙的餐厅（这就是大语言模型推理系统），你的厨师团队（GPU 显卡）非常强大，但你的厨房台面（显存） 却非常小。

1. 核心挑战：厨房太小，菜谱太大

现在的 AI 模型（比如 Llama 3.1-405B）就像一本几亿页厚的百科全书。

• 问题：一本百科全书根本放不进一个普通家庭的厨房台面（单张显卡的内存）。
• 后果：如果你强行把书塞进去，厨房就炸了（内存溢出）；如果你把书拆了，怎么让厨师们配合着把书读完并做出菜（生成答案）？

2. 两种“分餐”策略（并行化方案）

为了解决这个问题，论文研究了两种主要的“分餐”策略，就像管理餐厅的不同方式：

策略 A：张量并行 (Tensor Parallelism, TP) —— “切菜分工法”

• 比喻：想象你要切一个巨大的西瓜。
  • 普通做法：一个厨师切，切得很慢。
  • TP 做法：把西瓜切成 8 块，分给 8 个厨师。每个人切自己那块，切完后大家把切好的块拼起来，再一起切下一刀。
• 优点：因为每个人只切一小块，速度非常快（延迟低）。顾客点菜后，第一口菜（第一个字）能很快端上来。
• 缺点：厨师们需要频繁地互相喊话、传递切好的西瓜块（通信开销）。如果厨师太多，喊话的时间可能比切菜的时间还长，反而拖慢了整体效率。
• 适用场景：适合追求速度的场景，比如你正在和机器人聊天，希望它秒回，不想等。

策略 B：流水线并行 (Pipeline Parallelism, PP) —— “流水线作业法”

• 比喻：想象一条汽车装配流水线。
  • 普通做法：一个工人从头装到尾，装完一辆再装下一辆。
  • PP 做法：把装配过程分成 8 个阶段。工人 A 只负责装轮子，工人 B 只负责装引擎，工人 C 只负责喷漆。
  • 关键点：当工人 A 在装第 2 辆车的轮子时，工人 B 已经在装第 1 辆车的引擎了。大家同时在工作。
• 优点：虽然装好第一辆车（第一个字）的时间并没有变快（甚至因为传递零件稍微慢了一点点），但单位时间内产出的汽车总数（吞吐量）大大增加。
• 缺点：对于单个顾客来说，等待第一口菜的时间并没有缩短。
• 适用场景：适合追求产量的场景，比如你要批量生成 1000 份报告，不在乎第一份报告什么时候出来，只在乎多久能全部做完。

3. 论文发现了什么？（关键结论）

作者通过模拟实验，像做“压力测试”一样，测试了这两种策略在不同情况下的表现：

1. 想要“快”？选张量并行 (TP)

   • 如果你希望用户输入问题后，模型能立刻开始回答（低延迟），TP 是王者。它把计算任务拆分得更细，让每个步骤都跑得飞快。
   • 代价：如果拆分得太细（比如用 8 个显卡），大家沟通的成本太高，反而可能变慢。

2. 想要“多”？选流水线并行 (PP)

   • 如果你希望系统能同时处理成千上万个请求（高吞吐量），PP 是最佳选择。它通过让不同阶段的工人同时干活，极大地提高了整体产出。
   • 代价：单个请求的响应速度提升不明显。

3. 混合策略：左右逢源

   • 最聪明的做法是混合使用：既用 TP 把任务切细（保证速度），又用 PP 把流水线拉长（保证产量）。
   • 这就好比：你既让厨师们分工切菜（TP），又让他们在流水线上同时处理多道菜（PP）。通过调整“切得有多细”和“流水线有多长”，你可以灵活地控制是优先快还是优先多。

4. 现实中的瓶颈

论文还指出了一个有趣的细节：

• 通信是瓶颈：在 TP 策略中，厨师们（显卡）之间传递信息的速度（带宽）至关重要。如果路太堵（网络慢），切得再细也没用。
• 内存是瓶颈：在 PP 策略中，因为每个工人只负责一部分，所以每个人手里的“工作台”（显存）压力小了，可以放更多待处理的订单（更大的批量）。

总结

这篇论文就像给餐厅经理（AI 系统架构师）提供了一份操作手册：

• 如果你开的是高端私房菜（需要极速响应，如实时对话），请多用张量并行 (TP)，把任务切碎，让厨师们拼手速。
• 如果你开的是快餐连锁店（需要海量出餐，如批量处理数据），请多用流水线并行 (PP)，让流水线转起来，追求总产量。
• 如果你两者都要，那就混合使用，根据当天的客流量（请求量）和菜单复杂度（模型大小），动态调整你的“切菜”和“流水线”比例。

这就是这篇论文的核心：没有一种万能的方法，只有最适合你当前需求的“平衡术”。

技术摘要

论文技术总结：稠密大语言模型部署的并行化策略

1. 研究背景与问题 (Problem)

随着生成式人工智能的爆发，基于 Transformer 架构的大语言模型（LLM）应用迅速增长。其中，稠密模型（Dense LLMs）（如 Llama-3.1-70B 和 405B）因其强大的泛化能力、可扩展性和微调便利性，依然是当前先进应用的基础。然而，部署这些拥有数百亿参数的模型面临两大核心挑战：

1. 显存瓶颈：模型权重和动态增长的键值缓存（KV Cache）往往超出单张 GPU 的显存容量，迫使系统采用多卡部署。
2. 延迟与吞吐量的权衡（Latency-Throughput Tradeoff）：
   • 延迟（Latency）：通常由首字延迟（TTFT）和每字延迟（TPOT）衡量，对交互式应用至关重要。
   • 吞吐量（Throughput）：单位时间生成的 Token 数，对批量处理至关重要。
   • 两者通常相互制约：优化一方往往以牺牲另一方为代价。
3. 策略选择的模糊性：现有的并行化策略（如张量并行 TP、流水线并行 PP）及其混合模式，在不同输入特征、批处理大小（Batch Size）和系统配置下，对延迟和吞吐量的具体影响尚缺乏系统性的量化评估。

2. 方法论 (Methodology)

为了深入分析不同并行化策略的权衡，作者开发并验证了一个内部模拟器（In-House Simulator），并在 AMD 的 GPU 硬件上进行了验证。

• 模拟与验证：
  • 模拟器对 LLM 工作负载进行了端到端的建模，包括 Transformer 块中的核心算子（如 Attention, GEMM）。
  • 在单卡（MI325x）和多卡（8x MI325x）环境下，针对 Llama-3.1-70B 和 405B 模型进行了验证。
  • 验证结果：模拟器在预填充（Prefill）和解码（Decode）阶段的延迟预测准确率分别超过 90% 和 86%（针对 70B 模型），能够准确捕捉不同配置下的延迟和吞吐量趋势。
• 评估对象：
  • 模型：Llama-3.1-70B 和 Llama-3.1-405B（FP8/FP4 量化）。
  • 数据集：涵盖短序列（BBH, GSM8K, HumanEval）和长序列（LongAlpaca, MLPerf），以测试不同上下文长度下的表现。
  • 硬件：基于 AMD Instinct MI325x/MI355x GPU 节点，配备高带宽互联。
• 评估指标：
  • 延迟：首字延迟（TTFT）、每输出字延迟（TPOT）。
  • 吞吐量：每秒输出 Token 数（TPS）。
• 策略变量：
  • 张量并行（Tensor Parallelism, TP）：深度（Degree）从 2 到 8。
  • 流水线并行（Pipeline Parallelism, PP）：深度从 2 到 8。
  • 混合并行（Hybrid TP & PP）。
  • 批处理大小（Batch Size）和输入/输出序列长度。

3. 关键贡献 (Key Contributions)

1. 工作负载映射与内核级分析：详细展示了稠密 LLM 工作负载在不同并行化方案（TP, PP, 混合）下的内核级分解及在节点内 GPU 上的映射关系。
2. 多维度的性能量化：利用模拟器，在广泛的并行化配置、批处理策略、输入特征（长短序列）和模型规模下，量化了延迟和吞吐量的变化趋势。
3. 延迟灵活性与权衡分析：
   • 揭示了 TP 和 PP 在延迟灵活性上的本质区别。
   • 识别了限制性能进一步提升的关键瓶颈（如 All-Reduce 通信开销、显存限制导致的批处理上限）。
4. 混合策略的优化指导：证明了通过控制 TP 和 PP 的度（Degree），可以灵活调节延迟与吞吐量之间的平衡，为满足不同服务等级协议（SLA）提供设计依据。

4. 实验结果 (Results)

4.1 延迟灵活性分析 (Latency Flexibility)

• 张量并行（TP）优势：TP 显著降低了 TTFT 和 TPOT。
  • 原因：TP 将 Transformer 层内的计算（如 GEMM 和 Attention）切分到多张卡上并行执行，增加了单个 Transformer 传递的计算资源，特别适合计算密集型（Compute-bound）的预填充阶段。
  • 数据：在 Llama-3.1-70B 上，TP8 比 TP4 和 TP2 快得多（例如在 Batch Size=256 时，Prefill 阶段快 1.87-3.61 倍）。
  • 瓶颈：TP 引入了 All-Reduce 通信开销。随着 TP 深度增加，All-Reduce 的延迟占比增加，但总体上 TP 仍是降低延迟的最佳选择。
• 流水线并行（PP）劣势：PP 无法降低 TTFT 和 TPOT。
  • 原因：PP 将 Transformer 块分布在不同卡上，但每个 Transformer 块的计算资源并未增加（单卡执行整个块）。它主要解决显存问题，而非加速单次推理。
  • 通信影响：PP 的 P2P 通信开销相对于 TP 的 All-Reduce 开销极小，对延迟影响微乎其微（<0.5%）。

4.2 吞吐量权衡 (Latency-Throughput Interplay)

• 流水线并行（PP）优势：PP 显著提升了系统吞吐量（TPS）。
  • 原因：PP 通过分散模型权重，释放了单卡显存用于更大的 KV Cache，从而允许更大的微批处理（Nano-batch）。这使得系统能在解码阶段保持更高的计算利用率，避免显存瓶颈。
  • 数据：在 Llama-3.1-405B 上，PP8 方案相比无并行方案，在 MLPerf 数据集上实现了 13.8 倍的 TPS 提升。
• 张量并行（TP）的吞吐量局限：
  • 虽然 TP 能处理更大的批处理，但由于 All-Reduce 通信开销随 TP 深度增加，其 TPS 提升不如 PP 显著，甚至在某些情况下会因通信延迟而低于纯 PP 方案。
• 混合策略（Hybrid）：
  • 结合 TP 和 PP 可以在保持较低延迟（通过 TP）的同时，利用 PP 增加批处理容量以提升吞吐量。

4.3 通信与硬件影响

• All-Reduce 是 TP 的主要瓶颈：在 TP 深度较大时，All-Reduce 的延迟成为限制 TTFT 提升的关键因素。提升互联带宽（Link Speed）能有效降低延迟，但无法完全消除开销。
• 多节点扩展性：在多节点场景下，节点间通信带宽远低于节点内，All-Reduce 将成为严重的延迟瓶颈，使得 TP 的扩展性受限。

5. 意义与结论 (Significance & Conclusion)

本文通过系统性的实证研究，为稠密 LLM 的部署提供了清晰的指导原则：

1. 策略选择指南：
   • 低延迟场景（如聊天机器人、实时交互）：应优先选择张量并行（TP），尤其是较高的 TP 深度，以最小化 TTFT 和 TPOT。
   • 高吞吐场景（如批量处理、离线分析）：应优先选择流水线并行（PP），因为它能最大化显存利用率，支持更大的批处理，从而显著提升 TPS。
   • 混合场景：采用TP 与 PP 的混合策略，通过调整 TP 度控制延迟，调整 PP 度控制吞吐量，实现最优平衡。
2. 设计启示：
   • 单纯增加并行度并不总是带来线性性能提升，通信开销（特别是 All-Reduce）是主要制约因素。
   • 对于超大模型（如 405B），显存限制是首要问题，PP 在解决显存瓶颈以支持大 Batch 方面比 TP 更具优势。
3. 未来展望：研究结果同样适用于混合专家模型（MoE）和多节点系统，强调了在更复杂的架构和大规模部署中，通信拓扑和并行策略协同设计的重要性。

总结：该论文填补了现有文献在系统评估 LLM 并行化策略对延迟 - 吞吐量权衡影响的空白，证明了TP 是降低延迟的关键，而 PP 是提升吞吐量的关键，并提出了通过混合配置来灵活满足多样化 SLA 需求的解决方案。