Redes para la entrega de modelos de inferencia de IA en todos los backends

Last reviewed 2026-05-20 UTC

En este documento, se proporciona una arquitectura de referencia para crear un frontend unificado para varios modelos de IA alojados de forma local o por cualquier proveedor, incluidos terceros y Google Cloud. Si todos tus servidores de inferencia están alojados en Google Kubernetes Engine (GKE), consulta Redes para la entrega de modelos de inferencia de IA en GKE.

Esta arquitectura está diseñada para permitir que tus desarrolladores seleccionen modelos sin tener que especificar direcciones IP individuales para cada uno. En su lugar, los desarrolladores envían solicitudes a la API de OpenAI que incluyen el nombre del modelo al extremo de frontend. El sistema de la arquitectura enruta las solicitudes al backend que aloja el modelo especificado. El balanceador de cargas de frontend en la arquitectura proporciona las siguientes funciones administrativas centralizadas:

  • Un solo extremo de frontend para todas las llamadas al modelo, independientemente de cómo los alojes.
  • Funcionalidad de administración de APIs
  • Es un punto de control para las protecciones basadas en IA.
  • Punto de inserción de Service Extensions para la extensibilidad futura.

Este documento está dirigido a los administradores de red y de aplicaciones de IA generativa que deseen colocar modelos de IA generativa nuevos o existentes detrás de un solo extremo de inferencia. En este documento, no se proporciona guía sobre cómo diseñar una aplicación ni implementar un modelo de IA generativa individual. Para obtener orientación sobre cómo implementar un modelo, consulta Crea e implementa modelos de IA generativa y aprendizaje automático en una empresa. Esta arquitectura funciona con arquitecturas de redes de aplicaciones, como Red Multinube para aplicaciones distribuidas, y con otros diseños.

Arquitectura

En el siguiente diagrama, se muestra una arquitectura con un extremo en una red de consumidores que apunta a un frontend regional interno del balanceador de cargas de aplicaciones. Este balanceador de cargas usa el nombre del modelo especificado para enrutar las solicitudes a los conjuntos de réplicas del modelo que se alojan de forma local o por cualquier proveedor. El balanceador de cargas de frontend proporciona servicios consolidados para todos los modelos alojados.

Descripción general de alto nivel de las redes para la inferencia de IA.

La arquitectura del diagrama incluye los siguientes componentes:

  • Extremo de inferencia de Private Service Connect: Es un extremo unificado para todos los modelos alojados. El usuario final envía solicitudes de inferencia a la dirección IP del extremo. En el diagrama, se muestra un extremo de Private Service Connect en una sola red de nube privada virtual (VPC) del consumidor. Puedes alojar extremos en varias redes de VPC o en una red de VPC de servicios compartidos.
  • Balanceador de cargas de aplicaciones interno regional: En esta arquitectura, el balanceador de cargas de frontend es un balanceador de cargas de aplicaciones interno regional. El balanceador de cargas de frontend enruta el tráfico a los grupos de réplicas según el nombre del modelo especificado en la solicitud. En esta arquitectura, la aplicación del cliente realiza llamadas a la API de OpenAI al balanceador de cargas. Si el servidor de inferencia de backend es compatible con la API de OpenAI, todo funcionará de forma transparente. Si el servidor de inferencia no es compatible con la API de OpenAI, debes implementar un traductor de API con Extensiones de servicio. Esta arquitectura de referencia no incluye la implementación de un traductor de API.
  • Service Extensions callouts: Puedes usar texto destacado para agregar procesamiento adicional a un balanceador de cargas de aplicaciones. La arquitectura de este diseño usa las siguientes leyendas:
    • Enrutador basado en el cuerpo: El enrutador basado en el cuerpo se implementa en Cloud Run. Lee el nombre del modelo del cuerpo de la solicitud a la API de OpenAI y lo escribe en un campo X-Gateway-Model-Name del encabezado. El mapa de URL del balanceador de cargas usa el campo para reenviar la solicitud al servicio de backend adecuado. La implementación de Terraform que se proporciona con esta arquitectura de referencia incluye la configuración del router basada en el cuerpo.
    • Apigee: Es un administrador de APIs que proporciona autenticación, seguridad, límite de frecuencia, seguimiento de cuotas y otros servicios de administración de APIs. Esta arquitectura usa Apigee, pero admite otras opciones. Para llamar a Apigee desde el balanceador de cargas, la arquitectura y la implementación de Terraform usan una extensión de tráfico de Service Extensions para llamar al Procesador de extensiones de Apigee.
    • Model Armor: Es un sistema de protecciones de IA que realiza verificaciones de seguridad en las instrucciones de inferencia antes de que lleguen al servidor de inferencia. Luego, realiza verificaciones de seguridad en las respuestas salientes. Esta arquitectura usa Model Armor para los rieles de protección de IA, pero también admite otras opciones, como los rieles de protección de NVIDIA NeMo. La implementación de Terraform que se proporciona con esta arquitectura de referencia incluye una configuración básica de Model Armor.
  • Servicios de backend: El balanceador de cargas enruta las solicitudes a los servicios de backend según el nombre del modelo en la solicitud. El servicio de backend contiene un grupo de extremos de red (NEG).
  • Conjuntos de réplicas del modelo: Una réplica del modelo es una copia de un servidor de inferencia que se implementa en una o más GPU o TPU. Una réplica del modelo puede ser de un solo nodo o de varios nodos. Un conjunto de réplicas es un grupo uniforme de réplicas del modelo que se encuentra frente a un balanceador de cargas. En la arquitectura, las réplicas del modelo se encuentran en un clúster de Google Kubernetes Engine (GKE) detrás de una puerta de enlace de inferencia de GKE, en Vertex AI, en Cloud Run, en un centro de datos local o de otra nube, y detrás de un extremo en Internet.

