腾讯一念LLM分布式推理优化实战：关键技术突破与性能飙升内幕

mysmile 2025年12月10日 08:30 7 0

关键技术详解：腾讯一念LLM分布式推理优化实践

作者 | 袁镱

编辑｜李忠良

策划｜AICon 全球人工智能开发与应用大会

在AI推理框架的激烈竞争中，您是否好奇为什么腾讯还要推出“一念LLM”？从vLLM、SGLang到TensorRT-LLM、MindIE，再到新兴的“一念”，不同团队在算子优化、显存管理与调度策略上不断博弈，性能指标在短短半年间就提升了数倍。为什么竞争如此白热化？现有开源框架是否已成熟？推理系统到底卡在哪些瓶颈？

InfoQ荣幸邀请到腾讯/PCG机器学习平台技术负责人袁镱，在AICon全球人工智能开发与应用大会·深圳站分享《一念LLM分布式推理优化实践》。他从KV cache全链路管理、算子封装与自研，到多维并行（PP/DP/EP）、MoE负载均衡与MLA，以及PD分离与多阶段流水线调度，给出了一套高效工程化解法。

12月19～20日的AICon北京站将锚定行业前沿，聚焦大模型训练与推理、AI Agent、研发新范式与组织革新，邀您共同深入探讨：如何构建可信赖、可规模化、可商业化的Agentic操作系统，让AI成为企业降本增效、突破增长天花板的核心引擎。

详细日程见：

https://aicon.infoq.cn/202512/beijing/schedule

以下是演讲实录（经InfoQ进行不改变原意的编辑整理）。

“一念LLM”是一款面向大语言模型的推理框架，与vLLM、SGLang、TensorRT-LLM等同属一类。在众多开源框架存在的情况下，为什么腾讯还要开发“一念LLM”？

腾讯一念LLM分布式推理优化实战：关键技术突破与性能飙升内幕

要回答这个问题，先看大语言模型推理框架的基本工作流：当系统接收大量并发请求时，请求首先进入并行调度模块，随后进入显存管理。显存管理包括为KV cache分配显存；当显存不足时，需决定是从外部KV Cache调入、将部分请求offload到内存，或使用更远存储介质。

显存就绪后，系统对请求进行批处理，并针对不同模型调度算子，生成KV cache。随后算子执行，完成後进入采样阶段。生成过程中，会设置temperature等参数，系统随之生成Token。生成结束后，可能还需进一步处理，如将Token转换为JSON等结构化输出，或对齐业务模式；或在生成某个Token后，基于下一个Token的概率分布执行投机解码以加速推理。

整体流程中，不同模块对应并行调度、显存与队列管理及算子调度，这些是各框架的主要差异。算子层面，若深入代码会发现框架间相互借鉴：因Transformer架构稳定，优化路径趋同；一旦某个算子更优，会迅速被吸收推广。

从贡献角度看，硬件厂商在算子研发上具天然优势，因其对自家硬件理解深入，能充分利用特性设计。典型代表是TensorRT-LLM与MindIE。

非硬件厂商的研发重点更多在调度与显存管理，如vLLM从paged attention入手，SGLang以prefix caching为起点，“一念”等框架也在此探索。学术界持续在这些机制上创新。

另一贡献显著群体是模型厂商，他们贡献了大量算子。随着DeepSeek兴起，过去半年推理框架竞争异常激烈。为何如此？假设在H20 16张卡条件下部署完整DeepSeek模型，若所有算子MFU仅60%，理论吞吐应达30K。

今年2月时vLLM和SGLang性能仅2K。经半年优化，现提升至2-3倍。TensorRT-LLM横空出世，最新数据达11.2K。

一念最新数据为14.6K。但与理论30K相比，仍有巨大差距。这意味着基础设施层面优化空间广阔，工作需持续推进。

“一念LLM”的设计思路与实践

腾讯一念LLM分布式推理优化实战：关键技术突破与性能飙升内幕

为何要做一念框架？我们判断基于两个核心因素。

推理环节在业务逻辑中比重将越来越大。当单一模型完成整个流程时，推理成为后台最庞大服务。这趋势要求业务快速响应和系统稳定高效。

对开源框架，若研发路径可控性低，定制能力与稳定性冲突，可能影响业务收益。

算子优化方面，硬件厂商和模型发布者常深度优化。因此“一念”设计以高效引入开源算子、支持多硬件为基础，构建上层结构。

整体架构最上层采用手写模型。大语言模型本质是手写，常见实现基于PyTorch用Python编写；我们选择C++实现，并进行显存优化。

显存优化至关重要。以Kv-cache为例，它消耗大量显存，在高吞吐与长序列场景中尤为关键。同时需高效调度提升吞吐。

算子层面由三部分组成：开源封装、移植算子、自研算子。针对不同硬件适配，我们封装类CUDA接口，支持Nvidia GPU、华为昇腾芯片及腾讯紫霄芯片。这设计屏蔽下层异构硬件，对上提供统一体验。

需指出，因我们对显存全流程自主管理，在R1模型上Kv-cache可用显存比业界提升约130%，吞吐量提升约30%。

