Когда продукту нужна языковая модель, первый вопрос архитектуры — одна модель на всё или маршрутизация: классификатор оценивает сложность запроса и отправляет простой на дешёвую малую модель, а сложный — на большую. Одна модель — это предсказуемость и один договор; роутинг — это экономия на объёме и «профильные» модели под разные задачи, но также оркестрация, мониторинг маршрутов и новые виды отказов. Выбор зависит не от моды, а от объёма и разнородности вашего трафика.
Ниже — таблица «когда что», критерии и вердикты. Смежные развилки: «малая или большая модель» — выбор одного размера, «GigaChat или YandexGPT» — выбор вендора; здесь — стоит ли разводить запросы по нескольким моделям.
Кратко: когда что выбирать
Прямой ответ — в таблице: слева ситуация, справа разумное решение по состоянию на сентябрь 2026 года. Если узнали свою компанию в одной из строк — дальше достаточно проверить решение по чек-листу в конце страницы, а не перечитывать весь интернет.
| Ситуация | Что выбрать | Почему |
|---|---|---|
| Первый ИИ-сервис, объёмы умеренные | одна модель | проще запускать, оценивать и сопровождать |
| Миллионы запросов в месяц, рост тарифов давит | роутинг | рутина на малой модели радикально снижает счёт за инференс |
| Задачи разной сложности в одном продукте | роутинг | классификатор разводит запросы по «силе» модели |
| Жёсткие требования к единству тона и поведения | одна модель | одна модель — один стиль, меньше рассогласованности |
| Разные домены: документы, код, голос, поиск | роутинг по доменам | каждой задаче — профильно сильная модель |
| Маленькая команда эксплуатации | одна модель | меньше точек отказа, мониторинга и договоров |
Критерии сравнения
Развёрнутая матрица по критериям, которые заказчики проверяют перед решением: стоимость, сроки, риски, поддержка, комплаенс и режим данных. Каждая строка матрицы ниже раскрыта отдельным разбором — с пояснениями, откуда берутся цифры и на что смотреть в вашей ситуации.
| Критерий | Одна модель | LLM-роутинг |
|---|---|---|
| Стоимость | один тариф, предсказуемые счета | дешевле на объёме: рутина уходит на малую модель |
| Сроки | старт за недели | пилот 4–6 недель: классификатор, маршруты, фолбэки |
| Риски | зависимость от одного провайдера и его лимитов | ошибки маршрутизации, каскадные отказы |
| Поддержка | один вендор, один SLA | несколько договоров; оркестрация — от 50 000 ₽/мес |
| 243-ФЗ и комплаенс | один ИИ-актив в реестре | каждая модель — в реестре, плюс регламент маршрутизации |
| Данные | единый канал и режим передачи | у разных моделей разные политики — контролировать каждую |
| Качество ответов | консистентный тон и поведение | риск рассогласованности между маршрутами |
Ключевая строка — стоимость: экономика роутинга раскрывается только на объёме. Если ваш трафик умещается в строку «сроки» с запасом, простота одной модели перевешивает всю экономию пула.
Разбор критериев
Стоимость инференса
Экономика роутинга держится на простом факте: значительная часть трафика продукта — простые запросы, не требующие большой модели. Когда они уходят на малую дешёвую модель, счёт за инференс падает заметно — тем сильнее, чем больше доля рутины и объём. Одна модель платит «премиальную» цену за каждый запрос. Переломный момент — объём: на небольших потоках экономия не окупит оркестрацию, на массовых роутинг окупается за месяцы.
Сроки и сложность
Старт с одной модели — это недели: интеграция API, промпты, оценка. Роутинг добавляет слой: классификатор сложности (правила или малая модель), маршруты, фолбэки при отказе провайдера, сквозные метрики качества по маршрутам — пилот 4–6 недель от 480 000 ₽. Каждая новая модель в пуле — это новый договор, новые лимиты и новый профиль поведения, который надо тестировать.
Риски и отказоустойчивость
Риск одной модели — концентрация: сбой или изменение условий провайдера останавливает продукт целиком. Риски роутинга — распределённые: маршрутизатор ошибся и послал сложный запрос на слабую модель (падение качества), каскадный отказ при переключении на перегруженный фолбэк, рассогласованность ответов между маршрутами. Лечится мониторингом по маршрутам: доля ошибок классификации, качество ответов, доля фолбэков — метрики, которых в схеме с одной моделью просто нет.
Поддержка и оркестрация
Одна модель сопровождается одним договором и одним набором метрик. Пул моделей — это оркестрация: маршруты, версии, лимиты, тарифы каждой модели, а также сопровождение слоя маршрутизации — от 50 000 ₽/мес. Паттерны построения такого слоя разбирает технология «оркестрация ИИ-сервисов на FastAPI», а сам термин — статья «LLM-роутинг в словаре».
243-ФЗ и учёт
Для участника эксперимента по 243-ФЗ каждая модель в пуле — ИИ-актив в реестре: фиксируются модель, сценарий, контур данных. Роутинг добавляет регламент маршрутизации: какие классы запросов каким моделям разрешено обрабатывать — особенно если модели сидят в разных контурах (облачная и локальная). Это не бюрократия ради бюрократии: при проверке вопрос «какие данные уходили в какую модель» должен иметь документированный ответ.
Данные и политики моделей
Главная ловушка роутинга в данных: у разных провайдеров разные политики хранения и разные юрисдикции. Запрос, который можно отправлять одной модели, нельзя отправлять другой — и если маршрутизатор этого не знает, возникает системная утечка. Правило: чувствительные классы запросов жёстко закрепляются за контурной моделью на уровне правил маршрутизации, а не надеяться на «фильтр потом». Как менять контур модели безопасно, разбирает ответ на вопрос «как перевести LLM в локальный контур».
Вердикты по трём сценариям
Сценарий 1. Пилот или первый ИИ-сервис
Одна модель: минимум движущихся частей, быстрый запуск, честная метрика качества. Архитектурно оставьте место для роутинга — единый шлюз вызовов и журналирование с самого дня, — но не стройте пул, пока объём и разнородность трафика этого не потребуют.
Сценарий 2. Массовый продукт с миллионами запросов
Роутинг: классификатор сложности, малая модель на рутине, большая на сложном, фолбэки и метрики по маршрутам. Пилот — от 480 000 ₽, окупается на счёте за инференс. Обязательна регулярная перепроверка классификатора: дрейф трафика со временем меняет долю сложных запросов.
Сценарий 3. Регулируемая организация
Роутинг внутри контура: локальная малая модель для рядовых запросов, мощная локальная — для сложных; чувствительные классы жёстко закреплены правилами. Все модели — в реестре по 243-ФЗ, маршрутизация журналируется. Облачные модели в пуле допустимы только для обезличенных классов запросов.
Типичные ошибки выбора
Ошибки внедрения роутинга, которые съедают всю экономию на инференсе.
- Роутинг на маленьком объёме: оркестрация дороже сэкономленных токенов.
- Классификатор сложности без перепроверки: дрейф трафика молча растит долю ошибок.
- Нет фолбэков: отказ одного провайдера останавливает весь продукт.
- Чувствительные запросы уходят в облачные модели, для которых не предназначены.
- Метрики качества не разделены по маршрутам: деградацию одной модели не видно в общей.
Итог
Одна модель — пока объём мал и продукт молод; роутинг — когда трафик большой и разнородный. Главное — принимать решение по цифрам доли простых запросов, а не по хайпу вокруг мульти-модельных архитектур. Решение стоит перепроверить на своих цифрах: разбор задачи бесплатный, ответ — за 1 рабочий день.
Чек-лист решения
Семь пунктов, которые стоит закрыть до выбора: они одинаково полезны обоим вариантам и закрывают большинство ошибок из списка выше. Пройдите список с командой — обычно это один рабочий час, который экономит недели переделок.
- Какова доля простых запросов в трафике — без этой цифры решение о роутинге — гадание.
- Что измеряется по маршрутам: качество, доля фолбэков, стоимость тысячи запросов.
- Какой классификатор сложности: правила, малая модель, гибрид — и кто его переобучает.
- Что происходит при отказе провайдера: фолбэк, деградация или остановка сервиса.
- Какие классы запросов запрещено отправлять в облачные модели — где это закреплено.
- Все ли модели пула учтены в реестре ИИ-активов по 243-ФЗ, есть ли регламент маршрутизации.
- Как проверяется консистентность ответов между моделями пула на одних и тех же сценариях.
Смежные материалы
Смежные сравнения: «малая или большая модель ИИ» и «GigaChat API или YandexGPT API». Практика: услуга «интеграция и оркестрация LLM»; технология «оркестрация ИИ-сервисов». Вопросы: «какой LLM выбрать для бизнеса». Пошагово: гайд «как выбрать LLM для компании пошагово».
Полный каталог разборов «или — или» — в разделе Сравнения; форматы работ, сроки и цены «от» — в каталоге услуг.