Токенизация — этап предварительной обработки, который преобразует сырой текст в числовые последовательности токенов, фактически потребляемые языковыми моделями, — остается одним из наименее профилируемых компонентов ML-стека. По мере роста обучающих наборов данных до терабайтных и петабайтных масштабов время, затрачиваемое на такое преобразование, может становиться практическим узким местом в конвейерах подготовки данных, однако оптимизация этого этапа редко оказывается в центре внимания. Gigatoken, новая библиотека, выпущенная Marcel Rød, аспирантом Stanford, под лицензией MIT, показывает, что такое упущение имеет цену. Библиотека кодирует текст со скоростью гигабайт в секунду на одной машине, превосходя базовые решения, которые уже реализованы на многопоточном Rust.

Результаты бенчмарков

В бенчмарке токенизатора GPT-2 на корпусе owt_train.txt объемом 11.9 GB на двухсокетной системе AMD EPYC 9565 со 144 ядрами Gigatoken обрабатывает данные со скоростью 24.53 GB/s. На том же оборудовании OpenAI's tiktoken — библиотека, используемая для кодирования текста для моделей GPT, — достигает 36.0 MB/s, а HuggingFace tokenizers — фактический стандарт токенизации в open-source ML-экосистеме — показывает 24.8 MB/s, что соответствует преимуществу в производительности 681x и 989x соответственно.

Ускорение сохраняется на разных архитектурах. На Apple M4 Max с 16 ядрами та же нагрузка GPT-2 выполняется со скоростью 8.79 GB/s — в 1,268x быстрее HuggingFace tokenizers и в 140x быстрее tiktoken. На потребительском AMD Ryzen 7 9800X3D Gigatoken достигает 6.27 GB/s, что соответствует ускорению 106x и 68x относительно соответствующих базовых решений.

Что такое Gigatoken

Gigatoken — это токенизатор byte-pair encoding (BPE), написанный на Rust и оснащенный привязками Python. BPE является доминирующим алгоритмом субсловной токенизации для современных LLM и используется, среди прочего, в семействах GPT, Llama, Qwen и Mistral. Он доступен на PyPI как gigatoken (version 0.9.0, released 21 July 2026) и устанавливается через pip install gigatoken. Кодовая база состоит из 66.2% Rust и 33.3% Python. Опубликованные бенчмарки охватывают 23 отдельных семейства токенизаторов, включая GPT-2, GPT-OSS, Llama 3 through 4, Qwen 2 through 3.6, DeepSeek V3/R1/V4, GLM 4 and 5, Kimi K2, Nemotron 3, Phi-4, OLMo 2/3, ModernBERT, Gemma и Mistral.

Gigatoken предлагает два режима использования. Режим совместимости оборачивает существующий токенизатор HuggingFace или tiktoken, сохраняя точное совпадение выходных данных ценой пропускной способности. Rød заявил на Hacker News, что режим совместимости дает ускорение примерно 200–300x в зависимости от сценария использования, поскольку по-прежнему несет накладные расходы Python на создание списков и преобразование строк в байты. Нативный API Gigatoken, позволяющий Rust напрямую читать файлы, является источником опубликованных результатов бенчмарков.

Технический подход

Прирост производительности не связан с более быстрым циклом слияния BPE. Вместо этого он возникает в двух областях, которые большинство токенизаторов считают уже решенными.

Оптимизация предварительной токенизации

Большинство реализаций делегируют предварительную токенизацию regex-движку. Gigatoken вручную реализует весь предварительный токенизатор. Журнал оптимизации предварительного токенизатора отслеживает однопоточную пропускную способность предварительного токенизатора GPT-2 на 100 MB OpenWebText и показывает подробную эволюцию:

• Базовая реализация fancy-regex работает примерно на 47 MiB/s.
• Ручной конечный автомат достигает примерно 380 MiB/s.
• Реализация на комбинаторах winnow с NEON SIMD intrinsics достигает 462 MiB/s.

