LLM Gateway en Producción: el Proxy que Escala Agentes IA
Tienes tres servicios llamando a la API de Anthropic. Uno para el agente de atención al cliente, otro para el clasificador de documentos, otro para el generador de informes. Cada uno tiene su propia API key, su propio manejo de errores, su propio timeout. Cuando Anthropic devuelve un 529 a las tres de la tarde, los tres fallan a la vez, de formas distintas, con logs distintos, y nadie sabe exactamente cuánto ha costado cada uno este mes.
Un LLM gateway evita exactamente eso. Es el proxy que se sienta entre tus servicios y los proveedores de LLM, centralizando lo que ahora tienes repartido en múltiples puntos del código.
Por qué las llamadas directas no escalan
La primera implementación siempre es la misma: llamas a anthropic.messages.create() desde donde lo necesitas. Funciona el primer mes. El problema llega cuando el sistema crece.
Con llamadas directas por servicio aparecen cuatro problemas que ningún retry loop resuelve por sí solo:
- Rate limiting por silo: si el clasificador de documentos consume demasiado, los demás servicios no se enteran hasta que también empiezan a ver errores 429. No hay coordinación.
- Sin fallback automático: si Anthropic tiene una incidencia, tu servicio falla. No hay plan B incorporado en la arquitectura.
- Coste invisible por proceso: sabes cuánto gastas en total, pero no sabes si el coste viene del agente de soporte o del generador de informes. Imposible optimizar sin saber qué consume qué.
- Rotación de modelos manual: cambiar de
claude-opus-4-7aclaude-sonnet-4-6en producción implica tocar código y desplegar múltiples servicios.
Qué resuelve un LLM Gateway
Un gateway es un servicio HTTP que recibe tus peticiones de completions, las gestiona centralmente y las reenvía al proveedor adecuado:
Agente Soporte ─┐
Clasificador IA ─┤─▶ LLM Gateway ─▶ Anthropic / OpenAI / Gemini
Generador Docs ─┘
Lo que ganas al añadir esta capa:
Fallbacks automáticos entre proveedores. Si Anthropic devuelve un 529 o supera el timeout configurado, el gateway reintenta con OpenAI o Gemini sin que tus servicios lo noten.
Rate limiting global y coordinado. El gateway controla el número de tokens por minuto de forma centralizada. El clasificador no puede comerse la cuota del agente de soporte.
Cost tracking por servicio o cliente. Cada petición lleva un header x-service: classifier o x-tenant: acme-corp. El gateway registra tokens consumidos por ese contexto. Por fin puedes responder a la pregunta de cuánto cuesta cada proceso por separado.
Model routing declarativo. Tareas de clasificación simple → modelo económico. Generación de documentos complejos → modelo potente. La lógica vive en el gateway, no duplicada en cada servicio.
Implementación mínima en TypeScript
Si ya tienes Next.js, el punto de partida más directo es un route handler que actúe de proxy:
// app/api/llm/route.ts
import Anthropic from '@anthropic-ai/sdk'
const client = new Anthropic()
export async function POST(req: Request) {
const { messages, model, metadata } = await req.json()
const service = req.headers.get('x-service') ?? 'unknown'
const tenant = req.headers.get('x-tenant') ?? 'default'
try {
const response = await client.messages.create({
model: model ?? 'claude-sonnet-4-6',
max_tokens: 1024,
messages,
})
// Log centralizado: tokens por servicio y tenant
console.log({
service,
tenant,
input_tokens: response.usage.input_tokens,
output_tokens: response.usage.output_tokens,
model: response.model,
ts: Date.now(),
})
return Response.json(response)
} catch (err: any) {
if (err.status === 529 || err.status === 429) {
// Punto único para implementar el fallback a otro proveedor
return Response.json({ error: 'overloaded', retry: true }, { status: 503 })
}
throw err
}
}
Todos tus servicios pasan a llamar a /api/llm en lugar de a Anthropic directamente. Beneficio inmediato: un único punto donde añadir logging, fallbacks y rate limiting sin tocar cada agente.
LiteLLM: cuando la solución open source es la respuesta
Para equipos con carga real en producción, LiteLLM implementa todo esto out-of-the-box: proxy HTTP, soporte para más de cien modelos, budget limits por API key, logging a bases de datos y fallbacks configurables en YAML:
# litellm_config.yaml
model_list:
- model_name: production-llm
litellm_params:
model: claude-sonnet-4-6
api_key: os.environ/ANTHROPIC_API_KEY
- model_name: production-llm # mismo alias, fallback automático
litellm_params:
model: gpt-4o
api_key: os.environ/OPENAI_API_KEY
router_settings:
num_retries: 3
fallbacks: [{"production-llm": ["production-llm"]}]
allowed_fails: 1
Tus servicios llaman a http://gateway:8000/v1/chat/completions con model: "production-llm". El gateway gestiona el resto.
Cuándo lo necesitas (y cuándo no)
Si tienes un único agente en producción llamando a un solo proveedor, un gateway añade complejidad innecesaria. Empieza a necesitarlo cuando:
- Más de un servicio hace llamadas a LLMs
- Necesitas visibilidad de coste por tenant o por proceso
- Quieres poder cambiar de modelo sin desplegar todos los servicios
- Estás en un sector donde el 99,9% de disponibilidad importa de verdad
En DAILYMP añadimos la capa de gateway desde el primer sprint cuando el sistema tiene más de dos agentes. Los primeros días parece overhead. Dos meses después es lo que mantiene el sistema funcionando cuando los proveedores tienen incidencias — y en 2026, con el volumen de tráfico que manejan, eso ocurre con más frecuencia de lo que los dashboards oficiales reconocen.
Si te interesa ver cómo conectamos esto con observabilidad y tracing en agentes IA, hay un patrón natural: el gateway es el punto donde emites los eventos que el sistema de tracing recoge.
El argumento de arquitectura
El LLM gateway no es una optimización prematura: es la separación de responsabilidades que debería estar desde el día uno. Tu código de negocio no debería saber qué proveedor responde a cada petición, ni cómo manejar un 529, ni cómo dividir el coste entre clientes.
Si estás construyendo un sistema multiagente y quieres la arquitectura correcta desde el principio, hablémoslo directamente.