袁镱-一念 LLM分布式推理优化实践 conv.docxVIP

演讲人：袁镱

大语言模型推理框架

大语言模型推理的基本逻辑 硬件厂商：算子研发上有天然优势，充分利用自家硬件

TensorRT-LLM，MindIE

非硬件厂商：调度和显存管理是研发重点vLLM，SGLang，一念LLM

模型厂商：模型定制算子DeepSeek

DeepSeek-R1爆火为推理框架带来的挑战

理想：假定算子MFU60%，16卡H20的吞吐可以到30K+tokens/s（输入：1812，输出：978tokens）

现实：2025年2月，vLLM，SGLang基本都在2Ktokens/s，优化空间巨大2025年8月，vLLM，SGLang大约7Ktokens/s，TensorRT-LLM11.2Ktokens/s，一念LLM

14.6Ktokens/s，任重道远

一念LLM的研发基础逻辑

判断1：模型推理占据业务逻辑的比重会越来越大。引发“业务快速响应；系统稳定高效”的需求

方案：调度与定制能力自研，深度优化调度与显存管理

判断2：开源模型算子优化上，硬件厂商和模型开发者会深度优化相关算子

方案：开源算子高效引入，支持多种硬件

手写模型优化显存

高效调度提高吞吐

算子择优降低耗时

多硬件支持

DeepSeekR1：KvCache可用显存多130%，吞吐高30%（14.6Kvs11.2K）

大语言模型推理优化中的硬件限制PrefillingTokens DecodingTokens

SequenceTokens

1.计算能力随推理token数增长会逐步增长，并达到硬件上限。再增加只会增加耗时。

2.decode效率低，可以通过增大batchsize和投机解码来增大并行推理token数

3.Sequencetoken数越大，KvCache显存需求越大。会限制batchsize增大。

优化手段之一：在有限的显存条件下，增大推理token数来让各个阶段达到计算能力极限。但是一个阶段达到硬件极限了，就尽量不要再加，避免耗时增加

DeepSeek与推理优化方向

MoE特点：256个路由专家，1个共享专家问题：专家负载不均，算子稀疏

方案：增加并行token数（DP/EP），共享专家多副本

MLA特点：压缩KvCache

问题：额外Proj操作，多卡间CompressedKvCache重复方案：权重吸收，全DP

2025DeepSeek-V3TechnicalReport

假定一台机器4张卡

全TP

MLA和MoE的batchsize相同计算：MoE计算稀疏通讯：MoE通讯多显存：KvCache重复

DP+TP(MoE)MLA和MoE的batchsize不同计算：MoEtoken增多通讯：MLA通讯少，MoE不变显存：KvCache重复减少，权重/buffer增大

DP+EP

MLA和MoE的batchsize差距进一步拉大计算：MoEtoken继续增多，计算稠密通讯：MoE通讯减少显存：状态数据减少，共享专家会导致增大

显存瓶颈导致一般在DP+大EP方案下才有收益

DP+大EP剩余的问题：

1.Prefill+Decode过程混合，性能相互影响

2.Decode阶段权重吸收导致额外的权重显存消耗

3.两阶段对MoE的最佳Batchsize不同（请求的推理tokens数相差巨大）

PD分离：

优点：计算过程单纯，计算同构性好；节省显存；缺点：KvCache同步导致机器间通讯性能要求高；

大并行请求量来打满硬件

高性能大机需求

硬件厂商与云厂商的最爱

这是在往小型机方向走么？互联网的服务不应该是海量和柔性的么？成本怎么降下来？

为什么会这样？

1.所有请求同步执行

2.每层至少两次数据同步

一次推理操作需要61*2=122次跨机同步

优点：只进行2次跨机数据同步问题：单Batch执行，导致硬件资源空闲挑战：1.自回归推理过程保障

2.后期其他并行策略和显存优化策略的兼容

1.共享显存管理的多Batch流水线并行调度

2.多Batch负载均衡

不是什么新技术，这才是流水线并行本该有的样子只是大模型推理有状态（时序和KvCache）让调度变难

Token吞吐：5K 9K

MLA特性：

KvCache在卡间重复冗余

DP：

1.减少KvCache冗余2.并发更多请求

3.减少卡间通讯

DP1 DP4 DP8

冗余度 7 1 0

全DP（一张卡一份DP）：优点：

1.KvCache无冗余2.DP内无同步

3.容易实现高吞吐

挑战：

1.权重的显存需求上涨，侵蚀KvCache显存

2.DP之间负载均衡