SLM вместо LLM: когда бизнесу достаточно маленькой языковой модели

Когда компания начинает внедрять генеративный ИИ, первая мысль часто звучит так: нужно взять самую мощную языковую модель из доступных. Чем больше параметров, тем умнее система — а значит, тем лучше будет результат. На практике эта логика работает далеко не всегда. Если задача состоит в том, чтобы определить тему обращения, извлечь номер договора, найти ответ в корпоративной базе знаний или отправить тикет нужной команде, огромная LLM может оказаться цифровым экскаватором, которым пытаются посадить комнатный цветок. Во многих бизнес-сценариях достаточно SLM — small language model, или малой языковой модели. Она занимает меньше памяти, быстрее отвечает, дешевле работает и проще разворачивается внутри собственной инфраструктуры. Главное — правильно определить границу, за которой компактности уже недостаточно.

Что такое SLM и насколько маленькой она должна быть

Строгой границы между SLM и LLM нет. В профессиональной среде к малым языковым моделям обычно относят относительно компактные модели, рассчитанные на экономичный inference и запуск на ограниченном оборудовании. В некоторых исследованиях в эту категорию включают модели примерно от 1 до 8 млрд параметров, хотя конкретный диапазон всегда зависит от архитектуры, назначения и поколения модели. Само количество параметров тоже не рассказывает всю историю. На качество влияют: данные, использованные при обучении; качество instruction tuning; поддерживаемые языки; архитектура модели; длина контекста; формат квантизации; специализация под конкретную задачу. Поэтому модель на 4 млрд параметров нового поколения иногда справляется с узкой задачей лучше, чем более крупная, но плохо подходящая под домен модель. Хорошая аналогия — сотрудники компании. Универсальный консультант с огромным кругозором полезен при нестандартных вопросах. Но для сортировки входящих документов или проверки обязательных полей эффективнее специалист, который знает конкретный регламент и стабильно выполняет одну операцию. Именно в этом заключается сильная сторона SLM: ей необязательно знать всё. Достаточно хорошо решать задачу, ради которой её внедряют.

Почему большая модель не всегда даёт бизнесу больше пользы

Гигантские LLM впечатляют способностью рассуждать, программировать, анализировать сложные документы и поддерживать свободный диалог. Однако бизнес платит не за размер модели, а за полезный результат. Представим службу поддержки интернет-магазина. Каждый день она получает тысячи сообщений: «Где мой заказ?»; «Хочу изменить адрес доставки»; «Товар пришёл повреждённым»; «Не получается оплатить картой»; «Как вернуть покупку?». Для обработки таких обращений редко требуется сложное многоступенчатое рассуждение. Системе нужно определить категорию, извлечь номер заказа, оценить срочность и выбрать маршрут. Модель со сложными агентными возможностями здесь может повысить расходы, но почти не улучшить итоговую точность. Возникает простой вопрос: зачем оплачивать способности, которые не используются?

SLM особенно хорошо показывает себя там, где

• задача ограничена понятным набором сценариев

• результат можно проверить автоматически

• ответы опираются на конкретные корпоративные данные

• важны скорость и предсказуемость

• запросов много, а стоимость каждого inference имеет значение.

И наоборот, чем шире и неопределённее задача, тем заметнее преимущества большой модели.

Четыре причины присмотреться к SLM

Дешевле inference

Inference — это непосредственная работа уже обученной модели: она получает запрос, обрабатывает его и генерирует результат. Именно inference становится одной из основных постоянных статей расходов после запуска AI-сервиса. Большая модель выполняет больше вычислений на каждом токене. Ей требуется более дорогое оборудование, а под высокой нагрузкой — несколько ускорителей, репликация и сложная система распределения запросов. SLM уменьшает вычислительную нагрузку. Это особенно заметно в системах, которые обрабатывают сотни тысяч однотипных операций: классифицируют обращения; извлекают реквизиты; проверяют документы; создают короткие резюме; отвечают на типовые вопросы; определяют следующий шаг workflow. Разница в несколько копеек или центов на одном запросе кажется несущественной. Но при миллионах запросов она превращается в отдельную строку бюджета. При этом считать нужно не только стоимость GPU. В итоговую экономику входят энергопотребление, резервные мощности, хранение моделей, мониторинг, масштабирование и время инженерной команды.

Меньше требований к VRAM

