Маленькие доменные модели (SLM): почему не один гигант, а узкие модели под задачу

Несколько лет индустрия двигалась в одну сторону: чем больше модель, тем лучше. Появлялись всё более крупные нейросети, которые умеют «всё» — и писать тексты, и считать, и переводить, и рассуждать. Но в 2026 году стало заметно встречное движение: компании всё чаще берут не одного гиганта на все задачи, а несколько маленьких моделей, каждая из которых заточена под свой узкий сценарий. Это и есть тренд на SLM — маленькие доменные модели. Ниже я простыми словами разберу, что это такое, почему гигант нужен не всегда, в чём выгода узких моделей, как это ложится на российский контекст с импортозамещением и 152-ФЗ, и с чего начать внедрение. Без громких обещаний и с честным разговором про ограничения.

Что такое маленькие доменные модели

SLM расшифровывается как Small Language Models — «маленькие языковые модели». Слово «маленькие» здесь условное: речь о моделях, которые на порядки компактнее самых крупных универсальных нейросетей. А «доменные» означает, что модель настроена под конкретную область или задачу — под ваш «домен»: тип документов, отрасль, набор запросов, с которыми реально работает компания.

Идея простая. Вместо одной гигантской модели, которая пытается уметь всё на свете, вы берёте модель поменьше и настраиваете её под один понятный сценарий. После такой настройки на узкой задаче она часто оказывается так же точна или даже точнее, чем универсальный гигант, при этом работает заметно дешевле и быстрее. Гигант — как энциклопедия на все случаи жизни; маленькая доменная модель — как специалист, который знает свою область глубже, чем «человек, знающий обо всём по чуть-чуть».

Тренд ускоряют две вещи. Первая — открытый код: появилось много качественных открытых моделей разного размера, которые можно скачать, дообучить под себя и развернуть на своём сервере без оглядки на чужую подписку. Вторая — агентный ИИ: когда систему собирают из нескольких помощников-агентов, каждый из которых отвечает за свой шаг, удобнее ставить на каждый шаг свою компактную модель, а не гонять одного дорогого гиганта по кругу. В сумме это и даёт сдвиг от «одна модель на всё» к «много узких моделей под задачу».

Почему не один гигант

Логичный вопрос: если есть мощная универсальная модель, которая умеет всё, зачем городить зоопарк из маленьких? Ответ в том, что для большинства реальных бизнес-задач гигант избыточен. Компании редко нужна нейросеть, которая одновременно пишет стихи, решает олимпиадные задачи и ведёт философские беседы. Чаще нужна одна конкретная вещь: разобрать входящие обращения по категориям, вытащить из документа нужные поля, ответить сотруднику по внутренней базе знаний, отсортировать заявки по приоритету.

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

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

Преимущества под задачу

Когда модель подобрана и настроена под конкретный сценарий, преимущества складываются во вполне ощутимую выгоду. Разберу по пунктам.

• Дешевле в эксплуатации. Маленькая модель потребляет меньше ресурсов на каждый запрос. На больших объёмах однотипных задач это разница не в проценты, а в разы — особенно по сравнению с оплатой запросов к дорогому облачному гиганту.
• Быстрее отвечает. Меньше модель — меньше вычислений на ответ. Там, где важна скорость (онлайн-обработка обращений, подсказки в реальном времени), это заметно для пользователя.
• Можно развернуть локально. Компактную модель реально поднять на своём сервере или даже на относительно скромном железе, без обязательного похода во внешний облачный сервис.
• Проще контролировать. Вы знаете, на каких данных модель настроена, как она ведёт себя на ваших запросах, и можете её проверять и дорабатывать под свои требования.
• Меньше требований к железу. Маленькой модели не нужен дата-центр. Часто хватает одного сервера, а для некоторых задач — и без мощной видеокарты.
• Лучше приватность. Когда модель работает на вашем сервере, данные не уходят в чужой облачный ИИ. Запросы и документы остаются внутри вашего контура.

