GigaToken 声称分词速度最高提升 989 倍，挑战 Hugging Face

GigaToken 发布了一款语言模型分词器，据称在一台配备 144 核 AMD 处理器的服务器上，处理 GPT-2 文本的速度达到了 24.53 GB/s。在开发者的基准测试中，GigaToken 分词器比 Hugging Face Tokenizers 快 989 倍，也比 OpenAI 的 tiktoken 快 681 倍。

这些数字听起来像是足以全面取代现有方案的理由。但更准确的理解是：它展示了在高度优化、基于文件的工作负载下，分词可以达到多快的速度。GigaToken 使用专用 CPU 指令、激进的缓存策略、并行处理，并减少了与 Python 之间的数据往返。

这种区别很重要，因为速度最快的接口并不是直接兼容的替代层。该项目自身的 API 实现了宣传中的性能，而 Hugging Face 兼容模式会产生额外开销。一项独立复测也证实了其显著领先优势，但测得相较 Hugging Face 的提升仅为 83.4 倍，远低于宣传数字。

这一结果仍然给成熟的分词库带来了压力，但并不意味着每次模型请求都能快数百倍。真正的机会存在于数据集准备、大规模文档摄取、模型训练，以及其他将分词作为持续性基础设施工作的流水线中。

GigaToken 实际发布了什么

GigaToken 是一款开源 Rust 分词器，旨在利用现代 CPU 以每秒数 GB 的速度处理大型文本集合。

分词器将文本转换为语言模型所使用的整数标识符。字节对编码（即 BPE）通过反复合并常见字节序列来生成词表中的 token。GPT-2、Llama、Qwen 以及许多其他模型家族都使用了这一过程的变体。

开发者 Marcel Rød 表示，GigaToken 支持现代 x86 和 Arm 处理器以及许多常用分词器。该软件以 Python 软件包的形式分发，而其中对性能敏感的组件则使用 Rust 运行。

项目仓库介绍了两种使用方式。兼容模式可以封装现有的 Hugging Face 或 tiktoken 分词器；原生 API 则接受模型标识符，并可直接读取文本文件。

原生路径是其性能主张的核心。它允许 Rust 读取源数据，而无须反复转换 Python 对象，也让该库能够更全面地控制批处理、内存访问和并行执行。

兼容接口的目标有所不同。开发者可以封装现有分词器，并使用形似 Hugging Face Tokenizers 或 tiktoken 的 API。这可以减少那些已经围绕这些库构建的应用所需的迁移工作。

不过，开发者明确警告称，兼容性会牺牲性能。匹配 Hugging Face 的行为并返回熟悉的 Python 数据结构，会引入原生 API 所避免的额外工作。用户不应认为只需更改一处导入语句，就能获得宣传中的 989 倍提升。

此次发布支持一长串 BPE 模型家族。已公布的基准测试项目包括 GPT-2、Llama、Qwen、DeepSeek、GLM、Phi、OLMo、Kimi、Gemma、Mistral 和 ModernBERT 分词器。这些模型家族之间的性能差异相当明显。

GigaToken 在多个方面仍不完善。它不支持 WordPiece，而 SentencePiece 分词获得的优化少于 BPE。原生 API 尚未实现文件输出功能，并且建议 Windows 用户使用 Windows Subsystem for Linux。

截至本文发布时，该软件在 GitHub 上也没有列出正式版本。这并不妨碍通过 Python 软件包进行安装，但表明该项目仍处于早期阶段。生产团队应将 API 稳定性和兼容性覆盖范围视为尚待确认的问题。

因此，GigaToken 不只是一项合成速度实验，但也算不上通用的分词器替代品。它是一项雄心勃勃的系统级实现，提供兼容性桥接，存在已记录的限制，并提出了异常亮眼的基准测试成绩。

GigaToken 与 Hugging Face Tokenizers 对比：最吸睛的基准测试

在已公布的测试范围内，989 倍这一结果是真实的，但其硬件、数据路径和比较方法决定了这个数字究竟意味着什么。

