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

作者 | 袁镱

编辑｜李忠良

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

从 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”？

要回答这个问题，先看大语言模型推理框架的基本工作流：当系统接收到大量并发请求，请求首先进入并行调度模块，随后进入显存管理。显存管理包括为 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。经过半年的激烈竞争与优化，目前 vLLM 和 SGLang 的性能已提升至原来的两到三倍。与此同时，TensorRT-LLM 横空出世，最新测试数据达到 11.2 K。

一念的最新数据则为 14.6K。但整体来看，与理论预估的 30K 相比，仍存在巨大的差距。这也意味着，在基础设施层面仍有广阔的优化空间，相关工作需要持续深入推进。

一念 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 会带来新的挑战。由于序列长度不断增长，较大的序列长度叠加更大的 batch size，将导致 Kv-cache 的需求急剧增加，从而直接受限于显存容量。

因此，在有限显存条件下，提升推理阶段 Token 的并行处理能力。同时需要注意，一旦某一阶段达到硬件极限，就不应继续增加负载，否则只会导致整体耗时增加。

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

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

在 MLA 部分，其最大特点是对 Kv-cache 进行压缩，从而减少单个副本内各卡的 Kv-cache 占用。但这也带来新的问题：多卡之间的压缩 CompressedKv 出现重复，造成显存浪费。同时，额外的 Project 操作也进一步增加了开销。对应的解决方案包括权重吸收，以及采用全 DP（Data Parallelism），即只保留一份副本，避免重复存储。

目前的技术主要从计算、通信和显存三个维度展开优化。最原始的方案是 全 TP（Tensor Parallelism），这种方式实现最为简单，但其特点是：在 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 的优势在于通信量减少，因为它只需传输对应专家所需的参数、路由信息及部分状态数据。

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

不过，仅依靠扩大 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 次跨机通信。如果中间环节的性能不足，其结果可想而知。

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

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

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

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

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

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

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

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

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

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

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

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

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

总结与展望

我们并非不做 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 适配等相关工作。

谢谢大家！