Descripción general del enrutamiento de modelos

El enrutamiento de modelos para API Gateway es una capa de administración de tráfico administrada que acepta solicitudes de instrucciones compatibles con OpenAI, las transcodifica en tránsito y las enruta a modelos específicos de Vertex AI. El enrutamiento de modelos actúa como una alternativa administrada a los proxies del cliente, como LiteLLM, y proporciona una infraestructura centralizada para administrar el ciclo de vida de los agentes de IA.

El enrutamiento de modelos mueve la lógica de enrutamiento al perímetro de la red y se integra con Vertex AI Model Garden para optimizaciones en el mismo host. Esta arquitectura elimina el requisito de alojar, escalar y mantener servidores proxy no administrados, lo que reduce los costos operativos y de infraestructura.

Alcance y recorridos del usuario

El enrutamiento de modelos admite los siguientes recorridos del usuario principales:

  • Selección de modelos: Un desarrollador de IA usa modelos abiertos de Model as a Service (MaaS) en Vertex AI Model Garden. Estos son modelos de las familias Gemini, Anthropic Claude o OpenAI GPT.
  • Creación de especificaciones: Un desarrollador de IA crea o actualiza una configuración de enrutador de modelos dentro de una especificación de OpenAPI 3.x para hacer referencia a los modelos implementados.
  • Implementación de la puerta de enlace: Un desarrollador de IA implementa una configuración de API y una instancia de API Gateway con la especificación de OpenAPI creada.
  • Enrutamiento de instrucciones: Las aplicaciones cliente envían solicitudes de instrucciones compatibles con OpenAI a la puerta de enlace, que enruta las solicitudes y traduce las cargas útiles según el nombre del modelo especificado en la carga útil de JSON.

Se planea que las versiones futuras de API Gateway admitan recorridos del usuario adicionales.

Beneficios del enrutamiento de modelos

La implementación del enrutamiento de modelos en API Gateway proporciona las siguientes ventajas:

  • Administración centralizada: Consolida la administración del tráfico de IA en una sola puerta de enlace administrada, lo que reemplaza las configuraciones de enrutamiento fragmentadas del cliente.
  • Reducción de la sobrecarga operativa: Elimina los costos de infraestructura y la carga de mantenimiento asociados con la implementación de servidores proxy independientes.
  • Rendimiento optimizado para el perímetro: Inspecciona las instrucciones y enruta el tráfico en el perímetro de la red, aprovechando la integración directa con los extremos de Vertex AI Model Garden.
  • Interfaz cliente estandarizada: Permite que las aplicaciones cliente interactúen con una interfaz REST uniforme compatible con OpenAI mientras envían solicitudes de forma dinámica a diversos modelos de base subyacentes.

Personas y casos de uso

El enrutamiento de modelos aborda los requisitos de las siguientes personas:

  • Ingenieros de plataformas: Proporciona una solución de infraestructura administrada para reemplazar la lógica de enrutamiento del cliente en las implementaciones de IA empresariales.
  • Desarrolladores de IA: Expón un extremo de API estandarizado que enrute solicitudes de forma dinámica entre diferentes modelos de base (como Gemini Pro, Gemini Flash o Anthropic Claude) según los parámetros de la carga útil de la solicitud.
  • Administradores de gobernanza: Aplica políticas de acceso centralizadas (como la autenticación y las cuotas) y supervisa el volumen general de tráfico de IA en una organización.

Casos prácticos compatibles

Durante la versión preliminar pública, el enrutamiento de modelos admite el enrutamiento basado exclusivamente en la etiqueta o el nombre del modelo (por ejemplo, "model": "gemini-3.5-flash-lite") especificado en la carga útil de JSON de las solicitudes del cliente compatibles con OpenAI.

Arquitectura y flujo de solicitudes

El enrutamiento de modelos funciona como una capa de enrutamiento administrada dentro del plano de datos de API Gateway. Cuando una aplicación cliente envía una solicitud de instrucción compatible con OpenAI a la puerta de enlace, se produce la siguiente secuencia:

  1. Intercepción de solicitudes: La puerta de enlace intercepta la solicitud POST entrante (por ejemplo, POST /chat/completions).
  2. Inspección de la carga útil: El enrutador de modelos inspecciona el atributo model dentro de la carga útil de JSON entrante (por ejemplo, {"model": "claude-opus-4-7", "messages": [...]}).
  3. Evaluación de reglas: El enrutador compara la cadena model con las reglas de enrutamiento definidas en tu especificación de OpenAPI. Si no coincide ninguna regla, el enrutador selecciona el modelo predeterminado configurado.
  4. Transcodificación en tránsito: La puerta de enlace transcodifica la solicitud compatible con OpenAI en el esquema de predicción de Vertex AI de destino.
  5. Envío de backend: La puerta de enlace envía la solicitud transcodificada al extremo designado de Vertex AI Model Garden y muestra la respuesta del modelo al cliente.

