Самая дорогая строчка в микросервисе с LLM — это жёстко прописанное имя модели, например model="gpt-4o". За ней тянутся ключ вендора, ретраи и счёт, который потом некому разобрать. Решение — вынести выбор модели в отдельный шлюз, чтобы сервис не знал, какая модель ему отвечает. Вокруг этой идеи строятся четыре механизма: правила маршрутизации, автоматический выбор сложности, поведение при сбоях вендоров и контроль денег. Ниже — практические шаги, критерии и типичные ошибки.

1. Effort-маршрутизация: правила вместо хардкода

Вместо того чтобы указывать модель, сервис передаёт в шлюз уровень усилий (effort) — например, low, medium, high. Шлюз по правилам выбирает подходящую модель. Правила могут учитывать:

  • тип задачи (генерация, суммаризация, классификация);
  • требуемую точность или креативность;
  • бюджет на запрос;
  • доступность вендоров.

Пример: для чат-бота с простыми вопросами достаточно модели уровня low (дешёвой и быстрой), а для анализа юридического документа — high (мощной и дорогой). Правила хранятся в конфигурации, а не в коде сервиса. Это позволяет менять модель без пересборки и деплоя.

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

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

Пользователь не всегда знает, какой effort нужен. Шлюз может автоматически оценивать сложность запроса по длине, наличию кода, математических выражений или ключевых слов. Например, если в запросе есть «рассчитай», «проанализируй», «сравни» — повышаем effort. Если это короткий вопрос — понижаем.

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

Критерий выбора: автоматика должна быть предсказуемой и объяснимой. Логируйте, какой effort был выбран и почему — это поможет отлаживать.

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

3. Фолбэки: что делать, когда вендор недоступен

Даже у крупных провайдеров бывают сбои. Шлюз должен уметь переключаться на резервную модель того же уровня effort. Например, если gpt-4o вернул ошибку 429 или таймаут, попробуйте claude-3-sonnet или yandexgpt (если они есть в вашем списке).

Важно: фолбэк не должен быть бесконечным. Установите максимальное число попыток (например, 2) и таймаут на каждую. Если все модели уровня недоступны, верните ошибку с понятным сообщением.

  • Определите цепочку фолбэков для каждого effort.
  • Настройте разные таймауты для разных вендоров.
  • Логируйте каждый фолбэк, чтобы понимать частоту сбоев.

Пример: для high цепочка может быть: gpt-4o → claude-3-opus → gpt-4-turbo. Но помните, что модели могут отличаться по качеству и стоимости — проверяйте, что фолбэк не ухудшает результат критично.

Ошибка: делать фолбэк на модель другого уровня effort без предупреждения. Это может привести к неожиданным затратам или деградации ответа.

4. Лимиты расходов: контроль денег на уровне шлюза

Без лимитов один неаккуратный сервис может сжечь бюджет. Шлюз должен уметь:

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

Реализуйте счётчик расходов на основе фактического потребления токенов (из ответа модели). Для этого шлюз должен парсить метаданные ответа. Если вендор не возвращает стоимость, считайте по прайсу.

Конкретные шаги:

  • Введите квоты на каждый сервис (например, 1 млн токенов в день).
  • Настройте алерты при приближении к лимиту (80%).
  • Добавьте возможность временно повысить лимит для отладки.

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

В итоге, шлюз с такими механизмами снимает с микросервисов головную боль по выбору модели, обработке сбоев и контролю бюджета. Сервис просто говорит «мне нужен effort=medium», а шлюз делает всё остальное. Начните с простых правил и постепенно усложняйте, опираясь на логи и метрики.