聊天机器人那套推理引擎不够用了：TokenSpeed 想把 Agent 场景的缓存复用率拉到 99%

用聊天机器人的思路去服务 Agent，就像用出租车调度系统去管一支货运车队：单看每一单都没问题，放到全天候、多轮次、长上下文的真实负载里，账立刻算不平。

在 AICon 2026 深圳站上，TokenSpeed 独立贡献者尚旭春把这件事讲得很透：Agent 负载和 Chat 负载是两种生物，前者由多轮短请求组成，第一次可能带着几十 K 的前缀上下文，后面每轮只输出几百个 token。继续按“把 batch 打满、最大化吞吐”来优化，等于把力气用错了地方。

一分钟速览

• Agent 推理的特征是多轮短请求、长前缀、低单次输出，传统聊天引擎的优化目标失效。
• TokenSpeed 把目标改成“延迟约束下的吞吐”：每用户 TPS 不低于 70。
• 对比 TensorRT-LLM：batch=1 时端到端快 9%，每用户 100 TPS 时单卡吞吐高 11%。
• KV Cache 复用率被视作成本关键，DeepSeek 据称已达 99% 以上，业界多数只有 70%–80%。
• 上下文从 128K 扩到 1M，解码吞吐只下降 16%。

为什么旧引擎会“全面失效”

传统 Chat 场景里，一次请求生成一段完整回复，KV Cache 加载后很快释放，复用率天然不高也没人计较。但 coding agent 是另一回事：模型思考、调用工具、拿结果、再思考，几十 K 的上下文会被反复命中。如果每次都要重新 prefill，GPU 的时间就烧在了重复计算上。

所以 TokenSpeed 的优化目标不是单纯追求吞吐峰值，而是在保证“跟手性”的前提下提高单卡产出。用户对延迟非常敏感，推理环节慢半拍，整个 Agent 的体验就会垮掉。

三层改造：架构、编译、Kernel

项目走的是分层解耦路线。最上面把调度、缓存、执行拆开，让不同模块可以独立演进；中间做自动并行编译，把模型结构映射到不同硬件的并行策略；最下面针对 Kernel 做优化，并为不同平台保留抽象层，避免被单一硬件绑死。

这套设计的意义在于，Agent 负载变化快，模型和硬件也一年一换。如果引擎把假设写死在某代 GPU 或某种注意力实现上，下一代就得重写。分层之后，至少可以把变化关在局部。

KV Cache 才是成本开关

尚旭春给了一个很直白的判断：缓存复用率决定推理成本。同一段几十 K 的上下文，每命中一次就省掉一次 prefill；命中率从 70% 提到 99%，省下来的不是零头，而是整块算力。随着线性注意力等新结构普及，缓存管理还会更复杂，谁能把“跨轮次增量复用”做扎实，谁就更接近可用的 Agent 基础设施。

目前 TokenSpeed 已在 Blackwell 平台给出阶段性数据，但距离生产级还有路要走：多租户隔离、故障恢复、与上层 Agent 框架的配合，都不是单点优化能解决的。

趋势洞察

过去两年，推理引擎的竞争集中在“谁的吞吐更高”。Agent 普及之后，评价标准正在变成“谁能在延迟约束下，把长上下文的重复计算省掉”。这会倒逼引擎厂商重新设计缓存、调度和硬件适配，也会让“每用户 TPS”这类指标取代单纯的 tokens/s，成为采购时更现实的参考。

参考：InfoQ 演讲实录