Параметры модели хранятся в памяти ускорителя. В грубом приближении модель на 3 млрд параметров при использовании 16-битного формата требует около 6 ГБ только для весов. Модель на 7 млрд параметров — около 14 ГБ. Реальное потребление будет выше из-за KV-кеша, контекста, служебных буферов и особенностей inference-движка. Квантизация позволяет хранить веса с меньшей точностью. Например, 8-битная квантизация примерно вдвое сокращает память, занимаемую весами, а 4-битная уменьшает её ещё сильнее. Современные инструменты поддерживают 8- и 4-битные форматы именно для того, чтобы запускать языковые модели на более доступном оборудовании.

Для бизнеса это открывает несколько вариантов

• использовать одну GPU вместо нескольких

• запускать модель на более доступном сервере

• разместить несколько экземпляров модели на одном ускорителе

• обслуживать больше параллельных запросов

• развернуть решение на edge-устройстве или рабочей станции.

Компактность перестала означать примитивность. Например, Microsoft описывала Phi-3-mini как модель на 3,8 млрд параметров, достаточно компактную для локального запуска на мобильном устройстве. Семейства открытых моделей Google также включают компактные варианты, ориентированные на ноутбуки, мобильные и edge-сценарии. Это не означает, что любую SLM можно без подготовки запустить на офисном ноутбуке. Но выбор инфраструктуры становится заметно шире.

Ниже latency

Пользователю неважно, сколько параметров у модели. Он замечает другое: насколько быстро система отвечает.

Latency складывается из нескольких компонентов

• ожидания в очереди

• подготовки промпта

• обработки входного контекста

• генерации первого токена

• генерации остальных токенов

• сетевой задержки

• постобработки результата.

• Размер модели влияет не на каждый компонент одинаково, но компактная модель обычно требует меньше вычислений. При подходящем оборудовании это сокращает время до первого токена и повышает пропускную способность.

Для внутреннего аналитического отчёта разница между двумя и пятью секундами может быть терпимой. Для голосового ассистента, автодополнения, маршрутизации чата или подсказки оператору даже небольшая пауза ломает ощущение живого взаимодействия. Представьте call-центр, где AI должен показать оператору рекомендуемый ответ до того, как клиент закончит объяснять проблему. В таком сценарии быстрая специализированная SLM часто ценнее более умной, но медленной LLM. Низкая latency важна и для цепочек автоматизации. Если один бизнес-процесс последовательно вызывает модель десять раз, каждая дополнительная секунда умножается на количество шагов.

Проще self-hosted-развёртывание

Self-hosted означает, что модель работает в инфраструктуре, которую контролирует сама компания: на выделенном сервере, в частном облаке или внутри защищённого контура.

У такого подхода есть понятные преимущества

• данные не нужно отправлять внешнему AI-провайдеру

• проще контролировать журналирование и сроки хранения информации

• можно изолировать модель от интернета

• легче встроить её во внутреннюю сеть

• расходы на большой нагрузке становятся предсказуемее

• версия модели и конфигурация не меняются без ведома компании.

• Развернуть собственный inference-сервис для огромной модели возможно, но дорого и технически сложно. Потребуются производительные GPU, распределённый inference, балансировка нагрузки и специалисты, понимающие особенности конкретного стека.

С небольшой моделью порог входа ниже. Иногда достаточно одного сервера с GPU, а для лёгких задач — CPU или компактного ускорителя. Проще организовать резервирование, обновления и горизонтальное масштабирование. Конечно, self-hosted не означает «скачали модель и забыли». Всё равно потребуются мониторинг, контроль доступа, обновление зависимостей, тестирование новых версий и защита API. Но сама инфраструктура становится понятнее и дешевле.

Где маленькая языковая модель действительно уместна

Классификация заявок

Один из самых очевидных сценариев — определение категории входящего обращения. Например, система получает сообщение: После продления подписки с карты списали оплату два раза. Модель должна вернуть не красивый текст, а структурированный результат:

{
  "category": "billing",
  "subcategory": "duplicate_charge",
  "priority": "high"
}

Количество категорий ограничено, формат известен заранее, а правильность можно проверить на размеченной выборке. Это почти идеальная задача для SLM. Более того, иногда генеративная модель здесь вообще не нужна. Если классы стабильны, а формулировки хорошо представлены в данных, обычный классификатор или encoder-модель может оказаться ещё быстрее. SLM становится полезной, когда сообщения написаны свободным языком, содержат несколько намерений, отличаются по длине или требуют понимания контекста.

Извлечение данных из документов и сообщений

Вторая сильная область — преобразование неструктурированного текста в понятный машине формат.

