В индустрии больших языковых моделей (LLM) существует негласное правило: токенизатор — это данность. Когда мы берем открытую модель, такую как Qwen или Gemma, мы наследуем ее словарь, построенный для универсальных задач, и оставляем его нетронутым. Однако для узкоспециализированных систем, работающих в продакшене, этот подход может быть крайне расточительным. Команда Dharma-AI представила метод VocabX, который демонстрирует, что специализация словаря вокруг стоимости каждого токена, а не только его частотности, позволяет сократить измеренные затраты на инференс на 77% без изменения базовой модели или данных обучения.
Эта статья глубоко погружается в технические детали того, как работает токенизация, почему стандартные методы оптимизации неэффективны для узких доменов, и как VocabX решает эти проблемы, объединяя субсловную и многословную токенизацию под единым критерием стоимости. Мы рассмотрим реальный кейс с автоматизированным оценщиком эссе на португальском языке, где этот метод показал выдающиеся результаты, а также проанализируем его эффективность на различных доменах и семействах моделей.
01Проблема универсального токенизатора: фрагментация и избыточность
Токенизатор — это первый и часто игнорируемый этап конвейера обработки текста. Он решает, как именно текст превращается в последовательность токенов, которые понимает модель. Токенизаторы ведущих универсальных языковых моделей обучаются на огромных корпусах текстов из множества доменов и языков: от исходного кода до юридических контрактов и китайских текстов. Для модели, предназначенной для широкого круга задач, такой выбор логичен и необходим.
Однако, когда модель адаптируется под один конкретный домен, универсальный словарь становится источником двух видов потерь. Первая проблема — это фрагментация. Токенизатор разбивает на множество частей именно те конструкции, которые в данном домене повторяются чаще всего. В нашем кейсе с оценщиком эссе каждый ответ начинается с одного и того же JSON-контейнера, одних и тех же имен компетенций и стандартных фраз оценки. В юридических контрактах это шаблонные пункты, а в коде — идентификаторы. Каждая из этих последовательностей стоит несколько токенов, тогда как один специализированный токен мог бы их заменить. Модель платит за каждый из этих лишних токенов при каждом запросе.
Вторая проблема — это избыточность. Словарь содержит десятки тысяч записей, которые домен никогда не использует. Модель, настроенная на оценку экзаменов по биологии в американских школах, почти никогда не пишет на китайском языке, однако на каждом шаге генерации она вычисляет вероятность каждого китайского токена. Словарь разбивает на части то, что домен повторяет, и содержит записи, которые домен игнорирует. Это создает двойную нагрузку: на этапе чтения (prefill) и, что более критично, на этапе генерации (decode).
02Чтение дешево, запись дорого: архитектура инференса
Естественной реакцией разработчиков является попытка просто сократить количество токенов. Но количество токенов — это не счет. Чтобы понять, почему сгенерированный токен стоит дороже, нужно взглянуть на то, как работает инференс. Он состоит из двух фаз.
В фазе prefill (предварительная обработка) модель обрабатывает весь входной текст за один проход через сеть. Каждое чтение веса из памяти GPU повторно используется для каждого входного токена, и здесь лимитом является вычислительная мощность (compute). В фазе decode (генерация) модель создает ответ по одному токену за раз. Каждый токен требует полного прохода, и каждое чтение веса используется лишь несколько раз. GPU проводит большую часть времени, ожидая поступления данных из памяти: лимитом становится пропускная способность памяти (memory bandwidth).
Этот эффект наиболее выражен именно там, где мы работаем: с небольшими моделями, обслуживаемыми с умеренными батчами. Батчинг запросов распределяет чтение весов между ними и смягчает проблему, но не решает ее полностью. На каждом шаге decode модель также читает KV-кэш — память внимания, которая хранит уже обработанный контекст и растет вместе с ним. В нашем измеренном кейсе с оценщиком эссе сгенерированный токен стоит в 7,4 раза дороже, чем прочитанный токен. Хотя это соотношение варьируется в зависимости от оборудования, размера батча, длины контекста и других факторов, направление всегда одно: генерация стоит дороже чтения.
Представьте компанию по доставке, которая взимает плату за коробку, но взимает в семь раз больше за исходящие коробки, чем за входящие. Сокращение общего количества коробок помогает. Сокращение исходящих коробок помогает в семь раз больше. Метод, который сжимает вход и выход одинаково, упускает большую часть возможных сбережений.
03Третья компонента счета: стоимость самого словаря
Третья компонента счета — это сам словарь. Последний слой модели, LM head (голова языка), преобразует внутреннее состояние в оценку для каждого возможного токена. Для этого она хранит одну строку параметров для каждой записи в словаре. В модели размером с Qwen3-4B эта матрица составляет почти 10% от всех параметров. Это доля, которую большие модели поглощают незаметно, но она сильно бьет по маленькой модели.
И эта плата взимается не только один раз. Входной слой ищет только строку читаемого токена, но LM head читает и умножает всю матрицу для каждого сгенерированного токена. Поскольку decode уже ограничен пропускной способностью памяти, каждая дополнительная строка — это больше данных для перемещения на каждом шаге. Запись, которую домен никогда не использует, стоит ровно столько же, сколько и часто используемая. Вот почему добавление токенов может снизить количество токенов, но одновременно увеличить счет. VocabX не включает этот член в свой критерий выбора, но контролирует размер словаря в два этапа: слияние подслов заменяет базовый словарь меньшим, специфичным для домена, а макросы добавляются в рамках фиксированного бюджета. В оценщике выходной слой уменьшился примерно с 152 000 до 65 000 строк.
04Почему существующие решения не сработали
Адаптация словаря модели — не новая идея. Известные методы в литературе, такие как быстрая передача словаря (FVT), многословная токенизация (MWT) и расширение токенизатора на месте (in-place BPE) от Liquid AI, уже снижают фрагментацию. Однако при тестировании этих методов на нашей задаче мы обнаружили два серьезных ограничения.
Во-первых, они выбирают токены по частотности, а не по стоимости. Выражение, которое часто встречается во входных данных, ценнее для них, чем выражение, которое реже встречается в ответе, даже если второе дороже в обслуживании. Во-вторых, они работают на одном слое. Они либо настраивают, как слова разбиваются на части, либо объединяют целые фразы в один токен. Ни один из этих трех методов не делает и того, и другого под одним критерием. А главная потеря в оценщике эссе была именно в длинных, повторяющихся фрагментах, таких как JSON-контейнер, который метод подслов достигает только путем последовательного слияния каждой части.
05Как мы решили проблему: метод VocabX
VocabX устраняет оба этих ограничения, а также третью проблему, возникающую на очевидном пути решения первой. Метод состоит из трех ключевых инноваций.
1. Изменение вопроса: от количества к стоимости. Вместо того чтобы спрашивать, сколько токенов экономит кандидат, мы спрашиваем, сколько стоимости и времени он экономит. Каждый устраненный токен умножается на цену поля, в котором он появляется: системный промпт, сообщение пользователя или ответ модели. В нашем измеренном кейсе токен, сохраненный в ответе, стоит в 7,4 раза больше, чем токен, сохраненный во входе, и словарь строится соответственно.
2. Работа на обоих слоях одновременно. Возвращаясь к аналогии с компанией по доставке: вы можете сократить количество коробок, упаковывая каждый предмет лучше, или recognizing, что один и тот же комплект из двенадцати предметов отправляется каждую неделю, и отправлять его в одной коробке. VocabX делает и то, и другое. На уровне подслов он перестраивает, как слова домена разбиваются на части. На уровне многословий он ищет целые фрагменты, которые повторяются, от коротких выражений до полных строк и JSON-контейнеров, и превращает каждый из них в один токен, который мы называем макрословом (macro token). Оба уровня выбираются под одним критерием стоимости, каждый со своим бюджетом.
Для поиска этих фрагментов мы используем пять «майнеров» — автоматических поисков повторяющихся фрагментов в корпусе, каждый из которых специализируется на одном виде повторений: длинные слова, целые строки, выражения, полные предложения и структуры с пунктуацией, такие как JSON и теги. В среднем по восьми корпусам последний тип структур внес наибольший вклад, а в коде он один обеспечил 17,5 пунктов снижения. Без всех пяти майнеров снижение количества токенов в оценщике упало бы на 55,6 пунктов.
3. Оценка того, что выборка не видит. Выбор токенов по стоимости требует знания того, сколько еще сэкономит каждый кандидат после выбора уже выбранных. Точное измерение этого потребовало бы повторной обработки всего корпуса после каждого выбора, десятки тысяч раз. Обычный способ сделать это в масштабе — измерять на выборке документов, но тогда кандидат, отсутствующий в выборке, получает нулевую выгоду.
Выражение, которое встречается 37 раз в 50 000 документов, появляется в выборке из 400 документов только в 26% случаев. В корпусе контрактов только 16,6% кандидатов появляются в выборке из 400 документов; остальные никогда не оцениваются. Выгода кандидата состоит из двух частей. Одна — это то, сколько он экономит по всему корпусу, и это можно посчитать точно, без выборки. Другая — это то, сколько из этой экономии еще не покрыто выбранными токенами, и только эту часть нужно оценить. Для кандидатов, которых выборка не видит, мы используем статистическую оценку, основанную на поведении тех, которые она видит, вместо нуля. Кандидат, который редок в выборке, но част в корпусе, возвращается в игру. Это изменение само по себе, при той же выборке и том же бюджете, повысило снижение токенов в корпусе контрактов с 44,7% до 52,8%.
06Результаты на практике: Оценщик эссе
Чтобы измерить реальный эффект, мы обучили семь версий оценщика с той же базовой моделью, теми же данными, тем же рецептом обучения и тем же сидом. Единственное различие между ними было в токенизаторе. Все они выполняли одни и те же 500 запросов на одной тестовой машине с GPU RTX 5090 и сервером инференса vLLM, а затраты рассчитывались на основе измеренного времени выполнения.
Ответ модели сократился в среднем с 350 до 101 токена. Затраты снизились на 77,0%. Качество, измеренное по баллу бенчмарка, который сочетает точность оценки и точность отсечения нерелевантных или нарушающих правила эссе, выросло с 0,703 до 0,810.
Получение этих результатов потребовало корректировки курса. Первая версия словаря объединяла оценку каждой компетенции с окружающим JSON в один макрослов. Это был самый компактный вариант, но качество упало: его балл бенчмарка составил 0,689, что ниже, чем у продакшн-версии оценщика (0,703). Поскольку оценка находилась внутри макроса, каждая комбинация оценки и структуры становилась разным вариантом одного и того же токена, и модель выбирала их оба за один шаг. Предоставление оценке собственного токена стоило всего 2 дополнительных токена на ответ, но повысило балл бенчмарка до 0,810 и, в измерении, оказалось даже дешевле: снижение на 77,0% против 73,3% для объединенной версии.
Урок применим за пределами оценщика. Сжатие имеет цену, когда сжатый фрагмент несет само решение, для которого существует модель. Цель — не самый дешевый возможный словарь, а самый дешевый, который сохраняет токены, имеющие значение.
07Обобщение: VocabX против референсных методов
Чтобы узнать, было ли преимущество специфичным для нашего случая, мы сравнили VocabX с тремя референсными методами на пяти публичных доменах (контракты, медицинские статьи, научные статьи, новости и код Python) и трех семействах моделей (Qwen3, Llama-3.1 и Gemma-3). Все методы использовали одни и те же документы для майнинга и тестирования, а также один и тот же потолок размера словаря.
VocabX сжал больше, чем самый сильный референсный метод, во всех пятнадцати комбинациях, на 1,2–9,3 пункта. В оценочных затратах на инференс обрезанная версия VocabX также лидировала во всех пятнадцати случаях, со средними отрывами в 10,2 пункта на Qwen3, 7,5 на Llama-3.1 и 13,6 на Gemma-3. На контрактах обрезанная версия достигла снижения токенов на 62,6% при 113 426 записях в словаре, против 61,8% для лучшей конфигурации in-place BPE, которая использует 207 803 записи. Это демонстрирует, что VocabX не только эффективнее сжимает, но и делает это при значительно меньшем размере словаря, что дополнительно снижает накладные расходы на память.
08Что это значит на практике
Для разработчиков AI-систем, работающих в условиях ограниченных ресурсов или высоких требований к стоимости инференса, VocabX предлагает новый подход к оптимизации. Специализация обычно начинается с данных и весов модели. Но теперь она может начаться на слой раньше — в словаре. Это не делает модель «умнее» в смысле понимания, но она заставляет модель перестать платить за текст, который ей не нужно писать по частям, и перестать оценивать словарь, который она никогда не будет использовать.
Ключевые выводы для внедрения:
- Фокус на output-токенах: Оптимизация словаря должна приоритизировать сокращение токенов в ответе модели, так как их стоимость инференса многократно выше стоимости входных данных.
- Гибридная токенизация: Комбинация субсловной (для редких терминов домена) и многословной (для шаблонных структур, таких как JSON, HTML, код) токенизации дает синергетический эффект, недоступный при использовании только одного метода.
- Баланс сжатия и качества: Чрезмерное сжатие, особенно если оно объединяет критически важные для принятия решения элементы (например, оценку и структуру), может снизить качество модели. Необходимо сохранять отдельные токены для ключевых переменных.
- Доступность для локального запуска: Метод позволяет использовать открытые модели (Qwen, Llama, Gemma) с их родными токенизаторами, адаптируя их под локальные нужды без необходимости переобучения всей модели с нуля, что критично для компаний, запускающих AI в РФ и других регионах с ограничениями на доступ к облачным API.
Полный метод, таблицы для каждого эксперимента и отклоненные вмешательства будут опубликованы в статье VocabX, которая скоро появится. А пока мы рекомендуем протестировать этот подход на ваших узкоспециализированных моделях, особенно если вы работаете с JSON-структурами, кодом или юридическими документами, где шаблонность высока, а стоимость инференса является критическим фактором.
09Заключение
VocabX демонстрирует, что даже незначительные изменения в预处理-этапе (токенизации) могут привести к радикальному улучшению экономических показателей AI-систем. В мире, где масштабирование моделей часто считается единственным путем к улучшению, оптимизация «мелочей» может стать стратегическим преимуществом, позволяющим запускать более сложные задачи на более дешевом оборудовании. Это шаг к более устойчивой и доступной AI-инфраструктуре.
Источник: Hugging Face ↗