Una docena de funciones de tu empresa llaman a tres proveedores de modelos. Cada equipo guarda su propia clave de API, nadie sabe qué equipo gastó qué el mes pasado y, cuando el proveedor principal devolvió errores 429 durante una hora, cada app falló de una manera distinta. Una cambió de modelo y rompió su salida JSON.
Un gateway LLM, también llamado gateway de IA o proxy LLM, hace pasar cada llamada a un modelo por un único servicio que se encarga de las claves, el enrutamiento y la medición. Este artículo recorre la ruta de la petición etapa por etapa y luego trata el enrutamiento, la caché, los límites de tokens, las métricas, la seguridad y los gateways que puedes adoptar.
Por qué poner un gateway delante de los proveedores de modelos
Los límites y las facturas de los proveedores no siguen tu organigrama. OpenAI fija los límites de tasa por organización y proyecto, no por usuario, y Anthropic por organización con límites opcionales por workspace. Un trabajo por lotes nocturno en el mismo proyecto que un chat de clientes puede agotar los tokens por minuto del chat. Un gateway te da un único lugar para claves, enrutamiento, límites por equipo y atribución de costes.
No sustituye a tu API gateway. Un API gateway cuenta peticiones; un gateway LLM cuenta tokens y dólares, entiende las respuestas en streaming y trata el 429 de un proveedor como motivo para probar otro modelo.
La ruta de la petición, etapa por etapa
Las comprobaciones baratas van primero: nada llega a un proveedor hasta que la petición está permitida y no ha sido respondida ya.
- Autenticar. Asocia la clave virtual con una app, un equipo y sus modelos permitidos, o devuelve 401.
- Comprobar límites. Compara los contadores de tokens y el presupuesto del equipo en Redis. Si se supera el límite, devuelve 429 con
Retry-After. - Aplicar la política. Aplica la lista de modelos permitidos y un tope de
max_tokens, y enmascara datos personales como las direcciones de correo. - Consultar la caché. Un acierto devuelve la respuesta guardada sin llamar al proveedor.
- Enrutar. Elige un modelo y una cadena ordenada de fallbacks.
- Llamar al adaptador. Traduce la petición a la API del proveedor, añade la clave del proveedor e inicia un timeout para el primer token.
- Reintentar o hacer fallback ante 429, 5xx, el error de sobrecarga 529 de Anthropic o un timeout, pero solo antes de que el primer token llegue a la app. Un proveedor puede enviar un error después de que un 200 haya iniciado el stream, y cambiar de modelo a mitad de respuesta une dos respuestas en una.
- Emitir y medir. Pasa los server-sent events tal cual y escribe un evento de uso de forma asíncrona. La API Chat Completions de OpenAI envía el uso en un último fragmento solo con
stream_options.include_usage, y un stream cortado lo pierde, así que sigue leyendo después de que el cliente se desconecte.
Los pasos 1 a 4 deberían ser consultas en memoria o en Redis; el registro y las evaluaciones quedan fuera de la ruta de la petición.
Estrategias de enrutamiento
| Estrategia | Cómo elige | Ojo con |
|---|---|---|
| Coste | El modelo más barato que supera tus evals | Requiere evals por función |
| Latencia | El menor tiempo reciente hasta el primer token | Ruido sin suavizado |
| Capacidad | Longitud de contexto, visión, uso de herramientas | Puede que el fallback no la tenga |
| Clase de datos | Los datos marcados solo a modelos aprobados | Una petición mal clasificada filtra datos |
| Cadena de fallbacks | El siguiente modelo ante errores y timeouts | Las respuestas difieren según el modelo |
| División A/B | 90/10, fijada por conversación | Juzga por evals, no por tasas de error |
El fallback más seguro es el mismo modelo en otro host, como un modelo Claude en la API de Anthropic y en Amazon Bedrock. Una familia de modelos distinta necesita sus propias evals, ya que las llamadas a herramientas y la salida JSON son lo primero que se rompe, y todo fallback necesita cuota de reserva.
Reintenta en una sola capa: el SDK de Python de OpenAI reintenta dos veces por defecto, y la documentación de LiteLLM advierte de que los reintentos apilados convierten una petición en (1 + N)² llamadas al proveedor. Deja descansar un despliegue que falla en lugar de martillearlo, como hace LiteLLM durante 5 segundos tras un 429 por defecto; el patrón circuit breaker lo generaliza.
Caché: exacta, semántica y del proveedor
| Coincidencia exacta | Semántica | Prompt caching del proveedor | |
|---|---|---|---|
| Se ejecuta en | El gateway, normalmente Redis | El gateway más un índice vectorial | El proveedor |
| Clave | Hash de la petición completa | Similitud de embeddings | Prefijo de prompt idéntico |
| Ahorra | La llamada entera | La llamada entera | Parte del coste de entrada y de la latencia |
| Riesgo | Pocos aciertos en chat | Respuesta errónea a una pregunta parecida | Cualquier cambio al principio la rompe |
La caché de coincidencia exacta es segura pero estrecha: Cloudflare AI Gateway calcula el hash del proveedor, el endpoint, el modelo, la cabecera de autenticación y el cuerpo completo, así que cualquier cambio es una entrada nueva. Pon el tenant en tu clave de caché, o la respuesta de un cliente puede llegar a otro. La caché semántica también reconoce paráfrasis, pero «cancelar mi pedido» y «cancelar mi suscripción» pueden quedar muy cerca, así que úsala solo donde un fallo cercano sea inofensivo.
La caché del proveedor suele ahorrar más. Anthropic cachea los prefijos marcados con cache_control durante 5 minutos, renovados en cada acierto, y las lecturas de caché cuestan 0,1 veces el precio base de entrada en la mayoría de los modelos. OpenAI cachea por defecto en los modelos compatibles, con entrada en caché hasta un 95 % más barata (en el momento de escribir esto, noviembre de 2026). Mantén los prompts de sistema idénticos byte a byte, sin marcas de tiempo al principio, redacta de forma determinista y fija una conversación a un solo despliegue, porque cada cuenta de proveedor tiene su propia caché.
Con un supuesto de 3 USD por millón de tokens de entrada, un prompt de sistema de 6 000 tokens más una pregunta de 500 tokens cuesta 0,0195 USD. Con el prefijo leído desde la caché, 6 000 × 0,30 USD/M + 500 × 3 USD/M = 0,0033 USD, un 83 % menos por acierto. El artículo sobre estrategias de caché trata la invalidación.
Límites de tokens y presupuestos por equipo
Las peticiones por minuto son un mal límite para el tráfico LLM: una petición puede llevar 50 tokens o 200 000. Limita los tokens por minuto por equipo, pon un tope a max_tokens y fija un presupuesto mensual en dólares. El tamaño de una petición no se conoce hasta que termina, así que elige un enfoque:
- Reservar y luego conciliar. Cuenta de antemano la entrada estimada más
max_tokensy corrige después. OpenAI cuenta el mayor entremax_tokensy una estimación basada en caracteres contra sus propios límites. - Contar sobre la marcha. Anthropic cuenta los tokens de salida a medida que se generan, y las lecturas de caché no cuentan para los tokens de entrada por minuto en la mayoría de los modelos.
- Contar después. Sencillo, pero las ráfagas se pasan del límite. Cloudflare dice que las peticiones concurrentes pueden superar brevemente sus límites de gasto.
Guarda los contadores en Redis, compartidos por todas las instancias del gateway; el diseño de un rate limiter trata los algoritmos y una caída de Redis. Valora el uso con una tabla de precios versionada, alerta al 80 % de un presupuesto y decide si el 100 % significa una parada total o un modelo más barato.
Qué medir
Registra el tiempo hasta el primer token por proveedor y modelo, los tokens de entrada, salida y en caché por equipo, el coste por equipo y función, los errores por tipo y las tasas de fallback y de aciertos de caché. Las convenciones de IA generativa de OpenTelemetry nombran atributos como gen_ai.usage.input_tokens, pero siguen en desarrollo, así que fija la versión que emites. El diagrama de arquitectura de observabilidad muestra adónde van las señales.
Seguridad: lo que un gateway no resuelve
Un gateway guarda todas las claves de los proveedores y ve todos los prompts, así que dale pocos administradores, cambios de configuración auditados y registros que conserven metadatos de cada llamada pero solo prompts muestreados, redactados y de corta vida.
Ayuda contra lo que el OWASP Top 10 para aplicaciones LLM llama consumo no acotado: los límites y presupuestos impiden que un agente en bucle o una clave filtrada disparen la factura. No resuelve la inyección de prompts; OWASP dice que no está claro que exista una prevención infalible, y las instrucciones ocultas en un documento recuperado parecen datos para un gateway. Las defensas son herramientas con privilegios mínimos, aprobaciones y un manejo estricto de la salida, como en el diagrama de arquitectura de un agente de IA.
Construir o adoptar
| Gateway | Qué es | Licencia y alojamiento |
|---|---|---|
| LiteLLM | Proxy en Python para más de 100 proveedores: claves virtuales, presupuestos, fallbacks | MIT más un nivel enterprise comercial; autoalojado |
| Agent Router | Antes Envoy AI Gateway, construido sobre Envoy Gateway | Apache 2.0; autoalojado |
| Portkey AI Gateway | Reintentos, fallbacks, balanceo de carga, guardarraíles | MIT; caché semántica solo alojada o enterprise |
| Kong AI Gateway | Políticas de IA para Kong Gateway | Konnect o autoalojado; la caché semántica y los límites de tokens requieren licencia enterprise |
| Cloudflare AI Gateway | Caché, límites de tasa, fallback, registros | Gestionado |
| Azure API Management | Límites de tokens, caché semántica, métricas de tokens | Gestionado |
Envoy AI Gateway se unió a la Agentic AI Foundation como Agent Router en septiembre de 2026. Construye solo lo que es específico de ti, como el enrutamiento por clase de datos; lo caro es mantener actualizados los adaptadores de proveedor. Un gateway gestionado pone a un tercero en la ruta de cada prompt; uno autoalojado convierte Redis, Postgres y las actualizaciones en trabajo tuyo.
El diagrama del gateway LLM
Contenido del diagrama
- LLM gateway
- Support chat
- Doc summarizer
- 1 Auth
- 2 Policy
- 3 Cache
- 4 Router
- 5 Adapters
- Postgres: keys, budgets
- Redis: counters, cache
- Self-hosted model
- OpenAI API
- Anthropic API
- Usage and cost log
- virtual key A
- virtual key B
- miss
- sensitive data
- primary
- fallback on 429/5xx
- key → team, limits
- token counters
- lookup by hash
- usage events (async)
Cómo leerlo:
- Dos apps llaman a un único endpoint con formato OpenAI con sus propias claves virtuales y sin clave de proveedor.
- Cinco etapas se ejecutan en orden, con una nota encima de cada una sobre lo que decide. Una petición puede detenerse en Auth (401, 429) o en un acierto de caché.
- Tres destinos: OpenAI como principal, Anthropic como fallback discontinuo ante 429 o 5xx, y un modelo vLLM autoalojado para datos sensibles.
- Debajo de las etapas: Postgres para claves y presupuestos, Redis para contadores y respuestas en caché, y el registro de uso, escrito de forma asíncrona.
- El bloque Markdown lista ajustes de ejemplo para un equipo.
Cómo dibujar con claridad diagramas de gateways LLM
- Dibuja etapas, no una sola caja. Un único rectángulo de gateway oculta si la redacción ocurre antes de la caché.
- Pon las condiciones en las aristas: «fallback on 429/5xx», «sensitive data», «miss».
- Marca dónde salen los datos de tu red, para que los proveedores externos se vean distintos del modelo autoalojado.
- Dibuja con líneas discontinuas los caminos asíncronos, como la medición y el registro.
- Deja fuera el catálogo de modelos; pertenece a la configuración.
Constrúyelo en Archboard
- Inicia sesión con Google o GitHub y crea un diagrama.
- Añade un Marco del pack Básico llamado LLM gateway.
- Dentro, añade cinco nodos Componente del pack C4 Model en fila: 1 Auth, 2 Policy, 3 Cache, 4 Router y 5 Adapters, con una nota Texto de Básico encima de cada uno.
- Debajo, añade Postgres y Redis del pack Datos y un Almacén de datos para el registro de uso y costes.
- A la izquierda del marco, añade dos nodos Contenedor del pack C4 Model para las apps; a la derecha, dos nodos Sistema externo para OpenAI API y Anthropic API y un Punto de conexión del pack ML para el modelo autoalojado.
- Dibuja aristas con etiqueta; usa línea discontinua para el fallback y los eventos de uso.
- Añade un bloque Markdown del pack Básico con los ajustes de ejemplo.
Si mantienes la ruta como un diagrama de flujo de Mermaid, el conversor de Mermaid lo convierte en un primer borrador editable. El ejemplo usa 15 nodos de diagrama, dentro del plan Free.
Preguntas frecuentes
¿Qué es un gateway LLM? Un servicio por el que pasa cada llamada a un modelo. Guarda las claves de los proveedores, enruta y hace fallback entre modelos, cachea, aplica límites de tokens y presupuestos, y registra el uso por equipo.
¿Cuál es la diferencia entre un gateway de IA y un API gateway? Un API gateway limita peticiones HTTP. Un gateway de IA también entiende tokens, streaming y errores de proveedor, así que puede limitar por tokens, atribuir costes y hacer fallback a otro modelo.
¿Cuál es la diferencia entre la caché semántica y el prompt caching? La caché semántica se ejecuta en tu gateway y devuelve una respuesta guardada para una pregunta parecida. El prompt caching se ejecuta en el proveedor y reutiliza un prefijo de prompt ya procesado; el modelo sigue escribiendo una respuesta nueva.
¿Cómo se limitan por tokens las peticiones a un LLM? Mantén un token bucket por equipo en Redis, reserva la entrada estimada más max_tokens antes de cada llamada, corrígela después y devuelve 429 con Retry-After al llegar al límite.
¿Puede un gateway LLM evitar la inyección de prompts? No. Puede filtrar ataques evidentes y limitar el daño con presupuestos, pero las instrucciones inyectadas en documentos parecen datos. Defiéndete en la aplicación con herramientas de privilegios mínimos y aprobaciones.