Маршрутизация для обслуживания моделей ИИ-инференса — только для GKE и для всех остальных бэкендов

Предприятия и отдельные разработчики часто используют несколько моделей AI-вывода. Правильная архитектура может упростить процесс обращения к моделям, обеспечивая при этом централизованное управление. В этой статье мы рассмотрим две эталонные архитектуры, ориентированные на сетевое взаимодействие при обслуживании моделей AI-вывода: одну для Google Kubernetes Engine (GKE) и одну для всех остальных типов бэкендов. Сначала мы изучим общие черты этих архитектур, которые вы увидите далее. Затем мы рассмотрим уникальные компоненты архитектуры для бэкендов GKE и, наконец, разберем элементы архитектуры для всех типов бэкендов.

Точка входа

Вы можете разместить развертывание своей модели за стабильной, безопасной и надежной точкой входа, которая выступает в качестве интерфейса для вызовов вывода. Эта точка входа также служит зоной контроля, где могут применяться политики, средства безопасности и логика. Как Cloud Load Balancer, так и Inference Gateway обеспечивают функциональность точки входа. Эти типы конечных точек могут завершать безопасные соединения с помощью TLS, интегрироваться с компонентами управления API, расширять функциональность с помощью расширений сервисов (service extensions) и использовать возможности Model Armor для дополнительной безопасности.

Общие сервисы в проектах

Оба эталонных проекта используют следующие сервисы:

• Конечная точка вывода Private Service Connect: закрепляет точку входа внутри вашей потребительской сети Virtual Private Cloud (VPC). Трафик поступает на частный внутренний IP-адрес, сохраняя вызовы вывода внутри вашей частной сети.

Конечная точка вывода Private Service Connect: закрепляет точку входа внутри вашей потребительской сети Virtual Private Cloud (VPC). Трафик поступает на частный внутренний IP-адрес, сохраняя вызовы вывода внутри вашей частной сети.

• Apigee API Management (опционально): интегрируется через вызов Apigee Extension Processor для проверки подлинности клиента, ограничения частоты запросов и соблюдения квот до того, как запросы достигнут вычислительных ресурсов.

Apigee API Management (опционально): интегрируется через вызов Apigee Extension Processor для проверки подлинности клиента, ограничения частоты запросов и соблюдения квот до того, как запросы достигнут вычислительных ресурсов.

• Model Armor: служит встроенной контрольной точкой безопасности AI, проверяя промпты и выходные данные на предмет инъекций промптов и утечки конфиденциальных данных.

Model Armor: служит встроенной контрольной точкой безопасности AI, проверяя промпты и выходные данные на предмет инъекций промптов и утечки конфиденциальных данных.

Шаблон проектирования только для GKE

Этот раздел посвящен дизайну бэкенда исключительно для GKE. Чтобы понять концепцию целиком, пожалуйста, прочитайте полный архитектурный документ «Сетевое взаимодействие для обслуживания моделей AI-вывода в GKE». Шаблон проектирования основан на этой схеме:

В дополнение к общим сервисам, указанным в предыдущем разделе, в дизайне для GKE используются следующие компоненты:

• GKE Inference Gateway: развертывается как внутренний балансировщик нагрузки приложений (gke-l7-rilb). Он действует как специализированный механизм входящего трафика, который анализирует полезную нагрузку входящих запросов, оценивает правила HTTPRoute и направляет запросы к соответствующим целям обслуживания моделей.

GKE Inference Gateway: развертывается как внутренний балансировщик нагрузки приложений (gke-l7-rilb). Он действует как специализированный механизм входящего трафика, который анализирует полезную нагрузку входящих запросов, оценивает правила HTTPRoute и направляет запросы к соответствующим целям обслуживания моделей.

• Пулы вывода (Inference pools): логическая группа, содержащая реплики одной и той же модели. Когда шлюз получает промпт, он оценивает правила HTTPRoute, чтобы выбрать соответствующий пул вывода на основе идентификатора модели. Пулы имеют начальный размер и могут быть настроены на динамическое автоматическое масштабирование.

Пулы вывода (Inference pools): логическая группа, содержащая реплики одной и той же модели. Когда шлюз получает промпт, он оценивает правила HTTPRoute, чтобы выбрать соответствующий пул вывода на основе идентификатора модели. Пулы имеют начальный размер и могут быть настроены на динамическое автоматическое масштабирование.

• Наборы реплик моделей (Model replica sets): отдельные реплики моделей (экземпляры сервера вывода), развернутые в одноузловых или многоузловых пулах узлов GPU или TPU. Набор реплик представляет собой унифицированную группу этих реплик моделей.

Наборы реплик моделей (Model replica sets): отдельные реплики моделей (экземпляры сервера вывода), развернутые в одноузловых или многоузловых пулах узлов GPU или TPU. Набор реплик представляет собой унифицированную группу этих реплик моделей.

Пример потока трафика в GKE

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

• Входящий трафик: клиентское приложение в потребительской VPC выполняет API-вызов, совместимый с OpenAI, к локальной конечной точке Private Service Connect, направляя его напрямую к GKE Inference Gateway с использованием регионального внутреннего балансировщика нагрузки приложений.

Входящий трафик: клиентское приложение в потребительской VPC выполняет API-вызов, совместимый с OpenAI, к локальной конечной точке Private Service Connect, направляя его напрямую к GKE Inference Gateway с использованием регионального внутреннего балансировщика нагрузки приложений.

• Проверка полезной нагрузки: шлюз считывает параметр целевой модели, указанный в теле запроса, и добавляет его в HTTP-заголовки.

