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.51.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(AB)。追加文本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全量分词无历史缓存、上下文超过2KBGPU无损并行完成预分词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会话常驻内存仅15MB16字节/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.84.7GB/s仅预分词阶段可达3077GB/s支持中英混合、代码、模板文本。4.3 CUDA图单请求低延迟优化传统GPU流程多次CPU-GPU同步单请求延迟高TokTier将完整字节→Token链路封装为CUDA Graph缓冲区尺寸预分桶无需CPU读取计数调整内核主机同步操作从8次降至2次3 CPU高负载场景下P99延迟提升幅度降低50%。两种输出模式数组直传无Python解释器开销百万字符0.87msPython列表解释器序列化带来显著延迟百万字符3.86ms。4.4 GPU路径约束与降级逻辑支持分词器cl100k/o200k/DeepSeek带NFC归一化文本、WordPiece分词器走CPUGPU仅原生输出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 911532物理核心关闭超线程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¹⁰0GPU端到端6类生产分词器6.21×10⁷0增量修复两大公开智能体轨迹1.5万对抗编辑1.09×10⁵0线上影子采样离线/压测/vLLM闭环流量5×10⁴0关键发现大规模文本扫描捕获Unicode字符表版本不一致Bug标准分词Unicode16.0自研模块误用15.09700个码点分割错误小规模合成测试无法复现影子校验捕获工业Rust分词历史依赖Bug长前缀分词后相同文本生成不同Token ID仅全量线上流量可复现。5.3 增量修复性能延迟表现Rust原地存储实现10万300万字符上下文P50稳定0.51.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)100K0.290.642.0324.81M0.876.0520.5360.32M1.348.7845.9762.9100万字符场景下GPU比最优CPU方案快23.4倍仅带Python列表序列化时百万字符延迟3.86ms仍优于绝大多数CPU方案。5.5 并发吞吐与长尾延迟负载约束P99延迟≤50ms4核修复池单GPU最大1821请求/秒16核无状态CPU全量分词最大40请求/秒差距45倍CPU仅靠增加核心无法消除O(N)分词的基础延迟突发初始化请求会持续拉高P99GPU分流后初始化请求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功耗288W32核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仅CPUNFC归一化文本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倍路径BGigaToken作为窗口内部引擎字节BPE可重构偏移单核提速30~40倍路径CGPU全量分词设备端字节偏移导出超大追加最快百万字符仅1ms。混合路由策略超大追加直接GPU全量分词常规小追加增量修复可覆盖全流量最优性能区间。附录附录A 拼接定理理论正确性证明A.1 基础定义Token记录(token_id, 字节起始a, 字节结束b)记录文本对应区间分词流水线拆分F E* ◦ GG前端新增Token提取→归一化→预分词输出文本片段EBPE编码单片段独立生成Token序列无跨片段状态核心假设关闭截断/填充/特殊Token包装BPE Dropout关闭与线上推理配置对齐。A.2 拼接证书与无损定理拼接证书条件窗口分割点不存在任何预分词片段跨边界左右窗口片段完全等价完整文本对应区域片段。无损定理满足拼接证书时窗口分词结果拼接等价完整文本标准分词。推论匹配Token序列内部同步边界处分割与序列末尾分割结果完全一致支撑增量修复实现。A.3 分词族证书适配WordPiece匹配序列连续文本见证可安全拼接Byte-BPELlama/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-BPECGPU全量分词设备端偏移导出最优超大追加方案待完整上线校验综合路由决策图给出不同上下文/追加尺寸最优路径。补充资源信息论文原文网页链接https://arxiv.org/html/2607.29678v1论文PDF链接https://arxiv.org/pdf/2607.29678v1实验数据集codex_swebenchpro 公开智能体轨迹HuggingFace数据集Inferact/codex_swebenchpro_tracesTraceLab数据集github.com/uw-syfi/TraceLabNemotron-CC 12.4TB文本语料差分校验使用对比开源项目仓库Gigatokenhttps://github.com/marcelroed/gigatokenHuggingFace Tokenizershttps://github.com/huggingface/tokenizersvLLM Rust前端项目仓库RFC#40846实验环境复现约束依赖CUDA 12.4、Rust 1.78、PyTorch 2.6、vLLM 0.25GPU内核基于Blackwell架构优化Hopper/Ampere性能衰减所有分词器配置通过内容哈希锁定版本复现需使用论文固定快照。