De LiteLLM a Wäg en una tarde, no un trimestre
LiteLLM lleva a los equipos al multiproveedor rápidamente — por eso tantos stacks en producción lo utilizan. Lo que no aporta es una capa de gobernanza: presupuestos jerárquicos que frenan el gasto antes de llamar al proveedor, políticas aplicadas en la ruta de la petición, llamadas a herramientas retenidas para un aprobador con nombre y un registro de auditoría que pueda entregar a un equipo de cumplimiento. Wäg ocupa el lugar del proxy de LiteLLM y añade esa capa. Conserva su SDK, sus alias de modelo y su código de aplicación. Cambia una URL base.
Qué cambia
- La URL base a la que apuntan sus clientes
- Dónde reside la configuración
- El proceso de proxy que opera
Qué no cambia
- Su SDK — openai, langchain, llamaindex, el SDK de LiteLLM como cliente, cualquiera compatible con OpenAI
- Los alias de modelo que referencia su código
- Las formas de petición y de respuesta
- El comportamiento de streaming, el tool calling y la visión
- Sus cuentas de proveedor y sus claves de API
Cuatro pasos, y ninguno es una reescritura
1 · Importe su configuración
Lee su config.yaml de LiteLLM — en la línea de comandos o pegado en Platform → System → Import en la consola — y produce la configuración de Wäg: modelos y alias, referencias a credenciales de proveedor, estrategia de enrutamiento, fallbacks, Redis, proyectos como aplicaciones con presupuestos, claves virtuales, servidores MCP y agentes A2A.
$ waeg import litellm --from config.yaml -o waeg.yaml$ waeg config validate --config waeg.yamlLo que hay que revisar es el informe de importación. Cada clave acaba en una de cuatro listas — mapped, skipped, needs_human y notes — y la línea de comandos muestra los recuentos con ejemplos:
mapped
model_list (12 rows) → 6 aliases: gpt-4o, claude, fast, cheap, embed, vision
model_list[3].litellm_params.rpm: 600 → relative deployment weight
litellm_settings.fallbacks → alias fallbacks
litellm_settings.num_retries: 3 → routing.max_retries: 3
router_settings.routing_strategy → routing.strategy: weighted (see notes)
projects[0] (max_budget, budget_duration) → application app_ll_search + application budget
skipped
litellm_settings.success_callback → re-create under Observability
needs_human
general_settings.master_key: os.environ/LITELLM_MASTER_KEY → set WAEG_MASTER_KEY
litellm_settings.cache_params → re-create under Caching
notes
routing_strategy "latency-based-routing-v2" is not known → weightedSalida ilustrativa. El motivo de mostrarla es que el informe es un artefacto real: nada falla en silencio, todo lo que no tiene equivalente en Wäg se lista para revisión en lugar de aproximarse, y los secretos nunca se repiten en la salida.
2 · Apunte una URL base
Wäg sirve la superficie compatible con OpenAI — /v1/chat/completions, /v1/responses (sin estado), /v1/embeddings, /v1/images/*, /v1/audio/*, /v1/videos, /v1/rerank, /v1/ocr, /v1/moderations, /v1/files, /v1/batches, /v1/realtime, /v1/models — además de /v1/messages de Anthropic, /v1beta de Gemini, y /v1/mcp y /v1/a2a para agentes. Los clientes de LiteLLM como Cline y Roo siguen funcionando: GET /model/info responde con o sin /v1, x-litellm-api-key se acepta en las rutas pass-through y MCP, y x-litellm-session-id agrupa las llamadas en conversaciones. El streaming es SSE real.
client = OpenAI(
- base_url="http://litellm:4000/v1",
+ base_url="https://waeg.internal/v1",
api_key=os.environ["GATEWAY_KEY"],
)Lo que hay que revisar: GET /v1/models devuelve sus alias; después, una petición con streaming y otra con tool calling por cada alias.
3 · Verifique en paralelo
Ejecute ambos. Envíe un porcentaje del tráfico a Wäg, o replique en sombra el tráfico de producción, y compare. Como las réplicas no tienen estado y comparten sus contadores a través de Redis y su configuración a través de Postgres, puede escalar el canary hacia arriba y hacia abajo sin perder el estado de los presupuestos.
- Decisiones de enrutamiento — x-waeg-routed-model en cada respuesta, x-waeg-route-reason con el enrutamiento inteligente
- Comportamiento de la caché — x-waeg-cache, y si las tasas de acierto coinciden con lo esperado
- Recuento de tokens y atribución de coste frente a la factura de su proveedor
- Latencia p50 / p95 / p99, tasas de error y tasas de fallback
- Señales de compatibilidad — campos de petición y de respuesta de los que dependen sus clientes y que el gateway reenvió o descartó, contados a partir de su propio tráfico
4 · Conmutar
Cambie la URL base de un servicio y luego la del resto. Mantenga el despliegue de LiteLLM en marcha hasta que esté satisfecho: revertir es el mismo cambio de una línea en sentido inverso.
Un orden razonable: primero las herramientas internas, después las cargas por lotes y offline, luego un servicio de producción y al final todo lo demás.
Vuelva a cambiar la URL base. Ese es todo el procedimiento — Wäg no guarda ningún estado del que dependan sus aplicaciones, y sus cuentas de proveedor, claves y alias de modelo quedan intactos. Mantenga ambos despliegues en marcha durante la transición. Esta migración no tiene ningún paso de bloqueo, por diseño.
Campo de configuración por campo de configuración
| LiteLLM | Wäg | Notas |
|---|---|---|
model_list[].model_name | alias de modelo | Se conserva literalmente — su código sigue funcionando |
litellm_params.model | despliegue: proveedor + model_id | Varias filas con el mismo model_name se convierten en despliegues ponderados de un mismo alias |
api_key: os.environ/X | api_key_env: X | Se lee del entorno en tiempo de ejecución; más adelante puede pasar a una referencia a vault si lo prefiere |
litellm_params.api_base | base_url del proveedor | Otro host u otra región se convierte en otro proveedor |
router_settings.routing_strategy | routing.strategy | simple-shuffle y usage-based → weighted, least-busy y latency-based → latency, cost-based → cost; cualquier otra → weighted, con una nota. Wäg añade intelligent |
litellm_settings.fallbacks | fallbacks de alias | Ordenados del más potente al menos potente en la estrategia intelligent |
litellm_settings.num_retries | routing.max_retries | Además, un circuit breaker por despliegue |
general_settings.master_key | master_key | Una referencia os.environ se lista para revisión: defina WAEG_MASTER_KEY. Además, claves virtuales con presupuestos y listas de modelos permitidos |
projects[]: max_budget / budget_duration | aplicación + presupuesto | En Wäg es jerárquico: org → equipo → usuario → aplicación → modelo → clave |
rpm en un despliegue | peso del despliegue | Un peso relativo, no un límite de tasa. El rpm_limit y el tpm_limit de un proyecto pasan a la política de presupuesto de su aplicación; el TPM por despliegue no tiene correspondencia |
cache_params | recrear tras la importación | En Caching: niveles exacto, canónico, casi duplicado y semántico, con protecciones contra falsos aciertos |
guardrails | recrear tras la importación | Los mismos proveedores existen como elementos del catálogo, en una cadena ordenada: antes de la llamada, en streaming y después de la llamada |
success_callback / failure_callback | recrear tras la importación | En Observability: callbacks OTLP, Langfuse y HTTP, además de métricas de Prometheus |
custom Python callbacks | — sin equivalente | Wäg no es un proceso de Python. Use en su lugar un motor de políticas por webhook HTTP |
keys[] con un project_id | claves virtuales | Vinculadas a la aplicación del proyecto, de modo que el presupuesto de un agente de programación va con su clave |
mcp_servers | servidores MCP de plataforma | La autenticación Bearer y por clave de API pasa a ser credenciales estáticas; el OAuth de usuario y el intercambio de tokens requieren Enterprise. Las herramientas importadas quedan fijadas |
agents[] | agentes A2A de plataforma | Actualice la agent card de cada agente tras la importación; el gateway la obtiene y la comprueba |
import litellm (in-process) | un cliente del gateway | El SDK sigue funcionando apuntado a Wäg; su enrutamiento en proceso y sus callbacks, no |
Incluido lo que LiteLLM hace y Wäg no
Contraste esto con su instalación antes de empezar. Si alguna de las dos primeras es determinante para usted, la migración es un proyecto real y no una tarde, y conviene saberlo ahora y no a mitad de camino.
Sin enrutamiento en proceso
LiteLLM puede importarse como biblioteca de Python. Apuntado a Wäg, el SDK sigue funcionando como cliente, pero su enrutamiento en proceso y sus callbacks no se trasladan — el enrutamiento se hace en el gateway.
Sin callbacks de Python personalizados
LiteLLM permite insertar Python arbitrario en el ciclo de vida de la petición. El punto de extensión de Wäg es un motor de políticas por webhook HTTP — más limpio de operar y de asegurar, y menos flexible de inmediato. La lógica de callbacks pesada pasa a ser un pequeño servicio.
Menos proveedores exóticos, más fidelidad
La cobertura de proveedores de LiteLLM es más amplia. Wäg tiene alrededor de una docena de tipos de proveedor nativos, además de cualquier servidor compatible con OpenAI, con adaptadores nativos de Anthropic y Gemini que preservan la fidelidad de herramientas, visión y salida estructurada en lugar de aplanarlo todo en una sola forma. Compruebe antes su lista.
Otra filosofía de enrutamiento
Wäg puntúa las peticiones estructuralmente — herramientas, visión, longitud de contexto, indicios de razonamiento — hasta convertirlas en umbrales duros de capacidad, y luego elige el modelo más barato que los supere. Determinista y explicable en las cabeceras. Sin router de ML en la ruta caliente.
Otra filosofía de caché
Cuatro niveles — exacto, canónico, casi duplicado, semántico — con protecciones contra falsos aciertos. «Capital de Francia» y «capital de España» son un fallo de caché. Los números, la negación y los cambios de entidad rompen un acierto.
La gobernanza es jerárquica, no plana
Esta es la verdadera razón para migrar. Los presupuestos de LiteLLM son por clave. Los de Wäg se apilan en org → equipo → usuario → aplicación → modelo → clave con topes de reparto equitativo, de modo que el modelo se corresponde con la forma real de las organizaciones.
Lo que ha ganado
Presupuestos que frenan el gasto primero
Límites apilados en org → equipo → usuario → aplicación → modelo → clave. Cada petición se comprueba contra todos los contadores aplicables; el primer incumplimiento rechaza la llamada antes de gastar con el proveedor. Con WAEG_CLUSTER=1 también fallan en cerrado si Redis no está accesible.
Políticas en la ruta de la petición
Una cadena ordenada de escáneres antes de la llamada, en streaming sobre una ventana deslizante y después de la llamada. PII, inyección, moderación o su propio webhook. Bloquear, enmascarar o redactar según la regla.
Bucles de agentes gobernados
Los servidores MCP remotos reciben credenciales por servidor — clave estática, token de usuario reenviado o credenciales de cliente OAuth y, con Enterprise, la propia conexión OAuth del usuario o el intercambio de tokens — además de listas de herramientas permitidas y fijación. Las llamadas a herramientas pueden esperar a un aprobador con nombre, en Slack o Teams con Enterprise, y cada salto se presupuesta y se registra.
Un registro de auditoría
Cada petición, decisión de enrutamiento, veredicto de política y coste en registros de peticiones, trazas OTLP y métricas de Prometheus — y, una vez activado, un libro de evidencias firmado y encadenado por hash que cualquiera puede comprobar sin conexión con waeg ledger verify. Enterprise añade paquetes de evidencias asignados al AI Act y a DORA, con las lagunas señaladas, y el marcado de contenido de IA.
Un solo binario
Rust, distroless, sin root. Sin shell, intérprete ni gestor de paquetes en la imagen del gateway, releases firmadas con SBOM y sin runtime de Node en el gateway — el asistente opcional de la consola se ejecuta como un servicio propio.
Un operador que lo gestiona
Un operator de Kubernetes propio declara el gateway — topología, almacenamiento, OpenFGA, escalado con HPA o KEDA — y reconcilia proveedores, modelos, presupuestos, claves y guardrails como recursos. Los errores de configuración aparecen como condiciones con su motivo, no como un pod que falla una hora después.
Vea dónde termina el gateway y empieza el control plane · Ver los benchmarks
Preguntas que suelen surgir
¿Tengo que cambiar el código de mi aplicación?
No. Cambia la URL base que su cliente compatible con OpenAI ya utiliza.
¿Se traslada mi configuración de LiteLLM?
En su mayor parte, mediante waeg import litellm o Platform → System → Import en la consola. Obtiene un informe de lo que se trasladó, lo que se omitió y lo que necesita a una persona, y nada falla en silencio.
¿Puedo ejecutar ambos a la vez?
Sí, y es el camino recomendado. Replique o reparta el tráfico y compare decisiones de enrutamiento, coste y latencia antes de hacer el cambio.
¿Es Wäg un fork de LiteLLM?
No. Es una implementación independiente en Rust, construida en torno a un modelo de petición de inferencia y no al despacho mediante SDK de proveedor. La compatibilidad es deliberada; el linaje es distinto.
¿Admite streaming?
Sí — eventos server-sent reales, no una respuesta bufferizada y troceada después.
¿Tool calling y visión?
Sí, en las formas de petición de OpenAI, Anthropic y Gemini. Los adaptadores nativos preservan la fidelidad específica de cada proveedor en lugar de aplanarla a un mínimo común denominador.
¿Y las API nativas de Anthropic y Gemini?
Se admiten como formas de petición de primer nivel, no solo como traducciones de la forma de OpenAI.
¿Necesito Redis?
Para más de una réplica, sí: mantiene coherentes los presupuestos y los límites de tasa entre réplicas, junto a Postgres y OpenFGA, que producción necesita de todos modos. El modo embebido no necesita nada externo, pero es de un solo nodo y guarda su estado en memoria.
¿Funciona en Kubernetes?
Sí, de dos formas. Un operator propio declara el gateway y su catálogo como recursos — réplicas sin estado, escalado con HPA o KEDA, contadores de presupuesto compartidos y sondas de salud y de readiness — y hay un chart de Helm si prefiere gestionarlo usted mismo.
¿Es realmente Apache-2.0?
Sí. La ruta de producción del gateway es Apache-2.0: enrutamiento, HA, caché, failover, presupuestos, guardrails, MCP, trabajos, observabilidad y el libro de evidencias. Enterprise añade identidad (SSO, SCIM, tokens del IdP), paquetes de auditoría y de evidencias, pagos de agentes, aprobaciones en Slack y Teams, guardrails pass-through y soporte.
¿Hace phone-home?
No. Sin telemetría ni analítica, y la licencia es un token firmado sin conexión, sin servidor de licencias. Funciona completamente en air-gap: observe sus conexiones salientes y solo verá los proveedores que usted configuró.
¿Y si necesitamos ayuda con la migración?
Los socios de diseño reciben apoyo práctico en la migración, también desde LiteLLM: la hacemos con usted en lugar de entregarle una guía.
Un endpoint. Cada modelo. Control total.
Ejecútelo en su propia infraestructura
Todo lo necesario para operar un control plane en producción es Apache-2.0 y seguirá siéndolo: enrutamiento, alta disponibilidad, caché, failover, presupuestos, políticas, MCP, trabajos y observabilidad. Self-hosted, sin cuenta, sin phone-home.
$ docker run -p 4000:4000 <registry>/waeg-gateway:<version>No es un pull que funcione: las imágenes aún no son públicas. Los socios de diseño reciben los datos del registro en privado.
Despliega en 5 minutosContribuya a definirlo como design partner
Wäg todavía no se ha publicado. Trabajamos con un grupo reducido de equipos que ejecutan IA multiproveedor en producción y se toman en serio la gobernanza y la soberanía, para endurecer el control plane con cargas de trabajo reales.
- Todas las capacidades Enterprise incluidas, sin coste de licencia
- Migración acompañada: la hacemos con usted, también desde LiteLLM
- Línea directa con los ingenieros que lo construyen e influencia real sobre lo que llega después