coding agent 每完成一次读文件、改代码或执行工具都会把新结果追加到已有会话再发起下一次模型调用。在两套 agent 生态的 153,951 次调用中单次新增文本的中位数约为 1.4K 字符已有上下文的中位数却达到 86K 至 123K token。模型侧的 prompt KV 缓存可以跳过未变化前缀的 prefill但前端通常仍会先把完整请求重新分词。样本集群的 prompt 缓存命中率为 94.1%在组件测量中命中率接近 0.99 时tokenization 在首 token 延迟中的占比会从 10% 升至 64%。TokTier 要消除的就是这段发生在缓存之前的全量扫描。请求向已分词的会话追加中位约 1.4K 字符现有前端会在前缀缓存生效前重新扫描完整上下文。TokTier 围绕追加内容修复会话延续罕见的初始化与重建请求走精确 GPU 路径或参考 CPU 路径影子验证器会抽样复核输出。为什么不能只给新增文本分词最直接的做法是缓存旧 token再把新 token 接在末尾。问题在于 BPE 分词的边界会跨越追加位置旧文本末尾的pipe与新增的line分开处理时是两个 token完整文本里的pipeline却可能成为一个 token。一个边界变化就会让后面的 token 位置全部偏移也会改变前缀缓存依赖的 token ID 序列。这正是长会话难以做增量分词的原因。GPT 系列分词器先做带顺序依赖的正则预分词再进行 BPE 编码数字分组、换行等规则可能让新增字符影响旧文本末尾的切分。固定截取一段重叠窗口并不能天然保证拼接正确。Llama-3.1-8B 分词器中独立分词的pipe与line会产生两个 token完整分词的pipeline产生一个 token。修复路径重新分词受影响区域只在找到稳定边界后复用缓存前缀以逐位一致的方式复现串行分词结果。增量修复如何守住参考分词器的一致性TokTier 为每个会话保存 token ID 与源字节跨度。会话延续时它只重新分词新增内容和旧上下文末尾的窗口拿新的 token 记录与缓存记录比对。只有相同运行段中出现稳定预分词边界系统才在该位置拼接校验失败就扩大窗口最多五次后回退到完整的参考分词。稳定边界的作用是给拼接提供可验证条件边界右侧的分词结果不受左侧文本影响。这样常见的小追加可以避免重扫整段上下文遇到无法确认的输入也不会为了速度输出近似 token。服务重新分词追加内容和已保存上下文的后缀匹配新旧 token 记录并检查相同运行段中是否存在稳定预分词边界检查失败时扩大窗口最终回退到完整参考分词。没有可复用前缀的初始化或重建请求只占 1.0% 至 3.6%却会携带完整上下文。TokTier 对这类请求使用 GPU 全量路径把 GPT 系列分词器的顺序正则预分词改写为可并行的字符类别、连续片段与边界判定再交给分级 GPU BPE 编码。所有路径都要求输出与冻结参考分词器一致不支持的分词器、家族检查失败和 GPU 背压时都会回到参考 CPU 路径。分割级测试比较每个预分词边界端到端测试比较最终 token ID所有比较均以参考实现为准。表中的 GPU 路径覆盖 1.50×10¹⁰ 次分割边界检查和 6.21×10⁷ 次端到端 token ID 对比并扫过 12.4 TB 真实文本增量路径包含两套公开 agent 语料中的修复重放和 15,000 次对抗性编辑。影子验证器还在外部分词器中发现过一个真实 bug因此运行时抽样比对也是这套服务的一部分。小追加和完整上下文分别能快多少在真实 Qwen3 会话文本上TokTier 的增量修复从 100K 到 3M 字符保持 0.5 至 1.1 ms 的中位延迟。以 1M 字符为例修复为 1.23 ms完全预热的 Gigatoken 为 2.53 msHuggingFace 串行分词为 318.0 ms。Gigatoken 在 100K 字符以下更快100K 到 500K 字符之间出现交叉超过这一范围后修复路径的优势扩大。在相同主机、相同 Qwen3 会话文本上每个样本只计时一次调用每个上下文规模有 24 个样本追加文本中位长度为 1.5 至 1.6K 字符。Gigatoken 使用会话前缀已完全预热的对象级缓存。完整上下文无法复用时GPU 路径在 1M 字符真实文本上的单请求中位编码延迟为 0.87 ms对应 HuggingFace 为 360.3 ms。批量完整分词的扫描吞吐为 3.8 至 4.7 GB/s。这里的增量修复“已服务上下文吞吐”和完整分词“实际扫描字节吞吐”使用不同口径原文将两者分开报告不能直接放在同一坐标轴上比较。(a) 在相同真实文本上比较单请求 P50 延迟增量修复对应在线会话的一次追加完整分词对应新请求的完整编码。Gigatoken 在完全预热模式下于 100K 至 500K 字符交叉点以下更快。(b) 报告扫描字节口径下的批量完整分词。(c) 报告单个增量修复核心的已服务上下文口径扫描口径和已服务口径使用不同坐标轴不混合比较。接入 vLLM 后收益取决于 KV 状态还在不在通过 vLLM 的prompt_token_ids接口接入后受载场景中的 TTFT 中位数降低 16% 至 34%。在一组记录到达时间的突发回放中P50 改善 27%P99 从 2,961 ms 降至 2,288 ms降幅为 23%。这些结果来自特定会话形状、负载与 KV 缓存状态不能视作所有模型服务的固定增幅。当并发会话多到引擎无法保留所需 KV 状态时前缀复用会消失两条通道都会退化为完整 prefillTokTier 的分词位置也就不再主导端到端延迟。容量测试同样需要按硬件解释4 个 CPU 修复核心加 1 块 GPU 在 50 ms P99 目标下达到 1,821 请求/秒16 核无状态 CPU 前端达到 40 请求/秒这 45 倍以上是两套不同资源配置的系统容量对比不能拆解为状态化设计本身带来的等资源效率。图中使用测量得到的请求混合与泊松到达过程每个点运行 60 秒。该分层系统在 50 ms P99 目标下达到 1,821 请求/秒无状态 CPU 配置为 33 至 40 请求/秒只有纯 GPU 前端满足 10 ms P99 目标。TokTier 的适用范围TokTier 适合长会话中反复追加少量工具输出的 agent 流量前提是服务愿意维护每个会话的 token 状态并把输出逐次与冻结参考分词器保持一致。它解决的是 KV 缓存命中后仍需全量 tokenization 的前端成本不会替代模型 prefill也不会在 KV 状态已被逐出的场景中继续缩短端到端等待。当前 GPU 路径还有清晰的尾延迟边界。Qwen3 的 4.4M 字符样本中20 个输入有 4 个未通过 GPU NFC 快速检查回到 CPU 规格化后 P90 升至 133 ms30K 至 100K 字符的大追加也会让增量修复的服务 P99 保持在 13 至 17 ms当前路由还不会自动把这类请求改走其他路径。对这类超大追加与规格化输入论文只给出了探索性改进方向完整正确性认证仍未完成。