TokTier：面向智能体LLM服务的精确有状态分词系统-171主机测评

TokTier：面向智能体LLM服务的精确有状态分词系统

论文arXiv编号：arXiv:2607.29678v1

摘要

当前LLM推理服务系统虽能复用KV前缀缓存，但前端分词模块每次请求都会对完整文本重新分词，在代码智能体场景下性能损耗极其严重。这类智能体会话会持续追加少量工具返回文本，完整上下文长度可达百万字符，而每轮调用都要全量扫描文本。

基于153951条真实智能体调用轨迹统计：单次调用平均仅追加1400字符，仅1.0%~3.6%的请求为全新会话初始化；集群整体KV缓存命中率达94.1%，当缓存命中率逼近99%时，分词耗时占首Token生成总耗时的比例从10%飙升至64%。

本文提出TokTier，一套严格保证分词结果与标准参考分词完全一致的有状态分词服务，区分两类流量做差异化处理：

会话续传增量修复：保存历史分词序列，仅对追加文本附近窗口重新分词，校验稳定边界合法后拼接新旧Token；校验失败则扩大窗口，最坏降级为全量标准分词。

无缓存全新会话GPU精确分词：将GPT系列串行正则预分词重构为可并行的字符段分解算法，在GPU上无损执行预分词+BPE编码。
在这里插入图片描述

核心验证指标

正确性：覆盖17种主流分词器家族，完成1.5×10¹⁰次分割校验、12.4TB真实文本全量扫描、93000+智能体轨迹回放，全程零分词结果偏差。

增量修复性能：10万_{300万字符上下文单次修复耗时仅0.5}1.1ms；相比HuggingFace分词最高提速437倍，100万字符场景下比最优CPU缓存分词GigaToken快2.1倍。

GPU全量分词：100万字符文本编码仅0.87ms，比业界最优CPU方案快23.4倍，比HF分词快491倍。

端到端推理：对接vLLM后，负载场景中位数首Token延迟降低16%~34%，突发流量P99延迟下降23%；4核修复池+单GPU可支撑1821请求/秒（P99延迟50ms约束），同等约束下16核无状态CPU前端仅能承载40请求/秒。

本文三大创新贡献：

首次针对代码智能体完成会话粒度分词负载刻画，明确流量以少量追加、极少量全新初始化为主；

设计可证明无损的增量修复+GPU无损并行分词双路径架构，严格对齐标准分词输出；

构建分层校验体系（单请求边界校验、大规模差分测试、运行时影子验证），并基于vLLM完成完整服务链路验证。

1 引言

1.1 智能体场景的分词性能痛点

代码智能体会循环执行「读取文件→编辑→运行工具→观察结果」多轮LLM调用，单条用户指令可衍生数十轮模型请求，每轮都携带完整历史会话文本，仅末尾追加少量工具输出。

现有架构存在核心矛盾：模型层通过前缀KV缓存复用历史计算，但前端分词每次全量扫描完整上下文。在实测智能体流量中，94.1%的Token可被KV缓存命中，但分词仍需扫描数十万字符历史文本。上下文越大、缓存命中率越高，分词带来的性能开销占比越高。

智能体流量分为两类：

会话续传（96.4%~99.0%请求）：基于已有会话追加少量文本，理想分词仅需处理新增Δ字符，现有方案却处理完整N字符上下文；
全新会话初始化（1.0%~3.6%请求）：无历史缓存，上下文可达百万字符，并发初始化会造成CPU分词阻塞。

1.2 传统增量分词的致命缺陷

分词不具备拼接不变性：tok(A)+tok(B) ≠ tok(A+B)。追加文本B会改变A末尾的子词分割边界，例如pipe单独编码为一个Token，追加line后合并为pipeline单个Token，简单拼接会破坏Token序列，直接导致KV缓存失效。
固定重叠窗口启发式方案无法彻底解决问题：数字分组、换行、空白符前瞻等规则会让边界影响扩散至任意长度，不存在固定安全窗口半径。现有LoPT、GigaToken等工业缓存分词均未提供严格无损的拼接证明。

1.3 TokTier核心约束