开发者在一个 11.9 GB 的 OpenWebText 文件上测试了 GPT-2 分词。主服务器使用两颗 AMD EPYC 9565 处理器，两个插槽共提供 144 个 CPU 核心。

在这一配置下，GigaToken 报告的速度为 24.53 GB/s。Hugging Face Tokenizers 达到 24.8 MB/s，而 tiktoken 达到 36 MB/s，由此得出了所报告的 989 倍和 681 倍性能差距。

仓库称，输出验证覆盖了 20,401 份文档，结果与 Hugging Face 一致。这项验证十分重要，因为如果速度更快的分词器为相同输入分配了不同的 token 标识符，那么它几乎毫无价值。

GigaToken 还公布了在性能没那么极端的设备上的测试。据称，Apple M4 Max 处理 GPT-2 数据的速度达到 8.79 GB/s，相比之下 Hugging Face 为 6.9 MB/s，tiktoken 为 62.8 MB/s。

这相当于比 Hugging Face 快 1,268 倍、比 tiktoken 快 140 倍。在 AMD Ryzen 7 9800X3D 上，GigaToken 报告的速度为 6.27 GB/s，是 Hugging Face 测试结果的 106 倍。

这些数字表明，其优势并非仅限于某一种服务器架构。但它们并不能证明存在一个适用于所有硬件、分词器、文档大小或应用接口的固定倍数。

不同分词器家族的性能也会有所变化。在双 EPYC 系统上，据称 Llama 3 分词速度达到 22.15 GB/s，比 Hugging Face 快 457 倍。DeepSeek 分词速度则达到 19.69 GB/s，领先 750 倍。

其他分词器的差距相对较小。GigaToken 报告 Mistral 7B v0.3 的速度为 3.57 GB/s，约为 Hugging Face 吞吐量的十倍。Gemma 3 达到 3.43 GB/s，优势为 9.6 倍。

从约十倍到近一千倍的差距范围，才是更有用的结论。底层分词器规则决定了 GigaToken 优化后的预分词和缓存策略能提供多大帮助。

一项独立测试提供了另一个参考。复现的基准测试使用一台四核 Intel Xeon 虚拟机和一个 174.07 MB 的 OpenWebText 样本。

在三次运行中，GigaToken 的中位速度达到 277.77 MB/s。Tiktoken 达到 10.62 MB/s，而 Hugging Face Tokenizers 达到 3.33 MB/s。据报告，所有 35,356 份测试文档均产生了匹配的输出。

该独立测试显示，GigaToken 比 tiktoken 快 26.2 倍，比 Hugging Face 快 83.4 倍。它证实了开发者主张的整体方向，但未能复现其中最大的性能倍数。

这项独立测试使用了更少的数据、更少的核心和不同的主机，因此不应将其绝对吞吐量与双 EPYC 测试结果直接比较。其价值在于证明这种领先优势在脱离原始环境后依然存在。

因此，基准测试证据支持一个谨慎的结论：对于受支持的批处理型工作负载，GigaToken 的速度似乎快得多。具体提升倍数取决于硬件、输入、分词器、接口和测量方法的每一种组合。

GigaToken 分词器为何如此之快

GigaToken 的优势来自围绕 CPU 执行重新设计数据路径，而不是发明了一种不同的分词算法。

预分词是首要优化目标。在 BPE 应用词表合并规则之前，这一阶段会将文本拆分为更小的片段。许多分词器实现会将这项工作交给通用正则表达式引擎。

GigaToken 使用专用代码替代了这条路径中的大部分环节。该项目使用 SIMD，即一条 CPU 指令同时处理多个数据元素。其实现针对 AVX-512、AVX2 和 Arm NEON 指令集。

这种专用化减少了灵活的正则表达式引擎必须执行的工作，也使处理器的执行行为更加可预测，尤其是在大量文本遵循相似分词规则的情况下。

