TokenSpeed面向Agent重构LLM推理引擎

Agent工作负载正在改变大语言模型推理引擎的优化方向。与一次生成完整答案的聊天请求不同，coding agent通常会反复进行思考、调用工具和处理结果，形成多轮短请求：首轮可能携带数十K上下文，后续输出却只有数百个Token。因此，系统需要同时优化延迟、吞吐、缓存复用和硬件适配。TokenSpeed将每用户TPS不低于70作为约束，测试显示，batch size为1时端到端延迟较TensorRT-LLM降低9%，每用户100 TPS时单卡吞吐提升11%。

在缓存方面，项目关注跨轮次前缀复用。其测试表明，上下文从128K扩展到1M时，解码吞吐率仅下降16%。对于采用Gated DeltaNet、KDA等线性注意力机制的模型，缓存对象还从传统的Token级KV对转变为持续更新的SSM状态和卷积状态，推理引擎必须支持这些状态的保存、恢复与增量更新。面对拥有896个专家的MOE模型，以及Blackwell的Tensor Memory和新一代Tensor Core等特性，项目也对Kernel进行了针对性优化。

TokenSpeed采用控制面、Runtime和Kernel三层架构。控制面使用C++负责调度决策，Runtime以Python执行计划并连接PyTorch、CUDA等生态，Kernel则独立实现底层算子。这样的边界划分让调度、执行和硬件优化彼此解耦，NVIDIA与AMD工程师可以分别针对平台特性优化，而无需深入其他模块。

项目还将模型并行逻辑抽离为独立的Placement系统。开发者只需声明模块边界、输入输出类型及replicate、shard、partial等并行属性，编译器便会分析相邻模块并自动插入通信：partial到replicate使用all-reduce，shard到replicate使用all-gather，shard到partial使用reduce-scatter。最终生成统一执行计划，并在prefill、模型计算和输出通信阶段运行；类型信息也为算子融合创造条件，能够减少Kernel启动开销。

控制面的核心是覆盖请求全生命周期的C++状态机，请求会依次经历submitted、prefilling、decoding，以及retracting/timeout和finished等状态。每个状态持有对应的KV页、SSM或MLA槽位资源，状态切换时同步转移所有权。事件驱动机制配合unique_ptr move语义和RAII管理引用计数，使资源路径能够在编译阶段接受检查，降低缓存页泄漏、异常路径计数错误等并发调度问题。

调度器与执行面保持独立，只负责决定何时推进请求、何时触发撤回；Runtime按照计划执行缓存操作和前向计算，再将结果返回控制面。这样既便于单独迭代调度策略，也避免底层Kernel调整牵动上层逻辑。项目的整体目标，是让推理引擎更适合Agent持续交互、长上下文复用及新型模型和硬件的协同优化。