Миф: чем больше параметров модели, тем умнее ответ

MAATRIX

Когда выбираешь модель для локального запуска, глаза разбегаются: 7B, 13B, 34B, 70B — и интуитивно кажется, что чем больше цифра, тем умнее ответ. Это не совсем так, и если следовать этой логике вслепую, легко арендовать сервер с дорогой видеокартой под 70B-модель, которая для вашей конкретной задачи не даст ощутимого выигрыша над моделью в разы меньше. Разберём, откуда взялся этот миф, где он работает, а где подводит.

Откуда взялся миф про параметры

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

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

Дополнительно миф подпитывается маркетингом: цифра в названии модели (7B, 13B, 70B) — это единственный параметр, который легко воткнуть в промо-материал и сравнить "в лоб", как объём двигателя в автомобиле. Реальная разница в качестве датасета, инструктивном тюнинге и RLHF гораздо труднее уложить в одно число, поэтому маркетинг и упрощённые сравнения на форумах естественным образом скатываются к "чем больше B, тем лучше".

Данные и дообучение решают не меньше, чем размер

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

Три фактора здесь решают не меньше размера:

• Качество и состав претрейн-датасета. Дедупликация, фильтрация мусора и токсичного контента, баланс языков и доменов — всё это напрямую влияет на то, чему модель научилась "видеть" в тексте, независимо от числа параметров.
• Инструктивное дообучение (instruction tuning). Модель, прошедшая через качественный SFT-датасет с разнообразными форматами задач, будет заметно лучше следовать инструкциям, чем модель того же размера без такого этапа.
• RLHF / DPO и похожие методы выравнивания. Здесь модель учится не просто продолжать текст правдоподобно, а отвечать так, как ожидает человек: по делу, без лишней воды, без отказов там, где ответ уместен.

На практике это означает: 8B-модель с современным инструктивным дообучением может уверенно обходить менее аккуратно дообученную 30B-модель на задачах диалога, суммаризации или структурированного вывода. Причём разрыв особенно заметен именно на прикладных задачах "ответь по инструкции", а не на олимпиадных бенчмарках по математике, где сырая ёмкость модели действительно даёт больше запаса.

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

Узкая задача — не повод брать самую большую модель

Второй практический перекос: если у вас узкоспециализированная задача с ограниченным доменом — чат-бот поддержки по одному продукту, классификатор обращений, извлечение полей из однотипных документов — то модель на 70B почти всегда избыточна. Она не станет "умнее" отвечать на вопросы про ваш прайс-лист только потому, что умеет решать задачи по комбинаторике или писать код на Rust — эти способности вашей задаче попросту не нужны.

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

• Меньшая базовая модель + LoRA-дообучение под ваш домен и стиль ответов — см. дообучение LoRA на своём сервере.
• Меньшая модель + грамотный system-prompt и few-shot примеры без дообучения вообще — быстрее внедрить, дешевле в эксплуатации.
• Меньшая модель + RAG поверх базы знаний вашего продукта, если задача — отвечать по документации, а не проявлять общую эрудицию.

Практический ориентир: если ваша задача укладывается в закрытый набор из нескольких сотен-тысяч типовых вопросов и сценариев, 7B–13B модель с адекватным дообучением или RAG обычно закрывает её не хуже 70B — притом что 70B требует на порядок больше ресурсов на каждый запрос. Разницу вы почувствуете не в качестве ответов, а в счёте за сервер.

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

Что на самом деле означает "большая модель" в эксплуатации

Число параметров — это не абстракция, а прямая нагрузка на конкретное железо. Каждый дополнительный миллиард параметров означает больше видеопамяти на веса, больше вычислений на каждый токен генерации и, как следствие, более медленный и дорогой инференс. Модель, которая выигрывает пару процентов на бенчмарке, может быть непригодна для продакшена, если она не влезает в доступную VRAM или генерирует ответ в разы дольше.

Грубое сравнение требований по памяти для инференса (без квантования, FP16):

Это ориентировочные цифры для наглядности порядка величин, реальное потребление зависит от формата весов, длины контекста и настроек batching — на разном железе и при разной нагрузке цифры у вас будут отличаться. Квантование (Q4/Q5/Q8) снижает требования к памяти в разы, но платит за это точностью — подробнее в статье про квантование Q4/Q5/Q8: что выбрать.

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

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

Как выбирать размер модели практически

Вместо вопроса "какая модель самая мощная" полезнее задать последовательность из трёх практических вопросов.

1. Какой тип задачи вы решаете? Узкий домен (поддержка, классификация, извлечение данных, диалог по ограниченной теме) — начинайте с меньшей модели и RAG/дообучения. Широкий домен (код на разных языках, сложные рассуждения, творческие задачи без границ) — там имеет смысл смотреть на модели покрупнее.

2. Какой бюджет по железу и деньгам у вас есть? Посчитайте, во что реально обойдётся сервер под нужный размер модели — см. сколько стоит держать локальную LLM в месяц. Если бюджет ограничен, отталкивайтесь от него в первую очередь, а не от абстрактного "хочу модель посильнее".

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

Практический алгоритм подбора:

1. Сформулируйте 30-50 реальных вопросов/сценариев из вашей задачи
2. Прогоните их через модель среднего размера (7B-13B) без дообучения
3. Оцените: где модель ошибается системно, а где случайно
4. Системные ошибки на понятном домене -> дообучение (LoRA) или RAG
5. Системные ошибки на широком/абстрактном домене -> пробуйте модель крупнее
6. Сравните итоговое качество с ростом стоимости железа (VRAM, скорость)

Такой подход почти всегда даёт более экономичный результат, чем стратегия "берём максимально доступный размер, разберёмся по ходу". Если после дообучения меньшая модель закрывает 90% ваших сценариев, а оставшиеся 10% не критичны для бизнеса — это рациональный компромисс, а не "недоделанное" решение.

Отдельно стоит помнить про CPU-инференс: если задача не требует мгновенного ответа (фоновая обработка, пакетная генерация), можно вообще не упираться в GPU и посчитать, чем CPU уступает GPU для локальной LLM в вашем конкретном сценарии — иногда экономия на видеокарте окупает более долгую обработку.

Когда размер действительно имеет значение

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

• Многошаговые рассуждения и сложная логика — задачи, где нужно удерживать в голове длинную цепочку промежуточных выводов, обычно лучше даются моделям с большим запасом параметров.
• Широкий и непредсказуемый домен вопросов — если вы не можете заранее очертить тематику запросов пользователей (общий ассистент, а не узкий бот), запас общих знаний крупной модели снижает риск провала на нестандартном вопросе.
• Код на разных языках и фреймворках — чем шире набор языков и библиотек, которые должна покрывать модель, тем важнее становится широта охваченных данных, а с ней обычно растёт и размер.
• Задачи с высокой ценой ошибки, где чуть более высокое качество ответа окупает дополнительные расходы на железо (например, юридический или медицинский ассистент для внутреннего использования, а не публичный сервис).

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

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