В мире больших языковых моделей (LLM) существует один узкий горлышко, которое часто остается в тени: токенизация. Пока мы обсуждаем скорость инференса, оптимизацию VRAM и новые архитектуры трансформеров, процесс преобразования сырого текста в токены часто считается «решенной» задачей. Разработчики полагаются на стандартные библиотеки, такие как HuggingFace Tokenizers или tiktoken, не задумываясь о том, сколько ресурсов они тратят на этот этап. Однако Марсель Рёд, аспирант Стэнфордского университета, утверждает, что это была серьезная ошибка. Его проект — Gigatoken — библиотека на Rust с привязками к Python, которая не просто улучшает, а полностью пересматривает подход к кодированию текста.
Результаты тестирования Gigatoken поражают воображение. На одном сервере библиотека способна кодировать текст со скоростью до 24.53 ГБ/с. Это не просто небольшое улучшение производительности; это качественный скачок, который делает токенизацию в 989 раз быстрее, чем у HuggingFace Tokenizers, и в 681 раз быстрее, чем у OpenAI’s tiktoken, на идентичном оборудовании. В этой статье мы подробно разберем, как именно удалось достичь таких показателей, какие технические решения были применены, и что это значит для разработчиков AI, работающих с большими объемами данных.
01Почему токенизация стала узким местом?
Токенизация — это процесс разбиения текста на более мелкие единицы (токены), которые модель может понять. Для современных моделей с триллионами параметров объем данных для предобработки (preprocessing) колоссален. Даже если вы обучаете модель на корпусе в несколько терабайт, каждый байт должен быть преобразован в числовые идентификаторы. Традиционные инструменты, такие как HuggingFace Tokenizers (написанные на Rust, но с тяжелыми Python-обертками) и tiktoken (написанный на C, но с ограничениями в алгоритмах), не были спроектированы для максимальной параллелизации на уровне ядра процессора без значительных накладных расходов.
Марсель Рёд заметил, что большинство токенизаторов делегируют этап предтокенизации (pretokenization) регулярным выражениям (regex). Хотя regex гибки, они медленны. Gigatoken предлагает альтернативу: ручную оптимизацию каждого этапа конвейера. Библиотека выпущена под лицензией MIT, что делает ее доступной для коммерческого использования, и доступна через PyPI (версия 0.9.0, выпущенная 21 июля 2026 года). Репозиторий состоит на 66.2% из кода на Rust и на 33.3% из Python, что позволяет использовать мощь Rust для вычислений и удобство Python для интеграции.
02Бенчмарки: Цифры, которые невозможно игнорировать
Чтобы оценить масштаб прорыва, давайте посмотрим на конкретные цифры. Тестирование проводилось на корпусе owt_train.txt объемом 11.9 ГБ (OpenWebText) с использованием токенизатора GPT-2. Оборудование для основного теста — сервер с двумя сокетами AMD EPYC 9565, общим количеством 144 ядер.
- Gigatoken: 24.53 ГБ/с.
- OpenAI tiktoken: 36.0 МБ/с.
- HuggingFace Tokenizers: 24.8 МБ/с.
Разница в скорости составляет 681x для tiktoken и 989x для HuggingFace. Это означает, то то, что раньше занимало часы, теперь занимает минуты. Но самое интересное, что Gigatoken не зависит от специфического серверного железа. На потребительском процессоре Apple M4 Max (16 ядер) скорость составляет 8.79 ГБ/с, что в 1268 раз быстрее HuggingFace. На AMD Ryzen 7 9800X3D скорость достигает 6.27 ГБ/с. Эти данные доказывают, что ускорение обусловлено алгоритмическими улучшениями, а не просто использованием специализированных серверных инструкций.
03Архитектура успеха: Как Gigatoken обходит ограничения
Секрет производительности Gigatoken кроется не в самом алгоритме Byte-Pair Encoding (BPE), который остается стандартным. Прирост скорости достигается за счет двух ключевых оптимизаций, которые большинство разработчиков считают «решенными» и поэтому игнорируют: ручная предтокенизация и кэширование предтокенов.
1. Ручная предтокенизация и SWAR
Большинство токенизаторов используют библиотеки регулярных выражений для разделения текста на слова и символы. Gigatoken отказался от этого в пользу написанного с нуля конечного автомата. Марсель Рёд подробно задокументировал эволюцию этого модуля в логах оптимизации:
- Базовый regex (fancy-regex): ~47 МБ/с.
- Ручной конечный автомат: ~380 МБ/с.
- Winnow-combinator с NEON SIMD: 462 МБ/с.
- Прямой Iterator + таблица поиска 256 байт + SWAR: 830 МБ/с.
Ключевым моментом стало внедрение SWAR (SIMD Within A Register). Эта техника позволяет загружать 8 байт данных как одно 64-битное целое число (u64) и проверять их свойства (например, является ли символ буквой) с помощью безветвистой арифметики. Это избавляет от необходимости использовать архитектурно-специфичные инструкции (как NEON на ARM или AVX на x86), делая код более переносимым и эффективным. Финальным штрихом стала эксплуатация двукурсорной инструкционной параллелизации (ILP). Поскольку конец одного токена зависит от начала следующего, процессор часто простаивает, ожидая данных. Запуск двух независимых курсоров с безопасной точки разделения позволяет процессору с внеочередным выполнением (out-of-order execution) перемешивать потоки, заполняя простои. Это дало прирост до 1,049 МБ/с только на этапе предтокенизации.
2. Кэширование предтокенов
Второй столп производительности — кэширование. Если слово уже встречалось, его токены берутся из кэша, а не вычисляются заново. Однако Марсель честно признает, что реализовать это сложно: распределение слов в тексте имеет «длинный хвост», и кэш быстро разрастается. Тем не менее, минимизация взаимодействия между потоками и Python-обертками позволила сделать кэширование эффективным. Важно отметить, что WordPiece токенизаторы не поддерживаются, а SentencePiece оптимизированы частично.
04Методология тестирования и независимая проверка
Критики могут возразить, что сравнение не является абсолютно честным (apples-to-apples). Gigatoken кодирует целые неразбитые файлы, самостоятельно находя границы документов и параллелизуя процесс. В то же время HuggingFace (encode_batch_fast) тестировался на первых 100 МБ, а tiktoken (encode_ordinary_batch) — на первых 1 ГБ, причем данные были предварительно разбиты. Кроме того, базовые библиотеки не использовали кэширование в этих тестах, что держало их показатели стабильно низкими.
Тем не менее, результаты выдерживают проверку. Независимая репродукция на платформе KrabArena на виртуальной машине с 4 ядрами Intel Xeon (2.20 ГГц) и срезом OpenWebText объемом 174 МБ показала медианную скорость Gigatoken 0.9.0 в 277.8 МБ/с. Это в 26.2 раза быстрее tiktoken 0.13.0 (10.62 МБ/с) и в 83.4 раза быстрее tokenizers 0.23.1 (3.33 МБ/с). Все 35,356 документов были успешно валидированы, подтверждая, что тренд масштабируется с количеством ядер.
Также стоит отметить ограничения. Токенизаторы на базе SentencePiece (например, Gemma, CodeLlama) показывают прирост в 7–22 раза, что все еще очень хорошо, но на порядок ниже, чем у BPE-токенизаторов. Это связано с тем, что оптимизации Gigatoken в первую очередь нацелены на структуру BPE.
05Поддержка разнообразных семейств токенизаторов
Gigatoken не ограничивается одним алгоритмом. В опубликованных бенчмарках поддерживается 23 различных семейства токенизаторов. Это включает в себя:
- GPT-2 и GPT-OSS
- Llama 3 и Llama 4
- Qwen 2, 3 и 3.6
- DeepSeek V3, R1 и V4
- GLM 4 и 5
- Kimi K2
- Nemotron 3
- Phi-4
- OLMo 2 и 3
- ModernBERT
- Gemma (1 и 3)
- Mistral
Такая универсальность делает Gigatoken привлекательным выбором для разработчиков, работающих с мультиязычными моделями или различными архитектурами. Скорость остается высокой независимо от конкретного словаря, что устраняет необходимость поиска обходных путей для каждой новой модели.
06Что это значит на практике
Для кого-то цифры в 24 ГБ/с могут показаться абстрактными. Но для инженеров по машинному обучению, работающих с предобработкой данных, это меняет правила игры. Представьте, что вам нужно подготовить датасет для обучения LLM. Раньше этот процесс мог занимать дни, требуя кластеров серверов для распараллеливания. С Gigatoken тот же объем данных можно обработать на одной машине за считанные минуты.
Это снижает инфраструктурные затраты. Вам не нужно арендовать дорогие GPU или CPU-кластеры только для этапа токенизации. Вы можете запустить локально на мощном ноутбуке (как M4 Max) или на стандартном сервере и получить результат, который раньше требовал промышленного оборудования. Кроме того, быстрая токенизация ускоряет цикл обратной связи при исследовании моделей. Вы можете быстрее проверять гипотезы, быстрее загружать данные в память и быстрее запускать эксперименты.
Также стоит отметить, что Gigatoken написан на Rust, что обеспечивает безопасность памяти и высокую производительность. Интеграция с Python через PyPI делает его доступным для широкого круга разработчиков, использующих экосистему Python для AI. Если вы работаете с большими объемами текста, Gigatoken — это инструмент, который стоит добавить в свой стек. Он не просто быстрее, он переосмысливает то, как мы подходим к фундаментальным операциям обработки языка.
Вы можете найти репозиторий на GitHub и ознакомиться с подробными логами оптимизации. Весь кредит за это исследование принадлежит Марселю Рёду, чья работа демонстрирует, что даже в зрелых областях, таких как токенизация, есть место для революционных улучшений.
Источник: MarkTechPost ↗