GigaToken 能把 LLM Tokenization 做到 GB/s 吗？先别急着替换 tiktoken
Tokenization 这件事平时很不起眼，直到你真的开始处理 TB 级训练语料、做离线 embedding、或者给日志回放系统补算 token 成本，才会发现它不是“模型前面那一点点预处理”。 我看到 GigaToken 在 Hacker News 上拿到 600 多分时，第一反应其实不是“又一个性能神话”，而是：如果它的数字成立，LLM 数据管线里有一类被我们默认接受的慢步骤，可能确实该重新算账了。 项目本身很直接。GigaToken 是一个 Rust 写的语言模型 tokenizer，README 里给出的目标是“Language model tokenization at GB/s”，并且提供两种用法：一种是自己的高速 API，让 Rust 直接读文件；另一种是兼容 HuggingFace Tokenizers 或 tiktoken 的包装 API。作者在基准里声称，在 144 核 AMD EPYC 机器上，GPT-2 tokenizer 可以跑到 24.53 GB/s，而 HuggingFace Tokenizers 是 24.8 MB/s，tiktoken 是 36.0 MB/s；在 Apple M4 Max 上，GPT-2 也能到 8.79 GB/s。 这个数量级很夸张，所以我不建议只看“1000x”这个标题。 更有价值的问题是：它到底优化了什么？以及这些优化在你的生产链路里会不会被别的瓶颈吃掉？ Tokenization 为什么会慢 LLM tokenization 通常不是简单的 split()。以 BPE/Byte-level BPE 这类 tokenizer 为例，流程大概包括预切分、字节或 unicode 归一、查表、merge ranking、特殊 token 处理，以及把结果打包成 Python 侧可消费的数据结构。很多工程团队会默认使用 HuggingFace Tokenizers 或 OpenAI tiktoken，它们本身已经不是慢吞吞的纯 Python 实现，而是 Rust/C++ 等底层实现加 Python binding。 ...