tokenspeed

一年之计在于春，一日之计在于晨。——萧绎

TokenSpeed：面向智能体工作负载的极速大模型推理引擎

项目地址：https://github.com/lightseekorg/tokenspeed

当大语言模型开始从一次性问答走向持续规划、工具调用、多轮执行与复杂协作，推理系统面对的问题也随之改变。

模型不再只是接收一段输入，再返回一段输出。它需要处理更长的请求生命周期，需要在多个请求之间调度资源，需要管理 KV 缓存，需要让计算、通信与请求处理尽可能重叠，也需要在速度、吞吐与可用性之间找到更合理的平衡。

TokenSpeed 正是面向这样的场景而来。

它是一款面向智能体工作负载的大语言模型推理引擎，目标是在保持高性能的同时，提供接近易用推理框架的使用体验。项目将自身定位为速度极快的推理引擎，并强调希望成为性能最强的大模型推理系统之一。

它追求的不只是更快地产生下一个 token。

它试图从控制面、执行面、内核系统与请求入口等多个层次重新组织推理路径，让复杂的大模型服务在面对智能体式工作负载时，拥有更清晰、更可控、更高效的运行方式。

为智能体时代重新思考推理

智能体工作负载有自己的节奏。

它们可能不断生成下一步计划，调用外部工具，读取返回内容，继续推理，再次发起请求。这样的过程并不像一次静态生成那样简单，而是由许多彼此衔接的请求、状态与资源使用构成。

TokenSpeed 将重点放在这类场景上。

项目希望在智能体式推理任务中提供高性能表现，同时兼顾实际部署与使用体验。它并没有把推理系统理解成一条只需不断输出 token 的直线，而是将请求生命周期、缓存所有权、调度逻辑与底层内核放进同一个整体框架里思考。

对于智能体而言，速度不只是一个醒目的数字。

更快的响应意味着更短的等待。

更稳定的调度意味着更多任务能够连续推进。

更清晰的资源管理意味着缓存与执行过程可以被更可靠地组织。

TokenSpeed 所关注的，正是这一整段推理旅程。

控制面与执行面分离

TokenSpeed 的核心架构特点之一，是将控制面与执行面分离。

项目使用 C++ 构建控制面，并使用 Python 承担执行面。请求生命周期、KV 缓存所有权以及不同阶段的重叠时序，都被编码为有限状态机。

这意味着，系统不会只把请求看作一段简单的输入与输出。

每一个请求都有自己的状态变化。

每一份 KV 缓存都有对应的资源归属。

不同任务之间的重叠关系，也不只是依赖临时约定，而是被放进明确的状态逻辑之中。

有限状态机让推理过程拥有更清晰的边界。请求从进入系统开始，经历调度、执行、资源占用与资源复用等阶段，每一步都可以被放入可描述的状态转换中。

而对于 KV 资源的安全复用，TokenSpeed 进一步使用类型系统在编译期进行约束。

这让资源复用不只是运行时的经验判断，也尝试成为编译阶段能够被检查的一部分。对于高并发与高性能推理场景而言，缓存如何被使用、何时能够复用、不同请求之间如何避免不安全的资源交错，都会直接影响系统的可靠性与性能表现。

从请求生命周期开始管理推理节奏

大模型推理并不只是模型计算本身。

在真正的服务过程中，请求如何进入系统、何时占用资源、怎样持有缓存、如何完成执行、又在什么时刻释放或复用资源，都会影响整体效率。

TokenSpeed 将这些过程纳入调度器的职责。

项目中的调度器由 C++ 控制面与 Python 执行面组成，围绕请求生命周期、KV 缓存所有权和重叠时序进行组织。它让请求不再像彼此孤立的任务，而更像一组需要协调推进的状态单元。

当多个请求同时到来时，系统需要的不只是尽快开始计算。

它还需要理解这些请求当前处于什么阶段，哪些资源正在被使用，哪些资源能够被安全复用，以及哪些执行机会可以彼此重叠。

TokenSpeed 将这种复杂性放在调度层中处理，让推理引擎的运行节奏不只依赖于单点性能，也建立在对整个请求流程的组织之上。

内核不再只是隐藏在底层的细节

在许多推理系统中，内核常常被视为底层实现的一部分。

TokenSpeed 则将内核视为一等子系统。

项目提供可插拔、分层的内核系统，并通过可移植的公开接口与集中式注册机制来组织不同内核实现。内核不再只是与核心引擎紧密耦合的一段实现代码，而能够以更明确的方式被注册、选择与扩展。

这种设计让内核系统拥有自己的结构。

