LLM 推理的延迟问题，大家通常关注模型参数大小、量化精度、KV cache 效率。但在实际生产链路里，有一个很少有人讨论的瓶颈：分词（tokenization）。
大模型部署时，每个请求经过「文本 → token → 模型推理 → token → 文本」的完整链路。其中模型推理部分近年有 vLLM PagedAttention、Flash Attention、推测解码（speculative decoding）等多种优化手段，推理速度提升了数十倍。但分词这个环节，大部分部署仍然用 Hugging Face tokenizers 或 SentencePiece 的 Python 绑定——对长文本输入（比如代码分析、文档处理、RAG 检索），分词本身就能吃掉几十甚至上百毫秒。
GigaToken 是一个纯 Rust 实现的分词器，目标是把 tokenization 的throughput 推到 GB/s 级别。根据其公开基准，在长文本场景下比 Hugging Face tokenizers 快大约 1000 倍——不是修辞，是实测数据。
（配图：GigaToken GitHub 仓库的基准测试截图，展示不同分词器在长文本处理性能上的柱状图对比）
为什么这对部署有意义？
第一，长文本输入正在成为常态。Claude 的 200K 上下文、Gemini 的 1M 上下文、GPT-5.6 的扩展上下文——当输入是几十万的 token 时，分词阶段的开销会被显著放大。GigaToken 把这个阶段从 O(ms) 推到 O(µs) 级别。
第二，Rust 实现意味着可以直接编译为共享库嵌入现有推理框架。vLLM 的 tokenizer 层、llama.cpp 的 tokenization 都可以替换底层实现，不需要改上层逻辑。
第三，批处理场景收益更大。推理服务通常把多个请求合并为 batch 输入模型——但 tokenization 目前大多是逐请求处理的。如果批量分词也能达到 GB/s 级别，batch 的边际成本会进一步下降。
项目目前用 Rust 编写，支持 GPT-2、LLaMA、Mistral、Qwen 等多个主流模型的 tokenizer。许可证为 MIT，可以直接集成到生产部署 pipeline 中。
当然，实际落地需要验证：1000x 的性能提升倍率是否在所有场景（短文本、多轮对话、CPU vs GPU 侧编码）都能保持。但至少它揭示了一个被忽视的优化空间——当大家都在优化模型推理时，把分词瓶颈一并解决，也许能让端到端延迟再降一个数量级。
内容来源：HN 讨论（507 分）、GitHub 仓库（1640 stars）
延伸阅读：vLLM 的 tokenizer 层设计、llama.cpp 的 tokenization 实现、SentencePiece 的 BPE/Unigram 算法选择