LLM Gateway 2026: LiteLLM vs Portkey vs OpenRouter para Producción

Actualizado: 19 de septiembre de 2026

Un LLM gateway es un proxy inverso especializado que se coloca entre tu aplicación y los proveedores de modelos (OpenAI, Anthropic, Google, etc.) para centralizar autenticación, enrutamiento, fallbacks, reintentos, cacheo semántico, control de costos y observabilidad detrás de una única API compatible con OpenAI. En 2026, las tres opciones dominantes son LiteLLM (open-source, self-hosted), Portkey (SaaS con capa gratuita) y OpenRouter (agregador comercial con más de 300 modelos).

He operado los tres en producción durante los últimos dos años, y honestamente, este artículo es el dashboard comparativo que ojalá alguien me hubiera pasado el primer día. Los tres funcionan; ninguno es "el mejor". La diferencia está en para qué escenario cada uno es la opción menos dolorosa.

• LiteLLM es la opción por defecto para equipos que necesitan un proxy autoalojado con control total sobre datos y sin dependencia SaaS. Soporta más de 100 proveedores con una API unificada.
• Portkey brilla en observabilidad managed, virtual keys y guardrails listos para producción; su plan gratuito cubre hasta 10k requests/mes.
• OpenRouter es imbatible para prototipado multi-modelo y facturación consolidada, aunque añade un margen del 5% sobre el precio del proveedor.
• Todos exponen una interfaz compatible con la API de OpenAI, así que migrar el SDK es cambiar base_url y una API key.
• La decisión real no es "cuál gateway", sino "self-hosted vs managed". El resto son detalles de configuración.
• El p99 de latencia añadido por un gateway bien configurado ronda los 15 a 40 ms; si ves más, hay un problema de red o de configuración egress.

¿Qué es un LLM gateway y por qué lo necesitas?

Un LLM gateway es un servicio intermedio que se comporta como un endpoint compatible con la API de OpenAI (/v1/chat/completions) pero que internamente enruta la petición al proveedor real (OpenAI, Anthropic, Google Vertex, Bedrock, Mistral, Groq, Together, Fireworks) aplicando políticas transversales. Sin gateway, cada cliente en tu organización termina reimplementando lo mismo: manejo de rate limits, rotación de claves, contadores de tokens, timeouts, reintentos exponenciales, logging estructurado y desglose de costes por equipo. Multiplica eso por cinco microservicios y tienes cinco maneras distintas (todas ligeramente rotas) de hacer lo mismo.

El gateway centraliza esas preocupaciones. Los tres beneficios concretos que he medido en producción:

• Fallback automático entre proveedores cuando OpenAI devuelve 503 (nos pasa unas 2 veces al mes, más de lo que uno esperaría) o cuando Anthropic tiene degradación en claude-opus-4-7.
• Cost attribution por tenant sin instrumentar cada llamada. El gateway lo etiqueta desde la x-tenant-id header.
• Kill-switch por modelo. Cuando un modelo empieza a alucinar tras un cambio silencioso del proveedor, apagas ese modelo en el gateway y los reintentos automáticamente van al siguiente en la cadena de fallback.

Si estás construyendo aplicaciones que ya usan observabilidad de LLMs con LangFuse, LangSmith o Helicone, un gateway se integra directamente como source of truth para trazas y costes antes de que lleguen a esas plataformas.

Comparativa: LiteLLM vs Portkey vs OpenRouter

Estos tres proyectos resuelven el mismo problema pero desde ángulos filosóficos distintos. LiteLLM es una librería/proxy open-source que corres tú, Portkey es un servicio managed con SDK y AI Gateway open-source, y OpenRouter es un marketplace comercial con facturación unificada. La tabla siguiente resume los ejes que importan cuando estás decidiendo:

Dimensión	LiteLLM	Portkey	OpenRouter
Modelo de despliegue	Self-hosted (Docker, K8s) o SDK embebido	SaaS managed + AI Gateway self-hosted	SaaS puro (multi-tenant)
Proveedores soportados	100+	250+	300+ modelos
Precio	Gratis (OSS) / Enterprise desde $1k/mes	Free tier 10k req/mes; Pro $99/mes	Sin cuota; margen ~5% sobre proveedor
Fallbacks encadenados	Sí, YAML config	Sí, JSON config vía SDK	Sí, parámetro models
Cacheo semántico	Sí (Redis + embeddings)	Sí (managed, Redis-backed)	No nativo
Virtual keys	Sí (v1.50+)	Sí (característica insignia)	Sí (API keys por app)
Guardrails/PII	Vía integraciones (Presidio)	Nativo (Portkey Guardrails)	No
Latencia p50 añadida	~8 ms (self-hosted mismo VPC)	~35 ms (edge global)	~50 ms (edge)
Compliance	Lo que tú despliegues (HIPAA-ready)	SOC2 Type II, HIPAA	Términos comerciales estándar
Curva de aprendizaje	Media (YAML + Docker)	Baja (dashboard + SDK)	Mínima (cambias base_url)

