构建面向 Agentic 推理的下一代 LLM 推理引擎

在 Agent 推理负载快速增长的背景下，传统面向聊天场景的推理引擎正面临吞吐优化目标失效、缓存利用率不足、硬件适配滞后等一系列结构性挑战。 本文整理自 TokenSpeed 独立贡献者尚旭春在 AICon 2026 深圳站的分享《构建面向 Agentic 推理的下一代 LLM 推理引擎》。他系统介绍了该项目从立项到版本迭代的完整技术路径，围绕 Agent 场景下的工作负载特征、分层解耦的系统架构、自动并行编译系统、KV Cache 演进路线、Kernel 优化策略以及跨平台抽象设计展开，并给出在 Blackwell 平台上的阶段性性能数据。 以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。 为什么 Agentic 推理需要新推理引擎 TokenSpeed 立项之初，我们首先要回答的问题是：为什么 Agent 场景需要一套全新的推理引擎设计。 传统 Chat 类负载的优化目标相对单一，用户发起一次请求，模型一次性生成一段完整回复。在这种模式下，推理系统只需要尽可能将 batch 打满、最大化吞吐，KV Cache 在一次加载之后就被释放，利用率天然偏低。但 Agent 场景的负载特征与 Chat 有本质区别。以 coding agent 为例，模型需要持续地思考、调用工具、获取结果、再基于结果继续思考，整个过程由多轮短请求循环构成。第一次请求可能携带几十 K 的前缀上下文，但后续每次循环的输出往往只有几百个 token。这意味着推理引擎必须重新审视缓存复用策略、请求调度机制以及整个系统的优化目标函数。 在这种负载形态下，用户对延迟的敏感度显著提升。如果一个 Agent 工具在推理环节出现显著滞后，用户会直观地感受到“跟手性”不足。因此，Agent 场景下真正需要优化的是延迟约束下的吞吐。我们内部定义了一个性能指标：每用户 TPS 不低于 70，在此约束下尽可能提升每个 GPU 的吞吐能力。以 TensorRT-LLM 为对比基准，TokenSpeed 在 batch size 等于 1 的最小延迟场景下，端到端延迟比 TensorRT-LLM 快 9%；在每用户 100 TPS 的典型工作点上，每个 GPU 的吞吐高出 11%。 KV Cache 复用率是决定推理成本的关键变量。以 DeepSeek 为例，其缓存复用率据称在 99% 以上，而业界多数系统目前只能达到 70% 到 80%。在 Agent 场景下，同一段几十 K 的上下文如果能够被反复命中，意味着每次命中都能完全省去 prefill 计算，系统的整体成本会大幅下降。我们在测试中验证了 TokenSpeed 在上下文长度从 128K 扩展到 1M 时的表现，解码吞吐率仅下降 16%。此外，随着越来越多的模型采用线性注意力机制，包括千问的 Gated DeltaNet 以及 Kimi K3 所使用的 KDA，KV Cache 的管理模式也在发生变化。线性注意力模型不再维持传统的 token 到 KV 的一一对应关系，而是通过一个持续迭代的状态来表示上下文，其中包括 SSM 状态和卷积状态。如何在推理引擎中高效地更新、保存和恢复这些状态，是一个新的系统设计命题。 模型架构与硬件特性之间的耦合也在同步加深。MOE 架构自 DeepSeek 发布以来已经成为主流选择，但 MOE 模型的优化难度并不低。以 Kimi K3 为例，该模型有 896 个专家，虽然采用了 Latent MOE 技术将写成本大幅降低，激活专家的比例提升到了 16%，但路由和通信的复杂度显著增加。与此同时，Blackwell 这一代硬件引入了 Tensor Memory、新一代 Tensor Core 等一系列新特性，AMD 的 CDNA 架构也有其独特的硬件能力。如果推理引擎无法充分利用这些硬件特性，Blackwell 相对 Hopper 的性能优势就无法真正释放。基于这些观察，TokenSpeed 在 Kernel 层面针对 Blackwell 做了深度优化，确保硬件潜力被充分挖掘。 Runtime 与 Kernel 的协同设计同样不可忽视。调度器设计得再好，如果底层 Kernel 存在性能瓶颈或者耦合过深，系统整体仍然无法达到理想状态；反过来，Kernel 优化得再极致，如果调度器产生大量 bubble，吞吐也无法打满。TokenSpeed 在架构设计上吸取了这方面的经验，将调度、执行和底层算子做了系统性的解耦与重构。 Runtime：构建可扩展的推理引擎架构 TokenSpeed 的整体架构分为三个层次：控制、Runtime 和 Kernel。控制面完全使用 C++ 编写，Runtime 使用 Python 实现，Kernel 则独立为一个子包。这种分层设计的核心目的是保持模块边界的清晰性。控制面只负责调度决策，不涉及任何数据面的执行；Runtime 只负责执行控制面下发的执行计划，包括缓存计划和前向计算计划；Kernel 层则专注于算子实现。三者各司其职，避免了过去推理引擎中调度逻辑、执行逻辑和算子实现相互渗透导致的维护困境。 控制面选择 C++ 而非 Rust，有实际的历史原因。团队成员大多来自上古时代，对 Rust 的熟悉程度有限，C++ 在性能和表达力上完全满足需求，因此最终确定使用 C++ 进行控制面的程序设计。Runtime 保留 Python，则是因为 Python 生态在深度学习领域已经非常成熟，PyTorch、CUDA 等库的集成度高，模型适配层的开发效率远高于其他语言。Kernel 子包独立出来后，NVIDIA 和 AMD 的专家可以针对各自硬件特性做深度优化，而不需要理解调度器或 Runtime 的内部实现。 这种分层架构带来的另一个收益是并行编译的自动化。在过去的推理引擎开发中，模型并行切分的代码往往散落在各个模型适配模块内部，与注意力实现、MOE 实现、通信逻辑等深度耦合。随着支持的模型数量增加，这些散落的并行代码变得越来越难以维护，任何一个新模型的接入都可能牵动多个模块的改动。TokenSpeed 的做法是将并行切分逻辑从模型适配代码中完全抽离出来，形成一个独立的 Placement 系统。模型开发者只需要声明每个模块的边界、输入输出类型，以及该模块在并行维度的属性，是 replicate、shard 还是 partial，系统就会自动处理后续的切分和通信。 具体来说，每个模块可以挂载到不同的并行组上。注意力模块挂载到 Attention Tensor Parallel 组上，MOE 模块挂载到 MOE 并行组上，各模块独立选择并行策略。基于这些 Placement 定义，TokenSpeed 的类型编译系统会遍历整个解码层的执行计划，比较相邻模块之间的 Placement 差异。当发现不一致时，系统自动插入相应的通信原语：从 partial 到 replicate 需要 all-reduce，从 shard 到 replicate 需要 all-gather，从 shard 到 partial 需要 reduce-scatter。整个编译流程的输出是一个统一的 compiled_decoder_layer 执行计划