所有路径输出Token ID必须与官方参考分词（HuggingFace标准实现）完全一致，任何优化路径校验失败均降级至标准CPU分词，绝不输出近似结果。

续传流量：增量窗口重分词+稳定边界证书校验，合法拼接历史Token；

全新大上下文流量：GPU并行无损预分词+BPE，规避串行CPU瓶颈；

全链路运行时影子校验，实时捕获依赖历史状态的分词Bug。

2 负载与背景分析

2.1 分词在推理链路中的位置

完整推理前端流程：文本预处理→归一化→预分词→BPE子词编码→输出Token ID送入模型KV缓存。KV缓存复用发生在分词完成之后，高缓存命中率无法降低分词开销。
Token ID是KV缓存的索引键，任何分词偏差都会导致缓存失效、模型输出偏移，因此所有优化方案必须保证输出与参考分词完全等价。

2.2 数据集与轨迹来源

主轨迹数据集：6位用户、9台机器10个月Claude Code / Codex CLI日志，共153951条调用；日志仅统计文本长度、丢弃原始文本，用户ID通过HMAC哈希脱敏，过滤26578条重复伪造日志（占原始数据14.7%）。

三方校验数据集：

服务商侧51.2亿Token聚合轨迹，集群Token加权缓存命中率94.1%；
SWE-Bench Pro公开智能体轨迹：20230条调用，缓存命中率94.2%；
TraceLab数据集：4265个会话、35.7万步调用，仅统计上下文长度、无原始文本。

三份数据源无重叠用户、采集链路独立，关键指标完全吻合，验证负载特征通用性。

2.3 流量核心特征

绝大多数请求为少量追加、超大上下文

交互式轨迹中位数追加1400字符，自主智能体中位数追加3800字符；
会话中位数上下文：Codex 86K Token、Claude Code 123K Token，上限10⁶ Token；
单请求完整上下文/新增字符比值中位数132，加权均值23.5，每次调用需多扫描百倍冗余文本；
单次用户思考会衍生3~103轮LLM调用，O(N)全量分词会让会话总复杂度变为O(N²)。

在这里插入图片描述

全新初始化请求占比极低但负载极高
仅1.0%~3.6%调用无历史会话缓存，集中在会话新建、历史压缩、worker会话迁移场景；单条初始化上下文可达百万字符，突发批量初始化会打满CPU分词资源。

会话分词状态生命周期长于KV缓存
用户两轮交互间隔中位数3.6~6.4分钟，55% Claude、42% Codex交互间隔超过KV默认5分钟TTL；分词存储仅需16字节/Token，远低于KV显存开销，可持久保存会话Token序列，KV缓存失效后仍可毫秒级修复Token。

2.4 系统设计硬性需求

会话续传路径工作量仅与新增Δ相关，不随完整上下文N线性增长；

大初始化请求GPU分流，消除CPU长尾延迟；

多版本分词器并行兼容（线上同时存在12+模型分词版本）；

严格等价于标准分词输出，禁止近似分割。

2.5 现有方案资源瓶颈

主流Rust高速分词在0.5请求/每GPU负载下，每千块推理GPU需6.7颗前端CPU核心；三大趋势持续放大开销：单GPU吞吐提升、上下文窗口扩容、KV缓存命中率持续上涨，模型层优化无法缓解前端分词瓶颈。

3 系统整体设计

TokTier部署在请求路由与vLLM等推理引擎中间，接收{文本,模型ID}输入，输出与参考分词完全一致的Token ID；基于会话状态命中与否分流三条处理链路。

在这里插入图片描述

3.1 路由分流逻辑

会话状态命中（绿色链路：增量修复）：存在同分词版本的历史会话Token、字节偏移序列；仅重分词追加窗口，校验稳定边界后拼接；校验失败扩大窗口，最多重试5次后降级全量分词。

会话状态未命中、大文本（蓝色链路：GPU全量分词）：无历史缓存、上下文超过2KB；GPU无损并行完成预分词+BPE；如需生成字节偏移（用于新建会话存储）则自动切CPU参考路径。

会话状态未命中、小文本 / GPU异常 / 修复降级（灰色链路：标准CPU分词）：HuggingFace原生参考实现，作为兜底正确性基线。

