Envoy AI Gateway v0.7.0: Маршрутизация по имени хоста для мультиарендной среды и что это значит для операторов AI-инфраструктуры

Релиз Envoy AI Gateway v0.7.0, опубликованный 6 июня 2026 г., преодолевает важный порог для команд, работающих с общей AI-инфраструктурой: в нём появилась маршрутизация по имени хоста для изоляции каталога моделей — возможность обслуживать разные наборы моделей для разных арендаторов через единый шлюз без запуска отдельных экземпляров gateway. Этот выбор архитектуры, а также трансляция протоколов Anthropic → Bedrock и начальная поддержка квота-ориентированной маршрутизации, задают паттерны мультиарендной AI-маршрутизации, которые инженерным командам предстоит внедрять всё чаще.

Что произошло

Envoy AI Gateway v0.7.0 включает следующие изменения, значимые для операторов:

• Маршрутизация по именам хостов в AIGatewayRoute: назначьте имена хостов каждому маршруту, и endpoint /v1/models автоматически вернёт только те модели, которые видит конкретный арендатор. teamA.ai.example.com получает свой одобренный набор моделей, teamB.ai.example.com — другой, и всё это через единый gateway. Поддерживаются wildcard-хосты (*.ai.example.com) по правилам Gateway API.
• Трансляция Anthropic /v1/messages → AWS Bedrock Converse API: клиенты, использующие протокол Anthropic Messages, могут обращаться к моделям на Bedrock без смены SDK. Трансляция охватывает текст, изображения, tool use, thinking blocks и потоковую передачу — включая поля reasoning_content и многоходовые последовательности с tool calls, требующие сохранения CoT-контента.
• Квота-ориентированное ограничение трафика на backend (QuotaPolicy): при привязке QuotaPolicy к AIServiceBackend контроллер инжектирует backend rate limit filter. Это первый шаг к квота-ориентированной маршрутизации — троттлинг по запросам к отдельному backend на основе квот провайдера; полноценная маршрутизация с учётом квот по нескольким backend запланирована в будущих релизах.
• Авторизационная фильтрация tools/list в MCP: MCP-маршрут теперь применяет к tools/list те же правила авторизации, что и к tools/call. Неавторизованные вызывающие не смогут перечислять названия инструментов — это исключает утечку данных о возможностях и расход токенов LLM на инструменты, которые всё равно вернут ошибку.
• Azure OpenAI Responses API: endpoint /v1/responses теперь маршрутизирует запросы на backend Azure OpenAI, транслируя их в путь Azure /openai/responses?api-version=... без изменений на стороне клиента.
• Типы контента audio_url и video_url: запросы к chat completion теперь принимают части с audio_url и video_url, открывая мультимодальный ввод аудио и видео для совместимых backend-систем — таких как vLLM с phi-4-mm и Qwen 3.5.

Почему это важно для AI-инженерных команд

Маршрутизация по именам хостов решает реальную операционную проблему: команды, управляющие общей AI-инфраструктурой, исторически стояли перед бинарным выбором — отдельный шлюз на каждого арендатора (высокие эксплуатационные издержки) или единый шлюз без изоляции каталога (все модели видны всем арендаторам). v0.7.0 предлагает третий вариант: один ресурс Gateway, несколько AIGatewayRoute с привязкой к именам хостов и автоматическое ограничение области /v1/models для каждого арендатора.

Последствия для platform-команд существенны. Управление видимостью моделей для арендаторов прежде осуществлялось на прикладном уровне — через фильтрацию в коде приложения или в отдельном слое политик. Маршрутизация по имени хоста перемещает этот контроль в сам шлюз. Команда, добавившая новую модель не в тот маршрут, получит чёткий 404 от /v1/models — а не runtime-ошибку, обнаруженную уже после деплоя.

Трансляция Anthropic → Bedrock важна, поскольку enterprise-команды нередко фиксируют Bedrock как облачного провайдера по требованиям комплаенса, но предпочитают Anthropic Messages SDK за удобство для разработчиков. Раньше для перевода между этими двумя протоколами требовался кастомный middleware. v0.7.0 делает это первоклассным примитивом шлюза, включая thinking blocks и многоходовые последовательности reasoning — именно те граничные случаи, на которых ломаются самописные транслятор.

Угол зрения оператора

Три паттерна из v0.7.0 заслуживают выделения в качестве принципов проектирования любого AI-шлюза:

1. Область видимости каталога моделей относится к слою маршрутизации, а не прикладному уровню. Фильтрация /v1/models по именам хостов перемещает применение политики ближе к провайдеру. Это та же логика, что стоит за принудительным применением ограничений Gemini API Key на уровне edge: контроль на шлюзе надёжнее, чем политики на уровне приложения.

2. Трансляция протоколов — это примитив маршрутизации. Трансляция Anthropic→Bedrock в v0.7.0 дополняет существующие пути OpenAI→Bedrock и Anthropic→OpenAI, формируя матрицу трансляций. Практический эффект: команды могут стандартизироваться на одном клиентском SDK, маршрутизируя запросы на гетерогенные backend-системы без поддержки отдельных SDK для каждого провайдера. Это снижает стоимость добавления или замены провайдера — ключевое свойство надёжности маршрутизации.

3. Квота-осведомлённость — следующий рубеж политики маршрутизации. Инжекция backend rate limit filter в v0.7.0 явно обозначена как первый шаг. Полноценная квота-ориентированная маршрутизация — динамический выбор backend на основе остатка квоты провайдера — требует знания оставшегося бюджета каждого провайдера на момент запроса. Операторы, строящие системы на Envoy AI Gateway, должны проектировать CRD QuotaPolicy уже сейчас, а не когда квоты upstream-провайдеров начнут троттлить production-трафик.

Для MCP-деплойментов: авторизационная фильтрация tools/list — значимая граница безопасности. Предоставление неавторизованным вызывающим полного каталога инструментов создаёт риск утечки информации: вызывающий может перечислить инструменты и разработать prompt injection-атаки на основе известных сигнатур — даже не вызывая их успешно. Исправление в v0.7.0 прямолинейно, но легко упускается в самостоятельно развёртываемых MCP.

На что обратить внимание пользователям TheRouter

Паттерны Envoy AI Gateway v0.7.0 напрямую соответствуют вопросам, которые решают слои маршрутизации и управления TheRouter: какие модели видны каким командам, как обрабатывать гетерогенность протоколов провайдеров и как управлять бюджетами квот для каждого backend.

Командам, оценивающим AI-инфраструктуру, стоит использовать выход v0.7.0 как точку для аудита своей экспозиции каталога моделей: контролирует ли текущий слой маршрутизации, какие модели разные арендаторы или сервисные аккаунты могут обнаружить, или только то, какие они могут успешно вызвать? Это разные средства контроля с разными моделями отказов.

Просмотрите конфигурацию маршрутизации в /docs/ и проверьте, реализована ли у вас изоляция каталога моделей на уровне арендатора.