📌 项目地址：lightseekorg/tokenspeed | ⭐ 2,396 颗星 | 🔧 Python | 📜 未标注
先说数据
GitHub 上 2396 星，Python 项目，仓库是 lightseekorg/tokenspeed。它要解决的问题很明确：给 Agent 工作负载做推理，性能对标 TensorRT-LLM，易用性对标 vLLM。
这个定位值得单独说一句。Agent 跑起来和普通聊天完全是两回事：请求并发高、上下文反复拼接和复用、KV cache 的分配与回收非常频繁。通用推理引擎在这种负载下容易暴露短板，TokenSpeed 就是冲着这个空档来的。
最有意思的设计：编译期就拦住资源错误
推理引擎里最难查的 bug 通常是 KV cache 的生命周期问题，比如某段 cache 还在被引用就被回收了，这种错误在运行时才爆出来，排查起来非常痛苦。
TokenSpeed 的做法是把请求生命周期、KV cache 所有权、overlap 时序全部写成一个有限状态机，然后靠类型系统在编译期强制保证 KV 资源的复用是安全的。也就是说，资源管理的错误在编译阶段就报出来，而不是在生产环境里变成一个深夜告警。
这套架构还有一个配套决策：控制平面用 C++ 写（要性能和正确性），执行平面用 Python 写（要迭代速度）。PyTorch Foundation 把它收进 Ecosystem Landscape 时专门点了这个设计，原话是“第一个将控制平面与执行平面分离的开源 LLM 推理引擎”。
三个核心组件
- Scheduler：就是上面说的 C++ 控制平面加 Python 执行平面，状态机加编译期类型检查。
- Kernels：算子系统做成了可插拔的分层结构，有统一的公共 API 和集中式注册表。README 里特别提到，它包含 Blackwell 架构上针对 Agent 负载最快的 MLA（Multi-head Latent Attention）实现之一。算子是独立子系统，通过插件机制支持不同的加速器。
- Entrypoint：集成了 SMG 的 AsyncLLM，用来压低 CPU 侧的请求处理开销。
公开性能数据
README 里的几个数据点都集中在最新硬件上：
- NVIDIA GB300 跑 Qwen3.8-Flash-Next，单用户 685 tokens/s（2026 年 10 月博客）
- Kimi K3 在 AMD Instinct MI355X 上的推理优化，AMD 发了官方技术文章
- Kimi K3 在 GB300 上的优化系列博客（2026 年 9 月起）
- Qwen3.8 Flash Next 在 GB300 NVL72 上用于 agentic coding，做到 Day 0 支持
NVIDIA 和 AMD 两家都有实质性的硬件和工程支持，这个待遇在开源推理引擎里不常见。
治理结构：背后没有商业公司
TokenSpeed 由非营利的 LightSeek Foundation 支持，README 自称是开源推理引擎界的“瑞士”：中立，不隶属于任何商业公司。对比一下现状就不难理解这个卖点的分量：主流推理引擎大多挂在云厂商或芯片公司名下，路线图难免受商业利益影响。如果你的团队担心被绑定，这一点值得放进评估维度。
上手前要知道的几件事
我翻了 README，它没有给出安装和使用命令。这是一个“讲架构多于讲上手”的项目，部署细节需要去仓库和 lightseek.org 的文档博客里找。入口是 AsyncLLM，风格上预期接近 vLLM 的异步接口，但具体 API 以官方文档为准，我不做编造。
还有两点要留意：性能数据全部来自 GB300 和 MI355X 这类最新数据中心硬件，上一代或消费级 GPU 上跑成什么样，得自己验证；README 没标注许可证，商用前务必去仓库确认 LICENSE 文件。
我的判断
如果你在做对推理性能敏感的 Agent 系统，手里又是较新的 NVIDIA 或 AMD 数据中心硬件，TokenSpeed 值得进评估清单。编译期安全保证加 Agent 专项优化，再加中立治理，这三样凑在一起，目前在开源推理引擎里找不出第二个。如果只是跑普通对话服务，或者硬件较旧，现阶段可以先观望，等项目文档补齐再说。