不同硬件环境、不同算子需求与不同模型特征，可能需要不同的高性能实现。通过公开接口、注册机制与选择模型，TokenSpeed 将内核能力从核心引擎中分离出来，使它们能够以模块化方式参与推理过程。

项目特别提到，其中包含面向智能体工作负载的高性能 MLA 实现。

MLA 即多头潜在注意力，是项目重点关注的能力之一。TokenSpeed 在 Blackwell 平台上提供快速的 MLA 实现，并将其放入可插拔的内核系统之中。

这使底层计算优化不再是一块难以触及的黑箱。

它成为整个推理引擎架构中可被组织、调度与演进的重要组成部分。

AsyncLLM：让请求入口保持轻量

除了调度器与内核系统，TokenSpeed 还提供了与 SMG 集成的 AsyncLLM 入口。

这一入口面向较低开销的 CPU 侧请求处理。

在高性能推理场景中，GPU 计算往往最容易吸引注意力，但 CPU 侧的请求接收、组织与调度同样会影响整体体验。请求从外部进入服务，到真正进入执行阶段，中间仍然存在需要被处理的路径。

AsyncLLM 的存在，让 TokenSpeed 不只关注计算设备上的执行效率，也关注请求在进入系统时的处理成本。

对于持续到来的智能体请求而言，这种轻量化入口意味着推理系统可以从请求抵达的第一刻开始，尽量减少不必要的负担。

高性能与易用性，希望不再互相牺牲

TokenSpeed 在项目介绍中提出了一种明确的目标：希望获得接近 TensorRT-LLM 级别的性能，同时保持接近 vLLM 级别的易用性。

这句话指向了推理系统中一个长期存在的张力。

极致性能通常意味着更复杂的配置、更深入的硬件优化与更多底层细节。

而更容易使用的系统，则往往需要提供更顺畅的接口、更清晰的部署方式与更低的接入门槛。

TokenSpeed 希望在两者之间建立连接。

它不满足于只强调某一端，而是试图让高性能架构与可使用的推理体验同时成为项目的重要方向。控制面与执行面的分离、内核的模块化设计、轻量化请求入口以及面向服务的文档体系，都是这一目标的一部分。

对于使用者而言，真正有价值的推理引擎不只是快。

它还需要能够被部署、被配置、被理解，并适应不同模型与不同服务场景。

中立的开源推理引擎

TokenSpeed 将自己形容为开源大模型推理引擎中的瑞士。

这一表述所强调的是中立性。

项目由非营利组织 LightSeek Foundation 支持，而不是由某一家模型公司推动。它希望以中立的方式面向不同模型、不同平台与不同硬件环境。

这种定位对于推理引擎而言具有特别的意义。

推理系统站在模型与硬件之间，也站在开发者与实际服务之间。它需要面对不同模型架构、不同注意力机制、不同加速设备与不同部署需求。

中立意味着，项目不希望只围绕单一种模型或单一家硬件平台展开。

它希望成为一个能够适配更多推理需求的基础设施方向。

从 Blackwell 到 Vera Rubin，持续探索硬件边界

TokenSpeed 的 README 记录了围绕不同硬件平台与模型进行的优化进展。

项目提到 TokenSpeed MLA 2 面向 NVIDIA Vera Rubin 的解码基准。

在 NVIDIA GB300 平台上，TokenSpeed 服务 Qwen3.8 Flash Next 时，实现了每位用户每秒 685 tokens 的表现。

项目也记录了在 AMD Instinct MI355X GPU 上推进 Kimi K3 推理的工作。

此外，README 中还列出了围绕 GB300、Qwen3.8、GLM 5.3 Flash、Kimi K3、TML Inkling 与 Qwen3.5 等模型或平台展开的内容。

这些记录显示出 TokenSpeed 的优化方向并不局限于某一个固定模型。

它面向不同模型，也关注不同硬件平台。

从 NVIDIA 平台到 AMD 平台，从面向 Blackwell 的 MLA 实现到面向 Vera Rubin 的进一步探索，项目持续将底层优化能力带入具体推理场景。

Qwen3.5-397B-A17B 与 580 TPS

README 记录了一项围绕智能体工作负载的性能成果。

在 2026 年 5 月，TokenSpeed 在 Qwen3.5-397B-A17B 上达到 580 TPS。

这一记录被项目描述为面向智能体工作负载的速度成绩。

TPS 是每秒 token 数量的表达方式之一。在大模型推理场景中，它与系统如何调度请求、如何管理缓存、如何选择内核、如何处理不同阶段的计算密切相关。

