jobd
Jobd es un broker de tareas autoalojado y GPU-aware para máquinas propias, con integración nativa de MCP/agent.
Ficha actualizada 23 sept 2026, 4:28 · upstream 23 sept 2026, 4:15 · release v0.5.46
Qué es jobd
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
jobd permite ejecutar múltiples trabajos en paralelo sobre varias máquinas conectadas a la red (por ejemplo, mediante Tailscale). Distingue entre el broker que coordina las tareas y los workers que ejecutan cada tarea. El broker realiza un balanceo por VRAM disponible, preempts tareas cuando hay más carga y soporta una interfaz MCP nativa para agentes de IA como Claude Code.
Se diferencia de herramientas similares porque ofrece: (1) balanceo de recursos en tiempo real basado en VRAM libre, (2) preemoción con checkpoint duradero, (3) persistencia entre sesiones sin necesidad de reiniciar el servidor, y (4) una interfaz MCP para que agentes de IA puedan interactuar con los trabajos. No requiere Kubernetes ni Slurm; es un único proceso por máquina.
Se recomienda usarlo en homelabs con 2–5 GPUs donde no se puede instalar Slurm o Docker-in-Docker.
- Ejecutar entrenamientos de IA distribuidos entre múltiples GPUs sin necesidad de Slurm ni Kubernetes
- Automatizar pipelines de datos que requieren GPU y deben ejecutarse en la máquina con más VRAM disponible
- Crear un scheduler de tareas personalizable mediante MCP para agentes de IA como Claude Code o Cursor
- Ejecutar trabajos de análisis de datos que necesitan GPU pero no pueden instalarse en una infraestructura centralizada
- Gestionar múltiples cargas de trabajo con diferentes requerimientos de VRAM y CPU en un entorno local
- Balanceo por VRAM libre: el broker asigna cada tarea a la máquina que tenga suficiente memoria gráfica disponible, evitando que una GPU se quede ociosa.
- Preemoción con checkpoint duradero: si un trabajo más prioritario se ejecuta, el worker puede detenerlo y guardar un checkpoint persistente para rescatarlo sin reiniciar.
- Integración nativa de MCP: permite que agentes de IA como Claude Code o Cursor actúen como clientes del broker sin necesidad de configurar una API externa.
- Persistencia entre sesiones: los trabajos se guardan en el broker incluso si se cierra la terminal, permitiendo continuar desde donde se dejó.
- Sin dependencias pesadas: no requiere Kubernetes, Slurm ni Docker-in-Docker; es un único proceso Python por máquina que puede ejecutarse con systemd o cron.
- No soporta múltiples GPUs en una sola tarea (solo permite una GPU por job).
- El balanceo por VRAM no garantiza que el trabajo tenga suficiente CPU para ejecutarse, lo que puede causar cuellos de botella.
- La persistencia entre sesiones depende del almacenamiento local; si se pierde la conexión a la red o al servidor, los trabajos pueden perderse.
- No tiene un sistema de límites de tiempo por job ni de ejecución por worker (no hay timeout configurable).
- El balanceo por VRAM puede ser ineficiente en entornos con muchas GPUs pequeñas que compiten por recursos limitados.
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 desplegar, instala el broker como servicio systemd o cron. Usa un token de autenticación único para cada proyecto y rota periódicamente. Para workers, usa systemd-run --user con límites de memoria y CPU. En producción, considera replicar el broker en múltiples nodos si la carga es alta. El broker se ejecuta en modo no autorizado por defecto (JOBD_ALLOW_NO_AUTH=1) para evitar problemas de autenticación entre máquinas.
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.