Phase 13 - Lesson 21

LLM Routing Layer — LiteLLM, OpenRouter, Portkey

This lesson includes a graded coding exercise that runs in your browser, unlocked with lifetime access.

El bloqueo de proveedor (provider lock-in) es costoso. Diferentes cargas de trabajo de llamada a herramientas (tool-calling) se adaptan a diferentes modelos. Los gateways de enrutamiento ofrecen una única interfaz de API, reintentos, failover, seguimiento de costos y guardrails. Tres arquetipos dominan en 2026: LiteLLM (código abierto autohospedado), OpenRouter (SaaS administrado) y Portkey (grado de producción, código abierto en marzo de 2026). Esta lección define los criterios de decisión y recorre un gateway de enrutamiento basado en la biblioteca estándar (stdlib).

Type: Learn Languages: Python (stdlib, routing + failover + cost tracker) Prerequisites: Phase 13 · 02 (function calling), Phase 13 · 17 (gateways) Time: ~45 minutos

Objetivos de Aprendizaje

• Distinguir entre opciones de enrutamiento autohospedadas, administradas y de grado de producción.
• Implementar una cadena de fallback que reintente ante fallas del proveedor en un orden de prioridad definido.
• Realizar el seguimiento del costo por solicitud y el uso de tokens entre proveedores.
• Decidir entre LiteLLM, OpenRouter y Portkey para una restricción de producción determinada.

El Problema

Escenarios donde el enrutamiento de proveedores importa:

1. Costo. Claude Sonnet cuesta 3 veces más que Haiku. Para una tarea de triaje, Haiku es suficiente; para una tarea de síntesis, Sonnet vale la pena. Enrute por solicitud.

2. Failover. OpenAI tiene una mala hora. Cada solicitud falla. Desea un fallback automático a Anthropic sin tener que volver a desplegar.

3. Latencia. Una interfaz de usuario de chat en vivo necesita un tiempo rápido hasta el primer token (time-to-first-token). Un resumidor por lotes no. Enrute por SLA de latencia.

4. Cumplimiento. Los usuarios de la UE deben permanecer en las regiones de la UE. Enrute por región.

5. Experimentación. Pruebas A/B de dos modelos en la misma carga de trabajo. Enrute por segmento de prueba (test bucket).

Codificar a mano todo esto por integración es repetitivo. Un gateway de enrutamiento ofrece una interfaz de API compatible con OpenAI y se encarga del resto.

El Concepto

Formato de proxy compatible con OpenAI

Todos hablan el formato de OpenAI. El gateway de enrutamiento expone /v1/chat/completions, acepta el esquema de OpenAI y realiza internamente el proxy hacia Anthropic / Gemini / Cohere / Ollama / cualquier otro. Al cliente no le importa.

Aliases de modelos

En lugar de claude-3-5-sonnet-20251022, su código dice our_smart_model. El gateway mapea los aliases a modelos reales. Cuando Anthropic lance Claude 4, usted cambia el alias en el servidor; su código no cambia en absoluto.

Cadenas de fallback

primary: openai/gpt-4o
on 5xx: anthropic/claude-3-5-sonnet
on 5xx: google/gemini-1.5-pro
on 5xx: refuse

Los gateways definen esto en una configuración. Los reintentos se descuentan de un presupuesto para que las cascadas de fallback no disparen los costos.

Caché semántico

Los prompts idénticos o casi idénticos acceden a una caché en lugar de ir al proveedor. Los ahorros en bucles de agentes repetidos pueden ser del 30 al 60 por ciento. Las claves se basan en embeddings; prompts casi idénticos comparten el mismo espacio de caché.

Guardrails

A nivel de gateway:

• Redación de PII (PII redaction). Filtro basado en Regex o ML antes de enviar los prompts.
• Violaciones de políticas. Rechazar prompts con contenido prohibido.
• Filtros de salida. Depurar las respuestas (completions) para evitar filtraciones.

Tanto Portkey como Kong ofrecen guardrails de opinión integrados. LiteLLM los deja como opcionales.

Límites de tasa por clave

