Как специализация словаря SLM может сократить стоимость инференса на 77% в реальных приложениях
Модели, специализированные под конкретную область или задачу с помощью дообучения общих моделей с открытым исходным кодом, таких как Qwen и Gemma, наследуют словарь, созданный для множества областей и общих приложений.
В проверяющей эссе системе, которую мы используем в продакшене, этот словарь разбивал текст, чаще всего создаваемый моделью, на множество токенов. В этой статье представлены некоторые результаты из работы VocabX, которую мы вскоре опубликуем: как мы специализировали словарь с учетом стоимости каждого токена, а не его частотности, и снизили измеренную стоимость инференса на 77%, не изменяя базовую модель.
Токенизатор обычно считается фиксированным свойством базовой модели, унаследованным и не подлежащим изменениям. Для модели, специализированной в одной области, он может быть одним из крупнейших рычагов снижения затрат, причем задается еще до начала обучения.
Одна из систем, которую мы используем в продакшене, — автоматическая проверка эссе на португальском языке, созданная на базе Qwen3-4B. Она получает эссе, задание и вспомогательные тексты, а возвращает оценку в формате JSON с баллом и комментарием для каждой компетенции.
Модель уже была небольшой — 4 миллиарда параметров — и уже обученной для этой задачи. Однако ее токенизатор оставался исходным токенизатором Qwen3-4B, созданным для множества языков и типов текста. В проверяющей системе он использовался для одного языка — португальского — и одного формата ответа. Это создавало две проблемы: текст, который система генерировала при каждом запросе, занимал больше токенов, чем было необходимо, а при генерации каждого токена модель оценивала словарь из 151 669 элементов, включая множество тех, которые в этой задаче почти никогда не используются.
Мы перестроили этот словарь с помощью метода, который назвали VocabX, сохранив ту же базовую модель, те же данные и тот же рецепт обучения. Цифры в этой статье взяты из текущей версии работы, которая все еще проходит рецензирование, и могут измениться до публикации.
Словарь, созданный для всех
Ведущие языковые модели читают и записывают текст в виде токенов, а токенизатор определяет, как текст превращается в токены. Токенизаторы ведущих моделей общего назначения обучаются на больших наборах текстов из множества областей и языков — от исходного кода до контрактов и китайского языка. Для модели общего назначения такой выбор имеет смысл.
Для модели, используемой в одной области, он одновременно создает два вида потерь.
Первая — фрагментация. Токенизатор разбивает на множество частей именно то, что чаще всего повторяется в данной области. В проверяющей системе каждый ответ начинается с одной и той же оболочки JSON, содержит одни и те же названия компетенций и одни и те же формулировки оценки. В контрактах это стандартные положения. В коде — идентификаторы. Каждая из этих последовательностей занимает несколько токенов вместо одного, а модель платит за каждый из них при каждом запросе.
Вторая — избыточность. Словарь содержит десятки тысяч элементов, которые в данной области никогда не используются, а модель вычисляет оценку для каждого из них при каждом генерируемом токене. Модель, настроенная на проверку школьных экзаменов по биологии в США, почти никогда не будет писать по-китайски, однако на каждом шаге вычисляет вероятность каждого токена китайского языка. Словарь разбивает на множество частей то, что чаще всего повторяется в данной области, и содержит элементы, которые в ней никогда не используются.
Чтение дешево, запись дорога
Естественная реакция — посчитать токены и попытаться уменьшить их количество. Но количество — это не счет.
Чтобы понять, почему сгенерированный токен стоит дороже, полезно взглянуть на устройство инференса. Он состоит из двух фаз. На этапе prefill модель обрабатывает весь вход за один проход через сеть: каждое считанное из памяти GPU значение веса повторно используется для каждого входного токена, и ограничением становится вычислительная мощность. На этапе decode модель генерирует ответ по одному токену, и для каждого токена требуется полный проход. Каждое чтение веса используется лишь несколько раз, а GPU большую часть времени ожидает поступления данных из памяти: ограничением становится пропускная способность памяти.
Этот эффект наиболее выражен именно в условиях, в которых работаем мы: небольшие модели, обслуживаемые с умеренными размерами пакетов. Объединение запросов в пакеты распределяет чтение весов между ними и облегчает проблему, но не решает ее. На каждом шаге декодирования модель также читает KV-кэш — память механизма внимания, содержащую уже обработанный контекст и растущую вместе с ним. В измеренном нами случае, в проверяющей системе, сгенерированный токен стоил в 7,4 раза дороже прочитанного токена, однако соотношение зависит от оборудования, задачи, размера пакета, длины контекста и других факторов и может быть еще выше. В целом направление остается неизменным: генерация стоит дороже чтения.
Представьте транспортную компанию, которая взимает плату за каждую коробку, но исходящие коробки стоят в семь раз дороже входящих. Сокращение общего числа коробок помогает. Сокращение числа исходящих коробок помогает в семь раз сильнее. Метод, который одинаково сжимает вход и выход, упускает большую часть возможной экономии.
Третий компонент счета — сам словарь. Последний слой модели, LM head, превращает внутреннее состояние в оценку для каждого возможного токена. Для этого он хранит по одной строке параметров для каждого элемента словаря. В модели размером с Qwen3-4B эта матрица содержит почти 10% параметров. Крупные модели поглощают такую долю незаметно, но для небольшой модели она ощутима.
И затраты возникают не один раз. Входной слой обращается только к строке токена, который считывается, а LM head читает и перемножает всю матрицу для каждого сгенерированного токена. Поскольку декодирование и так ограничено пропускной способностью памяти, каждая дополнительная строка означает больше данных для перемещения на каждом шаге. Элемент, который область никогда не использует, стоит ровно столько же, сколько часто используемый. Поэтому добавление токенов может одновременно уменьшить их количество и увеличить счет. VocabX не включает этот фактор в критерий отбора, но контролирует размер словаря в два этапа: слияние субтокенов заменяет базовый словарь меньшим словарем для конкретной области, а макросы добавляются в рамках фиксированного бюджета. В проверяющей системе выходной слой уменьшился примерно со 152 000 до примерно 65 000 строк.
Почему существующие решения оказались недостаточными
Адаптация словаря модели — не новая идея. Эталонные методы из литературы, такие как fast vocabulary transfer (FVT), multi-word tokenization (MWT) и in-place tokenizer expansion (in-place BPE) от Liquid AI, продолжающий обучение BPE на основе исходного словаря, уже уменьшают фрагментацию. Когда мы протестировали их на нашей задаче, мы обнаружили два ограничения.
Они выбирают токены по частотности, а не по стоимости. Выражение, которое часто встречается во входных данных, для них ценнее выражения, которое реже встречается в ответе, даже если второе дороже в обслуживании.
Они работают только на одном уровне. Они либо корректируют разбиение слов на части, либо объединяют целые фразы в один токен. Ни один из этих трех методов не делает и то и другое по одному критерию. А наибольшая потеря в проверяющей системе была именно в длинных повторяющихся фрагментах, таких как оболочка JSON, до которой субтокенный метод добирается только после последовательного слияния каждой части.
Как мы решили эту задачу
VocabX устраняет оба ограничения, а также третью проблему, возникающую на очевидном пути решения первой.
Во-первых, мы изменили сам вопрос. Вместо того чтобы спрашивать, сколько токенов экономит кандидат, мы спрашиваем, сколько затрат и времени он экономит. Каждый устраненный токен умножается на стоимость поля, в котором он встречается: системного промпта, сообщения пользователя или ответа модели. В измеренном нами случае, в проверяющей системе, сэкономленный в ответе токен в 7,4 раза ценнее сэкономленного во входных данных, и словарь строится соответствующим образом.
Во-вторых, мы работаем сразу на обоих уровнях. Вернемся к транспортной компании: можно сократить число коробок, лучше упаковывая каждый предмет, или признать, что один и тот же набор из двенадцати предметов отправляется каждую неделю, и отправлять весь набор в одной коробке. VocabX делает и то и другое. На уровне субтокенов он перестраивает разбиение слов конкретной области. На уровне нескольких слов он ищет целые повторяющиеся фрагменты — от коротких выражений до полных строк и оболочек JSON — и превращает каждый в один токен, который мы называем макротокеном. Оба уровня выбираются по одному критерию стоимости, каждый со своим бюджетом.
Для поиска этих фрагментов мы используем пять майнеров — автоматических средств поиска фрагментов, повторяющихся в корпусе, — каждый из которых специализируется на одном виде повторения: длинных словах, целых строках, выражениях, законченных предложениях и структурах со знаками пунктуации, таких как JSON и теги. В среднем по восьми корпусам наибольший вклад внес последний, а в коде только он обеспечил 17,5 процентного пункта. Без всех пяти средств сокращение числа токенов в проверяющей системе уменьшилось бы на 55,6 процентного пункта.
В-третьих, мы оцениваем то, чего не может увидеть выборка. Выбор токенов по стоимости требует знать, сколько каждый кандидат продолжает экономить после уже выбранных токенов. Точный подсчет потребовал бы повторной обработки всего корпуса после каждого выбора — десятки тысяч раз. Распространенный способ масштабировать этот процесс — измерять показатели на выборке документов, после чего кандидат, отсутствующий в выборке, получает нулевой прирост.
Выражение, встречающееся 37 раз в 50 000 документов, появляется в выборке из 400 документов лишь примерно в 26% случаев. В корпусе контрактов в выборке из 400 документов встречается только 16,6% кандидатов; остальные никогда не оцениваются.
Прирост кандидата состоит из двух частей. Одна — это то, сколько он экономит во всем корпусе; это можно подсчитать точно, без выборки. Другая — то, какая часть этой экономии еще не покрыта уже выбранными токенами; оценивать нужно только ее. Для кандидатов, которых выборка не видит, мы используем статистическую оценку, основанную на поведении тех, кого она видит, вместо нулевого значения. Кандидат, редкий в выборке, но частый в корпусе, снова получает шанс.
Одно это изменение — при той же выборке и том же бюджете — повысило сокращение числа токенов в корпусе контрактов с 44,7% до 52,8%.
Что изменилось в проверяющей системе
Чтобы измерить реальный эффект, мы обучили семь версий проверяющей системы с одной и той же базовой моделью, данными, рецептом и seed. Единственное различие между ними — токенизатор. Все версии обработали одни и те же 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% для объединенной версии.
Этот вывод применим не только к проверяющей системе. Сжатие имеет цену, если сжимаемый фрагмент содержит решение, ради которого существует сама модель. Цель — не самый дешевый возможный словарь, а самый дешевый словарь, сохраняющий важные токены.
За пределами проверяющей системы
Чтобы выяснить, было ли преимущество специфичным для нашего случая, мы сравнили 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 не делает модель умнее. Он заставляет модель перестать платить за текст, который ей не нужно писать по частям, и перестать оценивать словарь, которым она никогда не воспользуется. В нашей проверяющей системе это снизило измеренную стоимость инференса на 77% при той же базовой модели и том же рецепте обучения.
Специализация обычно начинается с данных и весов. Но она может начаться на один уровень раньше — со словаря.
Полное описание метода, таблицы всех экспериментов и отброшенные варианты будут представлены в работе VocabX, которую мы вскоре опубликуем.
Источники
- Dharma-AI. "VocabX: Cost-Weighted Vocabulary Adaptation for Domain-Specific Language Models." В подготовке (2026).
- Gee, Leonidas, et al. "Fast vocabulary transfer for language model compression." EMNLP Industry Track (2022).
- Gee, Leonidas, et al. "Multi-word tokenization for sequence compression." EMNLP Industry Track (2023).
- Smith, Jimmy T.H., et al. "In-Place Tokenizer Expansion for Pre-trained LLMs." arXiv:2607.15232 (2026).
Дополнительные материалы
- Тот же кластер, загрузка выше на 33 пункта: изменился порядок
- Управление GPU: почему простаивающие GPU — это новые самолеты на земле
- Почему специализация неизбежна
- Специализация важнее масштаба: стратегическая переменная, которую упускает большинство решений о закупке ИИ
- Деградация текста: сбой в продакшене, который не отслеживает большинство бенчмарков
Изучите Dharma AI на Hugging Face, чтобы попробовать наши демонстрации, скачать наши открытые модели и увидеть, как специализированные системы ИИ превосходят модели общего назначения в реальных корпоративных приложениях.
Сообщество
· Зарегистрируйтесь или войдите, чтобы оставить комментарий
Переведено автоматически с английского. Оригинал статьи — по ссылке ниже.