Rendimiento y limitaciones

Antes de implementar el enrutamiento de modelos, revisa las siguientes restricciones técnicas:

  • Restricciones de host: El enrutamiento de modelos solo admite el enrutamiento a modelos de MaaS implementados previamente alojados en Vertex AI Model Garden, en los que todos los modelos a los que hace referencia un solo enrutador comparten el mismo nombre de host (por ejemplo, el extremo global aiplatform.googleapis.com o un solo extremo regional como us-central1-aiplatform.googleapis.com).
  • Requisitos de especificación: El enrutamiento de modelos requiere una especificación de OpenAPI 3.x y las extensiones de OpenAPI 3.x de API Gateway correspondientes. No se admiten las especificaciones de OpenAPI 2.0 (Swagger).
  • Actualizaciones de la puerta de enlace: No puedes actualizar una puerta de enlace existente que se implementó sin enrutamiento de modelos para habilitar el enrutamiento de modelos, ni puedes actualizar una puerta de enlace implementada con enrutamiento de modelos para inhabilitar o quitar el enrutamiento de modelos. Para cambiar los modos de enrutamiento, debes crear e implementar una nueva configuración de API y una instancia de puerta de enlace.
  • Configuraciones mixtas: Una especificación de OpenAPI no puede contener una combinación de operaciones de enrutamiento de modelos y de no enrutamiento de modelos. Todas las operaciones de la especificación deben usar el enrutamiento de modelos o el enrutamiento de puerta de enlace estándar.
  • Controles del servicio de VPC: Las puertas de enlace de enrutamiento de modelos no admiten los Controles del servicio de VPC. No puedes usar perímetros de Controles del servicio de VPC con instancias de API Gateway que habiliten el enrutamiento de modelos.
  • Transmisión y protocolos no compatibles: El enrutamiento de modelos admite la transmisión de respuestas (eventos enviados por el servidor), pero no admite la transmisión del lado de la solicitud, gRPC, WebSockets ni Gemini Live.
  • Modalidades compatibles: Durante la versión preliminar pública, el enrutamiento de modelos asume solicitudes de instrucciones basadas en texto con formato de cargas útiles de JSON compatibles con OpenAI y rutas basadas exclusivamente en la etiqueta o el nombre model de la carga útil.
  • Campos de carga útil obligatorios: La carga útil de la solicitud de JSON entrante debe incluir un atributo model. Durante la versión preliminar pública, si falta el campo model en la carga útil de la solicitud del cliente, la puerta de enlace procesa la solicitud de forma incorrecta en lugar de rechazarla con un error. Asegúrate siempre de que las solicitudes del cliente especifiquen un campo model en la carga útil de JSON.
  • Limitaciones del entorno de ejecución: Los límites y comportamientos estándar del servicio de infraestructura de alojamiento de la puerta de enlace se aplican a tus extremos de enrutamiento de modelos:
    • Tiempo de espera máximo: La puerta de enlace aplica un tiempo de espera máximo de solicitud de 3,600 segundos (1 hora), que se aplica a las solicitudes de transmisión de larga duración.
    • Latencia de inicio en frío: Si tu instancia de puerta de enlace se reduce a cero durante los períodos de inactividad, la solicitud inicial puede experimentar latencia de inicio en frío, lo que puede afectar las rutas de inferencia de IA sensibles a la latencia.
    • Rutas de URL reservadas: No puedes usar rutas de URL reservadas, como /eventlog, rutas que comiencen con /_ah/ o ciertas rutas que terminen en z (para evitar conflictos, evita usar nombres de ruta que terminen en z).
    • Decodificación de caracteres de URL: La puerta de enlace decodifica automáticamente ciertos caracteres codificados en las URLs de solicitud antes de procesar la solicitud (por ejemplo, %41 se decodifica como A).

¿Qué sigue?