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 ms，HuggingFace 串行分词为 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 状态时，前缀复用会消失，两条通道都会退化为完整 prefill，TokTier 的分词位置也就不再主导端到端延迟。容量测试同样需要按硬件解释：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 ms；30K 至 100K 字符的大追加也会让增量修复的服务 P99 保持在 13 至 17 ms，当前路由还不会自动把这类请求改走其他路径。对这类超大追加与规格化输入，论文只给出了探索性改进方向，完整正确性认证仍未完成。