Reed's News
← 返回精选

GigaToken：语言模型分词提速千倍

AI 81 syrusakbary 2026/7/22 1290 字 原文 ↗

比HuggingFace分词器快约1000倍，可直接替代使用。

文本数据分词速度可达GB级每秒！

请注意：HF分词器与tiktoken均已采用多线程Rust实现！

Gigatoken是当前速度最快的语言建模分词器，支持绝大多数主流CPU硬件与常用分词器。各分词器在不同CPU上的详细吞吐量数据，可查看性能基准测试章节。

pip install gigatoken Gigatoken可通过自有API调用，也可兼容HuggingFace Tokenizers或Tiktoken的使用模式。

import gigatoken as gt
# 与现有HuggingFace分词器用法几乎一致（兼容模式）
hf_tokenizer = ...
tokenizer = gt.Tokenizer(hf_tokenizer).as_hf()
# 该tokenizer可在原hf_tokenizer适用的场景中直接使用
tokens = tokenizer.encode_batch(["This is a test string", "And here is another"])
# 也可兼容tiktoken
tiktokenizer = ...
tokenizer = gt.Tokenizer(tiktokenizer).as_tiktoken()
# 现在可像原有tiktoken分词器一样使用
tokens = tokenizer.encode_batch(["This is a test string", "And here is another"])

我们投入大量精力确保此模式下的输出结果与HuggingFace Tokenizers完全一致，但这会带来不可忽视的性能损耗。即便如此，Gigatoken的整体速度仍远快于竞品，只是无法达到其自有API能实现的1000倍提速效果。

import gigatoken as gt
tokenizer = gt.Tokenizer("Qwen/Qwen3-8B") # 支持传入HF模型名称
file_source = gt.TextFileSource(["owt_train.txt"], separator=b"<|endoftext|>")
tokens = tokenizer.encode_files(file_source)

使用Gigatoken自有API时，Rust实现会直接读取数据，在最大化并行度的同时尽可能减少开销。需注意的是，若通过该API传递Python数据结构，仍会产生Python层面的读取开销。

基于owt_train.txt（11.9 GB）的编码吞吐量测试——AMD EPYC 9565 72核处理器×2插槽（共144核）

分词器 gigatoken HF tokenizers tiktoken 相对HF提速 相对tiktoken提速
GPT-2 24.53 GB/s 24.8 MB/s 36.0 MB/s 989× 681×
Phi-4 24.00 GB/s 29.9 MB/s — 801× —
GPT-OSS 23.96 GB/s 49.7 MB/s 42.8 MB/s 482× 560×
OLMo 2 / 3 23.06 GB/s 27.7 MB/s — 833× —
Nemotron 3 22.79 GB/s 49.4 MB/s — 462× —
Qwen 3 22.16 GB/s 34.2 MB/s — 648× —
Llama 3 / 3.1 / 3.2 22.15 GB/s 48.5 MB/s — 457× —
GLM 5 20.97 GB/s 74.8 MB/s — 280× —
Llama 3.3 20.82 GB/s 48.3 MB/s — 431× —
Llama 4 20.77 GB/s 72.7 MB/s — 286× —
GLM 4 20.61 GB/s 72.3 MB/s — 285× —
Phi-4-mini 20.05 GB/s 27.6 MB/s — 726× —
DeepSeek V3 / R1 / V4 19.69 GB/s 26.2 MB/s — 750× —
Qwen 2 / 2.5 19.12 GB/s 27.7 MB/s — 691× —
Kimi K2 18.85 GB/s — — — —
Qwen 3.5 / 3.6 15.49 GB/s 27.7 MB/s — 558× —
Gemma 4 4.82 GB/s 334.1 MB/s — 14× —
ModernBERT 4.18 GB/s 26.9 MB/s — 155× —
Mistral 7B v0.3 3.57 GB/s 354.7 MB/s — 10× —
TinyLlama / Phi-3 (Llama 2) 3.48 GB/s 323.6 MB/s — 11× —
CodeLlama 3.47 GB/s 347.4 MB/s — 10.0× —
Gemma 3 3.43 GB/s 357.2 MB/s — 9.6× —
Gemma 1 2.51 GB/s 342.2 MB/s — 7.3× —

基于owt_train.txt（11.9 GB）的编码吞吐量测试——Apple M4 Max（16核）

