Як спеціалізація словника SLM може скоротити вартість інференсу на 77% у реальних застосунках

Назад до статей

Як спеціалізація словника SLM може скоротити вартість інференсу на 77% у реальних застосуваннях

Команда Стаття

Опубліковано 21 жовтня 2026

Підтримати

Bernardo França de Aguiar

bernardoaguiar

Dharma-AI

Аватар Габріеля Піменти де Фрейтаса Кардозу

Gabriel Pimenta de Freitas Cardoso

Francisco de Almeida Rocha Alves

falves9101

Dharma-AI

Моделі, спеціалізовані під певну галузь або завдання шляхом донавчання загальних моделей із відкритим кодом, таких як 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 рядків.

Чому наявні рішення не спрацювали повною мірою

Адаптація словника моделі — не нова ідея. Еталонні методи в літературі, як-от швидке перенесення словника (FVT), багатослівна токенізація (MWT) і розширення токенізатора на місці Liquid AI (in-place BPE), яке продовжує навчання BPE на основі оригінального словника, уже зменшують фрагментацію. Коли ми протестували їх на нашій задачі, то виявили два обмеження.

Вони обирають токени за частотністю, а не за вартістю. Вираз, який часто трапляється у вхідних даних, для них цінніший за вираз, що рідше з’являється у відповіді, навіть якщо другий дорожчий в обслуговуванні.

Вони працюють лише на одному рівні. Вони або змінюють спосіб розбиття слів на частини, або об’єднують цілі фрази в один токен. Жоден із цих трьох методів не робить обох речей за одним критерієм. А найбільші втрати в оцінювачі припадали саме на довгі повторювані фрагменти, такі як JSON-каркас, до якого метод на рівні субслів доходить лише після послідовного об’єднання кожної його частини.

Як ми розв’язали цю проблему

VocabX усуває обидва обмеження, а також третю проблему, яка виникає на очевидному шляху до розв’язання першої.

По-перше, ми змінили запитання. Замість того щоб питати, скільки токенів заощаджує кандидат, ми питаємо, скільки вартості й часу він заощаджує. Кожен усунутий токен множиться на ціну поля, у якому він з’являється: системного промпту, повідомлення користувача або відповіді моделі. У виміряному нами випадку — в оцінювачі — токен, заощаджений у відповіді, у 7,4 раза цінніший за токен, заощаджений у вхідних даних, і словник будується відповідно.

По-друге, ми працюємо на обох рівнях одночасно. Повернімося до транспортної компанії: можна скоротити кількість коробок, краще упаковуючи кожен предмет, або помітивши, що один і той самий набір із дванадцяти предметів відправляється щотижня, і надсилаючи цей набір в одній коробці. VocabX робить і те, і те. На рівні субслів він перебудовує спосіб поділу слів галузі на частини. На рівні кількох слів він шукає цілі фрагменти, що повторюються, від коротких виразів до повних рядків і JSON-каркасів, і перетворює кожен на один токен, який ми називаємо макротокеном. Обидва рівні обираються за одним критерієм вартості, кожен зі своїм бюджетом.

Щоб знаходити такі фрагменти, ми використовуємо п’ять майнерів — автоматизованих засобів пошуку фрагментів, які повторюються в корпусі; кожен спеціалізується на одному типі повторення: довгих словах, цілих рядках, виразах, завершених реченнях і структурах із пунктуацією, таких як JSON і теги. У середньому для восьми корпусів найбільший внесок зробив останній, а в коді лише на нього припало 17,5 пункту. Без усіх п’яти скорочення кількості токенів в оцінювачі зменшилося б на 55,6 пункту.

По-третє, ми оцінюємо те, чого не бачить вибірка. Вибір токенів за вартістю потребує знати, скільки кожен кандидат усе ще заощаджує після вже обраних токенів. Точне вимірювання вимагало б повторно обробляти весь корпус після кожного вибору — десятки тисяч разів. Поширений спосіб масштабування цього процесу — вимірювання на вибірці документів, після чого кандидат, відсутній у вибірці, отримує нульовий виграш.

Вираз, який трапляється 37 разів у 50 000 документах, з’являється у вибірці з 400 документів лише приблизно у 26% випадків. У корпусі контрактів лише 16,6% кандидатів з’являються у вибірці з 400 документів; решта ніколи не оцінюються.

Виграш кандидата має дві складові. Одна — це обсяг економії в усьому корпусі, і його можна порахувати точно, без вибірки. Інша — частина цієї економії, яка ще не покрита вже обраними токенами, і лише її потрібно оцінювати. Для кандидатів, яких вибірка не бачить, ми використовуємо статистичну оцінку на основі поведінки кандидатів, яких вона бачить, замість нульового значення. Кандидат, рідкісний у вибірці, але частий у корпусі, знову отримує шанс.

Лише ця зміна — за тієї самої вибірки й того самого бюджету — підвищила скорочення кількості токенів у корпусі контрактів із 44,7% до 52,8%.

Що змінилося в оцінювачі

Щоб виміряти реальний ефект, ми навчили сім версій оцінювача з тією самою базовою моделлю, тими самими даними, тим самим процесом і тим самим початковим значенням. Єдина відмінність між ними — токенізатор. Усі вони виконали ті самі 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 та ін. «Fast vocabulary transfer for language model compression». Галузевий трек EMNLP (2022).
Gee, Leonidas та ін. «Multi-word tokenization for sequence compression». Галузевий трек EMNLP (2023).
Smith, Jimmy T.H. та ін. «In-Place Tokenizer Expansion for Pre-trained LLMs». arXiv:2607.15232 (2026).

Додаткове читання

Відвідайте Dharma AI на Hugging Face, щоб випробувати наші демо, завантажити наші відкриті моделі та побачити, як спеціалізовані системи ШІ перевершують моделі загального призначення в реальних корпоративних застосуваннях.

Більше від цього автора