TokenSpeed 将这一成绩放在项目发展记录中，也说明它希望将架构设计落实到实际推理表现中。

它并不是只描述控制面、执行面与内核系统的理论关系。

它还试图通过具体模型与具体硬件上的运行结果，展示这些设计在智能体式推理任务中的意义。

从模型首日支持到推理系统的快速响应

TokenSpeed 的新闻记录中，多次出现 Day 0 这一表达。

Qwen3.8、Kimi K3 与 TML Inkling 等模型相关内容，都被纳入项目的首日支持与优化记录之中。

对于推理引擎来说，新模型出现之后，能否尽快让它进入可服务、可优化的状态，是一项重要能力。模型本身可能带来新的结构、新的精度格式、新的注意力模式或新的计算特征，而推理系统需要迅速理解并适配这些变化。

TokenSpeed 围绕不同模型展开的工作，体现出一种持续响应模型变化的方向。

它不只是为既有模型准备推理路径，也希望在新的模型与新的硬件能力出现时，继续将高性能推理带入其中。

性能曲线背后，是吞吐与延迟之间的取舍

README 中展示了 TokenSpeed 与 TensorRT-LLM 在智能体工作负载上的性能曲线，对应 Kimi K2.5 与 B200 场景。

性能曲线之所以重要，是因为推理系统通常不会只面对一个单独的指标。

吞吐量、延迟、并发请求数量与资源利用方式之间，往往存在需要权衡的关系。一个系统在不同配置与不同负载下，可能呈现不同的性能位置。

TokenSpeed 通过相关图表呈现其在智能体工作负载上的性能比较，也将性能问题从一个简单的单值比较，带回更完整的曲线与取舍关系之中。

对于智能体服务而言，这种取舍尤其值得关注。

请求往往不是完全独立的。

它们会形成连续链路，也可能不断触发后续工作。系统如何在响应速度与整体服务能力之间保持合适状态，正是推理引擎需要持续处理的问题。

从文档开始进入 TokenSpeed

TokenSpeed 提供了面向使用者的文档入口，覆盖入门、服务启动、模型配方、服务参数、兼容参数与并行相关内容。

对于希望使用推理引擎的人来说，文档不是附属内容。

它是从架构愿景走向实际运行的重要桥梁。

一个推理引擎即使拥有复杂的调度设计与高性能内核，也需要让使用者知道如何开始、如何启动服务、如何选择模型、如何理解参数，以及如何面对并行执行相关配置。

TokenSpeed 将这些主题明确列入文档体系之中，使项目不只停留在架构介绍与性能新闻，也为实际使用保留了清晰路径。

速度不仅来自计算，更来自组织

TokenSpeed 的名字强调速度。

但从 README 所描述的架构来看，它所追求的速度并不只来自某一个更快的算子，也不只来自某一次性能测试。

速度来自请求生命周期被更清晰地管理。

来自 KV 缓存所有权被认真对待。

来自有限状态机对重叠时序的组织。

来自类型系统对安全资源复用的编译期约束。

来自内核作为独立、模块化子系统被注册与选择。

来自面向智能体工作负载的 MLA 优化。

来自 CPU 侧低开销的请求入口。

来自对不同模型与不同硬件平台持续进行适配与优化。

这些部分共同构成 TokenSpeed 对推理系统的理解。

它不只是希望让 token 更快出现。

它更希望让从请求抵达到模型执行、从缓存管理到内核选择、从单次推理到持续服务的整条路径，都能够以更高效的方式运转。

面向下一代推理工作负载的速度追求

大模型推理正在变得越来越像一套复杂的实时系统。

模型更大，任务更长，智能体调用更频繁，硬件平台也在持续变化。推理引擎所面对的，不再只是如何完成一次生成，而是如何让更多请求、更复杂的状态与更高要求的性能在同一套系统中协调推进。

TokenSpeed 从智能体工作负载出发，提出了自己的答案。

它将控制面与执行面分离。

它使用有限状态机组织请求、缓存与时序。

它让类型系统参与 KV 资源安全复用。

它将内核作为一等模块化子系统。

它提供面向低开销请求处理的 AsyncLLM 入口。

它围绕不同模型、不同 GPU 平台与不同注意力机制持续推进性能优化。

它试图在高性能与易用性之间建立新的平衡。

当推理不再只是模型输出的最后一步，而成为智能体持续行动的底座时，TokenSpeed 所追逐的速度，也就不再只是更快的数字。

它是在为下一次请求、更长的任务链与更复杂的模型服务，提前铺设一条更快的路。