Kanban en Hermes Agent para flujos de trabajo de LLM autoalojados

Hermes Agent incluye un tablero de tareas estilo Kanban que puede saturar fácilmente tu pasarela de LLM autoalojada si permites que todas las tareas se ejecuten simultáneamente.

Hermes Kanban es un tablero duradero con múltiples perfiles respaldado por ~/.hermes/kanban.db.
Cada carril representa una fase del trabajo y cada tarjeta es una tarea que puede ser asumida por un perfil específico de Hermes.
De fábrica, el demonio del despachador iniciará agentes para cualquier número de tareas listas (ready), lo cual es excelente para API en la nube, pero peligroso cuando tienes un pequeño clúster de GPUs autoalojadas.

Si eres nuevo en este stack, comienza con la Guía de configuración y operación de Hermes y el Pilar de Sistemas de IA para la arquitectura circundante.

Este artículo muestra cómo:

• Comprender cómo Hermes Kanban y el despachador interactúan con tu pasarela de LLM.
• Configurar la ejecución secuencial o paralela limitada para tareas pesadas.
• Agrupar (batch) el trabajo con cron para que las tareas nocturnas no colisionen con el uso interactivo diurno.
• Monitorear y ajustar el sistema para que tus GPUs estén ocupadas pero nunca sobrecargadas.

Cómo funcionan Hermes Kanban y el despachador

A alto nivel, el sistema tiene tres capas:

1. El tablero — una base de datos SQLite duradera que almacena tareas, columnas, relaciones e historial.
2. Trabajadores — perfiles de Hermes que pueden iniciarse en espacios de trabajo aislados para procesar una tarea.
3. Demonio del despachador — un proceso de larga duración que vigila el tablero y promueve tareas a ejecuciones.

Cuando creas una tarea usando la CLI o el panel de control, normalmente comienza en una columna backlog o ready (lista).
El despachador escanea periódicamente las tareas que cumplen tus filtros, reclama una tarjeta de forma atómica y genera el perfil asignado con las herramientas y la memoria adecuadas.
Cada trabajador luego se comunica con tu pasarela de LLM o runtime local — por ejemplo, un proxy compatible con OpenAI que frontea Ollama, vLLM o llama.cpp. Para decisiones de implementación entre estos runtimes, usa Alojamiento de LLM en 2026: Infraestructura Local, Autoalojada y en la Nube Comparada. Si estás ajustando la dispersión de solicitudes (fan-out) en Ollama en sí, esto se complementa bien con Cómo Ollama Maneja las Solicitudes Paralelas.

Si no haces nada más y agregas cincuenta tareas pesadas de investigación, el despachador puede intentar iniciar las cincuenta, inundando tu pasarela con solicitudes concurrentes. En un nodo limitado por GPU o CPU, esto produce colación, intermitencia (thrashing) y tiempos de espera en lugar de rendimiento.

Estrategia 1: Reducir la concurrencia en el despachador

El control más simple es limitar cuántos trabajadores puede ejecutar el despachador en paralelo. En tu configuración de Hermes, normalmente verás una sección que controla el despachador de Kanban y el grupo de trabajadores.

En las versiones actuales de Hermes, el despachador está integrado en hermes gateway start por defecto, y el mismo núcleo de reclamo y generación aplica los límites de concurrencia allí también.
Sin embargo, los usuarios reportan comportamientos extraños que pueden parecerse a una desviación de los límites, por lo que valida las condiciones de ejecución antes de culpar al límite en sí.

Un ejemplo mínimo usando una configuración estilo TOML podría verse así:

[kanban.dispatcher]
enabled = true
poll_interval_seconds = 10
max_active_tasks = 3

[kanban.workers]
profile = "researcher"
max_parallel_per_profile = 2

Si tu versión usa nombres de claves diferentes, mantén la misma intención al mapear la configuración. Los nombres de los comandos y los flujos de operadores se resumen en la Hoja de trucos de la CLI de Hermes Agent:

• un límite para el total de tareas activas en todo el tablero
• un límite para la paralelización por perfil o por grupo de trabajadores
• intervalo de tick de despacho opcional

Problemas conocidos de la documentación y hilos de la comunidad:

