Por qué realmente centralizo mi tráfico de LLM a través de LiteLLM

Tener diez API keys en diez herramientas distintas no es estrategia. Es deuda operativa.

Uso LiteLLM en mi cluster de Kubernetes. No porque sea la única opción, sino porque resuelve un problema real: centralizar el acceso a modelos de diferentes proveedores bajo una sola API key y un solo endpoint.

Qué problema resuelve

Cada proveedor de IA tiene su propia autenticación, sus rate limits, sus formatos y sus precios. Cuando tus herramientas (IDE, agentes, scripts, chatbots) hablan directamente con cada proveedor, acabas gestionando secretos por todas partes.

LiteLLM actúa como proxy. Los clientes envían requests compatibles con OpenAI. LiteLLM rutea al proveedor correcto según el modelo solicitado.

Cómo lo pienso

La arquitectura es simple:

Clientes -> LiteLLM Proxy -> Proveedor de IA

Los clientes solo conocen una URL y una master key. LiteLLM conoce las claves reales de cada proveedor y las políticas de ruteo.

Esto permite:

• Cambiar de proveedor sin tocar los clientes.
• Aplicar rate limits globales.
• Registrar uso y costos en un solo lugar.
• Fallback entre proveedores si uno falla.

Proveedores que realmente ruteo

• OpenRouter para experimentos y fallback.
• Kimi Code para tareas de coding.
• Modelos locales vía Ollama cuando prefiero privacidad o no quiero gastar créditos.

La flexibilidad es el punto. No me caso con un proveedor.

Lo que realmente pasó

Una vez estaba probando un nuevo modelo a través de OpenRouter. Funcionaba bien hasta que no funcionó. El modelo se volvió inconsistente, empezó a dar respuestas truncadas, y no sabía si era el modelo, el proveedor, o mi prompt.

Sin LiteLLM, habría estado cambiando API keys en múltiples herramientas, verificando cuál usaba qué proveedor, y rezando para no romper algo en producción. Con LiteLLM, cambié una línea en el archivo de configuración del proxy. Un modelo falló, otro tomó su lugar, y mis herramientas ni siquiera lo notaron.

Eso no es magia. Es abstracción. Pero la abstracción correcta ahorra horas de debugging cuando algo sale mal.

Mi configuración actual

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  - model_name: kimi-code
    litellm_params:
      model: kimi/kimi-code
      api_key: os.environ/KIMI_API_KEY

  - model_name: local-llama
    litellm_params:
      model: ollama/llama3.1
      api_base: http://ollama.ollama.svc.cluster.local:11434

router_settings:
  fallback_strategy: "simple"
  cooldown_time: 300

Nota el fallback_strategy. Si un proveedor falla, LiteLLM intenta el siguiente. No es perfecto, los modelos no son intercambiables, pero para tareas simples de coding y generación de texto, funciona lo suficientemente bien como para no bloquearme.

Lo que no hace

LiteLLM no hace que los modelos sean intercambiables. GPT-4o y Llama 3.1 8B no son lo mismo. No puedes simplemente cambiar uno por otro y esperar los mismos resultados. Lo que LiteLLM hace es evitar que tengas que cambiar URLs y API keys en diez lugares diferentes cuando quieres probar algo nuevo.

Tampoco resuelve el problema de los costos. Sí te da visibilidad de cuánto gastas por modelo y por proveedor, pero no hace que los tokens sean más baratos. Eso sigue siendo tu problema.

Conclusión

LiteLLM no es magia. Es un proxy bien diseñado que abstrae la fragmentación de proveedores de IA. Si usas más de un modelo en más de una herramienta, merece la pena evaluarlo.

Para mí, tener un gateway de IA centralizado es tan obvio ahora como tener un reverse proxy delante de tus servicios. No lo uso porque sea perfecto. Lo uso porque la alternativa, gestionar secretos y endpoints en cada herramienta por separado, es peor.

La próxima vez que un proveedor de IA cambie sus precios o deprecie un modelo, cambiaré una línea en un archivo YAML. Mis herramientas no se enterarán. Eso vale el esfuerzo de configurarlo.