Важно держать ожидания в реальности. Все эти плюсы проявляются именно тогда, когда модель действительно настроена под задачу. «Просто скачать маленькую модель» и ждать чудес не стоит — без настройки она будет слабее гиганта на тех же запросах. Выгода берётся не из размера самого по себе, а из связки «правильный размер плюс настройка под ваш домен». Это смежная тема с локальным LLM и собственным ИИ-ассистентом по базе знаний (подход RAG): часто маленькая доменная модель — это как раз тот компонент, который делает локальное решение быстрым и дешёвым.

Импортозамещение и 152-ФЗ

Для российских компаний у маленьких доменных моделей есть отдельный, очень практичный угол — приватность данных и независимость от внешних сервисов. Это две болевые точки, которые в 2026 году волнуют почти всех.

Начну с приватности и 152-ФЗ. Когда вы работаете с обращениями клиентов, договорами, заявками или внутренними документами, в них почти всегда есть персональные данные. Отправлять такие данные в чужой облачный ИИ — это всегда вопрос: где они хранятся, кто к ним имеет доступ, не уходят ли за пределы страны. Маленькую доменную модель можно держать на своём сервере в России — и тогда данные просто не покидают ваш контур. Это сильно упрощает соблюдение требований 152-ФЗ к обработке персональных данных, потому что нечего «отдавать наружу».

Второй угол — импортозамещение. Локальная маленькая модель не зависит от того, доступен ли вам конкретный зарубежный облачный сервис, не изменились ли его условия, не отключили ли его. Она работает на вашем железе и хорошо ложится на российский AI-стек: отечественный хостинг, локальное развёртывание через инструменты вроде Ollama (это удобный способ запускать открытые модели на своём сервере), при необходимости — связка с российскими сервисами. Вы контролируете всю цепочку.

Теперь честно про ограничения. Локальное размещение само по себе не делает систему «автоматически соответствующей закону» — нужно ещё грамотно организовать доступ, хранение и регламенты, и это решается на этапе внедрения. И главное: настройка модели под ваш домен требует данных и работы. Чтобы маленькая модель хорошо решала вашу задачу, ей нужны ваши примеры — размеченные обращения, образцы документов, типовые запросы. Это не «волшебная кнопка», а проект, в котором качество результата зависит от качества данных. Я говорю об этом сразу, чтобы ожидания были честными.

Как внедрить

Переход на маленькие доменные модели — это понятный маршрут, если идти по шагам, а не пытаться сразу «заменить весь ИИ». Вот логика, по которой я обычно двигаюсь.

• Выбрать узкую задачу. Начинать стоит с одного конкретного и измеримого сценария: классификация входящих обращений, извлечение полей из документов, ответы по внутренней базе знаний, сортировка заявок по приоритету. Чем уже задача, тем выше шанс, что маленькая модель её закроет.
• Подобрать подходящую открытую модель. Под задачу выбирается открытая модель подходящего размера — достаточно сильная, чтобы справиться, но не избыточная. Здесь важен баланс между качеством и требованиями к железу.
• Настроить на своих данных. Модель дообучается или настраивается на ваших примерах: реальных обращениях, документах, запросах. Это ключевой этап — именно он превращает универсальную заготовку в специалиста по вашему домену.
• Развернуть на своём сервере. Модель поднимается локально — на вашем сервере или в вашей инфраструктуре, например через Ollama. Так данные остаются внутри контура, а вы не зависите от внешнего сервиса. Для российского контекста это и есть тот самый локальный, импортонезависимый вариант.
• Мерить качество. Обязательный шаг, который часто пропускают: проверить модель на реальных запросах, сравнить с тем, что было, и убедиться, что точности достаточно. Без оценки качества вы не знаете, работает решение или только кажется, что работает.

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

Частые ошибки

За время работы с локальными моделями я вижу одни и те же грабли. Перечислю их, чтобы вы могли обойти.

