TokenSpeed：把调度器写成有限状态机的 LLM 推理引擎

它解决什么问题

TokenSpeed 面向的是 agentic 工作负载，也就是那些需要多轮推理、工具调用、长上下文交互的场景。这类负载的特点是请求生命周期复杂，KV cache 的分配和释放频繁，且对延迟敏感。现有的推理引擎要么像 TensorRT-LLM 那样性能高但使用门槛高，要么像 vLLM 那样易用但调度开销和并行扩展有瓶颈。TokenSpeed 想同时拿到两者的优点：用 C++ 写调度核心保证性能，用 Python 写执行逻辑降低开发成本。它的目标用户是那些在生产环境跑 agent 服务、需要高吞吐和低延迟、同时不想手写并行逻辑的工程团队。

控制平面和执行平面的分离

TokenSpeed 最核心的架构决策是把控制平面和执行平面分开。控制平面用 C++ 实现，请求生命周期、KV cache 所有权、重叠时序都被编码成一个有限状态机。这个状态机不是运行时检查，而是在编译期通过类型系统来保证资源安全。也就是说，非法状态转换在编译时就被拒绝，而不是等到运行时报错。执行平面用 Python 实现，负责实际的张量计算和内核调用。这种设计让研究人员可以快速迭代 Python 层，同时调度核心的正确性由 C++ 和类型系统兜底。PyTorch 基金会在其生态博客中引用过这个特点，称其为第一个分离控制与执行平面的开源推理引擎。这个说法是否绝对正确不好说，但至少说明它在架构上确实有辨识度。

本地 SPMD 与静态编译的并行策略

在建模层，TokenSpeed 采用 local-SPMD 设计，配合一个静态编译器。用户不需要手写张量并行或流水线并行的逻辑，而是在模块边界上放置位置注解，编译器根据这些注解自动生成集合通信。这与 vLLM 那种运行时动态决定并行策略的方式不同，更接近编译期确定一切。好处是通信模式在启动前就固定下来，可以减少运行时开销；代价是灵活性降低，模型结构变化时需要重新编译。README 提到这个编译器是静态的，意味着并行策略不能像某些引擎那样在运行时动态调整。如果你的模型结构频繁改动，这个编译期约束会是一个摩擦点。

内核注册表与 MLA 实现

内核被设计成可插拔的模块化子系统。它有一个便携的公共 API、一个集中式注册表，以及一个选择模型，还支持异构加速器的插件机制。这意味着引擎核心不直接绑定某个内核实现，而是通过注册表来选取合适的核。README 特别提到，这个注册表里包含一个针对 Blackwell 架构优化的 MLA（Multi-head Latent Attention）实现，据称是 agentic 工作负载下最快的之一。MLA 是 DeepSeek 等模型使用的注意力变体，能显著减少 KV cache 占用。TokenSpeed 把 MLA 作为重点优化对象，说明它瞄准的是长上下文和高效缓存利用。不过，这个“最快之一”的说法来自项目自身，没有独立的基准数据，读者需要自己验证。

启动服务与配置方式

仓库没有给出具体的安装命令，但文档索引指向 getting-started 和 launching 指南。从 README 的链接看，启动一个服务器会涉及模型 recipes，每个 recipe 定义了特定模型（比如 Qwen3.8、Kimi K3）的推荐配置。服务器参数在 configuration/server 页面，还有一组 compatible-parameters，这暗示 TokenSpeed 支持与 vLLM 或 TensorRT-LLM 兼容的参数名，以便迁移。并行配置在 serving/parallelism 页面。实际使用时，你需要先找对应模型的 recipe，然后按指南启动。由于没有直接的代码示例，具体的 CLI 命令和 YAML 格式无法从当前材料确认。建议直接打开文档站点的 getting-started 页面，那里应该包含可复制的命令。

性能声明与验证难度

新闻栏提到 TokenSpeed 在 Qwen3.5-397B-A17B 上达到 580 TPS，用于 agentic 工作负载。这个数字来自 PyTorch 博客的标题，但博客正文没有提供测试条件，比如 GPU 型号、batch size、输入输出长度分布、并发数。没有这些背景，580 TPS 只能当作营销数字。另外，多个模型在 Day 0 就得到支持，比如 Qwen3.8 Flash Next 和 GLM 5.3 Flash，这说明项目与模型厂商有合作，能提前适配新模型。但 Day 0 支持也意味着适配深度可能有限，后续版本是否持续跟进是个问题。对于想评估性能的团队，唯一可靠的办法是拿自己的负载在目标硬件上跑，并和 vLLM 或 TensorRT-LLM 做对照。

维护成本与许可证

项目采用 MIT 许可证，这意味着你可以自由使用、修改和商用，没有 copyleft 义务。但 MIT 许可证不附带任何维护承诺。仓库的最近一次推送是 2026 年 7 月，发布版本只有 v0.1.0，这说明项目处于早期阶段。控制平面是 C++ 写的，执行平面是 Python，这意味着如果你要深入修改调度逻辑，需要同时掌握两种语言，并且理解有限状态机的设计。类型系统在编译期强制资源安全，这减少了运行时错误，但也增加了编译时间和学习成本。社区支持方面，除了官方博客和 PyTorch 生态的引用，没有看到独立的社区渠道。采用前应该检查 GitHub Issues 和文档的更新频率，以判断维护活跃度。

与 vLLM 的差异和适用边界

vLLM 是当前最流行的开源推理引擎，它的调度器是 Python 实现的，使用 continuous batching 和 PagedAttention。TokenSpeed 的调度器是 C++ 状态机，编译期检查 KV cache 所有权，这是两者最根本的区别。vLLM 的优势在于生态成熟，支持大量模型和参数，社区反馈快。TokenSpeed 的优势在于性能潜力，尤其是对 MLA 的优化和静态编译的通信模式。但 TokenSpeed 的模型支持范围显然更窄，目前只列出了少数几个旗舰模型。如果你的模型不在 recipes 列表里，你可能需要自己写适配，这会是一个不小的工程。另外，vLLM 的动态并行允许你在运行时调整资源，而 TokenSpeed 的静态编译意味着每次配置变更都需要重新编译。对于快速实验和原型开发，vLLM 更灵活；对于追求极致性能的固定生产负载，TokenSpeed 值得一试。

编辑结论

TokenSpeed 适合正在运行 agentic 工作负载、且愿意接受新调度模型和编译期约束的团队。它不适合需要快速接入现有 vLLM 生态、或者只跑单卡小模型的用户，因为其设计重点在大规模并行和 MLA 优化上。在采用前，先确认你的模型在 recipes 列表中有对应配置，检查 TensorRT-LLM 与 vLLM 的兼容参数映射是否覆盖你依赖的采样参数，并用你自己的 prompt 模式跑一遍延迟和吞吐测试。该引擎的调度正确性依赖类型系统，这意味着你无法在运行时绕过 KV cache 的约束，调试方式与传统引擎不同。MIT 许可允许商用，但控制平面和内核的维护责任在你这边，社区支持尚不明确。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes