Kanban en Hermes Agent para flujos de trabajo de LLMs autoalojados

El agente Hermes incluye un tablero estilo Kanban y el Hermes Gateway, que pueden saturar su LLM autoalojado si se asignan demasiadas tareas a la vez.

Puedo decir que de esta forma es fácil realizar un ataque de denegación de servicio (DDoS) a su propio LLM.

Hermes Kanban es un tablero multiperfil duradero respaldado por ~/.hermes/kanban.db. Cada carril representa una fase del trabajo y cada tarjeta es una tarea que puede ser reclamada por un perfil específico de Hermes. De serie, el despachador puede promover muchas tareas ready (listas) en un solo pase. Esto está bien para APIs en la nube elásticas, pero puede sobrecargar un pequeño clúster de GPU autoalojado.

Si es nuevo en este conjunto de herramientas, comience con la guía de configuración y operaciones de Hermes y el pilar de Sistemas de IA para la arquitectura circundante.

Este post muestra cómo:

• Comprender cómo la asignación de Hermes Kanban interactúa con su puerta de enlace LLM.
• Controlar el paralelismo de forma segura para tareas pesadas.
• Agrupar las promociones con cron para que las tareas en segundo plano no colisionen con el uso interactivo.
• Monitorear y ajustar el sistema para que las GPUs estén ocupadas sin sobrecarga.

Cómo funciona Hermes Kanban y el despachador

A un alto nivel, el sistema tiene tres capas:

1. Tablero - estado SQLite duradero para tareas, columnas, relaciones e historial.
2. Trabajadores - perfiles de Hermes iniciados en espacios de trabajo aislados para procesar una tarea.
3. Despachador - un proceso de larga duración que busca tarjetas despachables e inicia ejecuciones.

Las tareas creadas desde la CLI o el panel de control suelen comenzar en backlog (lista de pendientes) o ready (lista). El despachador escanea en busca de tarjetas elegibles, reclama una de forma atómica e inicia el perfil asignado con sus herramientas y memoria. Cada trabajador luego llama a su puerta de enlace LLM o tiempo de ejecución local (por ejemplo, puntos finales compatibles con OpenAI respaldados por Ollama, vLLM o llama.cpp). Para las opciones de implementación entre estos tiempos de ejecución, utilice Alojamiento de LLM en 2026: Infraestructura Local Autoalojada y en la Nube Comparada. Si está ajustando la difusión de solicitudes en el propio Ollama, esto combina bien con Cómo Ollama maneja las solicitudes paralelas.

Si agrega muchas tareas pesadas y no limita las promociones, su puerta de enlace puede inundarse con solicitudes concurrentes. En un host con una sola GPU o limitado por CPU, eso a menudo significa colas, intercambio excesivo (thrashing) y tiempos de espera agotados en lugar de un mejor rendimiento.

La limitación práctica hoy en día

En las versiones actuales de Hermes que muchos equipos utilizan, la configuración del despachador expone solo dos claves de despacho de Kanban y no aplica un límite global de tareas activas desde la configuración:

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 10

Para el control de tareas activas, confíe en la cadencia de despacho explícita (hermes kanban dispatch --max ...) junto con la modelización de dependencias.

Problemas conocidos:

• No ejecute el despacho incrustado en la puerta de enlace y hermes kanban daemon --force contra el mismo tablero, o podría obtener carreras de reclamación.
• Si la puerta de enlace está caída, las tareas ready no se despachan y pueden estallar más tarde cuando el servicio se recupere.
• Los intervalos de despacho más largos se sienten desiguales porque la reclamación ocurre en intervalos.
• El comportamiento puede variar entre versiones porque los casos extremos de estado de ejecución y reclamación se parcharon con el tiempo.

Verificación rápida cuando el comportamiento parece incorrecto:

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

# 2) verifique las claves del despachador de Kanban cableadas
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) inspeccione la forma de la cola
hermes kanban list --status ready
hermes kanban list --status running