推理优化的挑战与突破

进行大语言模型推理优化时，先明确问题与限制。随应用规模扩大，Prefilling Tokens长度增加，而效率低下环节主要在Decoding Tokens阶段。

如上图，在A100上Forwarding计算时，随输入Token数量增加，GPU实时有效计算能力逼近硬件上限。一旦达上限，即便增加Token数量，计算功率无法提升，只能延长计算时间。

另一瓶颈在decoding阶段。其效率低，因常规每次仅生成一个Token，即便结合投机解码，通常也只生成两三个Token。因此提高batch size成显著优化手段。

但增加batch size带来新挑战。因序列长度增长，大序列叠加大批量导致Kv-cache需求剧增，直接受限于显存容量。

在有限显存下，提升推理阶段Token并行处理能力。同时注意，一旦某阶段达硬件极限，不应继续增加负载，否则只增耗时。

腾讯一念LLM分布式推理优化实战：关键技术突破与性能飙升内幕

接下来看推理过程多个阶段。在MoE部分，采用256路由专家加1共享专家架构。如上DeepSeek结构图，计算过程中大量Token经路由表时，导致专家间负载不均。共享专家路径全量Token直接通过，无路由，因此共享专家负载异常集中。

换言之，上半部分稀疏计算但负载不均，下半部分高负载计算。典型解决方案两点：一是增加并行Token数，摊薄不均衡效应；二是采用EP方式，为共享专家设多副本，分配到不同卡或芯片并行计算，获更多资源。

在MLA部分，其最大特点是对Kv-cache压缩，减少单副本内各卡Kv-cache占用。但带来新问题：多卡间压缩CompressedKv重复，造成显存浪费。额外Project操作增开销。解决方案包括权重吸收及采用全DP，即只保留一份副本，避免重复存储。

腾讯一念LLM分布式推理优化实战：关键技术突破与性能飙升内幕

目前技术主要从计算、通信和显存三维度优化。最原始方案是全TP，实现简单，但特点：MoE阶段计算稀疏，通信开销大；关键问题Kv-cache冗余存储。全TP方案中，若用4张卡，产生4份冗余副本。

针对此，出现第一批改进方案：通过减少冗余，将不同MoE分配到尽量少卡上。例如，将两张卡内容保持一致，计算逻辑同，只输入数据不同（如batch1与batch2）。

此情况下，逻辑等价batch扩大一倍，使后续MoE阶段batch规模加倍。方案优势显著增大MoE阶段Token数量，同时降低部分通信与Kv-cache冗余。但带来新问题：权重和buffer增加。

实际小规模部署中，会遇DP无法扩展过大问题。因当DP规模增大时，虽Kv-cache冗余减少，但权重与buffer占用显著增加。若资源消耗超可用显存，无法运行。

进一步扩展思路增MLA与DP份数，并在跨机时引入EP。EP优势通信量减少，因只需传输对应专家所需参数、路由信息及部分状态数据。

但采用共享专家负载均衡增显存开销，形成“跷跷板”效应。常见解决方式扩大批处理规模，将更多专家分布到多张卡上，即使每卡只增一专家或共享专家，也能获收益。

腾讯一念LLM分布式推理优化实战：关键技术突破与性能飙升内幕

不过，仅靠扩大DP+大EP组合方案仍不足解决问题，因此引入PD分离（Prefill与Decode分离）思路。原因在Prefill与Decode两阶段混合执行时相互影响性能。Prefill阶段通常一次性输入数千Token，将硬件完全占满。例如，若系统吞吐能力1K，却一次性输入4K Token，耗时增4倍；此时若Decode混合执行，Decode延迟随之放大。

在DeepSeek中，因引入权重吸收机制，Prefill与Decode混合执行还带来额外权重和显存开销。更重要的是，二者最优batch size本不同：Prefill阶段每请求Token数量大，因此只需较小batch size就能充分利用集群；而Decode阶段需更大batch size才能达集群利用率最大化。

但其缺点在需进行Kv-cache同步，同时需较大并行请求规模，才能充分发挥硬件性能。这类需求适合高性能大规模集群，因此成硬件厂商和云厂商最关注场景。若确有PD分离需求，并不建议自行实现。因该方案涉调度、集群管理、故障排查等复杂问题，对周边系统要求极高，实施维护成本巨大。因此更可行方式依赖云厂商成熟解决方案。

最后值得思考，为什么推理系统逐渐走向“小型机化”？按理互联网服务应依托海量、低成本、具柔性伸缩能力机器支撑，而非依赖高性能单机。

但现实情况，因推理请求普遍同步执行，且伴大量数据交换，这模式逐渐推动“小型机化”趋势。以上述推理过程为例，61层DeepSeek模型在输出一Token时需进行122次跨机通信。若中间环节性能不足，结果可想而知。

腾讯一念LLM分布式推理优化实战：关键技术突破与性能飙升内幕

基于此问题，我们必须探索其他路径减少跨机通信。从并行技术角度，流水线并行是较传统方案。以两机为例，该方法仅需两次跨机通信：一次传数据过去，另一次传回，且异步进行。这在通信量上具明显优势。