减少分支带来了另一项优势。分支要求处理器在不同执行路径之间做出选择。错误的分支预测可能使流水线停顿，因此减少不可预测的决策有助于维持吞吐量。

缓存是第二项主要机制。自然语言会重复出现单词、片段、空白模式和标点序列。GigaToken 对一个预分词单元完成编码后，可以在相同序列再次出现时复用结果。

这个想法听起来很简单，但该项目的开发者指出，其中存在一个更棘手的工程问题。预分词单元的分布具有长尾特征，缓存可能迅速膨胀。设计不佳的缓存可能会占用大量内存，同时频繁发生查找未命中。

GigaToken 使用一种缓存层级结构，旨在降低常见映射的检索成本。仓库将最终部分性能提升归因于消除分支和改进这一层级结构。

并行处理是第三项机制。原生接口让 Rust 可以直接控制文件输入和文档处理。它能够将工作分配到多个 CPU 核心，同时限制工作线程之间的通信。

这对于一台 144 核服务器至关重要。无法持续为这些核心提供独立任务的软件，会让机器的大部分计算能力处于闲置状态。GigaToken 围绕规模足以占满可用硬件的持续批处理任务构建。

Python 边界是第四项机制。在 Python 和原生代码之间移动数百万个小字符串、列表和整数对象会产生额外开销。当核心分词循环变得足够快后，这种开销可能占据主导地位。

GigaToken 的原生 API 通过在 Rust 内部读取文件来减少这些跨边界操作。它可以让输入字节、中间状态和 token 输出更贴近优化后的实现。

这种设计也解释了兼容模式为何较慢。直接替代式封装必须保留预期的方法、输出结构、特殊 token 处理、截断行为、填充和规范化。每一项兼容性承诺都会限制优化空间。

Hugging Face Tokenizers 本身已经主要使用 Rust 实现，并且支持并行处理。Tiktoken 同样依赖原生代码。GigaToken 获胜并不仅仅是因为其竞争对手在 Python 中执行分词。

相反，它针对的是一条更窄的路径。它假设用户经常需要使用受支持的分词器行为处理大型数据集合，并且只需进行最少的对象级交互。这种假设比起交互式应用，更符合数据集流水线的使用场景。

该项目还披露了在最后开发阶段使用 AI 辅助的情况。根据仓库说明，AI 协助移植 SIMD 策略、扩大兼容范围、重构代码，并找出了最后约四倍的性能提升空间。

开发者表示，代码库的大部分内容是在没有 AI 辅助的情况下编写的。这项披露并不能验证其正确性，但说明了优化和兼容性工作是如何完成的。

这些工程选择形成了一项实用的权衡。专用执行可以大幅超越通用框架，其代价则体现在功能支持范围较窄、包含更多针对特定架构的代码，以及更沉重的测试负担上。

更快的分词并不意味着更快的模型推理

GigaToken 可以消除预处理瓶颈，但它无法加速生成模型答案的神经网络。

一次在线语言模型请求通常会经过多个阶段。服务器接收文本，将其分词，运行模型预填充，生成输出 token，对其进行解码，然后返回响应。

分词只涵盖了这一流程的一部分。模型预填充通过 transformer 层处理输入，而生成阶段则反复预测下一个 token。这些 GPU 或加速器操作通常占据了请求延迟的大部分。

对于较短的聊天提示词，分词所需时间可能极短，因此即使相对性能有大幅提升，实际节省的时间也几乎可以忽略不计。将一个极短的预处理时段缩短 99%，并不能弥补模型缓慢或服务队列拥堵造成的延迟。

这一局限很快就在社区讨论中显现出来。一位开发者质疑分词究竟是不是瓶颈，并指出模型执行通常感觉更慢。另一位开发者则观察到，更快的分词改变的是推理开始前的耗时，而不是推理本身。

最有力的应用场景涉及持续的大规模文本处理。模型训练需要先对大型语料库进行分词，之后样本才能进入训练流水线。反复进行实验时，可能还需要使用多种词表配置处理同一语料库。

