一念 LLM分布式推理优化实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. 演讲人：袁镱

3. 大语言模型推理框架大语言模型推理的基本逻辑硬件厂商：算子研发上有天然优势，充分利用自家硬件 TensorRT-LLM，MindIE 非硬件厂商：调度和显存管理是研发重点 vLLM，SGLang，一念LLM 模型厂商：模型定制算子 DeepSeek DeepSeek-R1爆火为推理框架带来的挑战理想：假定算子MFU60%，16卡H20的吞吐可以到30K+ tokens/s（输入：1812，输出：978 tokens）现实：2025年2月，vLLM，SGLang基本都在2K tokens/s，优化空间巨大 2025年8月，vLLM，SGLang大约7K tokens/s，TensorRT-LLM 11.2K tokens/s，一念LLM 14.6K tokens/s，任重道远

4. 一念LLM的研发基础逻辑判断1：模型推理占据业务逻辑的比重会越来越大。引发“业务快速响应；系统稳定高效”的需求手写模型方案：调度与定制能力自研，深度优化调度与显存管理高效调度判断2：开源模型算子优化上，硬件厂商和模型开发者会深度优化相关算子方案：开源算子高效引入，支持多种硬件优化显存提高吞吐算子择优降低耗时多硬件支持 DeepSeek R1：KvCache可用显存多130%，吞吐高30%（14.6K vs 11.2K）

5. 大语言模型推理优化中的硬件限制 Prefilling Tokens Decoding Tokens Sequence Tokens 1. 计算能力随推理token数增长会逐步增长，并达到硬件上限。再增加只会增加耗时。 2. decode效率低，可以通过增大batch size和投机解码来增大并行推理token数 3. Sequence token数越大，KvCache显存需求越大。会限制batch size增大。优化手段之一：在有限的显存条件下，增大推理token数来让各个阶段达到计算能力极限。但是一个阶段达到硬件极限了，就尽量不要再加，避免耗时增加

6. DeepSeek与推理优化方向 MoE 特点：256个路由专家，1个共享专家问题：专家负载不均，算子稀疏方案：增加并行token数（DP/EP），共享专家多副本 MLA 2025 DeepSeek-V3 Technical Report 特点：压缩KvCache 问题：额外Proj操作，多卡间CompressedKvCache重复方案：权重吸收，全DP

7. 假定一台机器 4 张卡全TP MLA和MoE的batch size相同计算：MoE计算稀疏通讯：MoE通讯多显存：KvCache重复 DP + TP(MoE) MLA和MoE的batch size不同计算：MoE token增多通讯：MLA通讯少，MoE不变显存：KvCache重复减少，权重 /buffer增大 DP + EP MLA和MoE的batch size差距进一步拉大计算：MoE token继续增多，计算稠密通讯：MoE通讯减少显存：状态数据减少，共享专家会导致增大显存瓶颈导致一般在DP+大EP方案下才有收益

8. DP + 大EP剩余的问题： 1. Prefill+Decode过程混合，性能相互影响 2. Decode阶段权重吸收导致额外的权重显存消耗 3. 两阶段对MoE的最佳Batchsize不同（请求的推理tokens数相差巨大） PD分离：优点：计算过程单纯，计算同构性好；节省显存；缺点：KvCache同步导致机器间通讯性高性能大机需求能要求高；硬件厂商与云厂商的最爱大并行请求量来打满硬件

9. 这是在往小型机方向走么？互联网的服务不应该是海量和柔性的么？成本怎么降下来？为什么会这样？ 1. 所有请求同步执行 2. 每层至少两次数据同步一次推理操作需要 61*2 = 122次跨机同步

10. 优点：只进行2次跨机数据同步问题：单Batch执行，导致硬件资源空闲挑战：1. 自回归推理过程保障 2. 后期其他并行策略和显存优化策略的兼容 1. 共享显存管理的多 Batch流水线并行调度 2. 多Batch负载均衡不是什么新技术，这才是流水线并行本该有的样子只是大模型推理有状态（时序和KvCache）让调度变难 Token吞吐：5K 9K

11. MLA特性： KvCache在卡间重复冗余 DP： 1. 减少KvCache冗余 2. 并发更多请求 3. 减少卡间通讯冗余度 DP 1 DP 4 DP 8 7 1 0 全DP（一张卡一份DP）：优点： 1. KvCache无冗余 2. DP内无同步 3. 容易实现高吞吐挑战： 1. 权重的显存需求上涨，侵蚀KvCache显存 2. DP之间负载均衡需求大方案： 1. 显存管理精细化，buffer复用（之前就省出了130%） 2. DP/MultiBatch PP混合调度 Token吞吐：9K 14.6K

12. 进行中：EP，PD分离为什么先做了PP？在H20上EP，PD分离更容易触碰到算力天花板在H800上必须要做才能获得性能优势进行中： Q1. 调度策略与业务场景如何适配？ A1: 吞吐优先，响应优先柔性KvCache匹配 Q2. 是不是每层都要用相同的精度？ A2: 权重/KvCache分层量化 Q3. Batch之间流程是否可以并行？ A3: Multi-Stream并行 Q4. 多模态模型还有哪些可优化点？ A4: 持续优化中 Q5. 国产卡支持情况？ A5: 部分模型支持昇腾，持续更新中

13. 一念LLM，取“一念三千”之意，寓意“一念之间，用大模型生成世间万象”。一念LLM开源地址 GitHub： https://github.com/Tencent/KsanaLLM

14.

15.