腾讯一念LLM新版本发布：硬刚核心调度，满血版DeepSeek推理吞吐提升48%

前言DeepSeek-R1发布后推理框架加速需求暴涨。在最近四个月中各个开源框架vLLMSGLangFlashInfer等针对DeepSeek进行专项优化性能提升了2-3倍。经过四个月的开发一念发布了0.6.0支持了DeepSeek模型和分布式推理。针对PCG业务的特殊需求GPU资源供应灵活性要求高的特点一念实现了流水线并行PP的multi-batch分布式推理方式。相对业界常见的多机DPEP方案跨机通讯量降低98.3%机器之间通讯可以使用TCP大大降低运营难度。然而即便使用TCP进行机器间通讯一念的吞吐达到9084 tokens/s比业界开源框架高48%。一念LLM取“一念三千”之意寓意“一念之间用大模型生成世间万象”。Github开源地址 https://github.com/Tencent/KsanaLLM简介在业务数据的测试集总共512条平均输入1812 tokens输出978 tokens上我们经过理论推算如果两台H2016卡部署fp8满血版Deepseek吞吐的保守上限是18000 tokens/s。在2月底开源vllm/sglang的吞吐1400 tokens/s和2200 tokens/s存在巨大的优化空间。经过4个月的快速迭代后vllm/sglang最新版都上升到6100 tokens/s左右。同一时期一念从不支持Deepseek和分布式推理达到当前的9084 tokens/s发布0.6.0版本。其中主要的性能优化来源于两个方面1PP支持multi-batch并发执行相比多机DP数据并行EP专家并行方案跨机通讯量降低98.3%而且多个batch之间异步通讯大大降低了机器间网络抖动对整体性能的影响2通过显存的精细化管理留给kv-cache的可用显存增加137%可以进行更多的请求并行执行。PP在运营上有很多优秀的特点1没有节点同构的要求可以随意的卡数和卡型组合。2由于流水线并行节点之间通讯量低且都是异步通讯GPU机器之间的互联性能要求很低。这些特点都给到底层GPU资源调度运营更大的自由空间。PP支持multi-batch并不是一个创新是PP在经典定义中就应该有的特性我们在大模型推理框架ContinuousBatching投机解码等新兴技术背景下将经典重现。在大模型推理中使用PP是针对当前硬件条件和业务需求的设计选择和优化。H20相比H100计算性能相差10倍英伟达B系列性能更强而业界主流开源框架都源于美国设计和开发重点都在英伟达最强的硬件上从而很容易导致与我们特定情况的技术错配。我们有必要从实际的硬件条件出发结合业务的特点继续探索更合理的推理调度方案。当前性能只是勉强达到保守的理论上限的50%仍然有非常大的优化空间我们也看到还有很多优化工作可以做。比如目前使用的是TPPP的方式叠加EPDP后还会有不错的吞吐提升不管是计算还是通讯的算子很多都没有充分发挥硬件性能PD分离能够进一步降低权重和kv-cache对显存的消耗这些技术正在开发和优化中敬请期待后续发布。下面会首先介绍一下一念的研发思路然后结合现有方案的优缺点介绍PP的multi-batch支持。一. LLM的推理逻辑以及一念的研发思路。在介绍相关内容之前我们先简单回顾一下大语言模型推理的基础逻辑大致可以用下图来简单理解。当一个新请求被加入后会由调度器为新请求分配显存并与现有请求组装成batch交给下一步进行Forward操作。在Forward完成后通过Sampling得到一个token的输出。如果还需要继续输出则返回调度器进入下一个周期重复图中2-5步直到模型生成结束符或者到达用户设定的长度限制。这个过程中涉及到的模块我们大致可以分为三类调度与执行引擎。调度器会在请求级别管理计算和存储两种资源。在Forward中会有一个执行器来调度算子级别的计算和存储资源。不同的推理框架基于不同的设计理念会在这些模块选择不同的方案。算子。由于大语言模型结构相对固定算子优化的可复用性很高。各个框架会相互借鉴算子实现来让提升算子利用硬件的能力。定制/探索性功能。在大模型应用中由于模型推理过程占据了业务服务的主要耗时业务不再满足于看到生成结果后再处理而是希望控制token生成的过程。在整个生成过程的循环中常见的控制点在采样前和采样后。比如通过采样过滤功能限制输出token的选择范围。通过结构化输出控制输出结果的模式以及用特定的小模型或者逻辑来执行投机解码对特定业务场景进行推理加速。对于一念的研发路径选择我们基于两个基本判断:随着模型能力的增强模型推理占据业务逻辑的比重会越来越大。如果“模型即应用”这个比例会趋向100%。业务特性会在推理框架中越来越多地体现出来。框架需要有对业务需求快速的响应能力。由于定制化功能与资源调度息息相关要实现业务的快速响应并维持框架的持续迭代对调度和定制化功能的设计和研发进度需要有足够的控制力。开源模型算子优化上硬件厂商和模型开发者会深度优化相关算子。比如英伟达深度介入FlashAttention的新版本开发华为将ATB作为一个单独模块提供出来DeepSeek在其开源周上公布了多个DeepSeek相关的算子库迅速被各个开源框架采纳。所以为了掌握调度模块的控制权一念在立项之初放弃了基于开源框架进行二次开发的路线而是选择了自研调度和定制化功能模块。对于算子采用了多来源择优的策略这样即便开源框架迭代迅速一念通过在算子层面借鉴只要打平业界性能就能在调度上保持针对业务优化的额外收益。二. 技术介绍由于需要开发核心模块而开发人力有限需求排期上以业务主要使用的中小模型上的优化为主线导致DeepSeek-R1这样需要多机推理的大模型的支持上漏球。经过4个月的努力一念发布0.6.0在Deepseek满血版推理上吞吐达到了9084 tokens/s超过vllm/sglang最新版48%。这个过程中团队进行了大量细致的优化比如代码重构算子调优缓存优化等这些都是魔鬼细节这里就不一一讲述了。下面主要分析大家常听到的TP/DP/EP/PD分离技术再介绍PP实现multi batch并行推理的工作。2.1 TPDPEP和PD分离TPDPEP和PD分离是当前大模型推理中经常被提到的技术。我们首先看看单机情况下不同的TP/DP/EP组合有什么区别。这里以Deepseek的一层的推理为例我们大致可以将一层模型的推理分为Attention和FFN两个阶段Deepseek模型在两个阶段的模型结构分别是MLA和MoE。这两个阶段都会读取大量的参数权重并进行大量计算。为了让多张GPU卡并行执行这些操作TPTensor Parallelism将一个权重tensor切分到多张GPU卡上然后对应权重的计算也被分到了多张卡上。TP操作之后需要将这些切片的结果通过all reduce操作合并起来。所以我们可以看到在MLA和MoE之后都有all reduce的操作。为了便于后面描述DP我们将Attention部分的TP叫做Attention Tensor ParallelismATP。ATP4表示4张卡来执行一个Attention部分的Tensor并行操作。而TP专指MoE部分的tensor并行TP4表示4张卡来执行MoE部分的Tensor并行操作。图a中就是ATP4TP4的工作模式。在Dense模型的时候Attention和FFN的计算量差距不大。当MoE结构兴起后FFN阶段的计算量发生了很大的变化。以前MLP的结构会处理全部的tokenMoE的每个专家只会处理一部分token专家越多每个专家处理的token越少。比如Deepseek v3有256个专家每个专家只会处理batch中8/256的token。如果batch size是256在decoding阶段的时候一个专家只会处理8个token会造成巨大的计算资源浪费。而batch size的增长主要受限于kv-cache的显存消耗Deepseek的MLA结构会在ATP内的多张卡使用到相同的kv-cache数据所以需要ATP越小冗余的kv-cache拷贝越少。然而MoE需要更多的卡并行计算让batch size越大越好。于是就有了数据并行Data Parallelism的设计。有多份MLA的拷贝一份Data和Tensor每个拷贝内的ATP比较小而DP拷贝数越多MoE部分的TP就越大MoE部分的batch size也越大。DP拷贝的数量增大后TP的值可能超过单机的卡数就会导致另外一个问题在TP机制下每个专家计算输入和结果都是独立的切片数据专家数越多切片越多。而由于专家路由逻辑的特点切片不是均匀的导致融合多个专家的算子形成更高效计算的难度很大。加上共享专家机制的加入导致算子优化的难度上升以及通讯碎片。于是有了EPExpert Parallelism的方案通过将不同Expert分配到不同卡上这样只需要将batch中的token按照专家路由的结果发送到具体Expert上然后Expert将自己要计算的tokens收集起来就能进行整块数据的计算。通讯成本也更低。另外大模型推理分为Prefilling和Decoding两个阶段两个阶段推理的token数量有巨大的差异。一个请求在Prefilling阶段可能几K或者几十K个token同时推理而Decoding阶段只会有一个或者几个token在推理。所以为了达到MoE阶段GPU充分利用的目标两个阶段的batch size需求是不同的。在DeepSeek-V3的论文中Prefilling阶段是8路DP而Decoding阶段是80路DP。而且推理框架还会针对两种阶段会定制不同的算子以达到更优的计算效率。另外在Deepseek的设计中为Decoding阶段专门定制了权重吸收的计算逻辑WA-MLAweight-absorb MLA而权重吸收机制有独立的一份WA-MLA的权重如果在相同的卡上执行Prefill和Decode阶段流程多出来的一份权重会让留给kv-cache的显存更少直接影响吞吐。可以看出TP/DP/EP和PD分离的机制都是围绕一层模型的推理性能进行优化在多机情况下会有更好的单层耗时。然而在需要多机部署的时候都会导致每层计算中都有多次全局的数据交换和同步。以Deepseek-R1为例总共61层那么生成一个token就需要至少61*2次全局数据交换。在这种高频同步的情况下任何一个节点的计算性能问题或者网络通讯抖动都会形成木桶短板。为了避免高频同步通讯对推理性能的影响DPEP方案部署对多机互联网络的性能有很高的要求比如同路由器高速互联。业界采用这个方案大规模部署的基本都是使用Nvidia InfiniBand网络或者能够有相近性能的互联方案。需要基础设施团队与推理平台团队紧密协同增加了运营的复杂度。2.2 流水线并行PP通过分析TP/DP/EP和PD分离的技术会有几个疑问不管是H20还是机器间高性能互联都是以前训练集群的硬件配置。作为推理服务为什么一定要像小型机一样的高性能高可靠的硬件才能跑得好。互联网的服务不应该是海量和柔性的么成本怎么降下来如果要打造一个皮实的系统那么对于机型和网络这两项硬件的容忍度就必须需要提升。在可接受性能损失内减少高频的机器间同步操作就是一个自然的选择。沿着这个思路很容易想到的就是一个经典的但是在大模型推理领域少有被提及的流水线并行技术。以两个节点为例一个batch的流水线并行推理的流程如下从上面的示意图我们可以看出1优势是a. 实现简单跨机通讯小。以61层的Deepseek R1模型为例DP/TP/EP每层都需要进行至少两次HiddenState的同步通讯而PP只需要进行两次HiddenState的传输那么在双机情况下PP的传输量只有TP或DP方案的1/61。b. 运营灵活度高。对于不同计算能力的节点可以通过调整负载来保障整个流水线的顺利执行。比如计算慢的节点就分配少一点的层一般DP/EP方案的部署都要求卡数是2的倍数而PP完全没有这个限制。2弱势也是非常明显的。如果只能运行一个batch在ForwardLayer占据主要计算量的情况下会导致GPU算力只能用起来 1/pppp是流水线并行节点数造成巨大的GPU资源浪费。或者说如果batch调度不畅也很容易形成空泡。大模型的自回归推理流程下有状态的异步控制比较麻烦现有框架基本都把研发重点放在了DP/EP和PD分离这些同步方案上。流水线并行的实现也都只能运行一个batch或者说支持了多batch的实际效果也不好。经典的流水线并行就是要通过多个batch将多个资源充分利用起来。在大模型的推理过程中由于kv-cache的引入大模型自回归的推理生成过程是有状态的所以流水线并行的multi batch调度会稍微复杂一些。在大模型训练加速的领域早就遇到过类似的问题。现在的训练框架都会将一个大batch拆分成多个小batch的方式来执行。在多个小batch流水线执行后GPU空闲时间就显著变少了。如下图所示图片来源Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LMEfficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM与训练流程相比大模型自回归的推理流程有以下特点。1训练流程需要有一个Pipeline flush操作来同步更新模型参数。在推理流程中模型参数是不更新的。需要保证的只是请求的自回归流程正常。2训练流程中每个batch中样本使用的次数是确定的。而大模型推理过程中由于请求进入batch的时间不同输出长度的不同会导致batch随时可能有请求加入和退出。如果batch之间执行时间差异大就会导致执行时间长的batch卡住执行时间短的batch从而让其他环节的GPU空闲。我们在压力测试中观察到这个部分的空闲可能导致整体吞吐30%的下降。于是一念针对这两个特点有了以下的设计。1MultiBatch自回归流程我们期望的执行流程如下图所示为了尽量不影响现有逻辑和后期DP/EP的开发我们采用了一个相对简单的线程模型。以多线程方式执行多个batch每个batch的调度和执行流程控制都在一个线程中完成每个线程保证自己所负责batch的自回归流程的正确性。计算资源通讯资源和存储资源都被池化由多个batch线程自由竞争。2batch动态负载均衡针对大模型推理中存在batch内请求随时进入和退出的问题我们需要在原来continous batching技术的基础上增加batch间负载均衡的策略。在每次调度过程中负载均衡器都会尝试按照某个策略对batch的负载进行均衡。这个策略决策的主要因素是请求数推理计算的token数推理序列长度与算子性能之间的关系。优化目标是调整请求数推理token数推理序列长度让所有batch的执行耗时均匀同时每个batch的算子耗时最优。3layer offload机制在前面的分析中我们会发现master节点需要做调度embedding lookuplmheadsampling等操作用户的定制操作投机采样等操作也都在master上。为了不让master节点成为流水线上的计算瓶颈我们还提供了layer offload机制通过将一部份层分配给worker节点来降低master节点上推理的模型层数从而降低master节点的负载。2.3 性能情况测试数据我们采用从业务线上采集的请求作为测试集。总共512条平均输入1812 tokens输出978 tokens。测试硬件两台机器共16张96GB版本的H20。测试模型Deepseek-R1 0528权重格式fp8测试方法以不同的QPS向被测试服务发送请求采集token吞吐TTFTTPOT数据。测试结果首先我们看到两个框架的Token吞吐在小QPS的时候都保持一致的上升趋势。当QPS超过2之后SGLang逐步达到饱和吞吐也趋于稳定。从TTFT的数值上也可以看出SGLang在QPS2之后因为请求堆积而导致排队首token的输出时间暴涨。与此同时我们看到一念的吞吐还在逐渐增长在QPS10的时候达到了8823 tokens/s。而一念的P99 TTFT值在QPS8之后才开始有较大的增长。如果是不考虑TTFT的批处理场景一念到达9084 tokens/sSGLang能到6119 tokens/s。】如果观察TPOT的数值我们会发现一念的TPOT值一直高于SGLang。在低QPS的时候我们看到一念的TPOT值相对SGLang一直有13ms的偏差。主要有两方面的原因1一念在当前版本使用的是TCP通讯发送和接收方都需要在内存和显存之间拷贝数据。2一念目前的算子性能还未打平SGLang最新版本。这两块都是明确的问题正在优化会在稍后的版本中更新。在QPS高的情况下两者TPOT的差距达到了50ms左右。这里的增加量主要是由于batch size变大使得通讯量和计算量变大导致对于单请求的TPOT指标上升相信随着前面提到的两个问题解决这个差距也会缩小或者消失。2.4. PP与DPEPPD分离技术的关系简单来讲DPEP以及PD分离的架构都能在一层模型的的多机推理上提升计算资源的利用率从而提升整体的吞吐。而PP解决的是多层模型在多机上推理的性能问题。二者是正交的可以和DPEP以及PD分离技术结合使用。目前一念发布的0.6.0版本中已经包含了上面几个技术的功能但是性能上还不能打败当前方案。在达到团队的优化目标后会正式发布。三. 理论分析与未来工作在2月份我们做了一个粗略的理论上限计算来评估框架的优化空间。具体方法是以模型的数学公式计算每个数学计算逻辑所涉及到的计算量和通讯量。由于fp8权重模型的计算过程有较多算子都涉及fp16格式的数据计算计算量和通讯量都是按fp16来估算的。然后假定算子能够发挥出硬件60%的标称最大性能计算每个数学逻辑对应算子的计算或通讯耗时。得到一个双机16卡H20硬件的吞吐理论上限18000 tokens/s。当然这个估算是非常粗略的比如没有考虑算子调度本身的开销在实际推理过程中算子越小调度的耗时占比会明显增加。让我们吃惊的是2月时业界开源框架vllm和sglang的性能是大约1400 tokens/s和2200 tokens/s说明当时开源框架的性能优化空间巨大。后来发生的事情也证明了这一点随着vllm v1引擎支持Deepseek和SGLang多项优化的逐步上线两个推理框架的性能迅速提升都在5月份达到了大约6100 tokens/s的吞吐。性能提升了2-3倍。但是我们也看到相对理论上限各个框架连理论上限的一半都没有达到。一念目前只使用了TPPP的技术前面分析中提到的DP/EP和PD分离正在开发中很快将正式发布。预计很快还会有30%的性能提升。另外在这个上面的对比中我们使用的是fp8的满血版Deepseek。业内还有多个团队在探索低精度的推理方案。低精度推理方案能降低计算和显存的需求量从而降低时延提高吞吐。我们正在与相关团队沟通合作将大家在算子方面的深度优化与一念结合起来进一步降低业务使用大模型的成本。最后为什么要学AI大模型当下⼈⼯智能市场迎来了爆发期并逐渐进⼊以⼈⼯通⽤智能AGI为主导的新时代。企业纷纷官宣“ AI ”战略为新兴技术⼈才创造丰富的就业机会⼈才缺⼝将达 400 万DeepSeek问世以来生成式AI和大模型技术爆发式增长让很多岗位重新成了炙手可热的新星岗位薪资远超很多后端岗位在程序员中稳居前列。与此同时AI与各行各业深度融合飞速发展成为炙手可热的新风口企业非常需要了解AI、懂AI、会用AI的员工纷纷开出高薪招聘AI大模型相关岗位。最近很多程序员朋友都已经学习或者准备学习 AI 大模型后台也经常会有小伙伴咨询学习路线和学习资料我特别拜托北京清华大学学士和美国加州理工学院博士学位的鲁为民老师给大家这里给大家准备了一份涵盖了AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频全系列的学习资料这些学习资料不仅深入浅出而且非常实用让大家系统而高效地掌握AI大模型的各个知识点。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】AI大模型系统学习路线在面对AI大模型开发领域的复杂与深入精准学习显得尤为重要。一份系统的技术路线图不仅能够帮助开发者清晰地了解从入门到精通所需掌握的知识点还能提供一条高效、有序的学习路径。但知道是一回事做又是另一回事初学者最常遇到的问题主要是理论知识缺乏、资源和工具的限制、模型理解和调试的复杂性在这基础上找到高质量的学习资源不浪费时间、不走弯路又是重中之重。AI大模型入门到实战的视频教程项目包看视频学习是一种高效、直观、灵活且富有吸引力的学习方式可以更直观地展示过程能有效提升学习兴趣和理解力是现在获取知识的重要途径光学理论是没用的要学会跟着一起敲要动手实操才能将自己的所学运用到实际当中去这时候可以搞点实战案例来学习。海量AI大模型必读的经典书籍PDF阅读AI大模型经典书籍可以帮助读者提高技术水平开拓视野掌握核心技术提高解决问题的能力同时也可以借鉴他人的经验。对于想要深入学习AI大模型开发的读者来说阅读经典书籍是非常有必要的。600AI大模型报告实时更新这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示。AI大模型面试真题答案解析我们学习AI大模型必然是想找到高薪的工作下面这些面试题都是总结当前最新、最热、最高频的面试题并且每道题都有详细的答案面试前刷完这套面试题资料小小offer不在话下这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】