影子校验支路：5%流量采样，后台用标准分词重校验输出，捕获历史依赖型分词Bug。

所有分词器配置基于内容哈希注册，会话绑定固定分词版本，跨版本不执行增量修复。
在这里插入图片描述

3.2 追加文本破坏分割边界原理

GPT分词分为两步：正则预分词拆分片段、BPE独立编码每个片段；片段分割依赖前后文，追加文本会改变前序末尾片段边界。
在这里插入图片描述

示例：历史文本末尾pipe单独编码，追加line后完整字符串pipeline合并为单个Token；直接拼接tok(pipe)+tok(line)会生成两个Token，与标准结果不符，KV缓存键失效。
固定窗口无法解决：数字分组、Unicode字符规则可让边界影响无限扩散；现有LoPT、GigaToken均存在未覆盖的边界错误案例。

3.3 增量修复完整流程

读取缓存会话完整Token序列、字节偏移；截取历史末尾默认512字符窗口，拼接新增Δ文本；

对窗口执行标准分词，生成新窗口Token与偏移；

新旧序列匹配最长完全一致Token段，匹配段必须满足三条稳定边界证书约束：

匹配段至少包含2个Token；
覆盖字符长度超过分词器最长单Token长度（Llama系列128字符）；
匹配段内部存在字符类同步边界（字母/数字/空白符切换点，可证明右侧片段分割完全不受左侧文本影响）。

校验通过：缓存匹配段左侧Token + 窗口新Token拼接为完整结果，更新会话存储；

校验失败：窗口尺寸翻倍重试，最多5次，仍失败则全量重新分词。

附录A《拼接定理》严格证明：满足同步边界证书的拼接结果与完整标准分词完全等价；17个测试分词器中15套满足该边界规则，剩余2套永久走全量分词路径。

3.4 会话状态管理

存储内容：Token ID数组、字节起止偏移、分词器哈希、文本位置索引；修复时原地修改数组，索引延迟更新，复杂度O(Δ+窗口大小)，与总上下文N无关；

生命周期：会话结束自动回收内存，TTL可设置为小时级，远超KV缓存；worker绑定会话亲和，跨worker访问自动判定状态未命中；

内存开销：单500K Token会话常驻内存仅15MB，16字节/Token存储成本，远低于KV显存。

4 精确GPU分词模块

4.1 消除串行正则依赖

GPT原生预分词是左到右串行正则匹配，每个匹配起点依赖上一段结束位置，无法直接并行拆分；TokTier提出**字符段分解（Run Decomposition）**等价重构：

将字符分为4大类：字母、数字、空白、其他；划分连续同类字符最大段；

仅依靠段内偏移、前后最多4字符前瞻、段级统计信息，即可完全复刻原生正则分割结果；

字符分类、段划分、片段判定全部并行执行，无串行依赖，同时严格对齐原生预分词输出。

该方案兼容cl100k、o200k、DeepSeek三大主流分词家族，通过千万级差分验证保证片段分割完全一致。
在这里插入图片描述

4.2 GPU并行BPE编码

片段独立编码，可完全并行，优化分层调度：

短片段（≤32字节）：单线程处理，寄存器存储序列；

中片段（33~128字节）：单warp并行查找最小合并对；

长片段（>128字节）：单block共享内存位图批量合并；

Llama系列ignore_merges规则优先匹配完整词汇，短路合并流程。

硬件性能：单RTX PRO 6000完整分词吞吐3.8_{4.7GB/s；仅预分词阶段可达30}77GB/s，支持中英混合、代码、模板文本。

4.3 CUDA图单请求低延迟优化

传统GPU流程多次CPU-GPU同步，单请求延迟高；TokTier将完整字节→Token链路封装为CUDA Graph：

缓冲区尺寸预分桶，无需CPU读取计数调整内核；

主机同步操作从8次降至2次；
3 CPU高负载场景下P99延迟提升幅度降低50%。

两种输出模式：

数组直传：无Python解释器开销，百万字符0.87ms；

Python列表：解释器序列化带来显著延迟，百万字符3.86ms。

4.4 GPU路径约束与降级逻辑

支持分词器：cl100k/o200k/DeepSeek；带NFC归一化文本、WordPiece分词器走CPU；