Ideas clave:

• La configuración del despachador cablea dispatch_in_gateway y dispatch_interval_seconds.
• dispatch --max limita los nuevos lanzamientos en ese pase, no las tareas en ejecución totales.
• Para clústeres autoalojados pequeños, comience de manera conservadora y aumente solo después de que la latencia se mantenga estable.

Al desplegar Hermes por primera vez cerca de su puerta de enlace LLM:

• Mantenga solo las claves del despachador de Kanban compatibles en la configuración.
• Observe la utilización de GPU y CPU bajo presión de cola real.
• Use la Estrategia 1 o la Estrategia 2 para un ritmo determinista.

Hallazgos de investigación y causa raíz

hermes kanban dispatch no lee config.yaml para max_active_tasks.

En hermes_cli/kanban.py, el comando de despacho expone --max como un límite de CLI (predeterminado None) y pasa solo args.max a kb.dispatch_once(...). No hay búsqueda de configuración max_active_tasks en esta ruta. Ver hermes_cli/kanban.py raw.

Luego en kanban_db.dispatch_once, el único límite es max_spawn, con lógica equivalente a:

if max_spawn is not None and spawned >= max_spawn:
    break

No hay verificación de tareas ya en ejecución y ninguna referencia a max_active_tasks en esa ruta de despacho. Ver hermes_cli/kanban_db.py raw.

Comportamiento efectivo:

hermes kanban dispatch

ilimitado para ese pase (limitado por el tamaño de la cola lista).

hermes kanban dispatch --max 2

limita solo los nuevos lanzamientos en ese pase, no las tareas en ejecución totales.

Los controles de configuración cableados alrededor del despacho de la puerta de enlace son kanban.dispatch_in_gateway y kanban.dispatch_interval_seconds. Por lo tanto, max_active_tasks se ignora en esta ruta de despacho porque no está implementado allí.

Estrategia 1 - Codificar dependencias para flujos estrictamente secuenciales

Algunos flujos de trabajo deben ejecutarse estrictamente uno tras 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 almacén de objetos 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.

Puede 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 adecuada 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 sus límites de concurrencia.

Estrategia 2 - Usar cron de Linux con un límite de despacho consciente de lo que está en ejecución

Si desea un ritmo determinista, use cron del host junto con un pequeño script envoltorio. En lugar de llamar siempre a dispatch --max 2, primero cuente las tareas en ejecución actualmente, luego despache solo los slots restantes.

Cree hermes-kanban-dispatch-capped.sh:

#!/usr/bin/env bash
set -euo pipefail

MAX_PARALLEL="${MAX_PARALLEL:-2}"
BOARD="${BOARD:-}"

board_args=()
if [[ -n "$BOARD" ]]; then
  board_args=(--board "$BOARD")
fi

# o donde esté instalado su hermes
export PATH="/home/abc/.local/bin:$PATH"

running_out="$(hermes kanban "${board_args[@]}" list --status running)"

if [[ "$running_out" == *"(no matching tasks)"* ]]; then
  running_count=0
else
  running_count="$(printf '%s\n' "$running_out" | wc -l)"
fi

slots=$(( MAX_PARALLEL - running_count ))

if (( slots <= 0 )); then
  echo "Already at limit running=$running_count max=$MAX_PARALLEL dispatch skipped"
  exit 0
fi

echo "running=$running_count max=$MAX_PARALLEL slots=$slots dispatching up to $slots"

hermes kanban "${board_args[@]}" dispatch --max "$slots"

Hágalo ejecutable:

chmod +x ./hermes-kanban-dispatch-capped.sh

Ejecute con:

MAX_PARALLEL=2 ./hermes-kanban-dispatch-capped.sh

Para un tablero específico:

BOARD=my-board MAX_PARALLEL=2 ./hermes-kanban-dispatch-capped.sh

