Что такое маршрутизация LLM? Правила, веса и политики с учетом затрат

Что такое маршрутизация LLM? Правила, веса и политики с учетом затрат

Маршрутизация LLM — это процесс выбора модели, пути через провайдера или резервного пути, который должен обработать конкретный ИИ-запрос. Решение может быть зафиксировано в коде приложения, принято на основе явных правил, рассчитано по взвешенным критериям или делегировано обученному классификатору. Суть не в том, чтобы каждый запрос шел по разному пути. Суть в том, чтобы каждый путь был намеренным, тестируемым и безопасным.

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

Это различие важно. Дешевая модель не становится автоматически безопасным вариантом по умолчанию для клиентского рабочего процесса. Высокофункциональная модель не всегда является правильным выбором для простой задачи классификации. А резервный маршрут полезен только тогда, когда он сохраняет контракты вывода, инструментов и данных, ожидаемые вашим приложением.

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

Именно этому стандарту должен соответствовать практический ответ на вопрос что такое маршрутизация LLM: это решение, которое инженер может проверить, протестировать и изменить, не гадая, какое скрытое правило перенаправило трафик.

Что именно представляет собой маршрутизация LLM?

Что такое маршрутизация LLM? Это процесс принятия решения, который сопоставляет входящий запрос с наилучшим утвержденным путем выполнения для этого запроса. Путь может определять конкретную модель, провайдера, регион, группу моделей или протестированный резервный вариант.

Маршрутизатор может находиться в вашем приложении, API-шлюзе или управляемом сервисе маршрутизации моделей. Например, Amazon Bedrock intelligent prompt routing выбирает среди подходящих моделей в рамках семейства на основе прогнозируемого качества ответа и стоимости. Microsoft Foundry’s model router предоставляет сбалансированный режим маршрутизации, а также режимы, ориентированные на качество и стоимость. Это реализации одной и той же базовой идеи: выбирать осознанно, а не считать все промпты одинаковыми.

Маршрутизация LLM — это не то же самое, что:

• Балансировщик нагрузки. Балансировщик нагрузки распределяет запросы между похожими серверами. Маршрутизатор LLM также учитывает возможности модели и результаты задач.
• Цикл повторных попыток. Повторная попытка на том же маршруте может устранить временную ошибку; она не определяет, подходит ли другая модель для этой задачи.
• Непроверенная замена модели. Перенаправление запроса на резервный вариант, который меняет структуру JSON, поведение инструментов, границы конфиденциальности или качество ответа, может привести к более серьезному сбою, чем явная ошибка.
• Обучение модели. Маршрутизация выбирает путь обслуживания во время запроса. Она не изменяет веса модели.

Более подробно о границе, на которой размещаются эти решения, читайте в нашем руководстве о том, что такое LLM-шлюз и когда он становится полезен.

Как маршрутизатор LLM принимает решение

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

1. Применяйте жесткие ограничения до любой оценки

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

Типичные фильтры включают:

Такой порядок предотвращает распространенную ошибку маршрутизации: считать все модели взаимозаменяемыми. Это не так. Совместимость необходимо подтвердить для конкретной конечной точки и класса трафика, который вы планируете маршрутизировать.

2. Оценивайте допустимых кандидатов

После фильтрации маршрут может использовать прозрачную взвешенную оценку. Один из простых шаблонов:

оценка маршрута =
  вес_качества × ожидаемое_качество
  + вес_задержки × (1 - нормализованная_задержка)
  + вес_стоимости × (1 - нормализованная_стоимость)
  + вес_надежности × недавнее_состояние_маршрута

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

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

3. Выполняйте, наблюдайте и используйте ограниченный резервный вариант

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

1. Является ли ошибка достаточно временной, чтобы повторить попытку по тому же маршруту?
2. Является ли запрос идемпотентным, или повторная попытка может дублировать внешнее действие?
3. Сохраняет ли резервный вариант контракт вывода и инструментов?
4. Разрешено ли резервному варианту превысить бюджет запроса или границы данных?
5. Если нет, следует ли системе поставить запрос в очередь, корректно деградировать или вместо этого вернуть контролируемую ошибку?

Именно поэтому резервный вариант — это метод маршрутизации, а не синоним маршрутизации. В нашем руководстве по стратегии резервных моделей решения по восстановлению рассматриваются подробнее.

Шесть методов маршрутизации LLM, которые следует применять осознанно

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

1. Статическая маршрутизация

Каждый запрос в рабочей нагрузке направляется к одной указанной модели или конечной точке.

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

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

2. Маршрутизация на основе правил

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

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

На что обратить внимание: разрастание правил. Храните правила в файле или сервисе политик с контролем версий вместо того, чтобы разбрасывать проверки провайдеров по коду приложения.

3. Маршрутизация на основе возможностей

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

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

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

4. Взвешенная маршрутизация по стоимости, качеству, задержке и надежности

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

Используйте, когда: вы можете определить измеримый сигнал приемлемости и у вас достаточно телеметрии по маршрутам для сравнения кандидатов.

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

5. Маршрутизация на основе классификатора

Небольшой классификатор или классификатор на основе LLM маркирует запрос — например, как простое извлечение, генерацию кода, сложное рассуждение или контент, чувствительный к безопасности, — а затем передает его предопределенной политике для этого класса.

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

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

6. Маршрутизация с учетом состояния и резервного варианта

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

Используйте, когда: важна доступность и вы определили, какие резервные варианты совместимы с контрактом.

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