GPU仅原生输出Token ID，不生成字节偏移；新建会话需要偏移时自动切CPU参考分词；
3 GPU负载过高时自动分流小请求至CPU；

小于2KB文本直接走CPU，规避GPU启动开销。

4.5 完整服务实现

增量修复/会话存储：Rust实现，原地数组修改无拷贝；

参考CPU路径：原生HuggingFace实现，仅兜底，流量占比<0.3%；

vLLM对接：直接传入Token ID数组，与文本分词生成的KV缓存键100%兼容，引擎无需修改；

影子验证：后台线程随机采样，对比标准分词，检测到偏差隔离样本用于离线复现，采样率离线100%、线上5%。

5 实验评估

5.1 实验环境

硬件：双路AMD EPYC 9115（32物理核心，关闭超线程），4张RTX PRO 6000 96GB Blackwell；单GPU分别用于TokTier分词、vLLM推理；
基线方案：HuggingFace参考分词、vLLM内置fastokens、GigaToken（最优缓存CPU分词）、LoPT复现实现；
测试数据集：12.4TB Nemotron-CC解压真实文本、SWE-Bench智能体轨迹、人工对抗分词样本。
在这里插入图片描述

5.2 正确性验证（零偏差结果）

测试路径输入规模总校验次数偏差数

GPU片段级校验	合成/对抗/12.4TB全量文本	1.5×10¹⁰
GPU端到端	6类生产分词器	6.21×10⁷
增量修复	两大公开智能体轨迹+1.5万对抗编辑	1.09×10⁵
线上影子采样	离线/压测/vLLM闭环流量	>5×10⁴

关键发现：

大规模文本扫描捕获Unicode字符表版本不一致Bug（标准分词Unicode16.0，自研模块误用15.0，9700个码点分割错误）；小规模合成测试无法复现；

影子校验捕获工业Rust分词历史依赖Bug：长前缀分词后，相同文本生成不同Token ID，仅全量线上流量可复现。

5.3 增量修复性能

在这里插入图片描述

延迟表现：Rust原地存储实现，10万_{300万字符上下文P50稳定0.5}1.1ms；全量CPU分词随上下文线性增长，100万字符场景比修复慢13倍；

窗口命中率：56052条真实会话追加中，99.995%请求默认512字符窗口一次校验通过，仅3条扩大窗口，无请求降级全量分词；

与GigaToken对比（预缓存最优模式）：
| 完整上下文字符 | TokTier修复P50(ms) | GigaToken P50(ms) | 提速倍数 |
| —- | —- | —- | —- |
| 100K | 0.52 | 0.14 | 0.27倍（Giga占优） |
| 500K | 0.88 | 1.18 | 1.34倍 |
| 1M | 1.23 | 2.53 | 2.1倍 |
| 2M | 1.57 | 4.76 | 3.0倍 |
| 4.4M | 3.54 | 11.66 | 3.3倍 |

交叉点在10万~50万字符，超大上下文下增量修复优势持续扩大；GigaToken即使缓存命中仍需扫描完整上下文，复杂度O(N)。
4. 吞吐量两种统计口径：

扫描口径：仅统计实际重分词字符，单核仅3MB/s；
服务口径：统计完整交付上下文，单核最高1.4GB/s，远高于所有CPU全量分词。

5.4 GPU全量分词性能

在这里插入图片描述

单请求数组直传P50延迟：

上下文字符RTX PRO 6000 CUDA图(ms)GigaToken空缓存(ms)fastokens单核(ms)HF分词(ms)

100K	0.29	0.64	2.03	24.8
1M	0.87	6.05	20.5	360.3
2M	1.34	8.78	45.9	762.9

100万字符场景下，GPU比最优CPU方案快23.4倍；仅带Python列表序列化时，百万字符延迟3.86ms，仍优于绝大多数CPU方案。

5.5 并发吞吐与长尾延迟

在这里插入图片描述

负载约束：P99延迟≤50ms

4核修复池+单GPU：最大1821请求/秒；

16核无状态CPU全量分词：最大40请求/秒，差距45倍；

CPU仅靠增加核心无法消除O(N)分词的基础延迟，突发初始化请求会持续拉高P99；GPU分流后初始化请求P99控制在46.6ms以内。