分词器 gigatoken HF tokenizers tiktoken 相对HF提速 相对tiktoken提速
GPT-2 8.79 GB/s 6.9 MB/s 62.8 MB/s 1268× 140×
Nemotron 3 7.82 GB/s 10.9 MB/s — 715× —
Phi-4 7.76 GB/s 7.7 MB/s — 1012× —
Llama 3 / 3.1 / 3.2 7.60 GB/s 11.2 MB/s — 676× —
OLMo 2 / 3 7.56 GB/s 5.8 MB/s — 1299× —
Llama 3.3 7.50 GB/s 15.7 MB/s — 479× —
Phi-4-mini 6.97 GB/s 7.2 MB/s — 964× —
Kimi K2 6.88 GB/s — — — —
Llama 4 6.81 GB/s 11.6 MB/s — 590× —
Qwen 2 / 2.5 6.37 GB/s 5.8 MB/s — 1105× —
Qwen 3 6.36 GB/s 6.9 MB/s — 918× —
Qwen 3.5 / 3.6 6.31 GB/s 6.3 MB/s — 994× —
GPT-OSS 6.20 GB/s 20.2 MB/s 87.2 MB/s 306× 71×
GLM 4 6.17 GB/s 15.8 MB/s — 392× —
DeepSeek V3 / R1 / V4 5.68 GB/s 7.2 MB/s — 788× —
GLM 5 5.55 GB/s 12.2 MB/s — 456× —
ModernBERT 2.64 GB/s 5.8 MB/s — 452× —
Mistral 7B v0.3 1.99 GB/s 95.1 MB/s — 21× —
Gemma 4 1.82 GB/s 85.2 MB/s — 21× —
CodeLlama 1.73 GB/s 80.2 MB/s — 22× —
TinyLlama / Phi-3 (Llama 2) 1.69 GB/s 80.1 MB/s — 21× —
Gemma 1 1.42 GB/s 85.7 MB/s — 17× —
Gemma 3 1.38 GB/s 82.2 MB/s — 17× —

基于owt_train.txt（11.9 GB）的编码吞吐量测试——AMD Ryzen 7 9800X3D 8核处理器（16核）

分词器 gigatoken HF tokenizers tiktoken 相对HF提速 相对tiktoken提速
GPT-2 6.27 GB/s 59.0 MB/s 92.1 MB/s 106× 68×
Phi-4 6.09 GB/s 55.4 MB/s — 110× —
OLMo 2 / 3 6.06 GB/s 55.4 MB/s — 109× —
Phi-4-mini 5.80 GB/s 54.6 MB/s — 106× —
GPT-OSS 5.68 GB/s 79.6 MB/s 112.7 MB/s 71× 50×
Qwen 3 5.34 GB/s 54.4 MB/s — 98× —
Qwen 2 / 2.5 5.30 GB/s 51.7 MB/s — 103× —
Llama 3.3 5.26 GB/s 79.9 MB/s — 66× —
Llama 3 / 3.1 / 3.2 5.24 GB/s 79.5 MB/s — 66× —
Kimi K2 5.23 GB/s — — — —
Qwen 3.5 / 3.6 5.22 GB/s 51.6 MB/s — 101× —
Nemotron 3 5.20 GB/s 79.0 MB/s — 66× —
GLM 5 5.05 GB/s 79.5 MB/s — 63× —
GLM 4 5.04 GB/s 79.5 MB/s — 63× —
Llama 4 5.03 GB/s 78.2 MB/s — 64× —
DeepSeek V3 / R1 / V4 4.21 GB/s 51.6 MB/s — 82× —
ModernBERT 2.84 GB/s 52.1 MB/s — 54× —
Mistral 7B v0.3 1.47 GB/s 91.6 MB/s — 16× —
Gemma 4 1.45 GB/s 78.8 MB/s — 18× —
CodeLlama 1.38 GB/s 85.2 MB/s — 16× —
TinyLlama / Phi-3 (Llama 2) 1.37 GB/s 84.9 MB/s — 16× —
Gemma 1 1.14 GB/s 84.9 MB/s — 13× —
Gemma 3 1.12 GB/s 83.0 MB/s — 13× —

性能基准测试细节

选择OWT（openwebtext）数据集，是因为它能大致代表从CommonCrawl文档中提取出的文本类型。 Gigatoken会对整个文件进行无拆分编码，因此相比其他分词器，它需要额外完成拆分边界识别与自动并行处理的工作。 HuggingFace分词器（encode_batch_fast）仅处理前100MB数据，tiktoken（encode_ordinary_batch）处理前1GB数据，二者均提前按<|endoftext|>完成拆分。 这种对比方式是公平的，因为对比的两款分词器均不支持缓存，处理速度在整个过程中基本保持一致。 目前仅官方支持的分词器会填充tiktoken相关数据。

速度最慢的是基于SentencePiece的分词器，Gigatoken对这类分词器的优化程度较低。

