marbor
Marbor es un control plane para inferencia de IA autocontenido, que aloja modelos en GPU con ruteo inteligente basado en estado caliente (VRAM), orquestación multi-runtime y orquestación de trabajo por presión. Es una única binaria en Go.
Ficha actualizada 22 sept 2026, 18:28 · upstream 22 sept 2026, 17:15 · release v0.20.0
Qué es marbor
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Marbor es el control plane para la inferencia de IA autocontenida. Utiliza ruteo inteligente de GPU, orquestación multi-runtime entre Ollama, vLLM, llama.cpp, TGI y MLX. Se ejecuta con un único binario en Go.
- Alojamiento de modelos LLM en infraestructura local sin dependencias externas
- Reducción de latencia de inicio (cold-start) mediante ruteo a GPU con modelo ya calientado
- Orquestación multi-runtime que coordina múltiples motores de inferencia en un solo nodo
- Monitoreo y control de costos por token, con alertas cuando el gasto supera límites configurados
- Ruteo inteligente basado en VRAM disponible, GPU count y presión de trabajo del nodo
- Orquestación de despliegues multi-nodo para modelos tensor/parallel que requieren múltiples GPUs
- Ruteo a modelo calientado (warm state) reduce la latencia de inicio en hasta 43x comparado con carga fría
- Monitoreo por token real y atribución por clave API, sin estimaciones ni costos totales
- Orquestación multi-runtime que coordina Ollama, vLLM, llama.cpp, TGI y MLX desde un solo nodo
- Ruteo basado en GPU count (tensor/parallel) no solo VRAM disponible
- Sistema de persistencia con SQLite para sesiones de conversación con TTL de evicción
- Soporte para despliegues multi-nodo con orquestación de replicas y estado de resolución
- El ruteo a modelo calientado depende del tiempo de polling (2s) en cada nodo, lo que puede causar latencia adicional si el modelo no está completamente caliente
- La persistencia con SQLite se pierde al reiniciar la aplicación o el sistema operativo
- No hay soporte nativo para GPU hardware acelerado como NVIDIA CUDA (solo API)
- El monitoreo de costos es proporcional a tokens procesados, lo que puede ser ineficiente en modelos pequeños o de uso esporádico
- La orquestación multi-runtime requiere configuración manual del estado de cada nodo y no resuelve conflictos por defecto
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: `docker compose up -d` para el gateway, `docker compose -f docker-compose.yml -f docker-compose.monitoring.yml up -d` para incluir Prometheus y Grafana. Para producción recomendada, usar la versión instalable con `SERVICE=1` que inicia un servicio systemd persistente. El binario es estático en Go sin dependencias de runtime. Se recomienda mantener el binario actualizado al actualizar las imágenes de los modelos.
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.