5.6 对接vLLM端到端首Token延迟(TTFT)

在这里插入图片描述

负载场景中位数TTFT下降16%~34%，突发流量P99降低23%；

性能来源：消除前端全量分词耗时，队列、模型Prefill耗时无变化；

边界场景：KV缓存完全耗尽时，分词优化无收益，模型Prefill成为瓶颈。

5.7 内存与资源开销

在这里插入图片描述

会话内存：每Token 16字节，500K Token会话常驻<15MB；旧Python存储实现同场景占用70~129MB；

会话TTL收益：KV默认5分钟TTL，分词TTL提升至1小时，97%_{98%请求命中会话状态，5%}7%原本KV失效的请求可增量修复；

算力功耗：GPU分词4.14GB/s，功耗288W；32核CPU最优配置2.06GB/s，功耗221W，单位算力GPU更节能。

5.8 运行时影子验证效果

人工注入434类Token错误（替换、删除、分割偏移），5%采样率下90%故障42次请求内检出；

成功复现第三方工业分词隐藏历史依赖Bug，并向上游提交修复。

6 相关工作

6.1 CPU分段/缓存分词

HuggingFace tiktoken/fastokens/GigaToken：基于SIMD、进程缓存加速全量分词，每次请求仍扫描完整文本，无法解决超大上下文追加场景；

LoPT：单请求内分块并行，依赖固定长度阈值做安全分割，论文证明存在逃逸输入，无跨会话状态复用；

增量BPE：仅支持纯追加、不支持会话中间文本编辑，无正则预分词边界证明。

6.2 GPU分词（GPUTOK/BlockBPE/cuDF）

现有GPU方案均简化、删减原生GPT正则预分词规则，输出与标准分词存在偏差，无法用于KV缓存场景；TokTier首个实现完全等价原生预分词的GPU并行方案，通过万亿级差分校验。

6.3 KV前缀缓存优化（vLLM/RadixAttention/Mooncake）

全部优化聚焦模型推理阶段，未解决前端分词瓶颈；TokTier作为前置中间件，无需修改推理引擎即可兼容所有KV缓存框架。

6.4 智能体负载刻画（TraceLab/CacheWise）

现有轨迹数据集仅统计上下文、吞吐，未区分「完整初始化/少量追加」两类流量；本文首次量化会话增量分词的性能放大倍数。

6.5 差分验证

翻译验证、编译器差分测试多用于离线校验；TokTier将分层校验（理论证明+离线大规模扫描+线上实时采样）落地到分词服务生产环境，覆盖静态与历史依赖两类Bug。

7 系统局限性

GPU性能天花板：BPE合并存在串行内存依赖，带宽利用率仅4%，高时钟消费级显卡（RTX 5090）性能优于服务器GPU；

分词器覆盖限制：2类分词器无可用同步边界，永久全量分词；WordPiece仅CPU；NFC归一化文本GPU路径存在降级；
3 GPU缺失字节偏移导出：新建会话需要偏移时必须走CPU，是最高优先级工程优化点；

负载覆盖：轨迹仅覆盖代码智能体，对话、多模态智能体未验证；上下文越大增量修复优势越明显，短上下文GigaToken更优；

校验边界：零偏差仅针对本次测试分词版本，新版本必须完整重跑差分校验；线上影子校验不可下线。

8 结论与部署拓展

8.1 核心结论

智能体服务KV缓存大幅降低模型计算，但全量文本分词造成巨大冗余开销。TokTier通过有状态增量修复处理绝大多数少量追加会话，GPU无损并行处理少量超大初始化请求，严格对齐标准分词输出，在吞吐量、延迟、硬件开销上全面优于传统CPU分词前端。

8.2 生产部署建议

硬件搭配：少量高消费级GPU（高时钟）搭配多核CPU修复池，可与推理GPU共置；

会话优化：分词状态TTL设1小时，利用极低内存开销提升修复命中率；

状态容灾：当前无会话状态复制，生产需补充持久化/多副本逻辑。

8.3 增量路由拓展（未来工作）

