**TokTier：精确状态感知分词机制，Agent场景提速491倍！**
TokTier: Exact Stateful Tokenization for Agentic LLM Serving
在当前的大语言模型服务架构中，前缀缓存（Prefix Caching 或 KV Cache）已经成为降低推理延迟的标配。当模型处理多轮对话或长上下文时，前缀缓存能够有效复用已经计算过的状态，避免重复的预填充（Prefill）计算。然而，研究人员发现了一个长期被忽视的系统错位：尽管模型引擎后端能够高效重用 KV 状态，但大多数服务的前端在每次调用时，依然会对完整的请求文本进行从头到尾的重新分词（Tokenization）。
ArXiv URL：https://arxiv.org/abs/2607.29678
这种错位在基于代码智能体（Coding Agent）的场景中造成了极其高昂的代价。现代智能体工作流通常表现为深度的循环操作：读取文件、修改代码、运行工具、观察结果，然后决定下一步动作。在这样的工作流中，每一轮模型调用都会携带极其庞大的历史上下文，而每次工具运行的结果只会在末尾追加一小段文本。当系统层面的提示词缓存命中率逼近百分之百时，预填充的耗时被无限压缩，而前端全量分词的耗时占比则急剧上升。在极端情况下，分词甚至占到了首字延迟（Time to First Token, TTFT）的百分之六十四。
为了打破这一性能瓶颈，研究人员提出了 TokTier。这是一种精确的状态感知分词服务，其最核心的承诺是：在任何情况下，系统输出的 Token ID 序列都必须与完整请求文本在参考分词器（如 Hugging Face 分词器）下的输出保持绝对一致，实现零偏差。通过引入针对会话延续的增量修复机制，以及针对全新长文本的无状态 GPU 并行分词算法，TokTier 在保持数学级别精确的前提下，将百万字符级别的分词速度提升了惊人的四百九十一倍。
本文将深入拆解 TokTier 的系统设计，剖析大模型服务前端所面临的真实负载特征，并详细解读增量修复与 GPU 加速分词背后的核心机制，看看这项工作如何将 Agent 场景下的系统吞吐量推向新的高度。
智能体时代的负载陷阱：巨大的上下文与微小的增量
要理解分词为什么会成为大模型服务的核心瓶颈，首先需要审视真实世界中智能体调用的负载特征。在传统的多轮对话中，用户每次输入的文本长度相对可控。但在 Agent 场景中，单个用户的指令往往会裂变为几十次连续的模型调用。这些调用以机器的节奏高频到达，且历史转录文本在每一轮中单调递增。
研究人员对来自两个独立 Agent 生态系统的十五万次真实调用进行了深度追踪与分析。数据揭示了一个极具反差的现象：在绝大多数调用中，系统追加的新文本非常短小。统计显示，中位数级别的调用仅仅会在已有上下文中追加约一千四百个字符，但这些调用所背负的历史上下文却高达八万到十二万个 Token。随着会话的深入，上下文规模甚至会膨胀到百万字符级别。
上图展示了交互式调用中上下文大小与新增 Token 数量的联合分布。可以清晰地看到，绝大多数的数据点（代表会话延续）密集地分布在对角线的下方一到三个数量级的位置。这意味着，对于绝大多数请求而言，新增文本的长度远远小于总上下文的长度。如果使用传统的线性复杂度分词器，一个单调递增的会话将会累积产生平方级别的计算开销。模型后端只需处理少量未缓存的后缀，而前端分词器却在极其低效地反复扫描整个长篇巨著。
此外，研究人员还观察到，工作负载中存在另外一种截然不同但同样关键的调用模式：会话初始化与历史重建。这类请求在整体流量中的占比极低，仅为百分之一到百分之三点六。然而，它们到达时通常没有可复用的前缀缓存，且直接携带高达百万字符的完整上下文。这类请求往往在系统发生状态迁移或大规模任务并发启动时爆发，如果不加以妥善处理，会瞬间引发严重的尾部延迟。
基于上述负载特征，理想的分词系统必须具备两种截然不同的执行策略。对于占据绝对主导地位的会话延续请求，系统需要执行增量修复，使其计算量严格正比于新追加的文本长度；而对于罕见但巨大的全量上下文请求，系统必须能够吸收瞬时的大规模吞吐压力，避免拖垮整体服务。
分词操作的非组合性难题
既然绝大部分请求只是在已有文本末尾追加了一小段新内容，为什么现有的系统不能直接把新文本分词后拼接到旧的 Token 序列上？这是因为分词操作在本质上是不具备组合性的（Non-compositional）。
假设有两个字符串 A 和 B，对它们分别进行分词然后再拼接，其结果往往不同于将它们先拼接再进行整体分词。现代字节对编码（BPE）分词器通常包含两个阶段：首先是预分词器（Pre-tokenizer）利用正则表达式将文本切割成短片段（Pieces），然后是 BPE 算法对每个片段独立进行子词合并。当新的文本 B 追加到文本 A 之后时，预分词器极有可能在两者的交界处移动原有的片段边界。
例如，原本位于文本 A 末尾的一个单词，可能会因为文本 B 首字母的加入，在预分词阶段被重新划分为不同的基础片段。这种边界的改变会产生连锁反应，直接导致后续的 BPE 合并逻辑发生翻天覆地的变化。论文中给出了一个生动的例子：单词“pipeline”内部如果在追加时产生了一个新的边界，可能会把原本的一个参考 Token 变成两个完全不同的 Token。
更为棘手的是，简单的固定窗口重叠试探法并不能解决这个问题。由于现代分词器中存在数字分组、空白符前瞻（Whitespace Lookahead）以及换行符吸收等复杂的规则，边界的改变可能会跨越任何人为设定的固定重叠半径。如果前端分词器输出了哪怕一个错误的 Token ID，都会导致生成的序列与大模型训练时所见的标准序列产生偏差。更严重的是，由于前缀缓存是直接使用 Token 序列作为键（Key）来进行索引的，一个错误的 ID 会悄无声息地使得后续所有文本的 KV 缓存全部失效，造成灾难性的性能回退。
因此，为了保证大模型服务的性能和准确性，生产级系统必须确切地知道，在什么条件下拼接缓存的前缀是绝对安全的。当这个条件无法被严谨证实时，系统必须具备安全回退的能力。这也是为什么此前许多尝试对分词进行优化的开源项目（如 Gigatoken 等），因为只能将边界稳定性建立在工程假设之上，而无法提供严格的正确性保证。
状态感知与增量修复：将全局扫描降维为局部手术
为了彻底解决计算冗余问题，TokTier 引入了精确的状态感知增量修复机制。该机制的核心思想是维护活跃会话的生命周期状态，并在追加文本到达时，仅在修改点附近寻找数学意义上绝对安全的“稳定边界”。
TokTier 作为介于请求路由器与模型引擎之间的独立服务，会在内存中保留每个活跃会话的 Token ID、对应的原始字节跨度（Byte Spans）以及分词器的哈希值。当一个会话延续请求到达时，系统并不会去扫描上百万字符的完整上下文，而是提取出新追加的文本，再加上旧文本末尾一小段后缀窗口。随后，系统仅对这个小窗口内的文本进行重新分词。
重头戏在于新旧序列的比对与“稳定边界检查”（Stable Boundary Check）。系统会将窗口内重新分词产生的新 Token 记录，与状态库中缓存的旧 Token 记录进行逐一比对。只要在这段完全相等的匹配区域内，系统能够找到一个确定的稳定边界，修复就可以宣告成功。所谓稳定边界，是指预分词器在进行正则表达式匹配时，在数学和逻辑上绝对无法跨越的文本界限。
一旦检测到稳定边界，这就构成了严谨的理论证明：无论该边界右侧追加了什么复杂的内容，都绝不可能逆向影响到边界左侧的片段划分和 BPE 合并。此时，TokTier 就可以放心地将边界左侧的缓存 Token 序列，与边界右侧新鲜计算出的 Token 序列进行硬拼接。如果在一个窗口内没有找到稳定边界，系统会将窗口大小翻倍并重试，最多重试五次。如果依旧失败，才会回退到对完整文本进行全量参考分词。
这种设计确保了系统在最坏的情况下只会损失一定的计算时间，但绝对不会输出错误的 Token 序列。从实际运行的数据来看，这种回退极其罕见。在针对真实 Agent 流量的回放实验中，五万六千零五十二次追加请求中，有五万六千零四十九次在第一个初始窗口就成功完成了拼接，仅有三次需要扩大一次窗口，没有任何一次请求触发了全量重分词的回退。
通过这种局部手术般的修复机制，TokTier 成功将分词的时间复杂度从与完整上下文长度正相关的全局级别，断崖式降低到了仅与新增文本和极小窗口长度相关的局部级别。这种优化在动辄百万 Token 的上下文中，展现出了摧枯拉朽的性能优势。
突破序列依赖：重构 GPT 预分词正则逻辑实现 GPU 并行
尽管增量修复完美解决了高频微小追加的问题，但系统依然需要面对那百分之一到三的会话初始化与历史重建请求。对于这类动辄包含几十万甚至上百万字符的全量请求，单纯依赖 CPU 进行处理会产生极高的长尾延迟。将这种重负荷计算卸载到 GPU 上，是提升系统吞吐量的必由之路。然而，GPT 家族的分词逻辑在设计之初，就给 GPU 并行化设置了天然的障碍。
GPT 风格的预分词器通常被定义为一个带有回溯的“最左优先交替正则表达式”。在直接的实现中，正则匹配是强顺序依赖的：下一次匹配的起点，严格取决于上一次匹配的终点。这种从左到右的强串行依赖，意味着你无法将一段长文本任意切分成多个数据块丢给 GPU 的不同计算核心同时处理。如果强行切分，又会回到我们在前面讨论过的边界非组合性难题，导致切分缝隙处的 Token 划分出错。
由于这个顺序依赖问题极难攻克，此前业界发布的绝大多数 GPU 分词器（如基于近似算法或不同规格的实现）都采取了妥协策略：要么放宽预分词阶段的严格性，要么采用完全不同的匹配策略。妥协的代价就是牺牲了与参考分词器的严格等价性，这在对准确率和缓存命中率要求极高的大模型生产环境中是不可接受的。
TokTier 采用了一种被称为“运行域分解”（Run Decomposition）的创新数学转换方案，彻底打破了这一僵局。研究团队将复杂的串行正则表达式，重构为等价的局部规则。具体而言，系统首先会对输入文本进行字符分类，将其划分为多个极大的“字符类运行段”（Maximal Character-class Runs）。
在这个全新构建的逻辑框架下，每一个基础片段的起始位置，不再需要从文本最开头一路推演过来，而是仅仅取决于当前字符在它所属运行段中的相对位置、极少量的相邻文本特征，以及几个运行段级别的宏观摘要状态。这种分解不仅在数学上严格保留了原有串行正则表达式的所有输出特征，更重要的是，它彻底解除了数据块之间的长距离计算依赖。
解除了串行封印后，TokTier 成功将预分词和核心的 BPE 编码流水线全部部署到了 GPU 上。得益于显卡海量的并行计算核心，系统在处理全量长文本时展现出了惊人的爆发力。实验结果显示，在处理一百万字符的超长请求时，GPU 路径仅仅需要零点八七毫秒即可完成全量编码，这一速度不仅比最快的前沿 CPU 方案快了二十三点四倍，更是将传统 Hugging Face 默认分词器的处理速度甩开了四百九十一倍之多。
严格的零偏差验证与系统级吞吐量跃升
大模型基础设施的任何底层替换，都必须建立在绝对的可靠性之上。为了证明 TokTier 在保持极限速度的同时没有牺牲任何一丁点准确性，研究团队进行了一场堪称严酷的差分验证（Differential Campaigns）。
验证范围覆盖了多达十七个生产级分词器家族。研究人员不仅动用了合成与对抗性文本输入，更是对高达十二点四太字节（TB）的真实文本语料库进行了全量扫描比对。在高达一百五十亿次的分裂检查，以及九万三千多次真实 Agent 运行步骤的重放测试中，TokTier 生成的 Token 序列与官方参考分词器的输出保持了百分之百的一致，实现了真正的零偏差（Zero Divergence）。
为了防范由于复杂执行历史积累导致的隐蔽状态缺陷，TokTier 还独创性地在生产环境中部署了一个异步的“影子验证器”（Shadow Verifier）。该验证器会在后台按比例对实时流量进行采样，将其处理结果与参考分词器进行在线比对。通过这种从静态测试集到动态生产流量的全面覆盖，系统在工程上构筑了坚不可摧的正确性防线。
在剥离了理论层面的微观指标后，系统级的端到端表现才是衡量基础设施价值的最终标尺。研究团队将 TokTier 部署在了著名的开源大模型推理引擎 vLLM 的前端，并使用真实的突发流量模式进行了严苛的压力测试。
实验数据显示，在十万到三百万字符的巨大跨度下，增量修复机制能够始终将处理延迟死死压制在零点五到一点一毫秒的极窄区间内。相比于最强的基于缓存优化的基线方案（如 Gigatoken 在其最有利的全面预热模式下），TokTier 在一百万字符级别依然取得了二点一倍的速度领先。
在包含引擎完整处理流程的宏观视角下，前端瓶颈的消除为整体服务带来了立竿见影的收益。在高负载运行域中，中位数首字延迟（TTFT）显著下降了百分之十六到百分之三十四；在面对突发请求洪峰时，反映系统稳定性的 P99 尾部延迟也大幅缩减了百分之二十三。
最为震撼的对比体现在系统的极限吞吐量上。如果以保持五十毫秒的 P99 延迟作为严格的服务等级目标（SLA），一个传统的配备十六个 CPU 核心的无状态前端，在达到每秒四十次请求时就已经彻底饱和崩溃。而采用 TokTier 架构后，仅仅依靠四个 CPU 核心组成的状态修复池，再辅以一张用于吸收极端长文本的 GPU，系统就能在这个严苛的延迟红线内，从容支撑高达每秒一千八百二十一次的并发请求。
通过精巧的状态管理与严谨的正则解耦，TokTier 成功在完全不改变模型训练输出契约的前提下，将分词这一大模型服务中最不起眼却又最致命的性能顽疾彻底拔除。随着大语言模型上下文窗口的持续膨胀，以及智能体循环调用模式的日益普及，这种精确且状态感知的底层重构，必将成为下一代 AI 基础设施的标准化基石。