Из письма клиента можно извлечь

• название компании

• номер заказа

• сумму

• дату

• продукт

• причину обращения

• желаемое действие.

Из договора — стороны, срок действия, валюту, условия продления и штрафы. Из резюме — опыт, навыки, должность и образование. Здесь важно ограничить свободу модели. Вместо просьбы «проанализируй документ» лучше передать схему ожидаемого JSON, правила заполнения и несколько примеров. Допустим, клиент пишет: Добрый день. По счёту KS-4812 от 14 мая оплатили 890 евро, но сервер пока не активирован. Модель может вернуть:

{
  "invoice_id": "KS-4812",
  "invoice_date": "14 мая",
  "amount": 890,
  "currency": "EUR",
  "issue": "service_not_activated"
}

Для такого результата не требуется энциклопедический кругозор. Нужны аккуратность, соблюдение схемы и устойчивость к разным формулировкам.

FAQ и ответы по базе знаний

Корпоративный FAQ кажется простой задачей, но у него есть ловушка: языковая модель не должна отвечать по памяти там, где важны актуальные правила компании. Рабочая архитектура обычно строится на RAG — retrieval-augmented generation. Сначала система находит подходящие фрагменты в базе знаний, затем передаёт их модели и просит сформировать ответ только на основании найденного контекста.

В такой схеме значительная часть «знаний» хранится не внутри модели, а во внешнем источнике

• пользователь задаёт вопрос

• поисковый компонент находит релевантные документы

• SLM получает вопрос и несколько фрагментов

• модель формирует короткий ответ

• система прикладывает ссылку на источник.

Например, сотрудник спрашивает: «Можно ли перенести неиспользованные дни отпуска на следующий год?» Модели не нужно знать трудовое законодательство всех стран. Ей нужно прочитать внутреннюю политику компании, извлечённую RAG-системой, и понятно пересказать нужный пункт. Если документы короткие, запросы типовые, а ответ должен состоять из нескольких абзацев, малая языковая модель часто справляется достаточно хорошо.

Маршрутизация тикетов

Маршрутизация похожа на классификацию, но обычно учитывает больше факторов

• тему

• продукт

• язык

• регион

• уровень клиента

• критичность

• наличие персональных данных

• предыдущие обращения.

На основании этих признаков система выбирает очередь, специалиста или автоматический сценарий. Допустим, в службу поддержки приходит сообщение о недоступности сервера. Обычный фильтр увидит слово «сервер» и отправит обращение в технический отдел. SLM способна различить несколько ситуаций: сервер не отвечает; пользователь забыл пароль; требуется увеличение ресурсов; вопрос связан со счётом за сервер; клиент хочет заказать дополнительный IP-адрес. Это снижает число ошибочных переадресаций и сокращает время до первого содержательного ответа.

Внутренние ассистенты

Не каждый корпоративный ассистент должен писать стратегические планы и проводить сложные исследования.

Часто от него требуется гораздо более ограниченный набор действий

• найти регламент

• объяснить внутренний термин

• подготовить резюме тикета

• сформировать запрос в систему учёта

• подсказать последовательность действий

• заполнить шаблон

• создать черновик ответа.

Такой ассистент работает внутри конкретной предметной области и получает данные из корпоративных систем. Качество здесь определяется не только размером модели, но и тем, насколько хорошо спроектированы инструменты, поиск, промпты и права доступа. Компактная модель с качественным RAG и строгим набором функций может быть полезнее большой модели, которой просто передали длинный системный промпт.

Где SLM может не хватить

Маленькая языковая модель — не универсальная замена LLM. Экономия имеет смысл только до тех пор, пока система выполняет задачу с приемлемым качеством.

Сложное многоступенчатое рассуждение

Если модель должна сопоставить десятки факторов, построить гипотезы, проверить противоречия и спланировать несколько действий, размер и качество reasoning-компонента становятся важнее стоимости одного запроса. Пример — анализ нестандартного инцидента, в котором нужно изучить логи нескольких сервисов, изменения конфигурации, историю развёртываний и возможные зависимости. SLM может выполнить отдельные операции: классифицировать лог, извлечь ошибку, составить краткое резюме. Но роль ведущего аналитика лучше оставить более сильной модели или человеку.

Свободный диалог на множество тем

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

Работа с очень длинным и сложным контекстом