• No ejecutes tanto el despacho integrado en la pasarela como el legado hermes kanban daemon --force en el mismo kanban.db porque eso crea carreras de reclamo.
• Si la pasarela está caída, las tareas ready no se despachan en absoluto, luego parecen estallar cuando la pasarela regresa.
• Un intervalo de despacho largo puede sentirse como una programación desigual porque los reclamos ocurren en ticks en lugar de continuamente.
• Las versiones anteriores de Kanban tenían varios estados de ejecución y casos extremos de reclamación corregidos en parches posteriores, por lo que el comportamiento puede diferir según la versión.

Lista de verificación rápida de verificación cuando el comportamiento parece incorrecto:

# 1) confirmar que exactamente un camino del despachador está activo
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) verificar la bandera de despacho en modo pasarela
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) inspeccionar la forma de la cola
hermes kanban list --status ready
hermes kanban list --status active

Ideas clave:

• max_active_tasks limita cuántas tarjetas de Kanban pueden estar en el estado active a la vez.
• max_parallel_per_profile asegura que incluso si ejecutas muchos perfiles, solo un pequeño número de ellos pesados se ejecuten juntos.
• Con un pequeño clúster autoalojado, generalmente deseas valores entre 1 y 4 para mantener la latencia predecible.

Cuando despliegues Hermes por primera vez cerca de tu pasarela de LLM, comienza de forma conservadora:

• Comienza con max_active_tasks = 1.
• Observa la utilización de GPU y CPU.
• Aumenta a 2 o 3 solo si el hardware está claramente subutilizado.

Estrategia 2: Codificar dependencias para flujos estrictamente secuenciales

Algunos flujos de trabajo deberían ejecutarse estrictamente uno después del otro — por ejemplo:

• pipelines de datos de múltiples pasos con artefactos intermedios compartidos
• migraciones o cambios de infraestructura
• trabajos por lotes que escriben en el mismo objeto de almacenamiento o base de datos

Hermes Kanban admite dependencias padre-hijo entre tareas para que una tarjeta hija sea despachable solo cuando su padre esté terminado.

Puedes modelar esto con un pequeño script auxiliar alrededor de la CLI de Hermes:

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Ingest customer logs for April' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'Generate April anomaly report' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'Publish April summary to dashboard' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

Con una política de tablero apropiada y límites de despachador bajos, solo la tarea padre se ejecuta primero.
Una vez que termina, las tareas hijas gradualmente se vuelven listas, y el despachador las extrae una por una sin exceder nunca tus límites de concurrencia.

Estrategia 3: Deshabilitar el despacho automático y usar cron

Para algunos entornos, puedes preferir ventanas de tiempo explícitas para cargas de trabajo pesadas.
Por ejemplo, podrías querer que las tareas de investigación y la ingestión de documentos se ejecuten después de medianoche mientras las GPUs están inactivas.

Existen dos variantes de programación que la gente llama cron en esta configuración:

1. Cron del host Linux usando crontab.
2. Expresiones cron del programador interno de Hermes en la configuración de Hermes.

Opción A: Cron del host Linux

En este modelo, deshabilitas el despacho automático de Kanban y dejas que el sistema operativo programe un script envoltorio.

Un ejemplo de script:

#!/usr/bin/env bash

set -euo pipefail

MAX_TO_PROMOTE="${1:-3}"

ready_ids="$(hermes kanban list --column ready --limit "${MAX_TO_PROMOTE}" --quiet)"

if [ -z "${ready_ids}" ]; then
  exit 0
fi

for id in ${ready_ids}; do
  echo "Promoting task ${id} to active"
  hermes kanban promote --id "${id}" --column active
done

Luego agrega una entrada de cron de Linux en el host donde se ejecuta el despachador o la pasarela:

*/15 * * * * /opt/hermes/scripts/kanban-promote.sh 2 >> /var/log/hermes/kanban-cron.log 2>&1

Esto garantiza que no más de dos nuevas tareas se vuelvan activas cada quince minutos, independientemente de cuántas tarjetas sueltes en ready.

Opción B: Programador cron interno de Hermes