Configuraciones del conjunto de réplicas del modelo

En la arquitectura, el balanceador de cargas de frontend dirige el tráfico a un servicio de backend en particular según el nombre del modelo. Los servidores de inferencia del modelo especificado se pueden alojar en una de las configuraciones que se describen en la siguiente tabla.

Tipo de conjunto de réplicas Descripción Balanceo de cargas de réplicas
Vertex AI Las réplicas del modelo se ejecutan en Vertex AI. Publicas un extremo de Vertex AI como un grupo de extremos de red (NEG) de Private Service Connect. El balanceador de cargas de frontend usa NEG de Private Service Connect como backends para cada modelo distinto, y cada modelo se estructura como un servicio de backend. Vertex AI se ajusta y balancea la carga de forma interna. Vertex AI realiza un balanceo de cargas ponderado basado en métricas y un enrutamiento basado en la caché de prefijos, lo que optimiza el uso de recursos y acelera la inferencia. Para obtener más información, consulta Implementa un modelo en un extremo.
GKE Los servidores de inferencia se ejecutan como Pods en un clúster de GKE en la red de VPC del conjunto de réplicas de GKE. Varias réplicas del modelo dentro de GKE forman colectivamente un backend singular detrás de una puerta de enlace de inferencia. La puerta de enlace de inferencia publica un extremo de Private Service Connect al que el balanceador de cargas de frontend accede con un NEG de Private Service Connect. La puerta de enlace de inferencia proporciona un balanceo de cargas con reconocimiento de modelos para los backends de inferencia en un clúster de GKE. La puerta de enlace de inferencia usa la coincidencia de prefijo cuando corresponde. Si no hay una coincidencia de prefijo, Inference Gateway distribuye las solicitudes según las métricas de GPU o TPU. Esta configuración admite el ajuste de escala automático horizontal de Pods.
Cloud Run Los servidores de inferencia se ejecutan en Cloud Run. Cloud Run publica un extremo al que accede el balanceador de cargas de frontend con un NEG sin servidores. Cloud Run ajusta automáticamente la escala de la cantidad de réplicas según el tráfico. Solo se limita a réplicas de un solo nodo.
Híbrido Los servidores de inferencia se ejecutan de forma local o en otra nube. Configuras un balanceador de cargas de red de proxy interno regional en una red de VPC de enrutamiento. Este balanceador de cargas publica un extremo de Private Service Connect al que el balanceador de cargas de frontend accede con un NEG de Private Service Connect. A su vez, el balanceador de cargas interno de la red de VPC de enrutamiento tiene un backend del NEG híbrido que apunta a la dirección IP de un balanceador de cargas local o de otra nube frente a los servidores de inferencia locales. Los administradores de la instalación externa configuran el mecanismo de balanceo de cargas del balanceador de cargas externo.
Internet Servidores de inferencia a los que se puede acceder desde direcciones IP de Internet públicas. El balanceador de cargas de frontend tiene un backend de NEG de Internet que apunta a la dirección IP de un modelo alojado en Internet. El proveedor de servicios administrados se encarga del escalamiento.

Flujo de solicitud

El sistema enruta las solicitudes de inferencia de la siguiente manera:

  1. Un usuario final envía una solicitud a la API de OpenAI al extremo de Private Service Connect. Esta solicitud contiene lo siguiente:
    • Es la instrucción.
    • Nombre del modelo, que debe coincidir con el nombre del modelo de uno de los servidores de inferencia alojados.
  2. El extremo de Private Service Connect reenvía la solicitud al balanceador de cargas de aplicaciones interno de frontend.
  3. El balanceador de cargas reenvía la solicitud a Service Extensions.
  4. El código de enrutamiento basado en el cuerpo de las Service Extensions lee el nombre del modelo del cuerpo de la solicitud y lo escribe en un encabezado X-Gateway-Model-Name.
  5. El balanceador de cargas usa la leyenda de la extensión de tráfico de Service Extensions para enviar la solicitud al sistema de administración de APIs para cualquier servicio de administración de APIs que se necesite.
  6. El balanceador de cargas usa una llamada de extensión de tráfico de Service Extensions para enviar el mensaje a Model Armor para su análisis.
    • Si la instrucción contiene información sensible que no se puede redactar, se bloqueará y Model Armor devolverá una respuesta para indicar que se encontró un incumplimiento de política.
    • Si la instrucción contiene información sensible que se puede ocultar o si no tiene problemas, Model Armor oculta la información sensible y reenvía la instrucción.
  7. Si Model Armor permite la solicitud, el balanceador de cargas consulta el mapa de URL y reenvía la solicitud a un servicio de backend según el encabezado personalizado del nombre del modelo. Si es necesario, el mapa de URL reescribe la URL y la ruta de acceso de la solicitud para que coincidan con lo que necesita el backend.
  8. El servicio de backend reenvía la solicitud a su balanceador de cargas de conjunto de réplicas asociado.
  9. El balanceador de cargas del servicio de inferencia específico asigna la solicitud a una de sus réplicas.
  10. La réplica procesa la solicitud y envía una respuesta.
  11. El balanceador de cargas de aplicaciones interno regional de frontend envía la respuesta a Model Armor para su análisis.
  12. El balanceador de cargas de aplicaciones envía la respuesta al extremo de Private Service Connect y, luego, al usuario final.

En el siguiente diagrama, se muestra una vista de enrutamiento de una implementación de muestra:

Flujo de instrucciones para muestrear conjuntos de réplicas.

En este ejemplo, las instrucciones se controlan según el modelo que selecciona el usuario:

  • Gemma: Todas las instrucciones se enrutan al conjunto de réplicas que aloja el modelo de Gemma.
  • Llama: El sistema balancea la carga de estas instrucciones de manera equitativa entre dos conjuntos de réplicas que alojan el modelo de Llama. Estos dos conjuntos de réplicas no tienen que alojarse de la misma manera. Por ejemplo, un conjunto de réplicas podría alojarse en Vertex AI y el otro, en GKE.
  • LoRA-1-gemma o LoRA-2-gemma: El sistema envía todas las instrucciones al mismo conjunto de réplicas, que puede controlar ambos modelos.

Productos usados

La arquitectura de referencia de este documento usa los siguientes productos de Google Cloud :

  • Cloud Load Balancing: Una cartera de balanceadores de cargas escalables, globales y regionales de alto rendimiento.
  • Nube privada virtual (VPC): Es un sistema virtual que proporciona funcionalidad de red global y escalable para tus cargas de trabajo de Google Cloud . La VPC incluye el intercambio de tráfico entre redes de VPC, Private Service Connect, el acceso privado a servicios y la VPC compartida.
  • Private Service Connect: Es una función que permite a los consumidores acceder a servicios administrados de forma privada desde su red de VPC.
  • Cloud Run es una plataforma de procesamiento administrada que te permite ejecutar contenedores directamente sobre la infraestructura escalable de Google.
  • Apigee: Es una herramienta de administración de APIs que te brinda un control detallado sobre cómo se accede a tus APIs y cómo se usan. Proporciona seguridad, límite de frecuencia, aplicación de cuotas y estadísticas.
  • Model Armor: Es un servicio que brinda protección a tus recursos de IA generativa y de agentes contra la inyección de instrucciones, las filtraciones de datos sensibles y el contenido dañino.

