LLMGW
LLMGW es un gateway en Go que aloja una API de LLM con autenticación y facturación. Es un solo proceso, contenedor único y listener, sin proxy intermedio entre el SDK y la API.
Ficha actualizada 23 sept 2026, 11:35 · upstream 23 sept 2026, 11:22 · release v1.7.0
Qué es LLMGW
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
LLMGW es un gateway de lenguaje de modelo (LLM) autocontenido en un solo proceso ejecutado en Go. Integra CLIProxyAPI directamente dentro del binario, eliminando la necesidad de un segundo servicio o proxy inverso entre el SDK y la API. El proyecto gestiona autenticación con claves de proyecto, presupuestos por proyecto y registro de uso normalizado en PostgreSQL.
LLMGW se diferencia de otros gateways al ser completamente autocontenido: no requiere procesos hijos ni proxies adicionales. La arquitectura es monolítica donde CLIProxyAPI mantiene su propio manejo de protocolos, autenticación del proveedor, mapeo de modelos y comportamiento de cooldown. Esto simplifica la operación operativa y reduce la superficie de ataque.
La API se conecta directamente al SDK mediante llamadas HTTP estándar (Bearer token o x-api-key), sin reescritura de rutas ni transformación de payloads. El gateway actúa como un puente seguro que aplica políticas de presupuesto, auditoría y seguridad antes de delegar a CLIProxyAPI.
- Gestión de APIs de LLM con autenticación centralizada
- Implementación de presupuestos por proyecto con límites de tokens o llamadas
- Auditoría de uso en tiempo real mediante registro en PostgreSQL
- Seguridad reforzada con claves de proyecto y políticas de presupuesto
- Escalabilidad horizontal sin cambiar la arquitectura del SDK
- Monitoreo de costos y rendimiento por modelo
- Arquitectura monolítica en un único proceso (Go) que elimina proxies intermedios
- Autenticación centralizada con claves de proyecto gestionadas por el gateway
- Presupuestos aplicados al nivel del SDK sin reescritura de rutas
- Registro completo de uso normalizado en PostgreSQL para auditoría
- Soporte nativo de múltiples proveedores (Anthropic, OpenAI, Gemini) mediante CLIProxyAPI
- Configuración de cooldown por error transitorio y retry inteligente
- El gateway no puede reescribir rutas ni modificar payloads del SDK sin afectar el comportamiento del proveedor
- La autenticación con claves de proyecto se realiza en la capa del SDK, no en LLMGW
- No hay soporte nativo para orquestación multi-inicio (Kubernetes) en la configuración actual
- El registro de uso requiere una base de datos externa (PostgreSQL), lo que añade dependencias operativas
- La persistencia de claves se realiza en el SDK, no en LLMGW, limitando la gestión centralizada
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.
Instalación con Docker Compose: copiar config.example.yaml y .env.example, configurar variables de entorno (LLMGW_CONFIG, LLMGW_POSTGRES_DSN, LLMGW_KEY_PEPPER), ejecutar `docker compose up -d` y `curl http://127.0.0.1:8088/healthz`. Para producción, usar un tag immutable en LLMGW_IMAGE_TAG, desplegar con `docker compose pull`, redirigir tráfico y verificar que no existan instancias concurrentes del servicio. El binario hostable se ejecuta con `LLMGW_CONFIG=./config.yaml llmgw serve` y sigue el mismo flujo de cutover. Se recomienda mantener la configuración en modo host-side (0600) para evitar exposición de claves, usar secret manager para valores sensibles y no escalar réplicas del servicio.
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.