Si prefieres mantener las reglas de programación dentro de Hermes mismo, define un trabajo programado con una expresión cron en la configuración de Hermes y llama al mismo comando de promoción allí.

Patrón de ejemplo:

[kanban.dispatcher]
enabled = false

[[scheduler.jobs]]
name = "kanban-batch-promote"
cron = "*/15 * * * *"
command = "hermes kanban promote-batch --from ready --to active --max 2"
timezone = "Australia/Melbourne"

Si tu compilación de Hermes expone comandos de gestión del programador, puedes registrar el mismo trabajo desde la CLI en lugar de editar archivos de configuración manualmente:

hermes scheduler jobs add \
  --name "kanban-batch-promote" \
  --cron "*/15 * * * *" \
  --timezone "Australia/Melbourne" \
  --command "hermes kanban promote-batch --from ready --to active --max 2"

hermes scheduler jobs list

Si tu versión instalada no tiene hermes scheduler jobs ..., sigue usando el método basado en configuración anterior, luego recarga o reinicia Hermes para que el programador recoja el nuevo trabajo.

Cómo usar esto de forma segura:

• Mantén kanban.dispatcher.enabled = false si el trabajo del programador es tu único promotor.
• Comienza con un valor --max bajo, como 1 o 2.
• Coloca los registros del programador en tu pipeline de registros normal de Hermes para que las promociones omitidas o fallidas sean visibles.

Esto te da el mismo comportamiento de agrupación que cron de Linux, pero gestionado como configuración de Hermes en lugar de crontab a nivel de host.

Estrategia 4: Segmentar tableros y perfiles para diferentes pasarelas

Si operas múltiples backends de LLM — por ejemplo:

• un nodo GPU pequeño con un modelo instructivo de 7B
• un nodo solo CPU para clasificación liviana
• una caja de alto rendimiento separada para razonamiento pesado

puedes reducir la contención asignando diferentes perfiles y tableros de Hermes a cada pasarela.

Patrón típico:

• Crear perfiles como research-gpu, summarise-cpu, ops-gateway.
• Configurar cada perfil con una URL base y clave de API dedicadas para su propia pasarela.
• Crear carriles de Kanban separados o incluso tableros separados para cada perfil.

Cuando se combina con límites de despachador, esto mantiene cada pasarela saturada por su propio conjunto de trabajadores sin que una carga de trabajo ruidosa prive a las otras de recursos.

Monitoreo y ajuste de Hermes Kanban

Cualquiera sea la estrategia que elijas, debes monitorear:

• Métricas de la pasarela de LLM — tasa de solicitudes, latencia, tasa de errores, rendimiento de tokens.
• Salud del nodo — utilización de GPU, uso de VRAM, carga de CPU y RAM.
• Métricas de Hermes — cuántas tareas están en backlog, ready, active y done.

Para líneas base de métricas de producción y paneles de control, consulta Monitoreo de Inferencia de LLM en Producción con Prometheus y Grafana y el más amplio Hub de Rendimiento de LLM.

Comienza con baja concurrencia, luego aumenta gradualmente los límites mientras observas:

• latencia creciente a rendimiento constante
• aumento de errores de tiempo de espera o límite de tasa
• colas largas donde algunas tareas permanecen activas por un tiempo muy largo

Tan pronto como veas estos síntomas, retrocede a la configuración estable anterior y mantén esa como tu predeterminada.

Cuando Kanban es la herramienta correcta

Hermes Kanban brilla cuando tienes:

• backlogs de investigación o ingeniería de larga duración
• colaboración multi-agente con perfiles nombrados
• flujos de trabajo que deben sobrevivir a reinicios y reinicios del host
• humanos que quieren un panel de control para triar el trabajo

Si solo necesitas una ejecución única para crear algunos ayudantes temporales, las herramientas integradas de delegación de tareas suelen ser más simples.
Una vez que necesitas historial, paneles de control y control estricto sobre cómo tus agentes impactan a los LLM autoalojados, el tablero Kanban más el despachador es la base correcta.

Con algunos ajustes de configuración y agrupación opcional basada en cron, puedes mantener Hermes Kanban receptivo mientras proteges tu pasarela y hardware.