Проверка полезной нагрузки: шлюз считывает параметр целевой модели, указанный в теле запроса, и добавляет его в HTTP-заголовки.

• Проверка плоскости управления: если используется Apigee, он проверяет учетные данные клиента и квоты. Model Armor проверяет промпт на предмет нарушений политики или утечки данных.

Проверка плоскости управления: если используется Apigee, он проверяет учетные данные клиента и квоты. Model Armor проверяет промпт на предмет нарушений политики или утечки данных.

• Выбор бэкенда: шлюз оценивает сопоставления HTTPRoute для определения целевого пула, сопоставляет контекст кэша общего префикса и направляет запрос к наименее загруженной реплике GPU или TPU на основе данных Prometheus в реальном времени.

Выбор бэкенда: шлюз оценивает сопоставления HTTPRoute для определения целевого пула, сопоставляет контекст кэша общего префикса и направляет запрос к наименее загруженной реплике GPU или TPU на основе данных Prometheus в реальном времени.

• Исходящий трафик: реплика выполняет рабочую нагрузку вывода. Выходные токены проходят через Model Armor для окончательной проверки ответа перед потоковой передачей обратно через частное соединение.

Исходящий трафик: реплика выполняет рабочую нагрузку вывода. Выходные токены проходят через Model Armor для окончательной проверки ответа перед потоковой передачей обратно через частное соединение.

Шаблон проектирования для всех бэкендов

Этот раздел посвящен нескольким типам бэкендов, которые могут использоваться для вывода, и содержит обзор архитектуры на следующей схеме. Чтобы понять концепцию целиком, пожалуйста, прочитайте полный архитектурный документ «Сетевое взаимодействие для обслуживания моделей AI-вывода на всех бэкендах».

Для архитектур, охватывающих смешанные среды, такие как GKE, Cloud Run, Agent Platform, локальные центры обработки данных или внешние облака, используются следующие дополнительные компоненты:

• Региональный внутренний балансировщик нагрузки приложений: служит центральным прокси-сервером маршрутизации уровня 7, который управляет логикой маршрутизации, завершением SSL и вызовами расширений сервисов (Service Extensions).

Региональный внутренний Application Load Balancer: служит центральным прокси-сервером маршрутизации уровня 7, который управляет логикой маршрутизации, завершением SSL и вызовами Service Extensions.

• Inference Payload Processor (Service Extensions): это аналогично маршрутизации на основе тела запроса, используемой в GKE Inference Gateway, но для включения этой функциональности в Application Load Balancer требуется расширение службы (service extension). Легковесный вызов Cloud Run проверяет JSON-тело входящих запросов OpenAI API, извлекает идентификатор целевой модели и записывает заголовок X-Gateway-Model-Name для управления маршрутизацией по карте URL.

Inference Payload Processor (Service Extensions): это аналогично маршрутизации на основе тела запроса, используемой в GKE Inference Gateway, но для включения этой функциональности в Application Load Balancer требуется расширение службы (service extension). Легковесный вызов Cloud Run проверяет JSON-тело входящих запросов OpenAI API, извлекает идентификатор целевой модели и записывает заголовок X-Gateway-Model-Name для управления маршрутизацией по карте URL.

• Network Endpoint Group (NEG): обеспечивает гибкую маршрутизацию к гетерогенным бэкендам на основе внедренного заголовка модели.

Network Endpoint Group (NEG): обеспечивает гибкую маршрутизацию к гетерогенным бэкендам на основе внедренного заголовка модели.

Пример потока трафика для всех бэкендов

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

• Частный вход (Private ingress): клиентское приложение обращается к конечной точке Private Service Connect через пространство частных IP-адресов. Региональный внутренний Application Load Balancer получает запрос.

Частный вход (Private ingress): клиентское приложение обращается к конечной точке Private Service Connect через пространство частных IP-адресов. Региональный внутренний Application Load Balancer получает запрос.

• Извлечение имени модели: балансировщик нагрузки отправляет полезную нагрузку в вызов маршрутизатора Cloud Run на основе тела запроса, который проверяет JSON-полезную нагрузку и внедряет заголовок X-Gateway-Model-Name.

Извлечение имени модели: балансировщик нагрузки отправляет полезную нагрузку в вызов маршрутизатора Cloud Run на основе тела запроса, который проверяет JSON-полезную нагрузку и внедряет заголовок X-Gateway-Model-Name.

• Применение политик и безопасности: запрос передается в Apigee для проверки идентификации и квот, а затем в Model Armor для очистки конфиденциальных данных и блокировки вредоносных промптов.

Применение политик и безопасности: запрос передается в Apigee для проверки идентификации и квот, а затем в Model Armor для очистки конфиденциальных данных и блокировки вредоносных промптов.

• Маршрутизация NEG: карта URL балансировщика нагрузки проверяет заголовок модели и пересылает запрос в соответствующий бэкенд NEG (Agent Platform, GKE, Cloud Run, Hybrid или Internet).

Маршрутизация NEG: карта URL балансировщика нагрузки проверяет заголовок модели и пересылает запрос в соответствующий бэкенд NEG (Agent Platform, GKE, Cloud Run, Hybrid или Internet).

• Частная доставка: целевой бэкенд выполняет промпт модели, Model Armor проверяет результат, и ответ возвращается в частном порядке по пути входящего трафика.

Частная доставка: целевой бэкенд выполняет промпт модели, Model Armor проверяет результат, и ответ возвращается в частном порядке по пути входящего трафика.

• Разработчики и специалисты
• Сети