Как выбрать модель под свою задачу: методика без хайпа

MAATRIX

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

Почему подход «взять самую топовую» подводит

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

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

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

Методика ниже решает эту проблему последовательно: сначала сужает пространство вариантов жёсткими фактами (что реально решаем, что реально можем себе позволить), а уже потом сравнивает оставшихся кандидатов на данных, которые отражают именно вашу задачу.

Шаг 1. Сформулируйте реальную задачу и минимальное достаточное качество

Первая и самая частая ошибка — формулировка «хочу ИИ для бизнеса» или «нужен чат-бот». Это не задача, это направление. Настоящая формулировка задачи выглядит конкретно и проверяемо:

• Не «чат-бот для сайта», а «отвечать на 20 типовых вопросов о доставке и возврате товара по базе из 50 FAQ-статей, на русском, в рамках уже существующего виджета».
• Не «генерация текста», а «писать черновики описаний товаров по шаблону: название, три характеристики, 400 знаков текста, без выдумывания несуществующих свойств».
• Не «анализ документов», а «извлекать из договора аренды пять полей (срок, сумма, стороны, дата, штрафы) в JSON для последующей загрузки в 1С».

Для каждой такой формулировки сразу пропишите минимально достаточное качество — не «идеально», а порог, ниже которого решение бесполезно, и потолок, выше которого улучшение уже не даёт бизнес-эффекта. Для FAQ-бота порог может звучать так: «в 9 из 10 реальных вопросов клиента ответ фактически верный и не противоречит документам компании, тон вежливый». Для извлечения полей из договора порог жёстче: «все пять полей извлечены верно в 95% документов, ошибка в сумме недопустима вообще» — здесь цена ошибки высокая, значит и планка выше, вплоть до того, что вменяемая модель без ручной проверки может не подойти в принципе.

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

Шаг 2. Ограничения железа — первый практический фильтр

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

Определите жёстко, без иллюзий:

• Сколько VRAM реально доступно на видеокарте (или видеокартах), которую вы готовы арендовать или уже арендуете.
• Сколько системной RAM доступно, если часть модели будет выгружена на CPU (для CPU-инференса или гибридного режима это отдельный, более медленный сценарий).
• Какой бюджет в месяц вы реально готовы платить за сервер под эту задачу — не «сколько стоит топовая карта», а сколько стоит решение, окупающее себя вашей задачей.

Дальше — простая арифметика, знакомая тем, кто уже считал требования под конкретную модель: полноразмерная модель в FP16 требует примерно 2 байта на параметр, то есть 7B-модель — это около 14 ГБ только под веса, без учёта контекста и служебных буферов. Квантование до Q4 сокращает это примерно вчетверо от исходного FP16 объёма, что и делает возможным запуск крупных моделей на скромном железе. Мы подробно разбирали это в статье про требования к серверу для машинного обучения и в таблицах по объёму RAM для конкретных размеров моделей.

Ориентировочная (не измеренная точно, у вас будет отличаться в зависимости от квантования и контекста) картина по классам железа:

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

Шаг 3. Отберите 2-3 кандидата, а не одного «лучшего»

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

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

Практический набор кандидатов для задачи, которая помещается, скажем, в 16 ГБ VRAM, может выглядеть так:

• Один универсальный кандидат среднего размера из мейнстримного семейства с хорошей репутацией в инструктивных задачах.
• Один компактный кандидат меньшего размера — специально чтобы проверить гипотезу «а может, для этой задачи хватит модели раза в два меньше и дешевле». Мы разбирали этот подход отдельно в материале про малые модели на скромном железе — не потому что маленькая модель всегда достаточна, а потому что для многих реальных задач она оказывается достаточной, и проверить это дешевле, чем предполагать.
• Один кандидат, специализированный под ваш тип задачи, если такой есть (например, модель с акцентом на код — для задач с кодогенерацией, или модель с сильной русскоязычной инструктивной настройкой — для задач на русском).

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

Шаг 4 и 5. Свой набор примеров и честное сравнение кандидатов

Здесь методика расходится с «посмотреть рейтинг» сильнее всего. Соберите небольшой, но представительный набор реальных примеров именно вашей задачи — 15–30 штук обычно достаточно для первого прохода. Это не абстрактные тестовые вопросы («столица Франции», «напиши стих про весну»), а то, что реально придётся решать: настоящие обезличенные обращения клиентов, реальные брифы для генерации, реальные фрагменты договоров для извлечения полей. Если задача новая и реальных примеров пока нет — соберите максимально правдоподобные аналоги на основе того, что вы знаете о будущей нагрузке.

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

Прогоните всех кандидатов на одном и том же наборе при одинаковых настройках (температура, системный промпт, длина контекста) и сравните результат по критериям, которые вы зафиксировали на шаге 1, а не по общему впечатлению «звучит умно». Практичный формат — таблица: строка на пример, столбец на кандидата, оценка по шкале (например, 0/1/2 — не годится / приемлемо / хорошо) плюс короткий комментарий, что именно не так, если не годится.

| Пример                          | Кандидат A | Кандидат B | Кандидат C |
|----------------------------------|-----------|-----------|-----------|
| Вопрос о сроках возврата товара   | 2         | 1         | 2         |
| Извлечение суммы из договора №14  | 2         | 2         | 0 (перепутал валюту)
| Бриф на описание товара с ограничением 400 знаков | 1 (перебор длины) | 2 | 2 |

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

Итог этого шага — не абстрактный «победитель», а ответ на конкретный вопрос: какой из 2-3 кандидатов преодолевает порог минимально достаточного качества, зафиксированный на шаге 1, с наименьшими требованиями к железу и деньгам. Может оказаться, что у порога проходят два кандидата — тогда решающим станет шаг 6.

Шаг 6. Скорость и стоимость эксплуатации при реальной нагрузке

Качество — не единственный критерий. Модель, которая отвечает идеально, но за 40 секунд при нагрузке в 5 одновременных запросов, может быть непригодна для чат-виджета на сайте, где пользователь ждёт ответ за 2-3 секунды. И наоборот — для фонового пакетного извлечения полей из документов ночью скорость отклика на один запрос не критична, важна суммарная пропускная способность за час.

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

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

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

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