模型不慢，卡在“切词”：为什么分词速度会成为 AI Agent 的隐藏瓶颈

Thu, 23 Jul 2026 08:00:00 +0800

GitHub 上有个叫 GigaToken 的开源项目，最近在 Hacker News 上拿到了 331 分、63 条评论。它做的事很具体：把语言模型的 tokenization（分词）做到 GB/s 级别；按项目公布的部分基准，相对 Hugging Face tokenizers 可快约 1000 倍。

先别急着把这个数字当成结论。它来自项目自己的 benchmark，而不是一份独立复现报告。仓库使用双路 AMD EPYC 9565、Apple M4 Max 和 Ryzen 7 9800X3D 测试；最高倍率出现在 Rust 直接读取整文件、且输入没有预切分的路径上，对比库则走了预切分批处理。换到 SentencePiece（句子片段）类 tokenizer，增益可能只剩个位数到几十倍；若为了兼容 Hugging Face 或 tiktoken 的 Python 调用方式，速度也会掉下来。

这个项目有意思的地方，不是它承诺了一个惊人的跑分，而是它逼人重新看一眼 Agent 的等待时间。模型开始输出前，程序往往还在整理它要读的材料。

一次 Agent 回合，除了模型推理，还要做不少准备工作

普通聊天的路径很短。你输入一句话，客户端把它编码成 token，模型处理输入，再逐字生成回复。输入短、轮次少，分词这一步通常埋在总延迟里，很难被人单独注意到。

Agent 的回合要长得多。拿一个“帮我修测试”的任务来说，它可能先读项目说明，再打开几个源码文件，运行测试，收集报错，把日志塞回上下文，继续判断下一步。每次工具返回结果，系统都得重新组织材料，然后再把新一轮输入送进模型。

把这段过程摊开，大致是这样的：

读取文件 / 日志 / 搜索结果
        ↓
清洗、截断、拼接上下文
        ↓
tokenization（分词）
        ↓
prefill（预填充：模型处理全部输入）
        ↓
生成下一步动作 → 调用工具 → 获得新结果
        ↓
回到上下文装配

分词不是 prefill。前者是把文本映射成 token ID；后者是模型真正读取这些 token、建立注意力状态。再往后，还有输出生成、网络传输、工具执行、检索和磁盘 I/O。任何一个环节都可能慢。

但 Agent 的特点是，它会反复走这条链。文件越多、日志越长、工具回执越碎，输入准备就越容易从一个小常数，变成一笔反复支付的时间账。

在聊天里不显眼，为什么到了 Agent 里会冒出来

Agent 不一定每轮都输入更多文字，但它很容易把同一批文字处理很多遍。

例如，第一次让 Agent 看一个仓库，它可能读了 README、配置和三个核心文件。工具调用回来以后，若运行时只是把“旧上下文 + 新日志”整段重拼，前面已经出现过的说明和代码还得再编码一次。回合多起来，重复工作也跟着堆上去。

上下文窗口变大，确实让更多材料能装进一次请求；可每一轮放什么、哪些内容已经处理过、重复输入由谁承担延迟，还是得由运行时自己处理。

对用户来说，表面症状通常是首个回复迟迟不来，或工具执行明明很快，Agent 却在两轮动作之间停顿很久。模型服务端可能在忙 prefill，也可能是客户端或运行时还在切分大段文本、序列化工具结果。没有分段埋点，团队往往会把这些等待统称为“模型慢了”。

这正是 GigaToken 值得关注的地方。它不能证明每个 Agent 都卡在分词，也不该替代对整条调用链的测量。它只是把模型 API 前面那段常被忽略的输入管线，重新摆到了工程师面前。

“千倍提速”该怎么读

GigaToken 的高性能路径很有针对性：它直接用 Rust 读取文件，尽量并行处理，绕开 Python 层的数据搬运，并利用 SIMD（单指令多数据）等底层优化。离线语料处理、批量索引、长文件预处理，或能直接控制输入管线的服务端任务，可能更容易吃到这类优化的好处。

把它接进现有 Agent，并不会让所有交互立刻快千倍。至少有三件事要先算清。

