lightseekorg/tokenspeed

解决什么问题

在生产环境服务大型 Agent 模型时，团队要同时压榨昂贵 GPU 的时延和单用户吞吐，还要快速接入新模型。现有引擎往往二选一：最快的那些把调度和执行揉在一个运行时里、按厂商深度调优，难改；好改的又得自己重新调性能。TokenSpeed 就是冲着这个缺口来的推理引擎，README 宣称做到 TensorRT-LLM 级性能、vLLM 级易用性，面向 Agent 负载。

有什么不同

它最大的架构赌注是把控制面和执行面拆开：调度器是 C++ 有限状态机，请求生命周期和 KV cache 的状态安全由类型系统在编译期保证；执行面留在 Python，方便快速迭代。这和把调度与执行放在同一运行时里的引擎是两套思路。内核也被当作可插拔子系统，有可移植公共 API 和集中注册表，因此项目能覆盖 Blackwell、GB200/300、MI355X、Vera Rubin 等一批加速器，并给出较快的 MLA decode 内核。另一个差异是治理结构：背后是非营利基金会而非单一商业公司，并称有 NVIDIA 和 AMD 的工程支持。性能对比只有 README 里对 TensorRT-LLM 的 Pareto 曲线图，没有可供复现的文字数字。

适合谁

适合在最新数据中心加速器上跑超大规模 MoE 模型（Kimi、Qwen、DeepSeek、GLM 一类）、以每 token 成本和 Agent 吞吐为主要指标的基础设施与推理团队，也适合需要 day-0 支持新模型并愿意一起排错的团队。不适合在消费级 GPU 上跑小模型、单机玩具部署，或需要成熟插件生态和多年实战验证的人，这些场景 vLLM 或 llama.cpp 更合适。

上手成本

门槛不低。目标硬件都是较新的加速器，语言是 Python，README 把安装和配置全部指向官方文档而不是给命令。许可证是宽松的 MIT。真正的风险是成熟度：项目只有约半年，README 内容以新闻和链接为主，没有 API 稳定性或发布节奏说明，建议锁版本并预留应对破坏性变更的时间。

点评

这是全新项目而非成熟项目，但势头很陡：不到半年约 2.8k star，本月新增 617 排到 Python 月榜第 12，却从未上过日榜。这种分布更像是基础设施从业者的集中关注，而不是大众跟风，也和厂商博客、被 PyTorch 生态接纳而非 Hacker News 讨论相吻合。架构确实有区分度，非营利基金会的背景也降低了被单一厂商绑定的风险。但现有证据都是厂商发布的基准，上生产前务必在自己的模型和硬件上验证。