10 月 9 日提交 arXiv 的 GraphTok（编号 2610.13325，论文标题 Taking Tokenization off the Host for Agentic LLM Serving）从一个反直觉的观察出发：智能体把同一段长上下文在多次调用间反复重发，前缀缓存已经跳过了大部分预填充，可每次请求仍然要在 CPU 上把整个上下文完整分词一遍——因为缓存查都没法查，得先有 token 才能知道从哪里命中。论文的判断是：分词这个一向被当成可以忽略的 CPU 阶段，如今成了首 token 延迟的最大组成部分。
如果只影响单次请求的延迟，这件事值得关注但不算严重。真正的问题在集群尺度：一个前端节点要为整个 GPU 集群做分词，它喂得动多少块卡，集群才能用多少块卡。GPU 闲着等分词，是这个论文要解决的图景。
把整条编码流水线录成一段图
GraphTok 的做法是把整个编码流水线——从预分词、字节对编码合并到 token ID 组装——整体搬到 GPU 上，录成一段可重放的 CUDA 图。请求到来时重放这段图，分词在设备侧一次完成，不再来回穿梭于主机与设备之间。
两个工程细节值得单独说。一是逐位一致：在 GPT-2、Llama 3、Qwen 2.5、DeepSeek-V3、Gemma 3 五种分词器上，GraphTok 输出的 token ID 与参考实现完全一致。这不是性能指标，是正确性底线——token ID 差一位，缓存命中、采样逻辑、计费口径全都会悄悄漂移。二是短输入分流：短输入仍然交回 CPU 引擎处理，因为 GPU 不是在所有尺度上都赢，数据传输开销在小输入上可能反超。这个分流本身是个诚实的工程信号。
集成成本也压得较低：论文演示了直接挂进未改动的 vLLM 与 NVIDIA Dynamo，不需要改推理框架。
容量账与延迟账，分开读
论文的结果要分两本账算。容量账是主菜：在 121k token 流量、2 秒 P99 目标下，一个 Dynamo 前端配 GraphTok 可维持每秒 518 个请求，而同一节点换用论文对比中较快的 CPU 分词器 gigatoken 是 296，用默认分词器只有 18.5。518 这个量级对应 56 块 GPU 最忙一小时的负载——换句话说，一个前端节点从「喂不饱一个机柜」变成「喂得动半个集群」。跨 121k 到 1M token 区间，持续负载为 gigatoken 的 1.75 到 2.5 倍。
延迟账相对温和：有缓存前缀时，平均首 token 延迟降低 2.1 到 2.4 倍；100 万 GPT-2 token 的编码耗时 1.7 到 3.2 毫秒（含数据传输）；Llama 3 上比 gigatoken 快 4.7 到 6.0 倍。
两本账对应两类买家。如果你的痛点是「集群扩容后前端成瓶颈」，容量账直接对症；如果你的痛点只是「这一次回答慢不慢」，延迟账的改善存在但没那么戏剧。
它暴露的真问题
这篇论文更大的价值是重新划分了推理系统的责任边界。过去几年优化几乎全部围绕注意力与显存——前缀缓存、PagedAttention、量化、投机解码——分词被默认为「主机侧杂活」。智能体负载改变了这个假设：上下文反复重发、越攒越长，让「每次请求都完整分词」从常数变成了常数加一大项。
顺着这个逻辑往下想，类似的「被忽视的主机侧阶段」可能还有——序列化、模板渲染、多轮历史拼接。智能体把请求模式从「一问一答」改成「长上下文高频重发」，整个服务栈的瓶颈地图都在重画。
读数时的保留
论文数字来自作者自建的 TokTier 基准与特定集群形态，换部署方式、换流量构成，结论幅度需要重新压测。「逐位一致」目前只在五种分词器上验证，小众分词器未必覆盖。另外，它优化的是服务吞吐，不改变单次生成的计算量——该多慢的生成还是多慢，只是不用排队等分词了。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。