• Брать гигантскую модель туда, где хватит маленькой. Самая частая и самая дорогая ошибка. На простую классификацию или извлечение данных гнать универсального гиганта — значит переплачивать за ресурсы и терять в скорости там, где компактная настроенная модель справится не хуже.
• Ждать от маленькой модели универсальности. Обратная крайность. Маленькая доменная модель сильна на своей задаче, но не должна одновременно писать тексты, рассуждать на любые темы и решать чужие сценарии. Если вы хотите «всё в одном», маленькая модель вас разочарует — её ценность именно в узости.
• Настройка без качественных данных. Модель учится на ваших примерах. Если данные грязные, противоречивые или их слишком мало, результат будет слабым — каким бы хорошим ни был подход. «Мусор на входе — мусор на выходе» здесь работает в полную силу.
• Игнорировать оценку качества. Развернули, вроде отвечает — и на этом успокоились. Без измерения точности на реальных запросах вы не знаете, можно ли доверять модели в работе. Оценка качества — не формальность, а условие, при котором решением вообще можно пользоваться.
• Забыть про приватность данных при обучении. Если вы настраиваете модель на чувствительных данных, важно понимать, где идёт обучение и куда уходят примеры. Локальная настройка на своём сервере держит данные внутри; настройка через чужой облачный сервис — это уже отдельный вопрос с точки зрения 152-ФЗ, который нужно решить заранее.

Объединяет эти ошибки одно: попытка пропустить этап осмысленного выбора и настройки. Маленькие доменные модели дают выгоду не «из коробки», а когда подход выстроен под конкретную задачу и проверен на ваших данных.

Частые вопросы

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

Правда ли, что маленькая модель может быть точнее гиганта? На своей узкой задаче — да, такое реально. После настройки на ваших данных компактная модель глубоко «понимает» именно ваш домен и может давать более точные ответы, чем универсальный гигант, который знает обо всём, но ни о чём конкретном слишком глубоко. На широких и непредсказуемых задачах гигант по-прежнему сильнее.

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

Подходит ли это для соблюдения 152-ФЗ? Локальное развёртывание здесь — большое преимущество: модель работает на вашем сервере в России, и данные не уходят в чужой облачный ИИ, что упрощает соблюдение требований к персональным данным. Но само по себе локальное размещение не делает систему «автоматически законной» — нужно правильно организовать доступ, хранение и регламенты. Это решается на этапе внедрения.

Сколько данных нужно для настройки? Зависит от задачи: чем она уже и понятнее, тем меньше примеров требуется. Главное не объём ради объёма, а качество — чистые, репрезентативные примеры реальных обращений или документов. Если данных совсем мало или они противоречивы, результат будет слабым, и я честно скажу об этом до старта.

С чего начать? С выбора одной узкой задачи, на которой выгода очевидна, — например, классификация обращений или извлечение данных из документов. Дальше подбирается подходящая открытая модель, настраивается на ваших данных, разворачивается локально и проверяется на реальных запросах. Начинать почти всегда стоит с одного сценария, а не с попытки заменить весь ИИ сразу.

Коротко о главном

Маленькие доменные модели — это здоровый разворот после гонки за размером: вместо одного дорогого гиганта на всё вы ставите несколько компактных моделей, каждая под свою задачу. Для узких сценариев — классификации обращений, извлечения данных, ответов по своей базе — настроенная маленькая модель часто так же точна или точнее, при этом дешевле в эксплуатации, быстрее и проще в контроле. Для российских компаний к этому добавляется главное: такую модель можно держать на своём сервере в РФ, данные не уходят наружу, и это хорошо ложится и на импортозамещение, и на требования 152-ФЗ. Взамен нужны осмысленный выбор задачи, качественные данные для настройки и честная оценка качества — без этого выгода не появится сама. Я 16+ лет в IT и разворачиваю локальные модели под задачу под ключ: от выбора модели и настройки на ваших данных до развёртывания на вашем сервере. Если вам близка идея узких моделей вместо одного гиганта — помогу пройти этот путь до рабочего решения.