你让一个编程 Agent 连续干活：读代码、调用工具、查看结果，再继续推理。每一轮，它都会把此前的大段记录重新交给模型，只在末尾添上一点新内容。服务端虽然能复用旧记录的计算结果，却仍要从头把整段文字转换成模型认识的编号。就像仓库已经备好货，门口却还在反复登记同一张长清单。
这篇来自 KTH Royal Institute of Technology 的论文把目光投向这道常被忽略的工序。作者提出 GraphTok，把分词从 CPU 搬到 GPU，并把整条处理流程压进一次可重复执行的 CUDA graph。论文的核心提醒是：当前缀缓存省掉大部分模型计算后，瓶颈不会消失，只会向模型外部移动。本文数字均来自作者论文，尚无独立复现。
缓存越有效，分词反而越显眼
模型不能直接读取文字。分词器（Tokenizer）要先把文本切成词片段，再转换成 token ID——也就是模型真正接收的一串编号。之后，模型才会进行预填充（Prefill），并行读完整段输入，建立回答所需的内部状态。
Agent 的特殊之处在于，它会多次发送几乎不变的长上下文。前缀缓存可以保存共同开头的中间计算结果，让后续请求跳过大部分预填充。但系统通常仍要先把全文分词，拿到 token ID，才能查询缓存。
而且，不能简单保存旧编号，再把新增文字单独分词后接上。论文指出，追加文本可能改变旧结尾附近的切分结果。生产系统可以在确定安全的边界复用部分 token ID，却不能据此取消完整、高效的编码路径。
结果是，过去不显眼的 CPU 工作被推到了台前。作者在未经修改的 vLLM 0.27 和一块 H100 NVL 上测得：缓存未命中时，分词只占一个 13 万 token 的 Llama 3.1 8B 请求中位首 Token 延迟的 2%；缓存命中、绝大部分预填充被省掉后，占比升至 67%。首 Token 延迟（TTFT）指请求发出后，模型吐出第一个词要等多久。
这不是说所有 Agent 请求都会卡在分词上。它依赖几个条件同时出现：输入很长、前缀高度重复、缓存命中率高。论文讨论的正是这种越来越重要的服务形态。
GraphTok到底改了什么？
GraphTok没有只加速其中一个步骤。它把预分词、BPE 合并和 token ID 组装都放到 GPU 上。BPE 是一种常见分词方法：不断寻找相邻符号中优先级最高的一对，将其合并，直到不能再合。
难点在于，完整分词并非天然适合并行。预分词通常像拿着尺子从左向右逐段切；同一小段里的 BPE 合并也有严格顺序，前一步会改变下一步可合并的对象。
GraphTok换了一个角度。对于预分词，它让 GPU 上的线程同时检查各个字符位置，依据局部字符类别和紧凑的连续区间信息，判断这里是否应该开始一个新片段。对于 BPE，它先让不同片段并行处理；在单个片段内部，则让一组 GPU 线程共同寻找下一次最高优先级合并，同时保持参考实现的顺序。
光有快内核还不够。几毫秒级任务里，反复启动 GPU 内核、分配内存，以及 CPU 与 GPU 之间同步，本身就可能抵消收益。GraphTok因此把设备端的完整编码流程录成一个 CUDA graph——可以理解为预先排好的固定操作清单，之后直接重放。它提前按容量准备缓冲区，再由 GPU 上的计数器记录每次请求实际用了多少空间，从而在同一张图里处理长度不同的输入。
作者还保留了 CPU 路线。短输入上，GPU 的固定启动成本不划算，系统便交给 CPU 引擎处理。GraphTok可通过适配层接入未经修改的 vLLM，也能成为 NVIDIA Dynamo 前端的分词后端。
快多少，更重要的是能喂饱多少GPU
作者报告，GraphTok在 GPT-2、Llama 3、Qwen 2.5、DeepSeek-V3 和 Gemma 3 上，生成的 token ID与参考实现逐 bit 一致。在最大英文输入上，它处理 100 万个 GPT-2 token 用时 1.7至3.2毫秒，包含数据传输。不过，这个数字对应 GPT-2 分词器，不能直接外推到其他词表。
在 Llama 3 上，GraphTok比作者测得的 CPU 基线 gigatoken 快4.7至6.0倍。在 TokTier 的单请求基准中，它比 gigatoken 快2.6至3.9倍，峰值比 TokTier 快18.1倍。接入启用前缀缓存的 vLLM 后，平均 TTFT 降低2.1至2.4倍。
但论文认为，真正拉开差距的是前端容量。NVIDIA Dynamo 的一个前端要替整组 GPU 做分词，再把请求送往后端。在2秒 P99目标下，也就是99%的请求需在2秒内达到目标，GraphTok可让一个前端承载每秒518个、长度为12.1万 token 的请求。作者按其工作负载换算，称这相当于56块GPU最繁忙时段的流量；gigatoken为每秒296个请求，默认分词器为18.5个。
这并不表示 GraphTok 提高了 GPU 本身的推理吞吐。它提高的是前端供给能力：不让负责分词的 CPU 成为整组 GPU 前面的窄门。在12.1万至100万 token范围内，作者报告其可承载负载为 gigatoken 的1.75至2.5倍；在 gigatoken 尾延迟明显恶化的测试点，GraphTok的 P99最高低64倍。这两个峰值都依赖论文采用的硬件、并发、缓存和基线配置，应视为特定实验结果。
推理优化开始向主机侧外溢
这项工作的意义不只是一款更快的分词器。它展示了一种系统层面的迁移：当模型内部最昂贵的重复计算被缓存消掉，原本只是配角的文本处理、调度和数据搬运，就可能决定用户还要等多久。
过去，分词留在 CPU 很合理，因为预填充远比它昂贵。现在，Agent反复携带长历史，前缀缓存又能跳过绝大部分预填充，旧有分工便需要重算。GraphTok的答案是把模型入口也送上 GPU，同时保留短输入的 CPU 路线。这种混合设计比“所有工作都上GPU”更克制，也更符合不同输入长度的成本差异。
局限与未知
- 全部性能与容量结论均来自同一篇论文，尚缺第三方复现；“最高18.1倍”和“P99最高低64倍”都是特定场景下的峰值。
- 逐 bit 一致性覆盖论文测试的五类分词器和相应测试单元，但不能自动证明所有模型版本、特殊 token、Unicode及边界输入都已穷尽。
- GraphTok仍有明确边界：Qwen的 Unicode NFC 规范化保留在主机端，Gemma当前不支持批处理；不受支持的分词器配置会被拒绝，而不是近似执行。