# Как выбрать модель для локального ИИ под свою задачу

> Выбор открытой модели под задачу: контекст, язык, вызов инструментов, классы по размеру, квантизация, MoE и таблица VRAM с кандидатами по типам задач.

- Источник: https://lokai.ru/blog/kak-vybrat-model-dlya-lokalnogo-ii/
- Организация: Local AI — Внедрение ИИ в закрытом контуре
- Обновлено: 2026-08-07
- Раздел: Главная → Блог → Выбор модели

---

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

- **3–4** — кандидата прогоняем на ваших примерах перед выбором
- **100–300** — реальных примеров в тестовом наборе с эталонными ответами
- **16–24 ГБ** — VRAM хватает моделям на 7–14 млрд параметров в 4 битах
- **4 бита** — ходовой формат весов в продуктиве: 14B укладываются в 7–8 ГБ

## От задачи к требованиям: что выясняем до выбора модели

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

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

Пятое требование техническое: сколько запросов приходит в пиковый час и сколько людей работают одновременно. Оно превращает выбор модели в конфигурацию железа — числом карт и объёмом памяти. Порядок, в котором эти вещи выясняются на проекте, разобран в статье про [этапы внедрения](https://lokai.ru/blog/etapy-vnedreniya-ii/), а состав контура — на странице [локального ИИ](https://lokai.ru/lokalnyy-ii/).

## Шесть требований, из которых складывается выбор модели

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

1. **Длина контекста.** Считайте по худшему документу, а не по среднему. Договор с приложениями или техкарта на сорок страниц требуют окна, которое переживёт ещё и инструкцию с примерами. Если документ не влезает, задача решается нарезкой и поиском, а не покупкой модели с рекордным контекстом.
2. **Язык.** Деловой русский даётся моделям неравномерно: падежи, сокращения, реквизиты, отраслевая номенклатура. Ровнее других здесь работают Qwen, GigaChat и T-pro. Если в потоке встречаются документы на английском или казахском, кандидатов сразу проверяют на смешанной выборке, а не на отобранных русских примерах.
3. **Вызов инструментов.** Модель, которая красиво пишет, не обязана уверенно возвращать структурированный вызов функции. Под агентные сценарии берут семейства, обученные этому специально, — GLM, Qwen, DeepSeek от 30 млрд параметров. Мелкие модели рвутся на цепочке из пяти-шести вызовов подряд.
4. **Скорость ответа.** Диалог с человеком требует первых токенов за секунду-две, ночная пакетная обработка терпит минуты. Задержка зависит не только от размера: длинный контекст и очередь параллельных запросов замедляют ответ сильнее, чем лишние миллиарды параметров.
5. **Строгость формата.** Если на выходе нужен JSON, артикул или сумма, меряется доля ответов, которые пришлось чинить руками. По этому показателю модели расходятся сильнее, чем по «уму», и именно он чаще всего решает выбор в продуктиве.
6. **Лицензия.** Apache 2.0 и MIT разрешают коммерческое использование и дообучение без условий. У вендорских — Llama Community, Gemma Terms — есть оговорки по применению и распространению производных. Редакция меняется от сборки к сборке внутри семейства, поэтому смотрят карточку конкретной версии: разбор есть в [каталоге моделей](https://lokai.ru/modeli/).

## Классы моделей по размеру и что каждый требует от железа

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. Такой класс оправдан, когда поток задач с длинным контекстом постоянный, а не когда хочется взять самую сильную модель. Полная таблица по железу — на странице [локального ИИ](https://lokai.ru/lokalnyy-ii/).

## Задача, класс модели, требования к VRAM и кандидаты

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

*Ориентиры под инференс в 4-битной квантизации; под дообучение памяти требуется в 2–3 раза больше*

| Задача | Класс модели | 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 |

## Квантизация: сколько качества стоит экономия памяти

Квантизация снижает разрядность весов. Именно она решает, влезет ли модель в вашу карту, поэтому требование «нужно столько-то гигабайт» без указания формата бессмысленно.

1. **FP16, два байта на параметр.** Модель на 14 млрд параметров занимает около 28 ГБ только под веса. Формат для дообучения и для замера эталонного качества, с которым потом сравнивают сжатые версии.
2. **8 бит, один байт.** Те же 14B укладываются примерно в 14 ГБ. На прикладных задачах разница с FP16 обычно тонет в погрешности замера — разумный компромисс, когда формат ответа строгий.
3. **4 бита, около половины байта.** 14B превращаются в 7–8 ГБ и помещаются в одну карту. Самый ходовой формат продуктива: AWQ, GPTQ, GGUF Q4.
4. **Ниже 4 бит.** Качество сыпется неравномерно: свободный текст держится дольше, а JSON, артикулы и суммы ломаются раньше. В продуктивные внедрения такие сборки мы не берём.
5. **KV-кэш считается отдельно от весов.** Он растёт с длиной контекста и числом одновременных запросов. На стостраничных договорах кэш съедает больше памяти, чем сама модель, и расчёт «по весам» разваливается.
6. **Правило размена.** При одинаковом бюджете памяти крупная модель в 4 битах чаще обходит вдвое меньшую в 8 битах. Чаще — не всегда: на задачах со строгим форматом бывает наоборот, поэтому обе версии прогоняют на своём наборе.

## Плотные модели против MoE: что дешевле под вашу нагрузку

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

Практический вывод простой. Если узкое место — скорость и стоимость запроса, а память есть, MoE выгодна: так построены DeepSeek и Kimi. Если узкое место — объём VRAM и карт всего одна-две, плотная модель на 14–32 млрд параметров окажется единственным работающим вариантом, и спорить тут не о чем.

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

## Почему публичные бенчмарки не отвечают на ваш вопрос

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

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

Третья — условия замера. Один и тот же вес показывает разное качество при другой разрядности, другом промпте, другом движке инференса и другой длине контекста. Сравнение имеет смысл, когда все эти параметры зафиксированы, то есть когда кандидатов гоняете вы сами и на своих данных.

## Прогон кандидатов на своих данных: что именно меряем

Занимает от нескольких дней до полутора недель и укладывается внутрь пилота. Разбор процессов и первичный подбор кандидатов входит в [бесплатный аудит](https://lokai.ru/besplatnyy-audit-ii/).

1. **Набор из 100–300 реальных примеров.** Берутся из потока, а не подбираются: с опечатками, нестандартными формулировками и краевыми случаями. Эталонные ответы проверяет профильный сотрудник, иначе сравнивать не с чем и спорить не о чем.
2. **Три-четыре кандидата разных семейств и размеров.** Обязательно и крупная модель, и компактная: так видно, где заканчивается запас качества и начинается переплата за карты.
3. **Равные условия.** Один промпт, один и тот же поиск, одна разрядность, один движок. Меняется только модель — иначе замер меряет настройку, а не кандидата.
4. **Четыре числа на выходе.** Точность на вашем наборе, задержка первого токена, пиковое потребление VRAM и доля ответов со сломанным форматом. Пятое считается из них — стоимость запроса в пересчёте на месяц работы.
5. **Проверка на устойчивость.** Тот же набор прогоняется повторно и с перемешанным порядком примеров. Разброс между прогонами показывает, насколько полученной цифре вообще можно верить.
6. **Решение про дообучение.** Если отставание держится на терминологии и формулировках, дешевле [дообучить модель на ваших данных](https://lokai.ru/doobuchenie-modeley/), чем брать семейство на порядок крупнее и докупать карты.
7. **Фиксация версии.** Имя сборки, хеш весов, редакция лицензии, дата и результаты прогона уходят в проектную документацию. Следующее обновление проходит тот же прогон, прежде чем попасть в продуктив.

## Частые вопросы про выбор модели для локального ИИ

**Одну большую модель на всё или несколько маленьких?**

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

**Сколько параметров нужно, чтобы модель отвечала по внутренним регламентам?**

Обычно хватает 7–14 млрд параметров, если поиск отдаёт точный фрагмент документа. Качество ответа по регламентам определяется поиском не меньше, чем размером модели: при плохой нарезке и слабом эмбеддере модель на 70B выдаст такой же неверный ответ, только медленнее и дороже. Класс 24–32B берут, когда в ответе нужно связать несколько документов, учесть исключения и выдержать деловой стиль. Прежде чем увеличивать модель, проверьте долю случаев, где нужный фрагмент вообще не попал в контекст, — чаще всего проблема живёт именно там.

**Можно начать на маленькой модели и потом перейти на большую?**

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

**Как понять, что упираемся в модель, а не в поиск по документам?**

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

**Что делать, если ни один кандидат не дотягивает до нужного качества?**

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

**Сколько времени занимает подбор модели на проекте?**

От нескольких дней до полутора недель, и этот срок укладывается внутрь пилота на 2–4 недели. Больше всего времени уходит не на прогон, а на сбор тестового набора: 100–300 реальных примеров с эталонными ответами, проверенными профильным сотрудником. Сам прогон трёх-четырёх кандидатов автоматизируется и занимает часы. Если данные для набора уже собраны и размечены, выбор модели перестаёт быть отдельным этапом и растворяется в подготовке пилота. Отдельно закладывается время на проверку лицензий: редакция отличается от сборки к сборке внутри одного семейства.

---

Бесплатный аудит и расчёт окупаемости на ваших данных: https://lokai.ru/besplatnyy-audit-ii/

Почта: hello@lokai.ru · 123112, Москва, ММДЦ «Москва-Сити» · Пн–Пт, 09:00–19:00 МСК