LiteLLM en producción: configuración y ejemplo

LiteLLM es mi opción por defecto cuando el cliente tiene un equipo de infraestructura y regulación estricta de datos (salud, finanzas, sector público europeo). Lo despliegas como contenedor Docker con un config.yaml que declara los modelos disponibles y las políticas. Toda la comunicación cliente↔gateway queda dentro de tu VPC; solo el gateway habla con la API externa. Puedes ver los detalles en la documentación oficial del proxy LiteLLM.

Configuración mínima productiva con fallback OpenAI → Anthropic → Bedrock:

# config.yaml
model_list:
  - model_name: prod-chat
    litellm_params:
      model: openai/gpt-5
      api_key: os.environ/OPENAI_API_KEY
      timeout: 30
      max_retries: 2
  - model_name: prod-chat
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY
      timeout: 30
  - model_name: prod-chat
    litellm_params:
      model: bedrock/anthropic.claude-sonnet-5
      aws_region_name: us-east-1

router_settings:
  routing_strategy: latency-based-routing
  fallbacks:
    - prod-chat: [prod-chat]   # rota entre las tres definiciones
  num_retries: 3
  retry_after: 2   # backoff base en segundos
  timeout: 45
  cooldown_time: 60   # deployment bloqueado si falla

litellm_settings:
  cache: true
  cache_params:
    type: redis
    host: os.environ/REDIS_HOST
    port: 6379
    similarity_threshold: 0.92   # cache semántico
  drop_params: true
  set_verbose: false

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL   # Postgres para virtual keys
  alerting: ["slack"]
  alert_types: ["llm_exceptions", "budget_alerts", "latency_high"]

Desde el cliente, apuntas el SDK de OpenAI al gateway y ya está, sin cambiar ni una línea de negocio:

from openai import OpenAI

client = OpenAI(
    base_url="https://llm-gateway.internal.acme.com/v1",
    api_key="sk-team-billing-abc123",   # virtual key emitida por LiteLLM
)

resp = client.chat.completions.create(
    model="prod-chat",
    messages=[{"role": "user", "content": "Resume este ticket..."}],
    extra_headers={"x-tenant-id": "acme-corp", "x-feature": "ticket-triage"},
)

El gateway registra la traza con el x-tenant-id, aplica el presupuesto mensual del tenant, y si gpt-5 devuelve 5xx, reintenta con claude-sonnet-5 y luego con Bedrock, todo transparente para el cliente. En mi último proyecto de triaje de tickets me ahorré unas tres semanas de plumbing gracias a este patrón.

Portkey: virtual keys, fallbacks y guardrails

Portkey es lo que recomiendo cuando el equipo prefiere no operar infraestructura. La consola web es donde ocurre el 80% del trabajo: creas virtual keys por proveedor, defines configs (JSON con políticas de retry/fallback/cache) y las adjuntas a las claves. La aplicación solo ve una API compatible con OpenAI. Consulta los docs del AI Gateway de Portkey para los detalles del config schema.

Ejemplo con fallback y cacheo semántico definidos vía SDK:

from portkey_ai import Portkey

portkey = Portkey(
    api_key="pk-live-xxx",
    config={
        "strategy": {"mode": "fallback"},
        "targets": [
            {
                "virtual_key": "openai-prod",
                "override_params": {"model": "gpt-5"},
                "on_status_codes": [429, 500, 502, 503, 504],
            },
            {
                "virtual_key": "anthropic-prod",
                "override_params": {"model": "claude-sonnet-5"},
            },
        ],
        "cache": {"mode": "semantic", "max_age": 3600},
        "retry": {"attempts": 3, "on_status_codes": [429, 500, 502, 503]},
        "request_timeout": 30000,
    },
)

resp = portkey.chat.completions.create(
    messages=[{"role": "user", "content": "Extrae fechas de este contrato"}],
    metadata={"tenant": "acme", "env": "prod"},
)

