首字延迟的 67% 不是模型算的：GraphTok 把 LLM 分词整段搬上 GPU

一句话总结agent 应用每次调用都重发十几万 token 的上下文前缀缓存把 GPU 的活几乎干完之后CPU 上的分词反而成了首字延迟的最大头实测最高 67%。KTH 的 GraphTok 把分词的完整流水线整段搬进 GPU、压成一张 CUDA Graph位级精确不打折百万 token 编码 1.7 毫秒vLLM 首 字延迟砍半一台服务前端能多喂一倍的 GPU 卡。已开源vLLM/Dynamo 接入是环境变量级的。先问做推理服务的同行一个问题你的 vLLM 开了 prefix cachingagent 流量的首字延迟TTFTTime-To-First-Token从发出请求到吐出第一个 token 的时间还是压不下去你排查过 GPU 利用率、KV cache 命中率、调度器配置——有没有顺手看一眼tokenizer 在干什么大概率没有。分词嘛切切字符串的事谁在乎。KTH 皇家理工学院的团队较真了一把把真实编码 agent 的调用轨迹翻出来给你看TraceLab 统计的约 4300 个真实 agent 会话里中位每次模型调用携带约 11.9 万个缓存前缀 token新增的只有 875 个95.7% 的输入 token 直接命中前缀缓存。GPU 这边 prefill 几乎白嫖缓存那时间花哪了答案有点滑稽花在 CPU 上一分一分地把那 12 万 token 重新切一遍。想自己动手 论文arXiv 2610.13325 代码GitHub · Msiavashi/GraphTok 这篇论文到底想解决什么问题要理解这个瓶颈得先看现代推理引擎是怎么省钱的。vLLM、SGLang 这类引擎都有prefix caching前缀缓存同一段开头的文本只算一次 KV 状态下次请求开头一样就直接复用跳过昂贵的 prefill 计算。对 agent 来说这是天大的好事——每次调用只多了几百个新 token前面十几万个 token 的计算全部复用。但有一个环节逃不掉缓存查询需要 token ID而 token ID 要先分词才有。图说同一台 H100、同一个 vLLM左边冷缓存时分词只占 TTFT 的 1–2%prefill 是大头右边缓存命中后 prefill 没了分词一跃成为最大组成——Llama 3.1 的 13 万 token 请求里占 67%。那为什么不只切新增的那 875 个 token跟前面的缓存拼起来因为BPE 分词不满足「拼接守恒」。把两段文本各自分词再拼接结果一般不等于把两段拼起来再分词——追加的文本可能改变边界附近的切法。NVIDIA Dynamo 的做法是只在「安全边界」比如完整的对话轮次复用 token剩下的还是得重切。于是怪事出现了GPU 越闲缓存命中越高CPU 分词在 TTFT 里的占比越高。更要命的是容量视角——像 Dynamo 这样的架构里一台前端要为整个 GPU 舰队分词分词吞吐直接决定这台机器能喂饱几张卡。论文实测默认分词器下一台前端在 2 秒 P99 目标内只能伺候 2 张 GPU 的 12 万 token agent 流量。️ 它的思路是什么问题的病根是分词是串行的正则表达式扫描有序的数据依赖合并看起来天生不适合 GPU。前人试过两条路都有硬伤BlockBPE、GPUTOK 把合并搬上 GPU但把正则预分词删了——切出来的 token 和参考分词器不一致模型吃的是 token ID切错了等于喂错药。GraphTok 的答案是三个字全都要。精确性一个 token 都不让速度还要拉满。第一步把「串行扫描」改写成「逐位置并行判断」。观察是一个位置是不是新词的起点往往只取决于局部字符类型。比如 Llama 3 的规则说「连续数字每 3 个一切」——那一个数字要开新词当且仅当它是这段数字的第 1 个、第 4 个、第 7 个……字符。于是 GPU 上每个字符一个线程同时判断「我这儿是不是词边界」再用前缀扫描prefix scan一种并行前缀求和技巧把边界编号。正则语义一点没丢串行游标没了。第二步warp 协作的 BPE 合并。跨词并行是免费的BPE 不越词界难在词内部合并有序。GraphTok 的写法很漂亮把「合并优先级 位置」打包成一个 64 位整数一次硬件求最小值归约warp reduce最小的秩获胜、同秩最左优先——恰好就是参考实现的合并顺序。一次归约顺序和性能全保住了。第三步整条流水线压成一张 CUDA Graph。这是系统层面最见功力的部分。GPU kernel 快不等于调用快——重复的 kernel 启动、内存分配、主机同步能把几毫秒的活拖成几十毫秒。GraphTok 把「原始字节进 → token ID 出」的全程捕获成一张可重放的 CUDA GraphCUDA Graph预先录制好的 GPU 执行计划重放时无需 CPU 逐条调度。分词的工作量是随输入变化的「锯齿状」而图要求固定拓扑——解法是把「容量」和「占用」分离缓冲区按上限预配实际用了多少由 GPU 上的计数器标记host 全程只在开头拷一次数据、启动一次图。图说请求进 GraphTok 后host 只负责把文本拷进 GPU 和启动图❶❷预分词、三条合并路径常规 warp 路径 / 锦标赛树溢出路径 / 重复字符批量轮次、结果组装❹❺全在 GPU 内部完成结果可以拷回 CPU6a也可以直接留在 GPU 上6b给未来彻底「去 CPU」的推理引擎用。最后还有个务实的设计太短的输入不值得进 GPU图重放有约 0.06 毫秒的固定底价GraphTok 内置了 CPU 路由——短文本走静态链接的最强 CPU 分词器 gigatoken长文本走图按输入自动选。它不是「GPU 激进派」是「每个输入都走更便宜的那条精确路径」。 效果到底怎么样先说最重要的前提快但是一个 token 都没切错。论文的精确性验证是按「先证明清白再谈性能」来的GPT-2、Llama 3、Qwen 2.5、DeepSeek-V3、Gemma 3 五套词表 × 三种语料 × 十种长度 × 1–256 批每个格子都和参考分词器逐 token 对比——全部一致。这就是它和 BlockBPE/GPUTOK 的本质区别那些系统在 100 万 token 里悄悄少切了 1 万多个。速度方面挑三个最狠的数字单发延迟100 万 GPT-2 token约一部长篇小说的量级完整编码1.7–3.2 毫秒含往返传输。对比最强的 CPU 分词器 gigatoken 快 4.7–6 倍对比 Hugging Face 参考实现快865–1295 倍。TTFT99% 前缀复用时vLLM 换上 GraphTok 平均 TTFT 直降2.1–2.4 倍分词在 TTFT 里的占比从原装的 56–76% 压到1.4–2.5%。容量Dynamo 前端 12 万 token agent 流量2 秒 P99 目标内可承载从默认的 18.5 请求/秒提到518 请求/秒——从 2 张 GPU 的量提到56 张。极限处 P99 尾延迟最多低 64 倍。图说横轴是负载折合成多少张 GPU 在满速发请求纵轴是 P99 首字延迟虚线是 2 秒目标线。GraphTok绿的曲线最平、拐点最靠右换成它之后瓶颈已经不是分词而是 Dynamo 自己的请求解析与路由路径——作者用一个「假分词器」对照实验证实了这一点。还有一个容易被忽略的收益把 CPU 还给 agent。agent 平台一台机器上挤着上百个 agent 沙箱编译、测试、检索全在抢 CPU。实测 128 个 coding agent 和前端挤同一台 96 核机器时GraphTok 每次调用的 CPU 开销只有 gigatoken 的1/8.7——省下的核全还给了 agent 的工具调用。而它借的 GPU 资源呢不到推理空闲算力的十分之一模型吞吐变化 1.1%在测量方差之内等于白借。 为什么你要关心如果你的工作和 LLM serving 沾边这篇论文至少有三件事和你直接相关自建 vLLM / Dynamo 的团队接入成本几乎是变量级的——vLLM 走 tokenizer 工厂钩子不改源码Dynamo 加一个DYN_TOKENIZERgraphtok环境变量。如果你的流量里 agent 占比高前缀复用 90%这是今年性价比最高的一次 TTFT 优化试点。agent 平台工程「长上下文 高复用 小增量」的负载画像正在成为默认。分词、模板渲染、请求解析这些「非模型阶段」会一个接一个浮出水面——这篇论文等于提前给你画了张雷区地图。做系统优化的所有人信号意义大于数字本身。GPU 内卷attention、kernel、显存卷到头之后host 侧的固定开销成了新的主战场。论文结尾那句话值得抄下来缓存和更快的 prefill 每削掉一分 GPU 份额剩下的 host 阶段就多决定一分延迟——「每一个都得被搬走或干掉」。换个角度看GraphTok 的路线图其实指向「CPU-free 推理」token 生成后不再回 CPU整条请求链路都在 GPU 上闭环。分词只是第一块被搬走的砖。 理性看待泼点冷水。精确性是按家族手工换来的目前只支持五套具体分词器配置碰到不支持的 tokenizer.json 直接拒绝启动宁可不跑也不切错新家族要再写一套边界谓词——通用性是有意 sacrificed 的。全部实验基于单张 H100 NVLDynamo 舰队实验的 GPU 侧是模拟的结论限定于前端容量不是端到端多机实测。另外单引擎场景下gigatoken 这类快速 CPU 分词器的 TTFT 与 GraphTok 差距只有 3–18%——如果你的服务独占机器、不和人抢 CPU收益没有容量叙事那么性感。还有个细节与 gigatoken 的主力对比是在清空其缓存的条件下做的虽然论文用「图无缓存冷热同速」补了刀但读数时心里可以有杆秤。瑕不掩瑜。这是近期少有的「动机真实、方法闭环、测量诚实、读完就能上手试」的系统论文——尤其当你正被 agent 流量的 P99 折磨的时候。