数据集过滤和去重也可能依赖 token 数量。团队可能会剔除超出上下文限制的样本，按 token 长度对文档分组，或根据编码后的数据集估算训练预算。

检索系统则提供了另一种潜在工作负载。大型数据摄取任务可能会将数百万个文件拆分成适合模型处理的分块，并计算每个分块的 token 边界。更快的编码可以缩短这一预处理阶段。

Agent 系统是否适用则不太确定。Agent 可能会反复组装包含工具结果、日志、代码和检索文档的长提示词。当这些上下文变得非常庞大时，节省分词时间或许可以降低输入准备延迟。

然而，交互式 Agent 请求还包括网络调用、工具执行、模型预填充和生成。团队必须对完整链路进行性能分析，之后才能将明显的延迟归因于分词。

GigaToken 自己的基准测试侧重于基于文件的处理，因为这种环境最能展现其设计优势。通过原生路径读取 11.9 GB 语料库，与编码数千个相互独立的 Web 请求并不等同。

“直接替换”这一说法也需要加以限定。兼容性封装旨在匹配人们熟悉的 API，项目方也表示为实现一致输出投入了大量精力。然而，原生接口带来的速度提升最大。

因此，生产环境迁移需要作出选择。团队可以保留现有接口并获得较小的性能提升，也可以围绕 GigaToken 面向文件的 API 重新设计数据路径。

功能覆盖范围构成了另一项限制。使用 WordPiece 的工作负载目前无法迁移。SentencePiece 用户应当预期优化幅度较小，而 Windows 部署仅接受了有限测试。

输出等价性同样值得持续审查。分词器涉及特殊 token、规范化规则、截断、填充、偏移量以及模型专用的预分词器。正确的 token 标识符固然必要，但一些应用还依赖元数据。

tokenizer 文档反映出这一功能面的覆盖范围已经多么广泛。Hugging Face 提供训练、规范化、预分词、后处理、填充、截断、对齐追踪以及多种语言绑定。

GigaToken 无需复制每一项功能也能体现价值。但它确实需要明确说明哪些行为完全一致、哪些运行方式有所不同，以及哪些仍不受支持。

安全团队还应将分词器制品视为可执行配置。修改后的词表或规范化规则可以在不改变模型权重的情况下，改变模型解释输入的方式。

近期的篡改研究展示了被修改的分词器映射如何操纵解码后的 URL 或工具参数。GigaToken 并未制造这一问题，但迁移时应保留制品验证控制措施。

主要风险并不在于这些性能数据必然是虚假的，而在于读者可能会将吞吐量基准测试套用到那些对分词耗时、兼容性和安全性有着不同权重的系统上。

谁将面临 GigaToken 带来的压力

GigaToken 迫使成熟库解释其通用性在哪些方面牺牲了吞吐量，以及常见的批处理路径能否获得显著提速。

Hugging Face Tokenizers 服务于广泛的生态系统，而非单一的性能配置。它支持构建新分词器、加载现有配置、追踪文本对齐关系，并与模型工具集成。

这种广度对研究人员和应用开发者很有价值，但也可能引入专业化批量编码器能够避免的抽象层。GigaToken 使这些抽象带来的性能成本变得更难忽视。

Tiktoken 的定位有所不同。OpenAI 围绕 BPE 分词构建了它，并将其作为开源库发布。如今，它已成为在 OpenAI 兼容工作流中估算 token 数量和编码文本的常用选择。

它的参考实现已经在性能敏感的工作中使用 Rust。GigaToken 所报告的领先优势表明，仅仅使用原生代码并不能决定性能竞争的结果。

竞争的关键问题在于，成熟项目能否在不损害其 API 的情况下采用类似思路。SIMD 预分词器、改进的缓存以及更好的文件摄取机制都有可能缩小差距。

但现有项目可能会优先考虑不同的目标。Hugging Face 必须支持众多模型配置、运行环境和用户预期。Tiktoken 则必须为整个 OpenAI 工具生态中使用的 token 编码保持可预测的行为。

