Kanban in Hermes Agent für selbst gehostete LLM-Workflows

Der Hermes Agent wird mit einem Kanban-Board und dem Hermes Gateway ausgeliefert. Wenn zu viele Aufgaben auf einmal zugewiesen werden, kann dies Ihr selbst gehostetes LLM überlasten.

Ich kann sagen, dass Sie Ihr eigenes LLM auf diese Weise leicht einer DDoS-Attacke aussetzen können.

Hermes Kanban ist ein robustes, multi-profil-fähiges Board, das von ~/.hermes/kanban.db unterstützt wird.
Jede Spur repräsentiert eine Arbeitsphase, und jede Karte ist eine Aufgabe, die von einem bestimmten Hermes-Profil beansprucht werden kann.
Standardmäßig kann der Dispatcher viele bereit (ready) Aufgaben in einem Durchgang fördern. Das ist für elastische Cloud-APIs in Ordnung, kann aber einen kleinen, selbst gehosteten GPU-Cluster überlasten.

Wenn Sie neu in diesem Stack sind, beginnen Sie mit dem umfassenden Hermes Setup- und Operationsleitfaden und der AI Systems Säule für die umgebende Architektur.

Dieser Beitrag zeigt, wie man:

• Versteht, wie die Hermes Kanban-Verteilung mit Ihrem LLM-Gateway interagiert.
• Parallelität sicher für schwere Aufgaben steuert.
• Förderung mit Cron bündelt, damit Hintergrundjobs nicht mit interaktiver Nutzung kollidieren.
• Das System überwacht und anpasst, sodass GPUs ausgelastet bleiben, ohne überlastet zu werden.

Wie Hermes Kanban und der Dispatcher funktionieren

Im Großen und Ganzen hat das System drei Schichten:

1. Board – Robuster SQLite-Zustand für Aufgaben, Spalten, Beziehungen und Historie.
2. Worker – Hermes-Profile, die in isolierten Arbeitsbereichen gestartet werden, um eine Aufgabe zu verarbeiten.
3. Dispatcher – Ein langlebiger Prozess, der nach zu verteilenden Karten scannt und Ausführungen startet.

Aufgaben, die über die CLI oder das Dashboard erstellt werden, starten normalerweise in backlog (Rückstand) oder ready (bereit).
Der Dispatcher scannt nach berechtigen Karten, beansprucht eine atomar und startet das zugewiesene Profil mit seinen Tools und seinem Speicher.
Jeder Worker ruft dann Ihr LLM-Gateway oder die lokale Laufzeit auf (zum Beispiel OpenAI-kompatible Endpunkte, die von Ollama, vLLM oder llama.cpp unterstützt werden). Für Bereitstellungsentscheidungen über diese Laufzeiten hinweg nutzen Sie den Leitfaden LLM Hosting in 2026: Lokale Selbsthosting- und Cloud-Infrastruktur im Vergleich. Wenn Sie die Anfrageausbreitung (Fan-out) bei Ollama selbst anpassen, passt dies gut zusammen mit Wie Ollama parallele Anfragen handhabt.

Wenn Sie viele schwere Aufgaben hinzufügen und die Förderung nicht begrenzen, kann Ihr Gateway mit gleichzeitigen Anfragen überschwemmt werden.
Auf einem Host mit einer einzigen GPU oder CPU-Bindung bedeutet das oft Warteschlangenbildung, Thrashing und Timeouts anstatt einer besseren Durchsatzrate.

Die praktische Einschränkung heute

In aktuellen Hermes-Builds, die viele Teams nutzen, exponiert die Dispatcher-Konfiguration nur zwei Kanban-Dispatch-Schlüssel und wendet keine globale Begrenzung für aktive Aufgaben aus der Konfiguration an:

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 10

Verlassen Sie sich für die Kontrolle aktiver Aufgaben auf explizite Dispatch-Rhythmen (hermes kanban dispatch --max ...) sowie Abhängigkeitsmodellierung.

Bekannte Fallstricke:

• Führen Sie keinen gateway-embedded Dispatch und hermes kanban daemon --force gegen dasselbe Board aus, sonst können Sie Claim-Rennbedingungen (Race Conditions) erhalten.
• Wenn das Gateway ausgefallen ist, werden ready-Aufgaben nicht verteilt und können später, wenn der Dienst zurückkehrt, in einem Burst auftreten.
• Längere Dispatch-Intervalle fühlen sich ungleichmäßig an, da die Beantragung in Ticks erfolgt.
• Das Verhalten kann zwischen Versionen variieren, da Laufzustands- und Reclaim-Edge-Cases im Laufe der Zeit gepatcht wurden.

