Как выбрать модель для локального ИИ под свою задачу
Модель выбирают от задачи, а не от рейтинга. Сначала фиксируются четыре требования — длина контекста, язык, нужен ли вызов инструментов и допустимая задержка ответа. Из них следует класс модели по размеру, из класса — объём VRAM и разрядность весов. Финальное решение принимает прогон трёх-четырёх кандидатов на ваших примерах: публичные таблицы лидеров на конкретном домене почти ничего не предсказывают.
От задачи к требованиям: что выясняем до выбора модели
Вопрос «какая модель лучше» ответа не имеет. Ответ имеет вопрос «какая модель закрывает вот эту задачу при вот этих ограничениях». Поэтому сначала описывается сама операция: что приходит на вход, какого объёма, на каком языке, что должно оказаться на выходе — свободный текст, JSON, код номенклатуры или сумма из документа. И кто проверит результат: человек, скрипт или сверка с учётной системой.
Из описания вытаскиваются требования, и их немного. Длина контекста определяет, влезет ли документ в один запрос. Язык решает, брать ли модель с большой долей русского в обучении. Наличие инструментов переводит задачу в агентную и поднимает планку к размеру модели. Допустимая задержка отсекает крупные модели там, где ответ нужен за секунду, а не за десять.
Пятое требование техническое: сколько запросов приходит в пиковый час и сколько людей работают одновременно. Оно превращает выбор модели в конфигурацию железа — числом карт и объёмом памяти. Порядок, в котором эти вещи выясняются на проекте, разобран в статье про этапы внедрения, а состав контура — на странице локального ИИ.
Шесть требований, из которых складывается выбор модели
Каждое требование отсекает часть кандидатов. К моменту, когда список пройден, в шорт-листе обычно остаётся три-четыре модели — их и проверяют на данных.
- Длина контекста. Считайте по худшему документу, а не по среднему. Договор с приложениями или техкарта на сорок страниц требуют окна, которое переживёт ещё и инструкцию с примерами. Если документ не влезает, задача решается нарезкой и поиском, а не покупкой модели с рекордным контекстом.
- Язык. Деловой русский даётся моделям неравномерно: падежи, сокращения, реквизиты, отраслевая номенклатура. Ровнее других здесь работают Qwen, GigaChat и T-pro. Если в потоке встречаются документы на английском или казахском, кандидатов сразу проверяют на смешанной выборке, а не на отобранных русских примерах.
- Вызов инструментов. Модель, которая красиво пишет, не обязана уверенно возвращать структурированный вызов функции. Под агентные сценарии берут семейства, обученные этому специально, — GLM, Qwen, DeepSeek от 30 млрд параметров. Мелкие модели рвутся на цепочке из пяти-шести вызовов подряд.
- Скорость ответа. Диалог с человеком требует первых токенов за секунду-две, ночная пакетная обработка терпит минуты. Задержка зависит не только от размера: длинный контекст и очередь параллельных запросов замедляют ответ сильнее, чем лишние миллиарды параметров.
- Строгость формата. Если на выходе нужен JSON, артикул или сумма, меряется доля ответов, которые пришлось чинить руками. По этому показателю модели расходятся сильнее, чем по «уму», и именно он чаще всего решает выбор в продуктиве.
- Лицензия. Apache 2.0 и MIT разрешают коммерческое использование и дообучение без условий. У вендорских — Llama Community, Gemma Terms — есть оговорки по применению и распространению производных. Редакция меняется от сборки к сборке внутри семейства, поэтому смотрят карточку конкретной версии: разбор есть в каталоге моделей.
Классы моделей по размеру и что каждый требует от железа
7–14 млрд параметров — рабочий класс для массовых операций: классификация обращений, извлечение полей, короткие ответы по инструкции. В 4-битной квантизации такая модель вместе с кэшем занимает 16–24 ГБ и живёт на одной профессиональной карте. Сюда попадают Qwen, Gemma, Mistral и T-lite. Ограничение честное: длинную цепочку рассуждения этот класс не держит.
24–32 млрд — ассистент по базе регламентов, разбор документов, аккуратный деловой русский. Нужно 24–48 ГБ: либо одна карта на 48 ГБ, либо две по 24. От 70 млрд начинается класс агентов с инструментами и длинным контекстом — 80–160 ГБ и 2–4 карты с быстрым межкарточным обменом. Разница в качестве между 32B и 70B на прикладных задачах обычно меньше, чем разница в счёте за железо.
Отдельно стоят крупные MoE-модели уровня фронтира — DeepSeek, Kimi, GigaChat Ultra. Им нужно от 300 ГБ памяти, то есть серверный узел на восемь карт либо инференс на процессоре с очень большим объёмом RAM. Такой класс оправдан, когда поток задач с длинным контекстом постоянный, а не когда хочется взять самую сильную модель. Полная таблица по железу — на странице локального ИИ.
Задача, класс модели, требования к VRAM и кандидаты
Таблица — отправная точка расчёта, а не итог. Цифры даны под инференс в 4 битах и одного-двух параллельных пользователей: на десяти одновременных запросах с длинным контекстом память под кэш растёт быстрее, чем под сами веса.
| Задача | Класс модели | VRAM в 4 битах | Кандидаты из открытого стека |
|---|---|---|---|
| Классификация обращений, извлечение полей | 7–14B, плотная | 16–24 ГБ | Qwen, Gemma, Mistral, T-lite |
| Ответы по базе регламентов с поиском | 24–32B, плотная | 24–48 ГБ | Qwen, GLM, Gemma |
| Деловая переписка и документы на русском | 14–32B, плотная | 24–48 ГБ | GigaChat, T-pro, Qwen |
| Агент с инструментами и длинным контекстом | от 70B либо MoE | 80–160 ГБ | GLM, Qwen, Llama, DeepSeek |
| Разбор договора целиком, очень длинный контекст | MoE уровня фронтира | от 300 ГБ | Kimi, DeepSeek, GigaChat Ultra |
| Распознавание русской речи | специализированная ASR | 8–16 ГБ | GigaAM-v3, T-one, Vosk |
| Расшифровка встреч на нескольких языках | мультиязычная ASR | 8–16 ГБ | Whisper |
| Синтез речи для ответов и уведомлений | TTS | 4–8 ГБ | Silero, открытые VITS |
| Поиск по документам и поиск дублей | эмбеддер | 4–8 ГБ | BGE-M3, multilingual-e5, ru-en-RoSBERTa |
Квантизация: сколько качества стоит экономия памяти
Квантизация снижает разрядность весов. Именно она решает, влезет ли модель в вашу карту, поэтому требование «нужно столько-то гигабайт» без указания формата бессмысленно.
- FP16, два байта на параметр. Модель на 14 млрд параметров занимает около 28 ГБ только под веса. Формат для дообучения и для замера эталонного качества, с которым потом сравнивают сжатые версии.
- 8 бит, один байт. Те же 14B укладываются примерно в 14 ГБ. На прикладных задачах разница с FP16 обычно тонет в погрешности замера — разумный компромисс, когда формат ответа строгий.
- 4 бита, около половины байта. 14B превращаются в 7–8 ГБ и помещаются в одну карту. Самый ходовой формат продуктива: AWQ, GPTQ, GGUF Q4.
- Ниже 4 бит. Качество сыпется неравномерно: свободный текст держится дольше, а JSON, артикулы и суммы ломаются раньше. В продуктивные внедрения такие сборки мы не берём.
- KV-кэш считается отдельно от весов. Он растёт с длиной контекста и числом одновременных запросов. На стостраничных договорах кэш съедает больше памяти, чем сама модель, и расчёт «по весам» разваливается.
- Правило размена. При одинаковом бюджете памяти крупная модель в 4 битах чаще обходит вдвое меньшую в 8 битах. Чаще — не всегда: на задачах со строгим форматом бывает наоборот, поэтому обе версии прогоняют на своём наборе.
Плотные модели против MoE: что дешевле под вашу нагрузку
В плотной модели на каждый запрос работают все параметры. В MoE — смешении экспертов — активируется малая часть, остальные лежат в памяти. Отсюда главный эффект: MoE даёт качество крупной модели при стоимости вычислений, близкой к средней, но памяти требует по полному размеру, а не по активной части.
Практический вывод простой. Если узкое место — скорость и стоимость запроса, а память есть, MoE выгодна: так построены DeepSeek и Kimi. Если узкое место — объём VRAM и карт всего одна-две, плотная модель на 14–32 млрд параметров окажется единственным работающим вариантом, и спорить тут не о чем.
Второй момент — предсказуемость. Плотная модель ведёт себя ровнее на потоке однотипных задач, MoE сильнее выигрывает на разнородных: рассуждение, код и длинный контекст в одном контуре. На типовом внедрении рядом живут три-четыре модели — крупная под рассуждение, лёгкая под массовые операции, эмбеддер под поиск и распознавание речи, если в процессе есть звонки.
Почему публичные бенчмарки не отвечают на ваш вопрос
Рейтинги меряют среднюю температуру: школьная математика, олимпиадный код, общие знания. Ваша задача — разобрать акт сверки с опечатками в наименованиях и вернуть JSON с шестью полями. Связь между первым и вторым слабая, и она тем слабее, чем уже домен и чем строже формат ответа.
Вторая причина — утечка тестов в обучающие данные. Публичные наборы лежат в открытом доступе, а оттуда попадают в корпуса обучения, и часть высоких результатов объясняется этим, а не способностями модели. Проверить это со стороны нельзя, поэтому цифры из чужих таблиц мы приводим только как ориентир и без ссылки на измерение не публикуем вовсе.
Третья — условия замера. Один и тот же вес показывает разное качество при другой разрядности, другом промпте, другом движке инференса и другой длине контекста. Сравнение имеет смысл, когда все эти параметры зафиксированы, то есть когда кандидатов гоняете вы сами и на своих данных.
Прогон кандидатов на своих данных: что именно меряем
Занимает от нескольких дней до полутора недель и укладывается внутрь пилота. Разбор процессов и первичный подбор кандидатов входит в бесплатный аудит.
- Набор из 100–300 реальных примеров. Берутся из потока, а не подбираются: с опечатками, нестандартными формулировками и краевыми случаями. Эталонные ответы проверяет профильный сотрудник, иначе сравнивать не с чем и спорить не о чем.
- Три-четыре кандидата разных семейств и размеров. Обязательно и крупная модель, и компактная: так видно, где заканчивается запас качества и начинается переплата за карты.
- Равные условия. Один промпт, один и тот же поиск, одна разрядность, один движок. Меняется только модель — иначе замер меряет настройку, а не кандидата.
- Четыре числа на выходе. Точность на вашем наборе, задержка первого токена, пиковое потребление VRAM и доля ответов со сломанным форматом. Пятое считается из них — стоимость запроса в пересчёте на месяц работы.
- Проверка на устойчивость. Тот же набор прогоняется повторно и с перемешанным порядком примеров. Разброс между прогонами показывает, насколько полученной цифре вообще можно верить.
- Решение про дообучение. Если отставание держится на терминологии и формулировках, дешевле дообучить модель на ваших данных, чем брать семейство на порядок крупнее и докупать карты.
- Фиксация версии. Имя сборки, хеш весов, редакция лицензии, дата и результаты прогона уходят в проектную документацию. Следующее обновление проходит тот же прогон, прежде чем попасть в продуктив.
Частые вопросы про выбор модели для локального ИИ
Одну большую модель на всё или несколько маленьких?
Несколько. Одна модель на все задачи — дорогая и хрупкая архитектура: крупная LLM простаивает на разметке обращений, а мелкая срывается на цепочке рассуждения. На типовом внедрении рядом работают три-четыре модели: крупная под рассуждение и агентные сценарии, лёгкая под массовые операции, эмбеддер под поиск и распознавание речи, если в процессе есть звонки. Всю память одновременно они не занимают — лёгкие делят карту, крупная получает выделенные ресурсы, загрузку балансирует оркестратор. Побочный плюс: отказ одной модели не выключает весь контур целиком.
Сколько параметров нужно, чтобы модель отвечала по внутренним регламентам?
Обычно хватает 7–14 млрд параметров, если поиск отдаёт точный фрагмент документа. Качество ответа по регламентам определяется поиском не меньше, чем размером модели: при плохой нарезке и слабом эмбеддере модель на 70B выдаст такой же неверный ответ, только медленнее и дороже. Класс 24–32B берут, когда в ответе нужно связать несколько документов, учесть исключения и выдержать деловой стиль. Прежде чем увеличивать модель, проверьте долю случаев, где нужный фрагмент вообще не попал в контекст, — чаще всего проблема живёт именно там.
Можно начать на маленькой модели и потом перейти на большую?
Да, и это нормальный путь. Пилот на модели 7–14 млрд параметров показывает, работает ли сценарий в принципе, и обходится одной картой. Переход на класс выше — операция на несколько часов, если промпты, поиск и тестовый набор уже зафиксированы: меняется модель, прогоняется тот же набор, сравниваются те же четыре числа. Обратный порядок хуже: сервер под 70B, купленный до пилота, часто оказывается либо избыточным, либо не той конфигурации. Поэтому на старте разумно арендовать мощности, снять реальный профиль нагрузки за пару месяцев и покупать железо уже под него.
Как понять, что упираемся в модель, а не в поиск по документам?
Проверяется за час. Возьмите три десятка случаев с неверным ответом и посмотрите, попал ли в контекст нужный фрагмент документа. Фрагмента не было — виноват поиск: нарезка, эмбеддер, ранжирование. Фрагмент был, а модель ответила мимо — виноваты модель или промпт. По нашему опыту первый случай встречается чаще. Второй признак того же: задача решается верно, если правильный фрагмент подставить в запрос руками. Значит, менять надо поиск, а не семейство модели, и деньги на карты не потребуются вовсе.
Что делать, если ни один кандидат не дотягивает до нужного качества?
Сначала разберите, на каком типе примеров расходится результат: ошибки обычно собираются в одну-две группы, а не размазаны ровно. Дальше три пути по возрастанию стоимости. Поправить постановку — промпт, нарезку документов, примеры в контексте. Дообучить модель, если разрыв держится на терминологии и формулировках. Взять класс крупнее и докупить память, если не хватает именно рассуждения. Четвёртый вариант тоже честный: разбить задачу на две простые или оставить её человеку. Часть операций автоматизируется невыгодно, и говорить об этом лучше до внедрения, а не после.
Сколько времени занимает подбор модели на проекте?
От нескольких дней до полутора недель, и этот срок укладывается внутрь пилота на 2–4 недели. Больше всего времени уходит не на прогон, а на сбор тестового набора: 100–300 реальных примеров с эталонными ответами, проверенными профильным сотрудником. Сам прогон трёх-четырёх кандидатов автоматизируется и занимает часы. Если данные для набора уже собраны и размечены, выбор модели перестаёт быть отдельным этапом и растворяется в подготовке пилота. Отдельно закладывается время на проверку лицензий: редакция отличается от сборки к сборке внутри одного семейства.
Бесплатный аудит: посчитаем эффект внедрения ИИ на ваших цифрах
30–40 минут разбора: смотрим ваши процессы, отмечаем, что можно передать ИИ, считаем ROI-модель на ваших объёмах и сроках. Вы уходите с расчётом и картой внедрения — даже если работать дальше не будете.