Дальнейшая оптимизация была достигнута за счет замены winnow прямым Iterator, добавления 256-байтовой таблицы поиска классов для O(1)-диспетчеризации по первому байту и перехода с NEON intrinsics на SWAR (SIMD Within A Register). SWAR загружает 8 байт как u64 и проверяет все 8 на свойство буквы с помощью безветвистой арифметики, не требуя архитектурно-специфичных intrinsics. Это подняло пропускную способность до 830 MiB/s.

Финальный шаг оптимизации включал использование параллелизма на уровне инструкций (ILP) с двумя курсорами, что позволило достичь 1,049 MiB/s. Ключевое наблюдение заключалось в том, что узким местом примерно на 840 MiB/s была задержка, а не пропускная способность. Конечная позиция каждого токена зависит от предыдущей, создавая последовательную цепочку примерно из 25–27 циклов. Запуск двух независимых курсоров из безопасной точки разделения позволяет движку внеочередного исполнения чередовать оба потока через простаивающие исполнительные порты.

Чистый эффект только для предварительного токенизатора: 2.27x относительно базовой реализации winnow + NEON и 22.3x относительно regex-реализации.

Кэширование предварительных токенов

Если слово уже встречалось ранее, его закодированные токены извлекаются из кэша вместо повторного вычисления. Rød отмечает, что на практике это сложно, поскольку кэш быстро растет, а распределения предварительных токенов имеют длинный хвост. Кроме того, взаимодействия с Python сведены к минимуму, а потоки спроектированы так, чтобы минимально взаимодействовать друг с другом.

Журнал оптимизации также документирует подходы, которые не сработали. Разделение hot/cold с использованием #[cold] и #[inline(never)] привело к регрессии до 580 MiB/s и было отменено, поскольку inline-барьер помешал LLVM оптимизировать объединенный цикл ASCII и unicode. Двухпроходный буфер классификации с подсчетом переходов SWAR был алгоритмически корректен, но работал на 354 MiB/s, поскольку дополнительный трафик памяти перевесил экономию на ветвлениях. Profile-guided optimization не дала измеримого эффекта, потому что внутренний цикл уже безветвистый, а ветвление на границе слова зависит от данных.

Методология бенчмарков

Сравнение не является полностью равным. Gigatoken кодирует целые неразделенные файлы, самостоятельно находя границы документов и автоматически распараллеливая обработку. HuggingFace (encode_batch_fast) оценивается на первых 100 MB, тогда как tiktoken (encode_ordinary_batch) оценивается на первом 1 GB; в обоих случаях данные заранее разделены по <|endoftext|>. Поскольку базовые решения не реализуют кэширование, их пропускная способность остается равномерной. Все измерения указывают лучший результат из трех чередующихся прогонов с использованием новых процессов и включенным параллелизмом.

Тип словаря также накладывает ограничения. Токенизаторы SentencePiece оптимизированы лишь частично. На EPYC Gemma 1 обрабатывается со скоростью 2.51 GB/s (ускорение 7.3x), Gemma 3 — 3.43 GB/s (9.6x), а CodeLlama — 3.47 GB/s (10.0x). Хотя это существенные результаты, такие приросты на порядок ниже заголовочных показателей производительности BPE.

Независимое воспроизведение на KrabArena подтвердило результаты. На VM Intel Xeon с 4 vCPU (2.20 GHz) и фрагментом OpenWebText объемом 174 MB Gigatoken 0.9.0 достиг медианной скорости 277.8 MB/s, превзойдя tiktoken 0.13.0 (10.62 MB/s) в 26.2x и tokenizers 0.23.1 (3.33 MB/s) в 83.4x. Все прогоны успешно валидировали 35,356 документов, подтвердив, что тренд производительности масштабируется с числом ядер.

Область применения и ограничения

Ускорение Gigatoken сохраняется как на x86, так и на ARM-архитектурах, а также во всех 23 поддерживаемых семействах токенизаторов, а не ограничивается одной специально настроенной конфигурацией. Однако словари SentencePiece показывают ускорение 7–22x, а не приросты в диапазоне 1,000x, и WordPiece не поддерживается. Режим совместимости сохраняет точное совпадение выходных данных HuggingFace примерно на 200–300x, а не полное нативное ускорение.

Репозиторий GitHub и обозреватель бенчмарков доступны публично.