每一行代表一款独立分词器（词表、合并规则、预分词逻辑完全一致），测试基于具有代表性的代码仓库。若未找到你使用的分词器，它很可能基于以下某款现有分词器开发：

  • Llama 3 / 3.1 / 3.2：Llama 3 / 3.1 / 3.2、DeepSeek-R1-Distill-Llama、Hermes 3、Saiga及其他基于Llama-3的微调模型
  • Llama 3.3：Llama 3.3、Llama-3.1-Nemotron-Nano-VL、SmolLM3、Kanana 1.5、jina-embeddings-v5、Ultravox
  • Qwen 2 / 2.5：Qwen 2与2.5（含代码版与多模态版）、Qwen3-Coder、Qwen3-VL、基于Qwen蒸馏的DeepSeek-R1模型、MiMo V2.5、MiniCPM-o 2.6、InternVL3
  • Qwen 3：Qwen 3（含Embedding与Reranker）、Qwen2.5-Omni、Qwen3-VL-Embedding、MiMo V2.5 Pro、jina-reranker-m0、pplx-embed、MOSS-TTS、Zeta
  • DeepSeek V3 / R1 / V4：DeepSeek V3 / V3.1 / V3.2、R1、V4 Flash与Pro版、DeepSeek-VL2
  • GLM 4：GLM 4.1V、4.5、4.7
  • GLM 5：GLM 5 / 5.2、GLM-4.7-Flash
  • Nemotron 3：Nemotron 3 Nano、Super、Ultra
  • Kimi K2：Kimi K2 / K2.5 / K2.6 / K2.7、Kimi-Linear、Kimi-VL、Moonlight
  • Phi-4-mini：Phi-4-mini、Phi-4-multimodal
  • TinyLlama / Phi-3 (Llama 2)：TinyLlama、Phi-3-mini、Phi-3.5-mini、Phi-3.5-vision（采用Llama 2词表）
  • Gemma 3：Gemma 3（2.7亿至270亿参数）、EmbeddingGemma
  • Gemma 4：Gemma 4（ dense、MoE、E系列）、DiffusionGemma

没错，我针对所有这些组合做了极致优化！测试结果在现代x86与ARM架构CPU上、以及不同分词器之间均保持高度一致。

性能提升的核心在于：通过SIMD指令集、减少分支等技巧，对原本依赖正则引擎的预分词环节进行深度优化；同时大幅优化预分词映射的缓存机制（若某个词已出现过，可高效查询其编码后的token）。缓存是该领域的一大难题，因为缓存会迅速膨胀，且预分词的分布呈现典型的长尾特征。

此外，减少与Python的交互、避免线程间通信，也进一步提升了性能。

无需安装即可试用！以下命令可验证指定HuggingFace模型仓库的分词效果并计时：

# 下载测试数据
wget https://huggingface.co/datasets/stanford-cs336/owt-sample/resolve/main/owt_train.txt.gz # 示例数据！
gunzip owt_train.txt.gz

uvx --with tokenizers gigatoken bench 'openai-community/gpt2' owt_train.txt \
--validate --doc-separator "<|endoftext|>"

cpu: Apple M4 Max, 16 cores
gigatoken: 1.432 s | 11920.51 MB at 8327.05 MB/s | 2701.65 Mtok at 1887.23 Mtok/s
hf: 16.250 s | 100.00 MB at 6.15 MB/s | 22.76 Mtok at 1.40 Mtok/s
gigatoken is 1353.13x faster than hf
validation OK: 20401 documents match

cpu: AMD EPYC 9565 72-Core Processor, 144 cores, 2 sockets
gigatoken: 0.486 s | 11920.51 MB at 24532.45 MB/s | 2701.65 Mtok at 5564.94 Mtok/s
hf: 4.033 s | 100.00 MB at 24.80 MB/s | 22.76 Mtok at 5.63 Mtok/s
gigatoken is 989.21x faster than hf
validation OK: 20401 documents match

按照EPYC CPU上的测试速度，处理完整Common Crawl数据集（常被视为整个互联网的文本集合，含130万亿个token）仅需不到6.5小时！

本示例使用该数据集的训练样本，CLI默认选取文件前100MB进行验证，并与HF分词器对比。 可通过uvx gigatoken bench --help查看参数说明。 在macOS上可能需要运行两次命令才能获得准确结果，因为首次运行会触发安全扫描，导致Rust代码运行变慢。

大概率不会！尽管已开展大量测试，但我无法覆盖所有使用场景，若发现问题，请在GitHub Issue中提交反馈，我会尽快处理。

若在研究中使用Gigatoken，请按以下格式引用：

@software{roed2026gigatoken,
author = {Marcel R{\o}d},
title = {{G}igatoken: SIMD and Cache Hierarchies for 1000x Faster Byte-Pair Encoding Tokenization on Modern CPUs},
url = {https://github.com/marcelroed/gigatoken},
year = {2026},
}
  • Python迭代由Rust处理，但采用ABI3标准，速度慢于针对特定CPython版本的内部API。未来我计划为各Python版本做专门优化，以消除这部分开销。早期实验显示，在受开销限制的场景中，可实现2倍速度提升。
  • Gigatoken API目前尚未实现文件输出功能。
  • 暂不支持WordPiece分词方式。
  • 基于SentencePiece的分词优化程度远低于主流BPE分词器，目前优先级较低，因为仅谷歌模型及BERT类模型较多使用SentencePiece。
  • Windows平台测试不足，暂时建议使用WSL运行。

AI使用说明

本项目大部分代码为手动编写，未借助AI工具（可通过项目Git历史验证）。在项目最终阶段，AI工具仅用于辅助完成以下工作：

  • 实现面向用户的API
  • 拓宽兼容性，例如通用化预分词器实现以支持更多分词器，以及填充/截断/Unicode规范化等次要功能的移植
  • 在AVX512/AVX2/NEON指令集间移植SIMD策略
  • 最终性能分析阶段，以及通过消除分支、优化预分词缓存层级实现的最后约4倍性能提升
  • 代码重构与复用