Создайте политику с учетом затрат, не теряя из виду качество

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

Полезный подход — создать классы трафика до настройки весов:

Затем сравните показатель, который имеет значение: стоимость одного принятого результата, а не только стоимость одного запроса. Более дешевый маршрут, вызывающий дополнительные повторные попытки, проверку человеком, исправление схемы или неудачные вызовы инструментов, может обходиться дороже для каждой выполненной задачи.

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

Безопасная политика маршрутизации в псевдокоде

Этот упрощенный пример сохраняет возможность аудита решения. Он не предполагает, что каждый маршрут может обработать каждый запрос.

const candidates = catalog
  .filter(route => route.isHealthy)
  .filter(route => route.supports(request.modality))
  .filter(route => route.supportsTools(request.requiredTools))
  .filter(route => route.allows(request.dataClass))
  .filter(route => route.withinBudget(request.budget));

if (candidates.length === 0) {
  return failClosed("No approved route for this request");
}

const primary = candidates
  .map(route => ({
    route,
    score: score(route, request.trafficClass),
  }))
  .sort((a, b) => b.score - a.score)[0];

const result = await call(primary.route, request);

if (isTransient(result.error) && request.isIdempotent) {
  return retryWithinBudget(primary.route, request);
}

if (canUseEquivalentFallback(result.error, request, primary.route)) {
  return call(selectApprovedFallback(candidates, primary.route), request);
}

return returnControlledError(result.error);

Политика должна выдавать причину маршрута, например tool_contract_required, budget_preferred, primary_unhealthy или no_contract_safe_fallback. Эта небольшая деталь значительно упрощает отладку системы по сравнению с общим сообщением «модель завершилась с ошибкой».

Как измерить, помогает ли маршрутизация LLM

Маршрутизация не становится успешной только потому, что она выдала имя модели. Она успешна, когда улучшает определенный результат рабочей нагрузки, не создавая неприемлемого риска.

Отслеживайте результаты по классу трафика, версии политики и выбранному маршруту:

• Доля принятых результатов: доля ответов, прошедших бизнес-проверку, проверку схемы или проверку человеком.
• Стоимость одного принятого результата: общая стоимость модели, повторных попыток и исправлений, деленная на количество принятых задач.
• Задержка P50, P95 и P99: сегментированная по размеру запроса и маршруту; среднее значение может скрывать болезненную задержку в хвосте распределения.
• Коэффициент восстановления через резервный маршрут: как часто резервный вариант дает приемлемый результат, а не просто HTTP 200.
• Частота нарушений контракта: недопустимый структурированный вывод, неподдерживаемые инструменты, несовместимость потоковой передачи или отсутствие обязательных полей.
• Распределение маршрутов: не отправляет ли новая политика неожиданно большую часть трафика по дорогому или деградировавшему пути.
• Доля отклонений политикой: как часто не существует безопасного кандидата — это часто сигнал расширить одобренные возможности, а не ослаблять защитное ограничение.

Практическую систему показателей смотрите в статье Метрики API маршрутизации ИИ, которые действительно важны. Эти метрики особенно полезны, когда изменение маршрутизации, похоже, снижает стоимость токенов, но уменьшает количество принятых результатов.

Когда нужна маршрутизация LLM?

Маршрутизатор может не понадобиться, если один провайдер, один эндпоинт и одна стабильная рабочая нагрузка соответствуют вашим требованиям. Зафиксируйте модель, настройте четкие тайм-ауты и повторные попытки и сначала измерьте базовый уровень.

Маршрутизация LLM становится ценной, когда верно хотя бы одно из следующего:

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

Если это похоже на ваш стек, шлюз может упростить управление операционной границей. В документации Flatkey описаны совместимый с OpenAI базовый URL и единый API-ключ для поддерживаемых моделей; вызывающие стороны выбирают идентификатор модели для каждого запроса, а платформа документирует автоматическое переключение на резервный вышестоящий сервис. Начните с закрепления модели и журналирования результатов, затем внедрите явную политику маршрутизации для классов трафика, которым она действительно нужна. О следующем архитектурном шаге читайте в нашем контрольном списке требований к шлюзу API для ИИ.

О стратегиях маршрутизации, шаблоне политики и промышленном коде читайте в нашем руководстве по маршрутизации моделей.

Часто задаваемые вопросы

Чем маршрутизация LLM отличается от резервного переключения модели?

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

Что такое маршрутизация LLM в API с несколькими провайдерами?

В API с несколькими провайдерами маршрутизация LLM может выбирать как путь через провайдера, так и модель. Прежде чем считать двух провайдеров эквивалентными, политика должна проверять совместимость конечных точек, политику данных, возможности модели, единицы ценообразования, состояние работоспособности и поведение при резервном переключении.

С какой техники маршрутизации LLM следует начать новой команде?

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

Может ли маршрутизатор LLM автоматически выбирать самую дешевую модель?

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

Практический ответ на вопрос «что такое маршрутизация LLM?»

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

Если вы централизуете доступ к моделям, используйте эту границу для проведения контролируемых экспериментов по маршрутизации, а не распределяйте логику провайдеров по всем сервисам. Подробнее — в документации Flatkey API.

Источники и дополнительная литература

• Amazon Bedrock: понимание интеллектуальной маршрутизации промптов
• Microsoft Foundry: использование маршрутизатора моделей
• Книга Google SRE: работа с перегрузкой
• Документация Flatkey
• Flatkey: требования к шлюзу API для ИИ