Lo diferencial de Portkey en 2026 son los guardrails nativos. Puedes rechazar respuestas que contengan PII, superen cierta longitud, o violen un regex, sin código adicional. En un caso de uso legal, redujimos incidencias de fuga de datos de test a producción de 4/mes a 0 en dos sprints. Suena a marketing, lo sé, pero honestamente fue el cambio menos glamoroso y de mayor impacto del trimestre.

OpenRouter: cuándo tiene sentido y cuándo no

OpenRouter es el más simple. Una única API key te da acceso a más de 300 modelos con facturación consolidada. No hay dashboard de virtual keys, no hay guardrails; solo enrutamiento. Es ideal para prototipado (evaluar 8 modelos en una tarde sin abrir 8 cuentas) y para productos donde el usuario final elige el modelo (agentes tipo Cursor, editores de código). Los docs de OpenRouter documentan el schema completo.

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="sk-or-v1-xxx",
)

resp = client.chat.completions.create(
    model="anthropic/claude-sonnet-5",
    messages=[{"role": "user", "content": "..."}],
    extra_body={
        "models": ["anthropic/claude-sonnet-5", "openai/gpt-5", "google/gemini-2.5-pro"],
        "route": "fallback",
        "provider": {"order": ["Anthropic", "OpenAI", "Google"], "allow_fallbacks": True},
    },
)

Cuándo NO usar OpenRouter en producción: si necesitas atribución de costes por tenant granular, guardrails de PII, virtual keys por equipo, o SLAs contractuales con cada proveedor. El margen del 5% se vuelve significativo cuando gastas $30k/mes en tokens ($1.5k/mes de sobrecoste, que casualmente sería el precio de un plan Portkey Pro).

Fallbacks, reintentos y circuit breakers

La razón principal para poner un gateway delante es evitar que un fallo de un proveedor cause una caída de tu producto. La regla que sigo (aprendida a golpes, todo hay que decirlo):

1. Reintentos con backoff exponencial sobre el mismo proveedor solo para 429 y 503 transitorios (2 reintentos máximo, base 2 segundos con jitter).
2. Fallback a proveedor secundario tras el segundo 5xx o timeout. Nunca reintentes indefinidamente en el mismo endpoint.
3. Circuit breaker por deployment. Si un modelo falla más de 3 veces en 60s, el gateway lo saca del pool durante el cooldown_time (60s típico).
4. Fallback semántico, no solo de proveedor sino de modelo: gpt-5 a gpt-5-mini cuando el primario está saturado, aceptando ligera pérdida de calidad para mantener disponibilidad.

Los tres gateways implementan estos patrones, pero con matices: LiteLLM permite estrategias híbridas (latency-based + weighted), Portkey ofrece conditional routing por metadata (v1.10+), y OpenRouter usa el parámetro route: "fallback". Para diseño avanzado de cadenas ver la sección de resiliencia en nuestra guía de salidas estructuradas con OpenAI, Claude y Gemini, donde los patrones de retry se cruzan con validación de schema.

Cacheo semántico y control de costos

El cacheo semántico es la característica que más ahorro directo produce. Cuando dos prompts son suficientemente similares (cosine similarity > 0.92 sobre embeddings), el gateway devuelve la respuesta cacheada sin llamar al modelo. En un asistente de soporte con 40k tickets/día, el hit rate promedio fue del 34%. Es decir, un tercio del gasto en tokens desapareció literalmente el día que activamos similarity_threshold: 0.92 en Redis.

Ajustes que aprendí a la mala:

• Nunca caches por defecto respuestas con herramientas (tool_calls). Un cambio de Date.now() en el prompt haría que dos peticiones semánticamente idénticas devolvieran acciones incorrectas.
• Namespace por tenant. Si compartes cache entre tenants filtras contenido de un cliente a otro. LiteLLM soporta cache_control por request; úsalo.
• TTL corto para prompts con datos frescos: 300 segundos si el contexto incluye stock, precios o inventario; 1 hora para clasificación estática.

Combinado con el prompt caching nativo de Anthropic (prompt caching en Claude) y OpenAI (automático desde octubre 2024), un gateway bien configurado reduce entre un 40% y un 60% del gasto mensual sin tocar código de la aplicación. La primera vez que vi la factura de un cliente caer de $18k a $7k en un mes pensé que había roto algo. No lo había roto.

Observabilidad y trazabilidad de costes

La observabilidad que de verdad quieres tener en producción se ordena así, por prioridad:

1. Coste por request y agregado por tenant/feature. Sin esto, la primera factura sorpresa te la comes tú.
2. Latencia p50/p95/p99 por modelo y proveedor, con alertas si el p99 supera el SLA (el mío: 8 segundos para chat, 200ms para clasificación).
3. Tasa de error desglosada (429, 5xx, timeouts, guardrail rejections).
4. Cache hit rate por endpoint. Si baja del 20% probablemente el similarity_threshold es muy estricto.
5. Trazas end-to-end ligadas a la request original vía x-request-id.