Alternativas de diseño

En esta sección, se describen alternativas a algunos de los supuestos básicos de esta arquitectura.

Protecciones de IA

Te recomendamos que uses Model Armor para los rieles de protección de la IA. Para centralizar la administración, te recomendamos que lo llames directamente desde el balanceador de cargas, como en esta arquitectura. También puedes implementar Model Armor de las siguientes maneras alternativas:

  • Usa una política de administración de APIs para llamar a Model Armor.
  • Implementa Model Armor solo en la réplica.

Si implementas medidas de protección de la IA en otro lugar que no sea el extremo del modelo, puedes desactivar Model Armor en el balanceador de cargas de frontend si no lo necesitas. Si no quieres usar Model Armor, puedes usar extensiones de tráfico para implementar otras ofertas de protección, como NVIDIA NeMo Guardrails.

Administración de API

La arquitectura de este documento usa Apigee para la administración de APIs, que se implementa con una extensión de servicio de balanceador de cargas. Si Apigee no satisface tus necesidades, puedes usar Service Extensions para implementar un servicio de administración de APIs diferente.

Si la implementación de la administración de APIs con Service Extensions no satisface tus necesidades, es posible que debas implementar una red orientada al cliente y una red orientada a la API. En esta situación, el servicio de administración de APIs actúa como un puente entre las dos redes. Para obtener información sobre cómo implementar esto en Apigee, consulta Opciones de redes de Apigee.

Conexión a otras redes

La arquitectura de este documento usa una sola red de VPC del consumidor. Sin embargo, puedes compartir el extremo de Private Service Connect con muchas otras redes usando una red de VPC de acceso a servicios en una implementación de Red Multinube.

Consideraciones del diseño

Cuando compiles la arquitectura para tu carga de trabajo, ten en cuenta las prácticas recomendadas y las recomendaciones del Google Cloud Well-Architected Framework.

Security, privacy, and compliance

  • Para agregar protección contra ataques de denegación de servicio distribuido (DSD), funcionalidad de firewall de aplicación web (WAF) y la inspección de direcciones IP a tu implementación, agrega Cloud Armor a tu balanceador de cargas de aplicaciones interno regional de frontend.
  • Para agregar una capa de autenticación común a todos los backends, implementa Identity-Aware Proxy (IAP) para verificar la identidad y aplicar políticas de autorización.
  • Cuando enrutes el tráfico de una aplicación web a un modelo de Vertex AI, debes elegir un modelo de identidad para la autenticación:
    • Identidad de la cuenta de servicio (recomendada para apps web generales): La aplicación autentica al usuario final a través de IAP, pero llama a Vertex AI con la identidad de la carga de trabajo de los servicios (como Cloud Run, GKE o con una identidad de terceros). Esta implementación abstrae Identity and Access Management (IAM) del usuario final, pero requiere el registro a nivel de la aplicación para hacer un seguimiento de qué usuario generó qué instrucción.
    • Transferencia directa de la identidad del usuario final (recomendada para una auditoría estricta): La aplicación captura el token de acceso de OAuth de Google del usuario final y lo pasa directamente a Vertex AI en el encabezado Authorization: Bearer. Esta implementación proporciona el registro integrado de los Registros de auditoría de Cloud de las acciones del usuario, pero requiere que cada usuario final se aprovisione con permisos de IAM de Google Cloud(como roles/aiplatform.user).

Confiabilidad

Para protegerte contra las fallas regionales, replica tu implementación en una segunda región con el arquetipo de implementación multirregional.Google Cloud

Eficiencia operativa

  • Para supervisar los flujos de tráfico y poder identificar y solucionar problemas rápidamente, usa los registros de Cloud Logging de tu balanceador de cargas de aplicaciones interno regional.
  • Para facilitar el descubrimiento de los modelos que admite tu organización, implementa una lista que se pueda consultar para devolver los modelos disponibles. Por ejemplo, puedes crear una lista en un servidor que responda a la llamada a la API de list models.

Optimización del rendimiento

Implementación

Para implementar una muestra de esta arquitectura, usa el muestra de código Networking for AI Inference Model Serving disponible en GitHub.

Para obtener información sobre cómo implementar modelos de IA, consulta los siguientes recursos:

¿Qué sigue?

Colaboradores

Autor: Victor Moreno | Gerente de producto, Herramientas de redes de Cloud

Otros colaboradores: