Как специализирането на речника на 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) моделът обработва целия вход с един проход през мрежата: всяка тежест, прочетена от паметта на графичния процесор, се използва повторно за всеки входен токен, а ограничението е изчислителната мощност. При декодиране (decode) моделът генерира отговора токен по токен и всеки токен изисква пълен проход. Всяка прочетена тежест се използва само няколко пъти, а графичният процесор прекарва по-голямата част от времето си в очакване на данни от паметта: ограничението се превръща в пропускателната способност на паметта.

Този ефект е най-силен точно там, където работим: при малки модели, обслужвани с умерени размери на пакетите. Пакетирането на заявките разпределя четенето на тежестите между тях и смекчава проблема, но не го решава. При всяка стъпка на декодиране моделът чете и KV кеша — паметта за вниманието, която съхранява вече обработения контекст и нараства заедно с него. В измерения от нас случай при оценителя генерираният токен струва 7,4 пъти повече от прочетен токен, но съотношението зависи от хардуера, задачата, размера на пакета, дължината на контекста и други фактори и може да бъде още по-голямо. Като цяло посоката е ясна: генерирането струва повече от четенето.

Представете си транспортна компания, която таксува на кашон, но таксува седем пъти повече за изпращаните, отколкото за получаваните кашони. Намаляването на общия брой кашони помага. Намаляването на изпращаните кашони помага седем пъти повече. Метод, който компресира входа и изхода еднакво, пропуска по-голямата част от възможните спестявания.

Третият компонент на сметката е самият речник. Последният слой на модела — LM главата — превръща вътрешното състояние в оценка за всеки възможен токен. За тази цел той съдържа по един ред параметри за всеки елемент от речника. При модел с размерите на Qwen3-4B тази матрица представлява почти 10% от параметрите. Големите модели понасят такъв дял, без да го усетят, но при малък модел той тежи.

А разходът не се плаща само веднъж. Входният слой извлича само реда на токена, който се чете, но LM главата чете и умножава цялата матрица за всеки генериран токен. Тъй като декодирането вече е ограничено от паметта, всеки допълнителен ред означава повече данни за преместване при всяка стъпка. Елемент, който областта никога не използва, струва точно толкова, колкото и често използваният. Затова добавянето на токени може едновременно да намали броя им и да увеличи сметката. VocabX не включва този компонент в критерия си за подбор, но контролира размера на речника на две стъпки: сливането на поддуми заменя базовия речник с по-малък, специфичен за областта речник, а макросите се добавят в рамките на фиксиран бюджет. При оценителя изходният слой намаля от около 152 000 на около 65 000 реда.

Защо съществуващите решения не бяха достатъчни

Адаптирането на речника на даден модел не е нова идея. Референтни методи в научната литература, като fast vocabulary transfer (FVT), multi-word tokenization (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 заявки на една и съща тестова машина с графичен процесор 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).

Допълнително четене

Разгледайте Dharma AI в Hugging Face, за да изпробвате демонстрациите ни, да изтеглите отворените ни модели и да видите как специализираните AI системи превъзхождат моделите с общо предназначение в реални корпоративни приложения.

Още от този автор