Una clave de API = un equipo. Los presupuestos por clave evitan que un solo equipo consuma la cuota compartida. La mayoría de los gateways soportan esto.

Comparativa entre autohospedado y administrado

LiteLLM gana cuando se tiene un equipo de SRE y se desea soberanía de datos. OpenRouter gana cuando se quiere una sola suscripción y ninguna infraestructura. Portkey gana cuando se necesitan guardrails y cumplimiento listos para usar.

Seguimiento de costos

Cada solicitud incluye provider, model, input_tokens, output_tokens. Se multiplica por los precios por token de cada modelo (obtenidos de una lista de precios que el gateway mantiene). Agregación por usuario / por equipo / por proyecto.

MCP más enrutamiento

Un gateway puede enrutar tanto llamadas de LLM COMO solicitudes de muestreo (sampling) de MCP. Cuando las modelPreferences de una solicitud de muestreo prefieren un modelo específico, el gateway realiza la traducción al backend correcto. Aquí es donde la Phase 13 · 17 (MCP gateway) y el gateway de enrutamiento de esta lección a veces se fusionan en un solo servicio.

Estrategias de enrutamiento

• Prioridad estática (Static priority). Primero en la lista; realiza fallback en caso de error.
• Balanceo de carga (Load balancing). Round-robin o ponderado.
• Sensible al costo (Cost-aware). Elige el modelo más barato que cumpla con los requisitos de latencia / calidad.
• Sensible a la latencia (Latency-aware). Elige el modelo más rápido en los últimos N minutos.
• Sensible a la tarea (Task-aware). Un clasificador de prompts enruta la programación a un modelo y la resumización a otro.

Use It

El archivo code/main.py implementa un gateway de enrutamiento en unas 150 líneas: acepta solicitudes con formato de OpenAI, las traduce a stubs por proveedor, ejecuta una cadena de fallback por prioridad, realiza el seguimiento del costo por solicitud y aplica un paso de redacción de PII en las entradas. Ejecútelo en tres escenarios: solicitud normal, caída del proveedor primario que activa el enrutamiento de fallback y filtración de PII detectada por la redacción.

Qué observar:

• Diccionario ROUTES: alias -> lista de proveedores concretos ordenada por prioridad.
• El bucle de fallback reintenta ante errores de tipo 5xx.
• El rastreador de costos multiplica el uso de tokens por las tarifas de cada modelo.
• El redactor de PII elimina patrones con formato de SSN antes de reenviar.

Ship It

Esta lección produce el archivo outputs/skill-routing-config-designer.md. Dado un perfil de carga de trabajo (latencia, costo, cumplimiento), la habilidad selecciona LiteLLM / OpenRouter / Portkey y genera una configuración de enrutamiento.

Ejercicios

1. Ejecute code/main.py. Active el escenario de caída; confirme que el fallback se dirija al segundo proveedor y que el costo se atribuya correctamente.

2. Agregue caché semántico: el SHA256 del prompt es una clave de búsqueda; los aciertos de caché (cache hits) retornan instantáneamente. Mida los ahorros de costo en una llamada repetida.

3. Agregue un clasificador de prompts que enrute los prompts de "code ..." a un alias que priorice la inteligencia y los prompts de "summarize ..." a un alias que priorice la velocidad.

4. Diseñe presupuestos por equipo: cada equipo tiene un límite de gasto mensual; el gateway rechaza solicitudes una vez alcanzado el límite. Elija una granularidad de aplicación (por solicitud o por ventana de tiempo).

5. Lea las documentaciones de LiteLLM, OpenRouter y Portkey frente a frente. Identifique la característica exclusiva que ofrece cada uno y que los otros dos no tienen.

Términos Clave

Lecturas Adicionales

• LiteLLM — documentación — gateway de enrutamiento autohospedado
• OpenRouter — inicio rápido — SaaS de enrutamiento administrado
• Portkey — documentación — enrutamiento de producción con guardrails
• TrueFoundry — LiteLLM vs OpenRouter — guía de decisión
• Relayplane — LLM gateway comparison 2026 — encuesta de proveedores