Schnelle Verifikation, wenn das Verhalten falsch erscheint:

# 1) bestätigen, dass genau ein Dispatcher-Pfad aktiv ist
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) prüfen Sie die verkabelten Kanban-Dispatcher-Schlüssel
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) inspizieren Sie die Warteschlangenform
hermes kanban list --status ready
hermes kanban list --status running

Wichtige Ideen:

• Die Dispatcher-Konfiguration verkabelt dispatch_in_gateway und dispatch_interval_seconds.
• dispatch --max begrenzt neue Starts nur in diesem Durchgang, nicht die gesamte Anzahl laufender Aufgaben.
• Beginnen Sie bei kleinen selbst gehosteten Clustern konservativ und erhöhen Sie die Werte nur, wenn die Latenz stabil bleibt.

Beim ersten Deployment von Hermes in der Nähe Ihres LLM-Gateways:

• Behalten Sie nur unterstützte Kanban-Dispatcher-Schlüssel in der Konfiguration bei.
• Beobachten Sie die GPU- und CPU-Auslastung unter realistischem Warteschlangen-Druck.
• Verwenden Sie Strategie 1 oder Strategie 2 für deterministische Taktung.

Untersuchungsergebnisse und Root Cause

hermes kanban dispatch liest max_active_tasks nicht aus config.yaml.

In hermes_cli/kanban.py exponiert der Dispatch-Befehl --max als CLI-Begrenzung (Standard None) und übergibt nur args.max an kb.dispatch_once(...). Es gibt keine max_active_tasks-Konfigurationsabfrage in diesem Pfad. Siehe hermes_cli/kanban.py raw.

Dann in kanban_db.dispatch_once ist die einzige Begrenzung max_spawn, mit Logik, die äquivalent zu folgendem ist:

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

Es gibt keine Überprüfung bereits laufender Aufgaben und keinen max_active_tasks-Verweis in diesem Dispatch-Pfad. Siehe hermes_cli/kanban_db.py raw.

Effektives Verhalten:

hermes kanban dispatch

ist für diesen Durchgang ungebunden (begrenzt durch die Größe der ready-Warteschlange).

hermes kanban dispatch --max 2

begrenzt nur neue Starts in diesem Durchgang, nicht die gesamte Anzahl laufender Aufgaben.

Die verkabelten Konfigurationsregler für den Gateway-Dispatch sind kanban.dispatch_in_gateway und kanban.dispatch_interval_seconds.
Daher wird max_active_tasks in diesem Dispatch-Pfad ignoriert, da es dort nicht implementiert ist.

Strategie 1 - Kodieren von Abhängigkeiten für streng sequentielle Flows

Einige Workflows sollten streng nacheinander ausgeführt werden – zum Beispiel:

• Mehrstufige Datenpipelines mit geteilten Zwischenartefakten
• Migrationen oder Infrastrukturänderungen
• Batch-Jobs, die in denselben Objektspeicher oder dieselbe Datenbank schreiben

Hermes Kanban unterstützt Parent-Child-Abhängigkeiten zwischen Aufgaben, sodass eine Child-Karte erst dann dispatchbar wird, wenn ihr Parent abgeschlossen ist.

Sie können dies mit einem kleinen Helper-Skript um die Hermes CLI herum modellieren:

#!/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}"

Mit einer angemessenen Board-Richtlinie und niedrigen Dispatcher-Limits läuft nur die Parent-Aufgabe zuerst.
Sobald sie abgeschlossen ist, werden die Child-Aufgaben allmählich bereit, und der Dispatcher zieht sie einzeln, ohne jemals Ihre Parallelitätsbegrenzungen zu überschreiten.

Strategie 2 - Verwenden von Linux cron mit einer laufbewussten Dispatch-Begrenzung

Wenn Sie deterministische Taktung wünschen, verwenden Sie Host-Cron plus ein kleines Wrapper-Skript.
Statt immer dispatch --max 2 aufzurufen, zählen Sie zuerst die aktuell laufenden Aufgaben und dispatchen nur die verbleibenden Slots.

Erstellen Sie 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

# oder wo Ihr hermes installiert ist
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"

Machen Sie es ausführbar:

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

Starten Sie es mit:

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

Für ein spezifisches Board:

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