Заявленная длина контекста не гарантирует, что модель одинаково хорошо использует информацию из любой его части. Если нужно сопоставить несколько больших договоров, изучить репозиторий или проанализировать сотни страниц документации, малая модель может терять связи между фрагментами. Проблему частично решают RAG, иерархическое суммирование и разбиение задачи на этапы. Но иногда использование более крупной модели остаётся самым надёжным вариантом.

Высокая цена ошибки

В медицине, финансах, информационной безопасности и юридических процессах нельзя выбирать модель только по стоимости. SLM может быть частью системы: извлекать данные, проверять формат, находить документы. Однако финальное решение должно проходить дополнительную валидацию, а в критических случаях — контроль специалиста. Важно помнить: более крупная модель тоже ошибается. Размер снижает некоторые риски, но не отменяет необходимости проверок.

SLM, LLM или обычный алгоритм: как выбирать

Начинать стоит не с каталога моделей, а с описания задачи. Фраза «нам нужен AI для поддержки» слишком широка. Гораздо полезнее разложить процесс на отдельные операции: определить язык обращения; классифицировать тему; извлечь номер заказа; найти статью в базе знаний; сформировать ответ; оценить уверенность; передать сложный случай оператору. Для каждого шага может использоваться свой инструмент. Язык определит компактный классификатор. Номер заказа извлечёт регулярное выражение. Документ найдёт векторный поиск. SLM сформирует ответ по найденному контексту. Большая LLM подключится только при сложном или неоднозначном запросе. Это зрелее, чем попытка построить весь процесс вокруг одной гигантской модели.

Сначала определите измеримый результат

До выбора модели нужно понять, что считается успехом. Для классификации это могут быть precision, recall и F1-score. Для извлечения — доля правильно заполненных полей. Для FAQ — корректность ответа, соответствие источнику и процент запросов, переданных оператору. Latency тоже должна быть выражена числом. Например: 95% запросов обрабатываются менее чем за 800 мс; первый токен появляется не позднее чем через 500 мс; система выдерживает 50 параллельных запросов; стоимость тысячи обращений не превышает установленный лимит. Без метрик сравнение быстро превращается в обсуждение субъективных впечатлений: «эта модель отвечает вроде бы умнее».

Соберите тестовый набор из реальных запросов

Публичные benchmark-тесты полезны для предварительного отбора, но они не знают особенностей вашего бизнеса. Модель, показывающая хорошие результаты на математических задачах, необязательно правильно классифицирует обращения клиентов на русском языке. А лидер общего рейтинга может нестабильно соблюдать вашу JSON-схему.

Для проверки нужен собственный набор

• типовые запросы

• редкие случаи

• опечатки

• разговорные формулировки

• смешение языков

• очень короткие сообщения

• неоднозначные обращения

• потенциально опасный ввод.

Начать можно с нескольких сотен примеров. Главное, чтобы они отражали реальный поток, а не идеальные сообщения, придуманные командой разработки.

Сравнивайте систему, а не модель в вакууме

Одна и та же SLM может показать совершенно разные результаты в зависимости от промпта, формата данных и окружающей архитектуры.

Перед окончательным выводом стоит проверить

• few-shot-примеры

• constrained decoding

• JSON Schema

• RAG

• нормализацию входного текста

• повторный запрос при ошибке формата

• валидацию результата

• fine-tuning или LoRA

• разные варианты квантизации.

Иногда переход с модели на 4 млрд параметров к модели на 40 млрд даёт меньший прирост, чем добавление хороших примеров и строгой схемы ответа.

Гибридная схема: SLM для большинства запросов, LLM — для сложных

Выбор между SLM и LLM не обязан быть категоричным.

Для многих проектов оптимальна каскадная архитектура

• SLM получает входящий запрос.

• Определяет намерение, категорию и уровень сложности.

• Выполняет стандартную операцию или готовит ответ по RAG.

• Рассчитывает confidence score либо проходит отдельную проверку.

• Сложные и неоднозначные запросы отправляются большой LLM.

• Критические случаи передаются человеку.

Например, из 100 тысяч обращений за месяц 80 тысяч могут быть типовыми. Их обработает локальная SLM. Ещё 15 тысяч потребуют более сильной модели. Оставшиеся 5 тысяч попадут операторам. В результате компания не оплачивает дорогое рассуждение там, где достаточно простой операции, но и не жертвует качеством в нестандартных случаях. Эту архитектуру можно сравнить с медицинской регистратурой. Большинство пациентов не попадает сразу к профессору узкой специальности. Сначала проводится первичная оценка, после которой выбирается нужный маршрут. Главное — не доверять самой модели окончательное решение о собственной компетентности. Уверенность желательно проверять дополнительными механизмами: отдельным классификатором; правилами; сравнением нескольких ответов; проверкой наличия источников; контролем структуры; порогами для конкретных категорий; выборочной ручной оценкой.

