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

《袁镱-一念 LLM分布式推理优化实践.pdf》由会员分享，可在线阅读，更多相关《袁镱-一念 LLM分布式推理优化实践.pdf（15页珍藏版）》请在三个皮匠报告上搜索。

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

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

3、ng Tokens1.计算能力随推理token数增长会逐步增长，并达到硬件上限。再增加只会增加耗时。2.decode效率低，可以通过增大batch size和投机解码来增大并行推理token数3.Sequence token数越大，KvCache显存需求越大。会限制batch size增大。优化手段之一：在有限的显存条件下，增大推理token数来让各个阶段达到计算能力极限。但是一个阶段达到硬件极限了，就尽量不要再加，避免耗时增加DeepSeek与推理优化方向2025 DeepSeek-V3 Technical ReportMoE特点：256个路由专家，1个共享专家问题：专家负载不均，算子稀疏方

4、案：增加并行token数（DP/EP），共享专家多副本MLA特点：压缩KvCache问题：额外Proj操作，多卡间CompressedKvCache重复方案：权重吸收，全DP全TPMLA和MoE的batchsize相同计算：MoE计算稀疏通讯：MoE通讯多显存：KvCache重复DP+TP(MoE)DP+EP假定一台机器 4 张卡MLA和MoE的batch size不同计算：MoE token增多通讯：MLA通讯少，MoE不变显存：KvCache重复减少，权重/buffer增大MLA和MoE的batch size差距进一步拉大计算：MoE token继续增多，计算稠密通讯：MoE通讯减少显存：

5、状态数据减少，共享专家会导致增大显存瓶颈导致一般在DP+大EP方案下才有收益DP+大EP剩余的问题：1.Prefill+Decode过程混合，性能相互影响2.Decode阶段权重吸收导致额外的权重显存消耗3.两阶段对MoE的最佳Batchsize不同（请求的推理tokens数相差巨大）PD分离：优点：计算过程单纯，计算同构性好；节省显存；缺点：KvCache同步导致机器间通讯性能要求高；大并行请求量来打满硬件高性能大机需求硬件厂商与云厂商的最爱这是在往小型机方向走么？互联网的服务不应该是海量和柔性的么？成本怎么降下来？为什么会这样？1.所有请求同步执行2.每层至少两次数据同步一次推理操作需要

6、61*2=122次跨机同步优点：只进行2次跨机数据同步问题：单Batch执行，导致硬件资源空闲挑战：1.自回归推理过程保障1.共享显存管理的多Batch流水线并行调度不是什么新技术，这才是流水线并行本该有的样子只是大模型推理有状态（时序和KvCache）让调度变难Token吞吐：5K9K2.多Batch负载均衡2.后期其他并行策略和显存优化策略的兼容KvCache在卡间重复冗余1.减少KvCache冗余2.并发更多请求3.减少卡间通讯MLA特性：DP：DP 1DP 4DP 8