GigaToken 能够更快行动，因为它是一个规模较小、以性能为首要目标的项目。这一优势也使维护责任更加集中。针对特定架构的优化需要在不同处理器、编译器、操作系统和输入分布上进行测试。

此次发布也给基础设施团队带来了挑战。许多组织将分词视为一个已经解决的库调用问题。独立复现出的 26 倍或 83 倍性能差异表明，这一假设值得重新测量。

其业务影响取决于工作负载规模。对于偶尔出现的提示词请求，更换分词器可能只会带来迁移风险，而不会产生可见收益。对于数 TB 规模的数据摄取，数小时的预处理则可能缩短至几分钟。

训练团队最有动力进行测试。他们会定期处理固定数据集，能够控制计算环境，并可在正式启动训练前验证输出。这些条件与 GigaToken 的优势高度匹配。

数据平台团队也可能从中受益。token 数量会影响存储格式、批处理、过滤和调度。更快的编码可以让分词不再成为重复转换流程中的关键路径。

应用开发者应继续保持选择性。如果一项服务的大部分延迟来自模型生成、数据库或外部 API，优化分词器无法修复更大的系统问题。

这正是独立测试结果比最吸引眼球的最高数据更重要的原因。在普通云硬件上，相比 tiktoken 可重复实现 26 倍领先，已经足以成为评估理由，而不需要依赖千倍加速的承诺。

成熟库并未突然过时。它们仍然拥有成熟的 API、社区信任、更广泛的支持以及更深的集成能力。GigaToken 改变的是性能基准点，而这些优势今后都将以此为参照接受评判。

GigaToken 发布后值得关注什么

接下来需要关注的三个信号是更广泛的独立基准测试、兼容性测试结果，以及真实数据流水线中的采用情况。

第一个信号是在更多硬件和数据上的复现结果。双路 EPYC 基准测试展示了 GigaToken 的性能上限，而四核复现则提供了一个规模较小的独立样本。

有价值的后续测试应比较相同接口、完全一致的数据集、固定线程数以及匹配的输出。测试内容应涵盖短文档、多语言文本、代码、格式错误的 Unicode，以及大量使用特殊 token 的输入。

如果在这些条件下都能保持稳定的领先优势，核心主张就会得到进一步强化。如果性能波动较大或出现输出不匹配，GigaToken 的实际适用范围就会缩小。

第二个信号是兼容性覆盖范围。开发者应关注涉及规范化、偏移量、填充、截断、特殊 token 以及较少见 Hugging Face 配置的问题报告。

支持 WordPiece 将扩大可覆盖的模型集合。提升 SentencePiece 性能，则会让该项目对其最强 BPE 路径之外的模型系列更具相关性。

正式发布版本和有文档记录的兼容性保证也会降低部署风险。当下游系统依赖精确的 token 标识符时，稳定的版本管理策略十分重要。

第三个信号是生产环境采用情况。训练流水线、数据集构建工具、推理服务提供商和检索平台可以揭示分词器吞吐量目前是否确实限制了有意义的工作。

真实部署应报告端到端耗时，而不仅仅是编码器吞吐量。一个分词速度提升 100 倍但整体仅快 10% 的流水线，与其微基准测试所讲述的是不同的故事。

团队还应报告内存消耗和扩展效率。大量使用缓存的设计可以用内存换取速度，而多路系统可能遭遇带宽和协调方面的限制。

对于目前正在评估 GigaToken 的开发者，下一步很直接。单独分析分词性能，对照现有库验证输出，并测试计划在生产环境中使用的同一接口。

不要一开始就将 989 倍作为预期结果。首先应提出一个决定任何倍数是否重要的问题：如今分词占用了多少实际运行时间？

如果答案是占比显著，那么 GigaToken tokenizer 值得接受受控基准测试。如果模型推理占据主导，优化工作就应投入其他地方。这一区别将决定此次发布会成为核心 LLM 基础设施，还是仅仅停留在一个令人印象深刻的专业化引擎。