因Kv-cache及自回归逻辑等特性，使当前推理框架在实现多batch推理时复杂度和成本依然较高。

在“一念”实践中，目前多阶段流水线并行实现较完善，整体性能领先。需注意，在Forward阶段，流水线要求资源充分填充，因此任务划分必须尽量均匀。

此过程中，需通过多batch方式实现负载均衡，因推理过程中部分batch可能退出，同时新batch不断进入。

例如，在prefill阶段，可能很多请求仍处decode状态，若此时prefill与decode混合同一批次，再叠加更多decode请求，可能导致decode阶段因prefill操作性能下降。

为此，必须在batch调度中引入多种负载均衡策略。这不是全新技术，而是流水线并行本应具特性。不同处在我们首次在大规模语言模型推理这种有状态服务中实现此点。完成优化后，系统吞吐量从5K提升至9K。

腾讯一念LLM分布式推理优化实战：关键技术突破与性能飙升内幕

关于如何进一步提升MoE利用率，这里存在几个关键问题。

在DP中，最直接方式仅保留一份KvCache，避免多卡间冗余存储。但带来新挑战：权重需集中放置单卡上，而非分散在2、4或8张卡，显著增单卡显存压力。若再遇64K请求，必须保证任意DP都能处理该请求，这对中间计算过程buffer要求更严格。

当多个DP将资源切分过细时，若同时出现大规模请求，例如在8DP、8张卡情况下，每DP都接收一64K请求，那么MoE阶段压力放大为64K×8，导致中间缓存成瓶颈。因此需在DP间引入负载均衡机制，确保无论如何调度，都不使MoE buffer过载。

为应对此，一方面必须进行更精细化显存管理，以承载更高权重与buffer开销。这也是我们选择直接从显卡层面进行显存分配，而非依赖PyTorch等框架自动管理的原因。

另一方面，还需在DP间进行调度与均衡。结合前述MT-Batch与流水线并行，我们还可不同batch间调度，确保每个batch内部DP负载更均衡。

通过这些优化，目前系统吞吐量已提升至14.6K。若仔细对比会发现问题：从单DP扩展到8DP，理论上吞吐应近8倍，但实际提升不足一倍。这表明我们优化仍不充分。

相较下，TensorRT-LLM在开启DP前后几乎实现一倍提升，说明其DP算子性能明显优于我们。这也是后续需重点借鉴处。

总结与展望

腾讯一念LLM分布式推理优化实战：关键技术突破与性能飙升内幕

我们并非不做EP和PD分离，而是选择先实现PP。这顺序主要取决于硬件条件。从下图可见Token并行数与最终硬件性能关系。蓝色曲线代表H800，橙色曲线代表H20，二者间约十倍性能差距。

这意味着不同Token数下，算子性能上限存显著差异。H20很快达天花板并进入平稳期，再增加只带来时延。

EP和PD分离首要收益在可支持更大batch size。而PP带来更优显存利用率和更低通信开销。

我们先实现PP，现正推进EP与PD分离。在batch size已近上限情况下，下一步重点进一步释放显存并优化通信。

我们当前工作也聚焦几个关键问题：

一是调度策略与业务场景兼容。若业务峰值10倍量级，现有策略更偏“保吞吐”，那么后续调度需在保证吞吐同时，把TPOT、TTFT等体验指标做上去（既降首Token时延、又提升持续输出效率），这对调度提出更高要求；

二是柔性KV cache匹配。目前prefix cache采用严格匹配：例如一会话约50轮，对到第51轮时发生窗口回滚（从第2轮到第51轮重新送入模型）。此时大部分上下文同，但因严格匹配，KV cache往往无法命中。因此我们推进“柔性KV cache”，力图在上下文高度相似情况下也能复用缓存，减少重复计算。

三是模型层间进度是否必须同步。从研究与实践看，答案否定：不同层计算负载与时序分布不一致，没必要强行保持层层同速。适度引入层间解耦/异步有望提升整体效率。

四是batch间流程编排。虽两batch逻辑独立，但若视它们为计算图，并不必然冲突；因此没必要做硬件强隔离。通过在不冲突算子间交叉/穿插执行，可进一步提升资源利用率与吞吐。我们也在推进多模态支持与国产GPU适配等相关工作。

谢谢大家！

活动推荐

AI重塑组织的浪潮已至，Agentic企业时代正式开启！当AI不再是单纯辅助工具，而是深度融入业务核心、驱动组织形态与运作逻辑全面革新的核心力量。

把握行业变革关键节点，12月19日-20日，AICon全球人工智能开发与应用大会（北京站）即将重磅启幕！本届大会精准锚定行业前沿，聚焦大模型训练与推理、AI Agent、研发新范式与组织革新，邀您共同深入探讨：如何构建可信赖、可规模化、可商业化的Agentic操作系统，让AI真正成为企业降本增效、突破增长天花板的核心引擎。

腾讯一念LLM分布式推理优化实战：关键技术突破与性能飙升内幕