Gateways de modelos

Cuando una organización pasa de un prototipo a varios equipos que usan LLMsLLM Large language model: red neuronal entrenada para predecir el siguiente token y ajustada para seguir instrucciones., aparecen los mismos problemas: llaves de proveedores copiadas en diez repositorios, gastos que nadie puede atribuir, un proveedor caído que tumba la aplicación y ningún registro central de qué se envió a quién. Cada equipo lo resuelve a su manera, o no lo resuelve.

Un model gateway centraliza ese tráfico. En esta lección veremos qué hace, en qué se diferencia de un router o de una librería cliente, qué ofrece el ecosistema y, sobre todo, dónde deja de ayudar. El caso de estudio es docket, que no es un gateway, sino un cliente que puede hablar con ellos.

Qué es un gateway

 app A ──┐                        ┌──> proveedor cerrado 1
 app B ──┼──> gateway ────────────┼──> proveedor cerrado 2
 agente ─┘    · llaves virtuales  ├──> hosting de pesos abiertos
              · presupuestos      └──> servidor propio (vLLM,
              · fallback/reintento        llama.cpp, Adapta)
              · rate limits
              · caché, logs, guardrails

Las aplicaciones conocen una sola URL y una llave emitida por el gateway. Las llaves reales de los proveedores viven solo en el gateway.

Qué suele ofrecer

La caché semánticaCaché semántica Caché que reutiliza una respuesta previa cuando un prompt nuevo es suficientemente similar según sus embeddings. reutiliza una respuesta cuando un promptPrompt Todo lo que se envía al modelo en una llamada: mensajes con rol y definiciones de herramientas. nuevo se parece lo suficiente, según sus embeddingsEmbedding Vector de números que representa el significado de un texto; vectores cercanos indican contenido similar., a uno anterior. Ahorra dinero, pero dos preguntas parecidas pueden necesitar respuestas distintas; úsala solo cuando la respuesta no dependa del usuario ni del momento.

Gateway, router o SDK

Tres piezas que se confunden:

Un SDK como el AI SDK de Vercel o la librería de LiteLLM unifica el código, pero no centraliza el control. Un router puede vivir dentro de un gateway: OpenRouter, por ejemplo, elige proveedor según disponibilidad y precio, con fallbacks activos por defecto. El routing por rol es una decisión de diseño que puedes tomar con o sin gateway.

docket frente a un gateway

docs/MODEL-GATEWAYS.md separa tres cosas: el harnessHarness Runtime alrededor del modelo que ejecuta el loop y las herramientas, prepara el contexto y aplica límites. de código que trabaja en el repositorio, la política de modelos de docket y el gateway que llama el loop de docket. Cambiar una no cambia las otras.

Lo que docket hace y no hace, según el código:

• Llaves: las resuelve por proveedor, en este orden: variable global, bloque del proveedor, variable de entorno y almacén central en ~/.docket/secrets.json (resolve_endpoint). No emite llaves virtuales ni tiene presupuestos por equipo: es software beta de un solo operador, sin tenants.
• Reintentos: 408, 409, 425, 429 y los 5xx habituales se consideran reintentables. El dispatcher reintenta cada hop hasta dos veces con espera lineal (config.py, dispatch.py), por encima de lo que haga el gateway, y todavía no respeta Retry-After.
• Fallback: no hay. Ningún pedido se degrada a un modelo más barato ante una falla.
• Opciones del gateway: no envía parámetros de routing de proveedor ni headers propios de cada gateway, y no descubre catálogos ni precios.
• Costo: registra los tokens medidos, incluidos los cacheados que el endpoint reporta (_decode_usage). Los modelos detrás de OpenRouter o Vercel quedan sin precio a propósito, porque el marketplace cambia precios por modelo y por cuenta.

Dónde deja de ayudar

Un gateway controla qué se envía a qué modelo. No controla qué hace tu sistema con la respuesta. Si el modelo pide borrar un directorio o transferir dinero, el gateway solo ve un JSON con un tool call. Esa decisión pertenece al runtime del agenteAgente Sistema en el que un modelo, dentro de un bucle, elige la siguiente acción hasta decidir que terminó o alcanzar una condición de parada.: políticas, aprobaciones y auditoría, que tratamos en Gobernanza y human-in-the-loop.

Otros límites:

• Latencia: un salto de red más, y más si agregas guardrails o caché semántica, que requieren sus propias llamadas.
• Punto único de falla: si el gateway cae, caen todos los modelos a la vez. Necesita la misma redundancia y monitoreo que cualquier componente crítico.
• Reintentos apilados: si el cliente reintenta y el gateway también, un error puede multiplicar las llamadas y el costo.
• Reproducibilidad: con fallback o balanceo, la misma llamada puede ir a otro modelo. Registra qué proveedor respondió.
• Residencia de datos: el gateway ve prompts y respuestas, y puede guardarlos. Revisa dónde procesa y retiene. OpenRouter, por ejemplo, permite restringir el routing a endpoints sin retención de datos y ofrece procesamiento dentro de una región solo a clientes enterprise.

Para CTOs

La pregunta no es "¿qué gateway?", sino qué quieres centralizar y quién lo opera.

• Con un solo equipo y un proveedor, un SDK y buenas prácticas de secretos pueden bastar.
• Con varios equipos, necesitas llaves por equipo, atribución de costo y un registro central: ahí un gateway se justifica.
• Si hay datos regulados, decide primero dónde pueden procesarse; eso descarta opciones antes de comparar funciones.
• No confundas control de acceso a modelos con gobernanza de agentes. Necesitas ambos, en capas distintas.

Fuentes

• LiteLLM Proxy
• OpenRouter: provider routing
• Vercel AI Gateway
• Cloudflare AI Gateway: visión general, endpoint compatible, guardrails
• Portkey AI Gateway
• Kong AI Gateway
• Envoy AI Gateway ahora es Agent Router
• Azure API Management: capacidades de AI gateway
• Hugging Face Inference Providers

Para llevar

• Un gateway es un proxy central con API unificada: el lugar para llaves, límites, caché y registros.
• Gateway, router y SDK resuelven problemas distintos; puedes combinarlos.
• Revisa qué cubre de verdad cada presupuesto, caché y fallback antes de confiar en ellos.
• docket es un cliente de gateways: un protocolo, reintentos propios, sin fallback y sin precios para modelos de marketplace.
• Un gateway no gobierna las acciones de un agente, suma latencia y es un punto único de falla.

Comprueba lo aprendido