论文导读
亚利桑那州立大学提出Delta Tokenizer，为多轮对话保存已验证的分词状态，只重新处理新增文字和可能变化的尾部。在56052次追加回放中，仅3次需要扩大修复窗口，返回的Token序列仍与完整参考编码一致，让长对话的CPU前端有机会摆脱每轮重算历史的负担。
GPU记住了上文，CPU却又从头读一遍
一段对话已经积累十万Token，新一轮只追加一句话。模型端可能用缓存复用大部分上下文，但服务前端仍要把完整文本转换成Token编号。此时，CPU分词就可能变成首个Token到达之前的一道等待。
论文分析了153951次编码代理调用：大部分输入Token命中提示缓存，而典型追加文本远小于历史上下文。给服务更多CPU核也不一定缩短单个请求，因为参考分词调用本身仍在一个核心完成。
图：复用会话、并行长请求、调度分块与接入服务引擎的四项机制示意。
Delta Tokenizer给会话保留文本、Token编号和尾部位置等状态。下一轮到来时，先核对配置与历史前缀是否一致，再尝试只重编码尾部与新增文本。如果模板改动了前面的内容，旧状态就不能继续使用。
只接新Token不安全，边界还会变化
旧文本以pipe结束，新文本补上line，两段拼起来可能被编码成不同Token。空格、数字、特殊标记或字符归一化也会影响边界。因此，直接保留旧Token、再附加新文字的Token，并不能保证与完整编码一致。
方法先取旧文本的一段尾部，与新增文本一起编码，再寻找经过检验的稳定接缝。比较不仅看Token编号，也看源文本位置与顺序；失败就扩大窗口，必要时交给参考路径处理。
图：重新编码尾部与新增文本，在稳定过渡处对齐并拼接Token序列。
默认512字符只是第一次尝试的窗口大小，不是“任何边界变化最多影响512字符”的承诺。论文的56052次追加回放中，仅3次需要扩一次窗口，但正确性依靠检验规则，而不是依靠大多数样本碰巧容易。
对必须完整编码的新会话或无状态长请求，系统另找安全切点，把工作分成可以并行和调度的小块。短请求便有机会插在长请求的块之间执行，减少排队尾延迟。
省的是前端等待，别写成模型推理快几十倍
在SGLang的一组混合负载中，暖会话与百万字符长请求共享前端。长请求先分词、再因超出上下文被拒绝，主要用来隔离前端干扰。暖会话P99首Token延迟从参考方案1441毫秒，降到串行Delta的166毫秒、池化方案63毫秒。
图：混合前端负载下不同方案的暖会话P99首Token延迟和延迟分布。
这组差距不能推广为所有线上请求加速。论文还测试了能被模型实际接收的新长文；若瓶颈转到GPU预填充，三种分词方案的P99都约5.2至5.4秒，前端优化并没有消除那段等待。
一致性检查覆盖完整Token编号序列，作者报告大规模整文编码与分块检验中没有观察到差异。适配仍要求冻结并验证具体分词器配置，不支持的配置回到参考实现；字符归一化触发慢路径时，也要保住结果一致。
项目仓库当前介绍的TokTier功能与论文中的CPU方案已有扩展，本文实验数字以论文所述版本和设置为准。服务接入时，首先应确认会话历史是否真的可复用，再分别测量分词、排队与GPU阶段耗时。
参考资料
https://arxiv.org/abs/2610.19801
https://arxiv.org/html/2610.19801
