На архитектурной схеме LLM Gateway обычно занимает один прямоугольник между приложением и моделями. Из-за этой простоты его легко принять за техническую прокладку. В реальности gateway становится точкой, где сходятся секреты, расходы, данные пользователей, маршрутизация и доступность продукта.
Ниже — не чек-лист функций и не рейтинг сервисов. Это вопросы, которые стоит задать до того, как единый API станет критической инфраструктурой.
1. Что для нас означает OpenAI compatible?
Если ответ — «работает OpenAI SDK», требование слишком размыто. Совместимость базового Chat не гарантирует Responses API, JSON Schema, parallel Tool Calls, Vision, аудио или одинаковую семантику ошибок.
Запишите минимальный контракт приложения как тесты. Совместимость должна быть свойством конкретной версии вашего продукта, а не рекламной формулировкой gateway.
2. Кто выбирает модель: приложение или gateway?
Когда Model ID явно задаёт приложение, решение прозрачно и воспроизводимо. Автоматический router удобнее, но может менять стоимость и качество без изменения кода. Для критичных операций лучше передавать policy: допустимые модели, потолок цены, регион и требуемые capabilities.
3. Можем ли мы восстановить путь одного запроса?
Для расследования нужны Request ID приложения, gateway и upstream, фактический Model ID, выбранный route, число retries и Usage. Без этой цепочки команда увидит только жалобу пользователя и общий счёт.
4. Что произойдёт после timeout?
Timeout не доказывает, что upstream ничего не сделал. Это особенно опасно для Tool Calling. Повтор может отправить письмо или списать товар второй раз.
Retry допустим автоматически только для идемпотентного запроса или до подтверждения внешнего действия. Gateway не может решить это без участия бизнес-логики.
5. Как определяется fallback?
Резервная модель должна удовлетворять тому же Output Contract. Если primary возвращает строгий JSON для финансовой системы, нельзя выбирать fallback только по доступности. Он должен пройти тот же Eval и policy.
6. Где заканчивается экономия?
У дешёвого route может быть больше retries и ручных исправлений. У дорогого — чрезмерное качество для простой классификации. Поэтому gateway должен показывать стоимость по классу задачи и успешному результату, а не только суммарные Token.
Метрика | Что она обнаруживает |
Cost per accepted output | Скрытую цену невалидных и переписанных ответов |
p95 latency by task | Медленные хвосты конкретного workflow |
Retry rate by route | Нестабильность upstream или контракта |
Fallback success rate | Является ли резерв реальным, а не формальным |
7. Что логируется и кому это доступно?
Полный Prompt удобен для отладки, но может содержать персональные данные, исходный код и договоры. Нужны режимы redaction, сроки хранения, role-based access и возможность отключить content logging для отдельных проектов.
8. Как разделяются команды и клиенты?
Один master key быстро превращается в проблему. Нужны virtual keys или отдельные ключи проекта, бюджеты, Rate Limits и теги клиента. Тогда утечку можно локализовать, а счёт — распределить.
9. Что произойдёт при обновлении alias?
Имя latest удобно, пока новая версия не меняет стиль JSON, Tool Calling или длину ответа. Production-route должен использовать фиксированный snapshot либо управляемый rollout с shadow traffic.
10. Как gateway работает с native API?
Универсальный OpenAI-compatible слой удобен, но модели развиваются несимметрично. Anthropic Messages, Gemini media, provider-specific caching и Responses API могут давать ценность, которую минимальный общий интерфейс скрывает.
Зрелая архитектура допускает два пути: общий контракт для большинства задач и native adapter для функций, создающих реальное преимущество.
11. Можно ли уйти без переписывания продукта?
Gateway уменьшает vendor lock-in только при наличии собственного адаптера и независимых тестов. Если бизнес-логика зависит от уникальных заголовков, логов и router rules конкретного сервиса, зависимость просто перемещается с модели на gateway.
12. Кто отвечает за policy?
Платформа может предложить guardrails, но только команда знает, можно ли отправлять договор конкретному provider или выполнять Tool без подтверждения. Policy должна храниться как версия конфигурации и проходить review вместе с кодом.
Как выглядит решение после ревью
Область | Архитектурное решение |
API | Собственный минимальный контракт плюс adapters для native-функций |
Routing | Правила приложения задают ограничения; gateway выбирает только допустимый route |
Security | Project keys, redaction, ограниченное хранение и audit |
Reliability | Contract-tested fallback и идемпотентные retries |
Cost | Учёт по задаче, клиенту и успешному результату |
Где здесь OdiRouter
OdiRouter подходит на роль единого OpenAI-compatible gateway для русскоязычной команды, которой нужен доступ к нескольким семействам моделей через один API-контур. Его разумно оценивать не по количеству логотипов в каталоге, а по тому, как он проходит эти двенадцать вопросов на вашем workload.
Финальное решение
Gateway стоит внедрять не потому, что моделей стало много. Его внедряют, когда стоимость прямых интеграций, разрозненных ключей и непрозрачных retries стала выше стоимости одного управляемого слоя. Хороший OpenAI-compatible API gateway не скрывает различия моделей — он делает эти различия контролируемыми.