当前所有追加流量统一走增量修复；实测99%追加≤38K字符，0.8%追加≥50K字符超大文本，增量修复延迟显著上升。
三条优化原型路径（附录E）：

路径A：追加文本内多进程并行分词，8核可提速3倍；

路径B：GigaToken作为窗口内部引擎，字节BPE可重构偏移，单核提速30~40倍；

路径C：GPU全量分词+设备端字节偏移导出，超大追加最快，百万字符仅1ms。

混合路由策略：超大追加直接GPU全量分词，常规小追加增量修复，可覆盖全流量最优性能区间。

附录

附录A 拼接定理（理论正确性证明）

A.1 基础定义

Token记录：(token_id, 字节起始a, 字节结束b)，记录文本对应区间；

分词流水线拆分：F = E* ◦ G

G：前端（新增Token提取→归一化→预分词，输出文本片段）；
E：BPE编码，单片段独立生成Token序列，无跨片段状态；

核心假设：关闭截断/填充/特殊Token包装，BPE Dropout关闭，与线上推理配置对齐。

A.2 拼接证书与无损定理

拼接证书条件：窗口分割点不存在任何预分词片段跨边界；左右窗口片段完全等价完整文本对应区域片段。
无损定理：满足拼接证书时，窗口分词结果拼接等价完整文本标准分词。
推论：匹配Token序列内部同步边界处分割与序列末尾分割结果完全一致，支撑增量修复实现。

A.3 分词族证书适配

WordPiece：匹配序列+连续文本见证可安全拼接；
Byte-BPE（Llama/Qwen/DeepSeek）：仅匹配序列不足，必须包含字符类同步边界抵御数字分组上下文干扰；
15/17主流分词器满足同步边界规则，剩余2套无可用边界，强制全量分词。

附录B 负载采集细节

隐私规范：仅采集字符/Token计数，原始文本本地销毁，标识符HMAC哈希，无用户隐私流出；

日志清洗：过滤流式重复记录、会话分叉重复日志，剔除14.7%伪造调用；

多数据集指标对齐，提供完整时序分布图；

KV缓存衰减量化：交互间隔超1小时，缓存平均复用率仅17%。

附录C 追加尺寸全量扫描实验

固定上下文，遍历1K~100K追加字符，对比四类分词延迟，完整表格见原文Table5；
核心规律：追加越大增量修复优势收窄，50K以上追加GigaToken在短上下文反超，超大上下文仍优于CPU缓存分词。

附录D 吞吐量统计口径、硬件横向对比

两种吞吐量严格区分：扫描口径（实际分词字节）、服务口径（交付完整上下文），不可混用；

五种GPU跨代测试：RTX 5090 > RTX PRO 6000 > GH200 > H100 > A100，性能由GPU主频决定，非显存带宽；

前端CPU资源量化：给出每千推理GPU所需分词核心数量对比。

附录E 超大追加文本三条优化原型

针对0.8%超大追加流量，三条无损优化方案完整实现、测试指标、适用场景：

A：追加内部多进程并行修复（已退役，多核收益有限）；

B：缓存分词作为窗口内部编码器（单核心大幅提速，依赖Byte-BPE）；

C：GPU全量分词+设备端偏移导出（最优超大追加方案，待完整上线校验）；
综合路由决策图给出不同上下文/追加尺寸最优路径。

补充资源信息

论文原文网页链接：https://arxiv.org/html/2607.29678v1

论文PDF链接：https://arxiv.org/pdf/2607.29678v1

实验数据集：

codex_swebenchpro 公开智能体轨迹：HuggingFace数据集Inferact/codex_swebenchpro_traces
TraceLab数据集：github.com/uw-syfi/TraceLab
Nemotron-CC 12.4TB文本语料（差分校验使用）

对比开源项目仓库：

Gigatoken：https://github.com/marcelroed/gigatoken
HuggingFace Tokenizers：https://github.com/huggingface/tokenizers
vLLM Rust前端：项目仓库RFC#40846

实验环境复现约束：

依赖CUDA 12.4+、Rust 1.78+、PyTorch 2.6、vLLM 0.25；
GPU内核基于Blackwell架构优化，Hopper/Ampere性能衰减；
所有分词器配置通过内容哈希锁定版本，复现需使用论文固定快照。