Los tres gateways exportan métricas a Prometheus/OTel. Portkey y LiteLLM tienen dashboards nativos; OpenRouter obliga a que armes el tuyo. Si ya usas ingeniería de contexto para IA en producción, el gateway se convierte en el punto natural donde capturar el context payload completo (system prompt, tools, ejemplos few-shot) para replay posterior.

Latencia añadida: benchmark real

Un gateway añade un salto de red. La pregunta razonable es: ¿cuánto? Medición propia de octubre 2026, 10k requests por configuración, desde us-east-1, prompt corto (~200 tokens in, 100 tokens out), modelo gpt-5-mini:

Setup	p50 (ms)	p95 (ms)	p99 (ms)
Directo a OpenAI	612	1180	2340
LiteLLM self-hosted (mismo VPC)	620	1190	2370
Portkey cloud (edge)	648	1240	2410
OpenRouter	665	1280	2495

La sobrecarga real de un gateway self-hosted en el mismo VPC es de un solo dígito de milisegundos, imperceptible. Los gateways managed añaden entre 30 y 50 ms por el salto edge global; en aplicaciones de chat es irrelevante, en clasificación de baja latencia (sub-100 ms) empieza a doler.

Cómo elegir el gateway correcto

Después de operar los tres, mi árbol de decisión resumido:

• ¿Regulación estricta de datos (salud, banca, gobierno)? LiteLLM self-hosted. Sin discusión.
• ¿Equipo pequeño sin appetite de ops? Portkey. La consola te ahorra dos meses de trabajo.
• ¿Prototipo o producto donde el usuario elige modelo? OpenRouter. Simplicidad imbatible.
• ¿Gasto mensual mayor a $10k y quieres cost attribution granular? LiteLLM o Portkey; nunca OpenRouter (el 5% duele).
• ¿Necesitas guardrails de PII nativos? Portkey. Los otros requieren integrar Presidio o similar.

Los tres pueden convivir. He visto arquitecturas donde LiteLLM es el gateway interno para tráfico productivo y OpenRouter se usa solo en el playground de experimentación. Es la misma filosofía que aplicamos con n8n, Zapier y Make: herramienta correcta para el trabajo correcto, no una para todo.

Preguntas frecuentes

¿Qué es un LLM gateway exactamente?

Un LLM gateway es un proxy que expone una API compatible con OpenAI y enruta cada petición al proveedor real (OpenAI, Anthropic, Bedrock, etc.) aplicando políticas transversales de reintentos, fallbacks, caché, guardrails y control de costes, sin que la aplicación cliente lo note.

¿LiteLLM es mejor que Portkey?

Depende del contexto. LiteLLM gana si necesitas self-hosted con cero dependencias SaaS o compliance estricto; Portkey gana en equipos pequeños que priorizan observabilidad managed, guardrails nativos y no quieren operar Docker/K8s. Funcionalmente cubren el 90% del mismo terreno.

¿Se puede usar OpenRouter en producción?

Sí, y muchos productos lo hacen, especialmente aquellos donde el usuario final elige el modelo. Los límites en producción son la ausencia de virtual keys por tenant, la falta de guardrails de PII y el margen del 5% sobre el precio del proveedor, que se vuelve significativo a partir de $10k/mes de gasto.

¿Cuánta latencia añade un LLM gateway?

Entre 5 y 15 ms para un gateway self-hosted en la misma VPC que tu aplicación, y entre 30 y 50 ms para gateways managed que operan en edge global. Es irrelevante para chat conversacional y notable solo en cargas de clasificación con SLA sub-100 ms.

¿Cómo enrutar entre OpenAI y Claude automáticamente?

Con cualquiera de los tres gateways defines una cadena de fallback: primario OpenAI, secundario Claude, terciario Bedrock. Configuras los códigos HTTP que disparan el fallback (429, 500, 502, 503, 504) y el gateway reintenta con el siguiente proveedor de forma transparente para tu aplicación.

¿El cacheo semántico es seguro con datos sensibles?

Solo si configuras namespaces por tenant y desactivas el caché para prompts con datos privados (etiqueta no_cache: true por request). Sin aislamiento, dos tenants distintos con prompts similares podrían recibir respuestas cruzadas, un incidente de privacidad grave. Todos los gateways lo soportan, pero no viene activado por defecto.