Programarlo una vez por minuto con cron:

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

Notas operativas:

• Cron a menudo tiene una PATH mínima, por lo que si hermes no se encuentra, use su ruta completa dentro del script (por ejemplo /usr/local/bin/hermes).
• Si registra en /var/log/hermes/..., cree ese directorio primero y asegúrese de que el usuario de cron tenga acceso de escritura.

Ejemplo:

sudo mkdir -p /var/log/hermes
sudo chown "$USER":"$USER" /var/log/hermes

Crear o editar entradas de cron con:

crontab -e

Luego verifique con:

crontab -l

Cadencia sub-minuto con una entrada de cron

Cron marca una vez por minuto, pero aún puede despachar con más frecuencia ejecutando un bucle corto dentro del script.

Ejemplo hermes-kanban-dispatch-subminute.sh:

#!/usr/bin/env bash
set -euo pipefail

LOCK_FILE="/tmp/hermes-kanban-dispatch.lock"
RUNS_PER_MINUTE="${RUNS_PER_MINUTE:-4}"    # 4 ejecuciones => cada 15 segundos
CAP_SCRIPT="${CAP_SCRIPT:-/opt/hermes/scripts/hermes-kanban-dispatch-capped.sh}"

exec 9>"$LOCK_FILE"
flock -n 9 || exit 0

sleep_seconds=$(( 60 / RUNS_PER_MINUTE ))

for ((i=1; i<=RUNS_PER_MINUTE; i++)); do
  "$CAP_SCRIPT"

  if (( i < RUNS_PER_MINUTE )); then
    sleep "$sleep_seconds"
  fi
done

Hágalo ejecutable:

chmod +x ./hermes-kanban-dispatch-subminute.sh

Programarlo una vez por minuto:

* * * * * /opt/hermes/scripts/hermes-kanban-dispatch-subminute.sh >> /var/log/hermes/kanban-subminute.log 2>&1

Esto proporciona una cadencia efectiva sub-minuto mientras flock evita ejecuciones superpuestas.

Por qué funciona:

• list --status running da la carga en ejecución actual.
• dispatch --max N limita solo los nuevos lanzamientos para ese pase.
• Calcular N como slots restantes mantiene las tareas en ejecución totales cerca de su límite objetivo.

Aviso importante: este límite funciona solo para despachos realizados a través de este script. Desactive el despacho incrustado en la puerta de enlace, de lo contrario aún puede promover tareas de manera independiente:

kanban:
  dispatch_in_gateway: false

La documentación oficial describe ambas capacidades de comando y señala los valores predeterminados del despacho de la puerta de enlace en la guía de características de Kanban: Documentación de Hermes Kanban.

Hermes Cron Interno

No lo use. ¿Realmente quiere que su LLM procese prompts regulares como Execute in terminal the command /path/hermes-kanban-dispatch-capped.sh, especialmente cuando está ocupado haciendo algún trabajo útil?

Monitoreo y ajuste de Hermes Kanban

Cualquiera sea la estrategia que elija, debe monitorear:

• Métricas de la puerta de enlace 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 (pendientes), ready (listas), active (activas) y done (hechas).

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

Comience con baja concurrencia, luego aumente gradualmente los límites mientras observa:

• latencia creciente con rendimiento constante
• aumento de errores de tiempo de espera o límite de tasa
• colas largas donde algunas tareas permanecen activas durante mucho tiempo

Tan pronto como vea estos síntomas, vuelva a la configuración estable anterior y manténgala como su predeterminada.

Cuando Kanban es la herramienta correcta

Hermes Kanban brilla cuando tiene:

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

Si solo necesita una ejecución única para crear algunos ayudantes temporales, las herramientas de tarea delegadas integradas suelen ser más simples. Una vez que necesita historial, paneles de control y control estricto sobre cómo sus 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, puede mantener Hermes Kanban receptivo mientras protege su puerta de enlace y hardware.