Малые модели до 4B: на что они реально годятся

MAATRIX

Вокруг малых языковых моделей — тех, что укладываются в 1-4 миллиарда параметров, — сложилось два одинаково нездоровых лагеря. Одни считают их игрушкой, недостойной серьёзных задач. Другие поверили маркетингу и пытаются поставить такую модель туда, где нужна широкая эрудиция и сложное рассуждение, а потом разочаровываются. Истина прозаичнее: малая модель — это инструмент под конкретный класс задач, и если вы понимаете границы этого класса, она экономит вам деньги и время не хуже, а иногда и лучше, чем модель в десять раз крупнее.

Завышенные ожидания: "маленькая модель — это большая, но дешевле"

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

Практический вывод: малая модель — не "младший брат" GPT-класса ассистента, а отдельный инструмент вроде регулярного выражения или SQL-запроса. Regex не разочаровывает вас тем, что не пишет стихи — вы просто не пытаетесь заставить его это делать. С малой LLM работает та же логика: сначала определите узкий класс задач, а потом смотрите, тянет ли его конкретная модель.

Подробнее о том, почему число параметров плохо коррелирует с "умом" модели вне контекста конкретной задачи, — в статье про миф "чем больше параметров, тем умнее ответ".

Где малые модели реально хороши: узкие задачи с ограниченным входом

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

Классификация коротких текстов по фиксированному набору категорий. Определить тональность отзыва, отнести обращение в поддержку к одной из 5-10 заранее известных категорий, пометить письмо как спам/не спам, отсортировать заявку по срочности. Здесь пространство возможных ответов узкое и заранее известное — модели не нужно "изобретать" структуру ответа, только выбрать из ограниченного набора вариантов.

Пример system-prompt для классификатора обращений в поддержку:

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

Обращение: "{текст_обращения}"
Категория:

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

{
  "system": "Извлеки из текста поля в формате JSON: {order_id, amount, currency, date}. Если поле не найдено — null.",
  "user": "Заказ #48213 на сумму 3200 руб. от 12.08.2026, оплата прошла успешно"
}

Ожидаемый вывод: {"order_id": "48213", "amount": 3200, "currency": "RUB", "date": "2026-08-12"}. Отдельно о том, как заставить модель надёжно возвращать именно валидный JSON, а не текст с JSON внутри, — в статье structured output в LLM: как получить JSON.

Простое суммирование короткого текста. Сжать письмо на 3-5 абзацев в одно предложение для превью, выделить ключевую мысль из отзыва, сократить лог ошибки до одной строки для алерта. С многостраничными документами малая модель справляется заметно хуже — контекст в 20+ абзацев она склонна терять, но короткий самодостаточный фрагмент текста — обычно посильная задача.

Общее у всех трёх подтипов: узкий, предсказуемый вход и узкий, предсказуемый выход. Модели не нужно "рассуждать" — нужно распознать паттерн и применить простое правило. Именно тут разница между 4B и 70B моделью для конечного пользователя часто неразличима, а разница в стоимости и скорости — разительная.

Малая модель как первый фильтр перед дорогой большой

Второй практичный сценарий — не замена большой модели, а её напарник. Малая модель работает маршрутизатором: принимает входящий запрос первой, дёшево и быстро определяет, простой это случай или сложный, и только сложные передаёт дальше на дорогую крупную модель или облачный API. В большинстве реальных потоков (обращения в поддержку, вопросы к ассистенту, модерация контента) подавляющее большинство случаев типовые, и лишь небольшая доля требует настоящего рассуждения. Пропускать 100% трафика через дорогую модель "на всякий случай" — значит платить за сложность там, где её нет.

Пример упрощённой схемы роутинга на псевдокоде:

def route_request(user_message):
    # Быстрый локальный классификатор на малой модели (например, gemma3:4b через Ollama)
    complexity = classify_complexity(user_message)  # "simple" | "complex"

    if complexity == "simple":
        return small_model.generate(user_message)   # дёшево, быстро, локально
    else:
        return large_model_api.generate(user_message)  # дороже, но только для сложных случаев

Сам классификатор сложности — это тоже задача из предыдущего раздела: классификация по фиксированным категориям ("простой" / "сложный", либо более детальная разбивка по типу запроса). Малая модель отлично умеет отвечать на вопрос "к какому типу относится этот запрос", даже если сама ответить по существу на сложный запрос не способна.

Практическая выгода такой схемы — не только деньги за токены облачного API, но и задержка: малая модель на своём сервере отвечает на простые случаи почти мгновенно, не дожидаясь сетевого round-trip до внешнего API. Это частный случай гибридной схемы "локальная модель + облачный API", где малая модель забирает на себя основной объём типовых запросов.

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

