Когда в компании появляется первая рабочая интеграция с языковой моделью, почти всегда всплывает один и тот же вопрос: «Какую модель брать основной?» Вопрос понятный, но слишком узкий. В реальной системе важнее не выбрать единственную «лучшую» модель, а спроектировать маршрут: какой запрос куда отправлять, сколько это должно стоить, как быстро должен прийти ответ и что делать, если провайдер недоступен или упёрся в лимиты.
Я смотрю на LLM как на заменяемый компонент внутри контура, а не как на центральный объект поклонения. Одна модель может хорошо справляться с длинной аналитикой, другая быстрее отдавать короткие классификации, третья быть удобнее для приватного размещения, четвёртая использоваться как резерв. В AI First подходе это нормальная инженерная задача: не «угадать фаворита месяца», а собрать систему, которая выбирает достаточно подходящий инструмент под конкретную работу.
Ниже разберу, как я обычно думаю о маршрутизации LLM: от типов задач и бюджета до fallback, качества и эксплуатационных ошибок. Без универсальной таблицы «эта модель всегда лучшая», потому что такая таблица устаревает быстрее, чем её успевают внедрить.
Почему маршрутизация важнее любимой модели
У языковых моделей разные ограничения. Отличается цена входных и выходных токенов, скорость ответа, доступные режимы, контекстное окно, качество на разных типах задач, политика обработки данных и лимиты конкретного аккаунта. Эти параметры ещё и меняются: провайдеры обновляют модели, тарифы и условия доступа.
Поэтому я не закладываю в архитектуру тезис «всё делаем через одну модель». Это удобно на прототипе, но плохо живёт в эксплуатации. Как только появляются регулярные задачи, ночные кроны, пользовательские чаты, отчёты, генерация контента, классификация заявок и работа с внутренними данными, единая модель превращается в узкое место.
Маршрутизация решает несколько задач сразу:
- снижает стоимость простых операций;
- оставляет дорогие модели для задач, где они действительно нужны;
- даёт резерв при сбое, лимите или деградации качества;
- разделяет публичные и внутренние сценарии;
- помогает измерять, какая модель лучше работает на конкретном классе задач.
В архитектуре AI-систем я отношу маршрутизацию к ядру: рядом с инструментами, правами, контекстом, журналированием и обработкой ошибок. Это не декоративная прослойка. Это место, где система принимает решение, какой вычислительный ресурс использовать.
Сначала классифицировать задачу
Маршрутизатору нельзя просто передать текст и спросить: «Куда бы тебя отправить?» Сначала нужно описать классы задач. Иначе правила быстро превратятся в набор случайных исключений.
Я обычно начинаю с простого разбиения.
Быстрые и дешёвые операции
Это классификация, извлечение полей, короткая нормализация текста, выбор категории, проверка соответствия формату, первичная сортировка обращений. Здесь часто не нужна самая сильная модель. Важнее задержка, стоимость и стабильный формат ответа.
Например, если нужно понять, относится ли заявка к поддержке сайта, SEO или автоматизации, дорогая reasoning-модель обычно избыточна. Лучше дать короткий контекст, строгую схему ответа и отправить задачу в модель, которая быстро и предсказуемо работает с такими запросами.
Смысловая аналитика и проектирование
Это другая зона: разбор процесса, архитектурное решение, сложный документ, сравнение вариантов, диагностика причины, редакторская работа с большим контекстом. Здесь экономия на модели может обернуться дорогой ручной переделкой.
Я не считаю, что сильная модель нужна всегда. Но если задача требует удерживать несколько ограничений, видеть противоречия и аккуратно объяснять решение, маршрут должен учитывать качество рассуждения, а не только цену токена.
Потоковые пользовательские ответы
Чат поддержки, внутренний ассистент, быстрые ответы менеджеру, подсказки в интерфейсе — тут важна скорость. Пользователь не должен ждать сложную модель там, где нужен короткий рабочий ответ. Но и тут нужна граница: если запрос выходит за сценарий или требует действия с риском, его лучше переводить в другой маршрут, а не заставлять быструю модель уверенно импровизировать.
Приватные и чувствительные данные
Не каждый запрос можно отправлять в облачный API в исходном виде. Иногда достаточно обрезать контекст, обезличить данные или передать только признаки. Иногда нужен отдельный контур с локальной моделью или другим режимом размещения.
Маршрутизация по приватности должна происходить до выбора «самой умной» модели. Если данные нельзя передавать конкретному провайдеру, качество модели уже не имеет значения: маршрут закрыт.
Критерии маршрута
На практике я стараюсь не делать маршрутизатор слишком «умным» в первой версии. Лучше явные правила, которые можно проверить, чем красивый слой, который никто не понимает.
Тип задачи
Самое простое правило: у каждого сценария есть основной маршрут и резервный маршрут. Классификация идёт в одну группу моделей, длинная аналитика — в другую, генерация черновика — в третью, проверка результата — иногда вообще в отдельную.
Это хорошо сочетается с контекст-инжинирингом. Сначала система формирует правильный контекст, затем выбирает модель. Если поменять порядок, легко получить бессмысленную оптимизацию: дорогая модель получает шумный контекст, дешёвая получает слишком сложную задачу, а команда потом спорит о «качестве ИИ».
Скорость
Для интерактивных сценариев задержка важнее идеальной формулировки. Если сотрудник задаёт короткий вопрос в рабочем чате, ответ через минуту может быть уже неуместен. Для фоновой аналитики, наоборот, можно подождать дольше, если результат потом попадёт в отчёт или решение.
Поэтому я разделяю маршруты по режиму ожидания: синхронный быстрый ответ, отложенная задача, фоновый batch, ручная проверка. Одна и та же модель может быть хорошей в одном режиме и неудобной в другом.
Бюджет
Стоимость LLM складывается не только из цены за токен. Важно учитывать длину входного контекста, ожидаемый объём ответа, повторы из-за ошибок, стоимость проверки и ручной доработки. Иногда дешёвая модель становится дорогой, если её приходится три раза перезапускать и потом долго вычитывать результат.
Я бы не жёстко вшивал цены в статью или код без регулярного обновления. Цены и условия лучше сверять по первичным страницам провайдеров: например, у OpenAI есть официальный раздел API pricing, у Anthropic — страница pricing. В рабочей системе это должно быть не знание «из головы», а конфигурация, которую можно обновить.
Лимиты и доступность
Rate limits — не авария, а нормальное эксплуатационное ограничение. Anthropic отдельно описывает различие между spend limits и rate limits в документации API, Google для Gemini также ведёт отдельную страницу rate limits. Значит, маршрутизатор должен уметь жить с ограничениями, а не удивляться им.
Минимальный набор: таймауты, повтор с backoff, учёт ошибок по провайдеру, fallback, очередь для не срочных задач и понятный статус для человека. Если запрос важный, но не срочный, его можно отложить. Если срочный, нужен резервный маршрут. Если действие рискованное, лучше остановиться и объяснить причину, чем тихо отправить его в неподходящую модель.
Качество и проверяемость
Маршрутизация не заканчивается выбором модели. Нужно ещё понимать, сработал ли маршрут. Для этого я закладываю проверку результата: схема ответа, валидатор, тестовые примеры, выборочный человеческий review, сравнение нескольких моделей на одинаковых задачах.
Если система пишет черновик статьи, качество нельзя измерять только фактом, что файл создался. Если система классифицирует заявки, можно считать долю ручных исправлений. Если система готовит аналитический отчёт, нужны контрольные вопросы и проверка источников. Маршрут без обратной связи быстро превращается в веру.
Простая схема маршрутизатора
В первой версии мне обычно хватает не нейросетевого маршрутизатора, а обычной таблицы решений. У каждой задачи есть поля: класс, чувствительность данных, максимальная задержка, допустимая стоимость, требуемая глубина рассуждения, формат результата, основной провайдер, резерв, способ проверки.
Пример логики:
- короткая классификация без чувствительных данных — быстрый дешёвый маршрут;
- длинный разбор с несколькими источниками — сильная модель и отложенный режим;
- персональные данные — урезание контекста, обезличивание или приватный контур;
- массовая генерация — бюджетный маршрут, batch-режим и выборочная проверка;
- действие с последствиями — модель готовит предложение, человек подтверждает.
Такой подход скучный, зато управляемый. Он хорошо работает вместе с проектированием AI-архитектуры: сначала фиксируем компоненты, данные, права и ошибки, потом выбираем модели под маршруты.
Типовые ошибки
Одна модель на всё
Самая частая ошибка — взять сильную модель и отправлять в неё все запросы. На демо это удобно. В эксплуатации простые задачи переплачивают за ненужное качество, сложные конкурируют с мелким потоком, а лимит одного провайдера влияет на всю систему.
Выбор по названию, а не по задаче
Модель может быть новой и действительно сильной, но это не значит, что она нужна в каждом маршруте. Я предпочитаю проверять её на своих классах задач: классификация, редактура, работа с таблицей, технический разбор, извлечение структуры. Название модели не заменяет тестовый набор.
Нет резервного маршрута
Если провайдер недоступен, система должна знать следующий шаг: повторить позже, отправить в резервную модель, поставить задачу в очередь или вернуть человеку понятную ошибку. Вариант «просто упасть» допустим только для прототипа.
Нет бюджета на уровне сценария
Нельзя управлять стоимостью, если бюджет существует только в конце месяца на счёте. У сценария должен быть ожидаемый объём: сколько запросов, какой контекст, какой ответ, сколько повторов допустимо. Иначе дорогая модель незаметно выполняет дешёвую работу.
Приватность вспоминают после интеграции
Если в систему уже пошли реальные данные, поздно выяснять, какие поля можно отправлять провайдеру. Политика данных должна быть частью маршрута: что передаём, что обрезаем, что храним и где нужен отдельный контур.
Проверку качества заменяют ощущением
«Мне кажется, эта модель пишет лучше» — плохой эксплуатационный критерий. Для творческих задач человеческая оценка нужна, но её стоит превращать в повторяемый review: примеры, чек-лист, причины отклонения. Для структурных задач нужны валидаторы.
Как я бы внедрял маршрутизацию по шагам
Сначала я описываю не модели, а работу: кто запускает запрос, какие данные входят, какое решение нужно получить, что считается ошибкой и кто отвечает за спорный случай. На этом этапе часто выясняется, что часть задач вообще не требует LLM и лучше решается обычным скриптом или workflow.
Затем делю сценарии на группы. Обычно хватает четырёх корзин: быстрые операции, содержательная работа, приватный контур, рискованные действия. Для каждой задаю основной маршрут, резерв, таймаут, формат ответа и проверку.
После этого запускаю набор контрольных примеров: короткая заявка, плохой источник, длинный документ, неполные данные, конфликт инструкций, запрос на действие с последствиями. Если модель ошибается на пограничных случаях, это не повод сразу менять провайдера. Иногда нужно уточнить контекст, ограничить полномочия или добавить валидатор.
Дальше появляется журнал: класс задачи, выбранный маршрут, размер контекста, статус, ошибка, время ответа и результат проверки. Без журнала невозможно понять, где система дорожает, где тормозит и где даёт плохой результат. И только после этого имеет смысл оптимизировать: переводить часть потока на более дешёвую модель, добавлять batch-режим, менять резервные маршруты, тестировать новые модели, вводить кэширование или сокращать контекст.
Практический чек-лист
Перед тем как подключать новую модель или менять маршрут, я прохожу по короткому списку.
- Какой класс задачи обрабатывается: классификация, генерация, аналитика, действие, проверка?
- Какие данные уходят в модель и есть ли среди них чувствительная информация?
- Нужен быстрый ответ пользователю или допустима отложенная обработка?
- Какая стоимость считается нормальной для одного успешного результата, а не для одного API-вызова?
- Что произойдёт при таймауте, лимите, ошибке провайдера или плохом ответе?
- Есть ли резервная модель или сценарий остановки с понятным сообщением?
- Как проверяется результат: схема, тест, человеческий review, сравнение с источником?
- Где хранится решение маршрутизатора и можно ли потом объяснить, почему запрос ушёл именно туда?
- Кто отвечает за обновление цен, лимитов и списка доступных моделей?
- Какие операции модель только предлагает, а какие система имеет право выполнять сама?
Если на эти вопросы нет ответов, я не считаю маршрутизацию готовой. В таком состоянии лучше запускать ограниченный пилот: один процесс, несколько классов запросов, понятный журнал и ручная проверка. А уже после этого расширять контур, подключать ИИ-агентов для бизнеса и отдавать системе больше самостоятельности.
Маршрутизация LLM — это не способ красиво переключаться между модными названиями моделей. Это эксплуатационная дисциплина. Хороший маршрут экономит деньги на простых задачах, оставляет сильные модели для сложных, защищает данные, переживает сбои и даёт команде возможность объяснить каждое решение системы.