先分开看真实请求的耗时。大模型接收长输入时，prefill 往往本身就很重；工具调用如果耗时几秒，分词从 50 毫秒降到 1 毫秒，用户未必能感到同样数量级的变化。

输入形态也会改变结果。整文件读取、预先切分的小批次、Python 字符串列表、流式增量文本，对缓存、并行度和内存访问模式的要求完全不同。项目仓库提到预 token 缓存有长尾问题，缓存规模可能很快膨胀，这部分成本不能略过。

兼容性也有成本。GigaToken 提供 Hugging Face 和 tiktoken 兼容模式，不过项目说明，最高性能来自原生 API 和文件级路径。已经绑定 Python 生态的 Agent，能否替换、替换后 token 边界和特殊标记是否一致，都需要逐项验证。

分词吞吐会不会成为瓶颈，取决于工作负载。大文件、离线批处理更有可能受影响；在线 Agent 是否受影响，得看自己的 trace（调用链追踪）。

先别急着换分词器，先把上下文浪费找出来

大多数团队甚至不需要改 tokenizer，也能让 Agent 少等一会儿。

最直接的是按需读取。不要为了让模型“了解项目”，先把整个目录树和所有文件内容一口气送进去。先让 Agent 根据任务检索文件名、符号和少量片段，只有需要时才展开全文。这样既缩短输入准备，也减少模型在无关材料里走神的机会。

接着是把重复内容变成引用，而不是副本。项目约定、环境信息、已读文件摘要可以保存为稳定状态；后续回合只追加变化的 diff、报错和新证据。一个运行时如果每轮都把完整 README、历史命令输出和旧补丁重发一遍，换再快的分词器也只是更快地做重复劳动。

工具回执同样值得整理。命令输出不是越原始越好。测试失败时，保留失败用例、关键栈帧和环境差异，往往比把数千行日志完整塞回模型更能帮助下一步判断。日志需要全文时，可以让 Agent 显式展开，而不是默认携带。

最后是把时间拆开记。至少分开记录：检索/文件读取、上下文拼接、分词、prefill、首 token、完整生成、工具执行。只有知道哪段在涨，才知道该优化缓存、调模型、缩上下文，还是换底层 tokenizer。

这些做法听起来没有“千倍提速”那么醒目，却更接近 Agent 产品里的日常收益。因为它们同时减少了延迟、token 消耗和错误干扰。

分词器、上下文工程和 Agent harness，各管一段

这三件事经常被混在一起谈，实际职责很不一样。

分词器负责把文本变成模型可处理的数字序列。它影响输入准备的速度、token 边界，以及某些语言和格式的编码效率。GigaToken 想优化的主要是这一层。

Context Engineering（上下文工程）决定什么内容值得被送进去。它处理的是选择与组织：读哪些文件，保留哪些历史，如何压缩工具回执，何时引用缓存。即使分词速度不变，好的上下文工程也能让每一轮少处理大量无关文本。

Agent harness（智能体运行框架）则把这些动作变成可控的循环：它调度工具、维护状态、控制权限、记录 trace，并在每轮之间决定是否继续、缩减上下文或交还给人。没有 harness，分词器再快也只是一段局部库；没有上下文工程，harness 仍可能反复把垃圾送进模型。

因此，Agent 的端到端体验很少由单一组件决定。分词器解决“怎么把选定的文本尽快变成输入”，上下文工程解决“哪些文本应该被选定”，harness 解决“这个选择和执行循环如何被观察、约束与复用”。把三层分开测，才不会在模型侧盲目加预算，却错过了真正拖慢任务的那一段准备工作。

参考来源

以上来源用于核对项目定位、基准条件和相关工具实现。GigaToken 的性能数字来自项目仓库基准，未等同于独立复现结果；实际收益取决于硬件、语言、输入形态、兼容模式以及整个 Agent 工作负载。

Tokenization on 奇诺分享 | 重在分享

模型不慢，卡在“切词”：为什么分词速度会成为 AI Agent 的隐藏瓶颈

“千倍提速”该怎么读

先别急着换分词器，先把上下文浪费找出来

分词器、上下文工程和 Agent harness，各管一段

参考来源