Что учитывать при self-hosted-запуске

Компактная модель упрощает развёртывание, но не отменяет инженерную работу.

Лицензия

Открытые веса не всегда означают отсутствие ограничений. Нужно проверить: разрешено ли коммерческое использование; можно ли модифицировать модель; допустимо ли предоставлять доступ третьим лицам; есть ли требования к атрибуции; существуют ли ограничения для отдельных отраслей. Лицензию следует изучать до того, как модель станет частью продукта.

Поддержка языка и домена

Модель может хорошо работать на английском и заметно хуже — на русском. Или понимать обычный русский текст, но путаться в технических терминах, названиях тарифов и внутренних сокращениях. Проверять нужно именно те языки и форматы, которые встречаются в продакшене.

Квантизация

Квантизация уменьшает потребление памяти, но иногда влияет на качество. Особенно чувствительными могут оказаться задачи, требующие точного извлечения, математических операций или соблюдения сложного формата. Каждый вариант следует тестировать отдельно. Нельзя автоматически считать, что 4-битная версия полностью повторяет поведение исходной модели.

Контекст и KV-кеш

Вес модели — только часть потребления VRAM. При длинных промптах и большом числе параллельных запросов значительный объём занимает KV-кеш. Компактная модель с огромным контекстом под высокой нагрузкой тоже может потребовать серьёзной инфраструктуры. Поэтому capacity planning должен учитывать: среднюю и максимальную длину запроса; длину ответа; количество одновременных пользователей; размер batch; целевую latency; выбранный inference-движок.

Наблюдаемость

В продакшене полезно отслеживать не только загрузку GPU.

Нужны метрики бизнес-качества

• доля правильных маршрутов

• ошибки JSON

• ответы без подтверждённого источника

• частота эскалаций

• повторные обращения

• ручные исправления операторов

• изменение качества после обновления модели.

SLM может работать быстро и дёшево, но стабильно решать не ту задачу. Без наблюдаемости это обнаружится слишком поздно.

Практический чек-лист: подходит ли вам малая языковая модель

SLM стоит тестировать в первую очередь, если на большинство вопросов ниже можно ответить утвердительно

• задача ограничена конкретным бизнес-процессом

• выходной формат заранее известен

• качество можно проверить автоматически

• запросы похожи друг на друга

• система работает с корпоративной базой знаний

• ответ не требует широких знаний о мире

• важна низкая latency

• запросов много

• данные желательно обрабатывать внутри собственного контура

• инфраструктурный бюджет ограничен

• сложные случаи можно передать LLM или человеку.

Большая модель, вероятно, понадобится, если системе регулярно требуется

• разбирать нестандартные ситуации

• вести свободный разговор на разные темы

• выполнять длинные цепочки рассуждений

• работать с множеством неструктурированных источников

• принимать решения при неполных или противоречивых данных

• генерировать сложные тексты с высокой вариативностью

• самостоятельно планировать использование нескольких инструментов.

Но даже в этом случае SLM может взять на себя вспомогательные этапы и уменьшить общую стоимость системы.

Начните с минимальной модели, которая решает задачу

Правильный вопрос звучит не так: «Какая языковая модель сейчас самая мощная?» Гораздо полезнее спросить: «Какая минимальная модель обеспечивает нужное качество при нашей нагрузке, latency и инфраструктуре?»

Такой подход меняет экономику проекта. Вместо демонстрационного AI-сервиса, который впечатляет на презентации, компания получает устойчивую производственную систему

• с понятной стоимостью

• предсказуемым временем ответа

• контролируемой инфраструктурой

• измеримым качеством

• возможностью масштабироваться без резкого роста расходов.

Для классификации заявок, извлечения данных, FAQ, маршрутизации тикетов и внутренних ассистентов small language model часто оказывается не компромиссом, а рациональным инженерным выбором. Большую LLM всегда можно добавить как следующий уровень — для сложных случаев, глубокого анализа и нестандартных запросов. Но начинать разумнее не с максимального размера, а с реальной задачи. Иногда бизнесу нужен универсальный интеллектуальный комбайн. А иногда — компактный, быстрый и надёжный инструмент, который каждый день без лишнего шума выполняет свою работу.