Слабое железо и жёсткие ограничения по задержке

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

Типичные ситуации:

• VPS без видеокарты — только CPU и ограниченный объём RAM. Крупная модель на десятки миллиардов параметров туда просто не влезет по памяти, а если и влезет через агрессивное квантование — генерация будет мучительно медленной.
• Edge-устройства и встроенные сценарии — обработка запроса должна происходить локально, без обращения к внешнему API, а вычислительных ресурсов на устройстве немного.
• Интерактивный сценарий с жёстким требованием по задержке — например, автодополнение в реальном времени, где предсказуемая скорость ответа важнее чуть более высокого качества.

Малые модели вроде вариантов на 1-4B параметров изначально проектируются и обучаются с расчётом именно на такие сценарии — это отдельный продукт, а не урезанная версия большой модели. Подробный разбор того, как трезво выбрать вариант размера и квантизации под конкретное слабое железо, — в статье Gemma 3 на слабом железе: что реально работает. Там же методика "начинайте с самого компактного варианта и поднимайтесь по размеру только если качества не хватает" — она применима и к другим семействам малых моделей.

Ограничение по железу — это ограничение, а не оправдание для завышенных ожиданий от результата. Если у вас VPS на 8 ГБ RAM без GPU и задача требует широкого рассуждения — малая модель не решит её качественно только потому, что это единственное, что физически помещается. Честный ответ здесь — либо упростить задачу до узкого сценария, который малая модель потянет, либо признать, что нужен более мощный сервер.

Где малые модели объективно слабы

Чтобы не создавать иллюзию, будто малая модель "всё может, если правильно попросить", стоит прямо перечислить классы задач, где 1-4B модели закономерно проваливаются, и пытаться "натянуть" их туда — трата времени.

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

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

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

Длинные связные тексты с сохранением контекста на протяжении многих абзацев. Статья на 5000+ знаков, где нужно не терять логическую нить и не повторяться, — задача, где преимущество более крупной модели в удержании длинного контекста заметно. Малая модель на таком объёме чаще "плывёт": теряет ранее введённые детали, начинает противоречить сама себе.

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

Как проверить, хватит ли вам малой модели: методика

Вместо того чтобы решать вопрос "малая или большая" абстрактно, полезнее прогнать задачу через простую практическую процедуру ещё до аренды сервера под дорогую модель.

Шаг 1. Определите минимально достаточное качество для вашей задачи. Не "максимально возможное", а именно минимально достаточное. Если модель классифицирует обращения в поддержку и ошибается в 5% случаев, а оператор перепроверяет спорные случаи — это может быть приемлемо. Если та же модель извлекает сумму платежа для автоматического списания денег — 5% ошибок неприемлемы категорически. Порог качества определяется ценой ошибки в вашем сценарии, а не общими соображениями "чем точнее, тем лучше".

Шаг 2. Соберите 30-50 характерных примеров из вашей реальной задачи, а не абстрактных тестовых вопросов из интернета. Важно, чтобы примеры отражали реальное распределение — включая пограничные случаи, которые встречаются на практике.

Шаг 3. Прогоните эти примеры через малую модель и оцените долю ошибок. Отдельно отметьте, какие ошибки случайные (можно списать на шум), а какие системные — модель стабильно путает одни и те же две категории или всегда неверно парсит один и тот же формат даты. Системные ошибки на понятном домене обычно чинятся точечно — уточнением промпта или лёгким дообучением; ошибки на грани возможностей модели — сигнал, что нужна модель крупнее.

Шаг 4. Сравните результат с порогом из шага 1. Если малая модель укладывается в приемлемый процент ошибок — берите её и не переплачивайте за более крупную альтернативу. Если системно не дотягивает даже после уточнения промпта — переходите к сравнению с более мощной моделью, уже понимая точную цену вопроса в качестве и в деньгах.

Практический шаблон для локального теста через Ollama:

# Быстро поднять малую модель для проверки на своих примерах
ollama pull gemma3:4b

# Прогнать пример из вашего датасета
ollama run gemma3:4b "Классифицируй обращение по категориям [оплата, сбой, вопрос, жалоба]: Не могу оплатить заказ картой, выдаёт ошибку"

Такой прогон стоит сделать на 30-50 реальных примерах, посчитать долю совпадений с ожидаемым ответом — и только по факту этих цифр принимать решение, а не по общему ощущению "модель маленькая, наверное, слабая". Развёрнутая методика оценки качества ответов на своих данных разобрана в статье как тестировать качество ответов своей модели.

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