Planen Sie es einmal pro Minute mit cron:

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

Betriebshinweise:

• Cron hat oft eine minimale PATH, also wenn hermes nicht gefunden wird, verwenden Sie seinen vollständigen Pfad innerhalb des Skripts (zum Beispiel /usr/local/bin/hermes).
• Wenn Sie nach /var/log/hermes/... loggen, erstellen Sie dieses Verzeichnis zuerst und stellen Sie sicher, dass der Cron-Benutzer Schreibzugriff hat.

Beispiel:

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

Erstellen oder bearbeiten Sie Cron-Einträge mit:

crontab -e

Verifizieren Sie dann mit:

crontab -l

Sub-Minuten-Taktung mit einem Cron-Eintrag

Cron tickt einmal pro Minute, aber Sie können immer noch häufiger dispatchen, indem Sie eine kurze Schleife innerhalb des Skripts ausführen.

Beispiel 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 runs => every 15 seconds
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

Machen Sie es ausführbar:

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

Planen Sie es einmal pro Minute:

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

Dies ergibt eine effektive Sub-Minuten-Taktung, während flock überlappende Ausführungen verhindert.

Warum das funktioniert:

• list --status running gibt die aktuelle Last der laufenden Aufgaben.
• dispatch --max N begrenzt nur neue Starts für diesen Durchgang.
• Das Berechnen von N als verbleibende Slots hält die Gesamtzahl der laufenden Aufgaben nahe an Ihrem Zielwert.

Wichtiger Hinweis: Diese Begrenzung funktioniert nur für Dispatches, die über dieses Skript erfolgen.
Deaktivieren Sie den gateway-embedded Dispatch, sonst kann er Aufgaben weiterhin unabhängig fördern:

kanban:
  dispatch_in_gateway: false

Die offiziellen Docs beschreiben beide Befehlsfähigkeiten und notieren die Gateway-Dispatch-Defaults im Kanban-Feature-Leitfaden: Hermes Kanban docs.

Internes Hermes Cron

Verwenden Sie es nicht. Wollen Sie wirklich, dass Ihr LLM regelmäßige Prompts wie Execute in terminal the command /path/hermes-kanban-dispatch-capped.sh verarbeitet, besonders wenn es mit nützlicher Arbeit beschäftigt ist?

Hermes Kanban Monitoring und Tuning

Welche Strategie Sie auch wählen, Sie sollten überwachen:

• LLM-Gateway-Metriken – Anfragetakt, Latenz, Fehlerrate, Token-Durchsatz.
• Knotengesundheit – GPU-Auslastung, VRAM-Nutzung, CPU-Last und RAM.
• Hermes-Metriken – Wie viele Aufgaben sich in Backlog, Ready, Aktiv und Fertig befinden.

Für Produktions-Metrik-Baselines und Dashboards siehe Monitor LLM Inference in Production with Prometheus and Grafana und die umfassendere LLM Performance Hub.

Beginnen Sie mit niedriger Parallelität und erhöhen Sie dann allmählich die Limits, während Sie auf Folgendes achten:

• Steigende Latenz bei konstantem Durchsatz
• Zunehmende Timeout- oder Rate-Limit-Fehler
• Lange Schweifverteilungen, bei denen einige Aufgaben sehr lange aktiv bleiben

Sobald Sie diese Symptome sehen, rollen Sie zur vorherigen stabilen Konfiguration zurück und behalten diese als Standard.

Wann Kanban das richtige Werkzeug ist

Hermes Kanban glänzt, wenn Sie haben:

• Langlebige Forschungs- oder Engineering-Backlogs
• Multi-Agent-Zusammenarbeit mit benannten Profilen
• Workflows, die Neustarts und Host-Neustarts überleben müssen
• Menschen, die ein Dashboard zur Triagierung von Arbeit wünschen

Wenn Sie nur einen einzelnen Lauf benötigen, um einige temporäre Helfer zu erstellen, sind die eingebauten Delegierte-Aufgaben-Tools (delegate task tools) in der Regel einfacher.
Sobald Sie Historie, Dashboards und strenge Kontrolle darüber benötigen, wie Ihre Agents selbst gehostete LLMs treffen, ist das Kanban-Board plus Dispatcher die richtige Grundlage.

Mit einigen Konfigurationsanpassungen und optionaler cron-basierter Bündelung können Sie Hermes Kanban reaktionsfähig halten, während Sie Ihr Gateway und Ihre Hardware schützen.