litellm-multi-gateway
Gateway multi-backend AI basado en LiteLLM que enruta clientes como Claude Code o Hermes a proveedores ARK/Anthropic/Zhipu. Incluye conversión automática vision-to-text para backends text-only, Admin UI y seguimiento de uso por cliente.
Ficha actualizada 24 sept 2026, 2:50 · upstream 24 sept 2026, 2:30 · release sin release detectada
Qué es litellm-multi-gateway
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
litellm-multi-gateway es una solución de auto-hospedaje construida sobre LiteLLM que resuelve el problema de utilizar planes económicos de codificación (endpoints text-only como ARK/GLM) que no soportan imágenes, combinándolos con la necesidad de un Admin UI para seguimiento de uso y gestión de claves. El sistema permite enrutar múltiples proveedores simultáneamente mediante alias de claves virtuales, eliminando la necesidad de reconfigurar clientes.
La arquitectura incluye soporte dual para protocolos Anthropic (Claude Code) y OpenAI (Hermes), con una capa de hook personalizada que convierte automáticamente imágenes a descripciones de texto cuando el backend destino es text-only. El seguimiento de uso se realiza en PostgreSQL, desglosado por usuario o clave virtual, permitiendo auditoría granular sin intervención manual.
La gestión de claves se centraliza en un script CLI (keys.sh) que permite crear, actualizar y eliminar rutas dinámicamente sin reiniciar el servicio. La configuración de backends se define en un archivo YAML único (backends.yaml), generando automáticamente la configuración interna de LiteLLM para mantener la coherencia entre proveedores.
- Centralizar múltiples proveedores LLM (ARK, Anthropic, Zhipu) en un único endpoint para clientes que no soportan reconfiguración dinámica
- Habilitar visión multimodal en backends text-only mediante conversión automática de imágenes a texto antes del envío al proveedor
- Seguir el uso por cliente o clave virtual sin modificar la configuración del cliente final
- Gestionar rutas y claves dinámicamente vía CLI sin reiniciar el servicio
- Arquitectura dual de protocolo: soporta Anthropic (Claude Code) y OpenAI (Hermes) en el mismo gateway
- CLI keys.sh permite gestión dinámica de claves y rutas sin reinicio del contenedor
- Hook vision-to-text configurable por backend mediante flag needs_vision en backends.yaml
- Admin UI integrado en :4001/ui para gestión visual de claves y seguimiento de uso
- Soporte nativo para Docker Compose con PostgreSQL como base de datos persistente
- Dependencia de un modelo de visión externo (Zhipu GLM-5V-Turbo o GPT-4o) que añade latencia y costo adicional
- Pérdida de precisión en tareas pixel-perfect al convertir imágenes a descripciones textuales
- Acoplamiento a PostgreSQL; no soporta bases de datos alternativas sin cambios en el código
- La conversión vision-to-text es opcional y debe configurarse explícitamente por backend
- Puerto 4001 puede requerir configuración de proxy bypass en entornos locales con Clash o similares
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Para desarrollo local, usar Docker Compose con 2 núcleos CPU y 2GB RAM mínimo. Configurar proxy bypass para 127.0.0.1/localhost en la UI admin. Para producción PaaS (Railway/Render), usar el Dockerfile incluido con instancia de Postgres gestionada vía DATABASE_URL. Migrar a HTTPS mediante dominio asignado por el proveedor PaaS. Verificar imagen localmente con ./scripts/verify-image.sh antes de desplegar.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.