Delta Tokenizer：会话增量与多核并行如何让长提示词分词提速40倍

被忽视的前端瓶颈：为什么KV缓存救不了分词

在Agent驱动的LLM应用中，同一个会话被反复送给模型，每轮只追加少量文本。推理引擎通过KV缓存复用共享前缀，让新token直接跳过重复计算。问题在于：分词环节没有这样的捷径。

服务引擎的CPU前端每次都要从第一个字符开始，把整个请求重新转换成token ID。多轮对话越长，这个重复劳动越昂贵，它同时拉高了首token延迟（TTFT）并持续占用CPU。据rss来源介绍，Delta Tokenizer正是针对这一前端瓶颈设计的CPU分词方案。

Delta Tokenizer 论文来源页面

TTFT（Time To First Token，首token延迟） 指从请求发出到模型返回第一个生成token的时间，是交互式LLM应用最敏感的用户体验指标之一。它由两段构成：前端的请求预处理（分词、拼接prompt）和后端的prefill计算（对输入序列做注意力前向）。KV缓存只优化后者——通过复用历史token的key/value张量跳过重复的prefill。但如果前端分词本身就要花掉几十到几百毫秒，尤其是当请求有数十万token、CPU前端被多个长请求排队占满时，这部分时间无法被GPU侧的优化掩盖。这正是文章强调“优化空间不止在GPU侧”的原因：TTFT是一条串联流水线，任何一环成为瓶颈都会直接体现为端到端延迟。

增量路径：只编码“变化的尾巴”

Delta Tokenizer的核心思路很直接——只对当前请求与同一会话上一请求之间的delta做分词。

它保留此前的token序列，仅重新编码追加的文本，以及一段可能受追加影响的“短尾部”，然后在一个分词器自身切分规则无法移动的位置上把两段拼接起来。这个拼接位置的选择是保证结果精确性的关键：只要连接点落在分词规则不会跨越的边界上，增量输出就与从头编码的结果逐字节一致。

这一设计直接回应了分词器的一个特性：大多数实用分词器的切分决策是局部化的，相邻片段之间存在天然的独立边界。找到并利用这些边界，就能在不停用参考实现的前提下做增量。

分词器的局部性（tokenization locality） 是现代BPE/Unigram类分词器的一个底层性质：一次切分决策通常只依赖有限的上下文窗口，合并规则不会跨越任意远的字符边界。正因为如此，一个长文本被切开后分别编码，再拼接起来，结果往往与整体编码一致——前提是切点落在“合并规则不会跨越”的位置。Delta Tokenizer的增量拼接正是利用这一点：它保留旧token序列，只重编码追加文本，并在一个规则稳定的边界上把新旧两段缝起来。这里的“短尾部”指的是追加文本可能改变原序列末尾几个字符的切分方式，因此也必须一并重算，直到遇到一个正则或合并规则无法触及的锚点为止。

长请求的分段并行：把四百万字符摊到16核

对于没有状态可复用的长请求，Delta Tokenizer走了另一条路——分段并行编码。

它按照实用分词器本就保持相邻片段独立的位置切分文本，把各段分发到多个核心上同时编码，再把输出拼接成与参考编码完全一致的结果。在16核环境下，编码一个400万字符的请求比串行编码快8.2倍，比LoPT快1.6至2.1倍。

值得一提的是它的调度设计：一个共享CPU池同时管理长请求的分块和短的增量更新，让一次增量更新可以插在两个分块之间执行，而不必排在整段长任务之后。这种细粒度调度对混合负载下的尾延迟尤为关键。

实测收益：TTFT降幅与正确性验证

性能数据来自多个维度：

增量路径相对Hugging Face参考分词器，把单轮会话的分词时间缩短约40倍
在SGLang内部，聊天接口的中位TTFT在100K token时降低59%
负载下Agent会话的P99 TTFT下降9.5倍；当前端被长请求占满时，这一数字达到23倍

正确性方面，作者表示每一个检查过的输出都与参考实现匹配，其中包含由其快速编码器处理的418亿份文档。这个规模的一致性验证，说明增量拼接与分段拼接的策略在真实语料分布上没有引入偏差。

对推理服务的启示

Delta Tokenizer揭示了一个容易被忽略的事实：在KV缓存、注意力优化、量化等环节被反复打磨之后，分词这个“前处理步骤”仍可能是TTFT的重要贡献者，尤其是在长提示词和Agent多轮场景中。

对推理引擎开发者而言，这意味着优化空间不止在GPU侧。把增量复用和分段并行引入CPU前端，并与CPU池调度结合，可以在不改动模型和输出语义的前提下拿到可观的延迟收益。对依赖Agent会话的产品来说，P99延迟的大幅下降往往比中位数更能决定用户体验是否稳定。

P99尾延迟指把所有请求的响应时间从小到大排序后，第99百分位对应的值，代表最慢的1%请求有多慢。在Agent多轮会话场景中，用户往往在前一轮响应结束前就发起下一轮，形成连续交互流，任何一轮的卡顿都会破坏体感连贯性。中位TTFT下降说明典型情况变好，但P99下降才说明“最坏的那批请求”也被拉回可接受区间——这正是长请求占满CPU前端时Delta Tokenizer带来23倍改善的意义。对于高并发推理服务而言，尾延迟常由排队和资源争抢主导，因此像文章提到的共享CPU池、细粒度插队调度这类机制，往往比单请求加速更能决定整体SLA是否达标。