TokTier：Agent 推理的新瓶颈，竟然是分词器

当提示词缓存命中率已经做到 94.1%，为什么 Agent 的首 token 还是慢？一篇 7 月 31 日提交的论文给出了一个反直觉答案：GPU 可能没在算模型，而是在等 CPU 把几百万字符重新分词。

KV Cache 省下来了，前端却还在重复劳动

普通聊天通常一次发来一段新文本；编码 Agent 的流量完全不同。它会把很长的历史轨迹保留在请求里，每执行一次工具，只在末尾追加一小段结果，然后再次提交整段上下文。

TokTier 团队分析了两个 Agent 生态中的 153,951 次调用：一次续写的中位新增量约为 1,400 个字符，只有 1.0%–3.6% 的调用会新建或重建会话，但完整上下文最长可达数百万字符。后端能复用 KV Cache，很多前端分词器却仍从头扫描全文。随着提示词缓存命中率接近 99%，论文的组件测量显示，分词过程可从首 token 时间的 10% 膨胀到 64%。

这不是把 tokenizer 换成更快的 Rust 实现就能彻底解决的问题。Agent 请求的真正特征是“巨大旧前缀 + 很短新尾巴”，系统需要复用上一次的分词状态，而不是每轮把相同前缀重做一遍。

只重算边界，但结果必须逐 token 一致

难点在于，BPE 分词并非简单追加。新字符可能改变旧文本末尾的 token 边界，粗暴拼接会让 token ID 与完整分词结果不一致，进而破坏 KV Cache 对齐。

TokTier 的做法是保存会话上一轮的 token 序列，只在新增文本附近重新分词，并执行逐请求的“稳定边界”检查。检查通过才拼接；不通过就扩大窗口，仍不安全则退回完整分词。它追求的不是近似，而是一个明确契约：输出 token ID 必须与参考分词器从头处理全文完全相同。对无法复用前缀的新请求，系统再把 GPT 系列 tokenizer 的预分词与 BPE 搬到 GPU 上执行，并用抽样影子校验监控线上偏差。

论文在 17 个 tokenizer 家族上做了 150 亿次切分检查，覆盖 12.4 TB 真实文本和超过 9.3 万个 Agent 步骤，报告零差异。对于 10 万到 300 万字符的上下文，增量修复耗时为 0.5–1.1 毫秒，相对 Hugging Face tokenizer 最多快 437 倍；GPU 完整分词处理 100 万字符只需 0.87 毫秒。

真正重要的，是端到端延迟

接入 vLLM 后，TokTier 把首 token 中位延迟降低 16%–34%，突发流量下 P99 降低 23%。在 50 毫秒 P99 目标下，4 个修复 CPU 核加 1 张 GPU 可支撑 1,821 请求/秒，而 16 核无状态前端在 40 请求/秒就饱和。

但这些数字仍需谨慎解读：论文目前是预印本，主要基于两个 Agent 生态和特定硬件配置；引入有状态服务还会带来会话路由、状态一致性、GPU 利用率及故障恢复成本。它并不意味着每个聊天接口都该加一层 GPU tokenizer。

更值得关注的是系统优化逻辑变了。过去大家盯着模型计算、KV Cache 和投机解码；当这些环节被逐步加速，原本不起眼的 CPU 前处理会成为新的最长板。Agent 时代的推理优化，不再只是让模型算得快，而是让整条请求链少做重复工作。