Un router de modelos en GCP: una API gobernada delante de varios LLM abiertos
Un diseño para desacoplar las aplicaciones empresariales de LLM concretos: tareas lógicas, selección de modelo por restricciones, cadenas de respaldo, vLLM y una API estable al estilo OpenAI en GCP.
La mayoría de los proyectos de LLM en empresas empiezan con una pregunta: ¿a qué modelo debe llamar la aplicación? En cuanto una organización ejecuta varios modelos, esa pregunta se convierte en un problema. Los modelos difieren en puntos fuertes, latencia, necesidad de recursos y disponibilidad. Fijar un modelo en el código de cada aplicación consumidora lleva esas decisiones a la capa equivocada del sistema.
Una regla más limpia es esta: las aplicaciones piden una capacidad de IA y la infraestructura de IA decide qué modelo la ejecuta. En un diseño construido para la integración Open LLM de Workato en GCP, un router de modelos se sitúa delante de cuatro modelos de pesos abiertos y los expone a través de una única API gobernada. El router acabó siendo una pieza más interesante que el propio despliegue de los modelos.
De integrar modelos a abstraerlos
El montaje convencional es una línea directa:
Application
│
▼
Specific LLM
Añade más modelos y se fragmenta en un cableado por aplicación:
Application A ──► Model A
Application B ──► Model B
Application C ──► Model C
Ahora cada aplicación tiene que conocer nombres de modelos, endpoints, autenticación, capacidades, disponibilidad, modelos de respaldo y probablemente parámetros de inferencia. La forma mejor invierte la relación:
┌──► Model A
│
Enterprise ├──► Model B
Application ─► Router
├──► Model C
│
└──► Model D
Desde el lado de la aplicación hay un único servicio de IA. Solo el router sabe que detrás hay toda una cartera de modelos. Todo lo demás del diseño cuelga de esa línea divisoria.
La arquitectura general
Desde fuera, el esquema sigue siendo sencillo:
Enterprise Consumers
│
Workato / Applications
│
▼
GCP API Gateway
│
▼
Model Router
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
Model A Model B Model C Model D
│ │ │ │
└─────────┴─────────┴─────────┘
│
GPU Inference
Debajo están GCP, la inferencia en contenedores y vLLM. Importan para la operación, pero no son lo que hace interesante el diseño. Lo que le da valor es el paso de enrutado situado entre el contrato público de la API y los motores que hacen la inferencia.
Qué hace de verdad el router
Un router es más que un proxy inverso. Un proxy decide adónde va una petición HTTP. El router de modelos decide qué modelo debe ejecutar una carga de trabajo de IA. Cada petición pasa por cuatro etapas:
Request
│
▼
1. Validation
│
▼
2. Workload classification
│
▼
3. Candidate model selection
│
▼
4. Execution + fallback
│
▼
Normalized response
Gracias a esto, los clientes no tienen que nombrar un despliegue físico. En vez de un payload como este:
{
"model": "physical-model-name",
"prompt": "..."
}
el contrato público puede describir una capacidad lógica:
{
"task": "general_generation",
"messages": [...]
}
Dentro de la plataforma, esa capacidad se resuelve en el modelo que resulte elegido:
general_generation
│
▼
Router
/ | \
▼ ▼ ▼
M1 M2 M3
│
▼
selected model
Los nombres de los modelos pasan a ser un detalle de infraestructura y dejan de ser asunto de la aplicación.
La selección es un problema de restricciones
El round-robin no sirve para esto, porque los LLM no son copias intercambiables de un mismo servicio. La primera etapa es la elegibilidad. De todos los modelos desplegados, el router obtiene el subconjunto que puede atender legítimamente la petición, según factores como:
- si el modelo está activo
- si admite la tarea solicitada
- la longitud de contexto necesaria
- la capacidad libre de la infraestructura
- el carácter de la carga de trabajo
Solo después empieza la clasificación. Una función de puntuación general combina la idoneidad esperada para la tarea, la latencia esperada, el coste de inferencia o la presión sobre recursos y la disponibilidad actual, cada una multiplicada por un peso que expresa su importancia. Los coeficientes concretos son cuestión de la política de implementación. Lo que importa en la arquitectura es que la elección de modelo se convierte en política explícita y deja de ser un accidente de la configuración de la aplicación.
Un ejemplo con cuatro modelos
Imagina cuatro modelos con tareas distintas:
Model A → general-purpose generation
Model B → stronger reasoning workload
Model C → lightweight / low-latency requests
Model D → alternate or fallback capability
Una petición corta de clasificación o transformación no necesita el modelo más grande:
Short deterministic task
│
▼
Router
│
▼
Lightweight model
Una petición más difícil toma otra ruta:
Complex reasoning task
│
▼
Router
│
▼
Higher-capability model
Esto también evita un antipatrón conocido: usar el modelo más caro para todo solo porque existe.
El respaldo pertenece al router
La selección le da al manejo de fallos un lugar natural. Supongamos que la ruta preferida es:
Request
│
▼
Model B
Si ese modelo no está sano, está sobrecargado o ha desaparecido, el servicio no tiene por qué rendirse de inmediato. La tabla de enrutado puede definir una cadena de alternativas:
Preferred
│
▼
Model B
│
failure
▼
Model A
│
failure
▼
Model D
El router puede entonces distinguir dos situaciones:
MODEL failure
y
AI SERVICE failure
No son lo mismo, y tratarlas de forma distinta compensa con modelos abiertos, donde se prueban nuevos runtimes o versiones y nada de esa inestabilidad debería llegar a los usuarios de la empresa.
Un contrato estable sobre modelos cambiantes
La propiedad más valiosa es lo que permanece fijo. Desde el punto de vista de Workato, este endpoint no cambia nunca:
POST /v1/chat/completions
Detrás, el panorama evoluciona con el tiempo. Al principio:
Today
y luego una progresión como esta:
Router ──► Model A
LaterRouter ──► Model B
Later stillRouter ──► Models A/B/C/D
selected dynamically
El flujo de negocio no cambia en absoluto. Eso es desacoplamiento en la práctica. El equipo de IA tiene libertad para cambiar versiones de modelos, ajustes del runtime, asignación de GPU, reglas de enrutado, prioridades de respaldo o incluso toda la familia de modelos sin tocar un solo flujo de la empresa.
Por qué una interfaz compatible con OpenAI
La capa de inferencia usa vLLM, que expone una interfaz HTTP compatible con OpenAI. La ventaja no es depender de OpenAI. Esa forma de API simplemente se ha convertido en un estándar práctico de interoperabilidad. El flujo es así:
Client
│
│ standard request
▼
Router
│
│ model-specific decision
▼
Inference runtime
│
▼
Open model
Las respuestas también pueden normalizarse a la vuelta. Así, el router aísla dos tipos de cambio:
Northbound
Stable enterprise API
──────── Router boundary ────────Southbound
Changing models and runtimes
Es el mismo trabajo que hace una capa de abstracción en otras partes de los sistemas distribuidos.
Una capa de GCP aburrida a propósito
La infraestructura de soporte es convencional a propósito:
Workato
│
▼
API Gateway
│
▼
Containerized Router
│
▼
vLLM inference
│
▼
Open-weight models
Los artefactos de los modelos pueden vivir en Cloud Storage y montarse en el entorno de inferencia, así que no quedan incrustados en las imágenes de la aplicación. API Gateway marca la frontera externa. Para una prueba de concepto basta con autenticación por API key para demostrar el camino de integración. Las cargas de producción con datos sensibles piden más: controles de identidad reales, servicios autenticados, red privada, cuotas, logs centralizados y un almacén de secretos como es debido.
El objetivo no es inventar un nuevo patrón de despliegue en GPU. Es mantener reemplazable todo lo que hay bajo la abstracción de enrutado.
Workato como consumidor, no como runtime
Esto cambia de qué se encarga Workato. Debe entender el flujo de negocio:
business event
↓
business workflow
↓
AI capability request
No debería tener que preocuparse por nada de lo siguiente:
GPU
model checkpoint
vLLM process
context limits
model health
fallback order
routing policy
Eso corresponde a la plataforma de IA. La integración se reduce a una llamada sencilla:
Workato Recipe
│
▼
HTTP request
│
▼
Governed AI API
Otros consumidores pueden usar el mismo patrón:
┌── Workato
│
AI Gateway ◄────────┼── Copilot / Agent
│
├── Web application
│
└── Internal service
Así, una sola cartera de modelos sirve a muchas plataformas sin una nueva integración de inferencia para cada una.
Hacia un plano de control interno de IA
Un proyecto que empezó como forma de enlazar la automatización empresarial con modelos abiertos apunta a algo mayor:
Enterprise Layer
│
┌────────────────┼────────────────┐
│ │ │
Workato Agents Applications
│ │ │
└────────────────┼────────────────┘
│
▼
AI API Gateway
│
▼
Model Router
│
┌────────────┼────────────┐
▼ ▼ ▼
Model A Model B Model C Model D
El router es el comienzo de un plano de control de IA. Más adelante, la política podría añadir clasificación de cargas, latencia, salud de los modelos, capacidad, adecuación a la tarea, coste, requisitos de privacidad, puntuaciones de evaluación y, con el tiempo, reglas por tenant. Los consumidores quedan protegidos de todo ello.
La lección que destaca
La pregunta inicial era cómo conectar un LLM abierto a Workato. Tras construirlo, resultó ser el nivel de abstracción equivocado. Uno mejor es cómo pueden las aplicaciones empresariales usar IA sin quedar acopladas a modelos concretos. La respuesta es una combinación:
Stable API
+
Model Router
+
Explicit Selection Policy
+
Multiple Open Models
+
Fallback
Cada modelo se convierte en infraestructura reemplazable, y para la arquitectura de IA empresarial eso puede importar más que qué modelo se elija.