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

Hermes Agent wird mit einem Kanban-Style-Aufgabenboard geliefert, das Ihr selbst gehostetes LLM-Gateway leicht überlasten kann, wenn Sie zulassen, dass alle Aufgaben gleichzeitig ausgeführt werden.

Hermes Kanban ist ein dauerhaftes, multiprofil-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 wird der Dispatcher-Daemon Agenten für beliebig viele fertige (ready) Aufgaben erstellen, was für Cloud-APIs großartig ist, aber gefährlich, wenn Sie über einen kleinen Cluster selbst gehosteter GPUs verfügen.

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

Dieser Beitrag zeigt, wie man:

• Versteht, wie Hermes Kanban und der Dispatcher mit Ihrem LLM-Gateway interagieren.
• Konfiguriert sequentielle oder begrenzt parallele Ausführung für schwere Aufgaben.
• Batcht Arbeit mit Cron, damit Nachtaufgaben nicht mit dem interaktiven Tagesgebrauch kollidieren.
• Überwacht und das System so einstellt, dass Ihre GPUs ausgelastet, aber niemals überlastet bleiben.

Wie Hermes Kanban und der Dispatcher funktionieren

Auf einem hohen Niveau hat das System drei Schichten:

1. Das Board — eine dauerhafte SQLite-Datenbank, die Aufgaben, Spalten, Beziehungen und Historie speichert.
2. Worker — Hermes-Profile, die in isolierten Arbeitsbereichen gestartet werden können, um eine Aufgabe zu verarbeiten.
3. Dispatcher-Daemon — ein langlebiger Prozess, der das Board überwacht und Aufgaben zu Ausführungen befördert.

Wenn Sie eine Aufgabe über die CLI oder das Dashboard erstellen, beginnt sie normalerweise in einer backlog (Rückstand) oder ready (bereit) Spalte.
Der Dispatcher scannt regelmäßig nach Aufgaben, die Ihren Filtern entsprechen, beansprucht eine Karte atomar und startet das zugewiesene Profil mit den richtigen Tools und dem Speicher.
Jeder Worker spricht dann mit Ihrem LLM-Gateway oder der lokalen Laufzeitumgebung — zum Beispiel einer OpenAI-kompatiblen Proxy-Instanz vor Ollama, vLLM oder llama.cpp. Für Bereitstellungsentscheidungen bei diesen Laufzeitumgebungen nutzen Sie den Leitfaden LLM-Hosting im Jahr 2026: Lokal, Selbstgehostet und Cloud-Infrastruktur im Vergleich. Wenn Sie die Fan-out-Anfragen bei Ollama selbst optimieren, passt dies gut zu Wie Ollama parallele Anfragen handhabt.

Wenn Sie nichts weiter tun und fünfzig schwere Forschungsaufgaben hinzufügen, kann der Dispatcher versuchen, alle fünfzig zu starten und Ihr Gateway mit gleichzeitigen Anfragen zu überschwemmen. Auf einem einzelnen GPU- oder CPU-gesättigten Knoten führt dies zu Warteschlangenbildung, Thrashing und Timeouts statt zu Durchsatz.

Strategie 1: Parallelität auf Disputcher-Ebene reduzieren

Die einfachste Kontrolle besteht darin, zu begrenzen, wie viele Worker der Dispatcher parallel ausführen kann. In Ihrer Hermes-Konfiguration sehen Sie typischerweise einen Abschnitt, der den Kanban-Dispatcher und den Worker-Pool steuert.

In aktuellen Hermes-Release-Versionen ist der Dispatcher standardmäßig in hermes gateway start eingebettet, und derselbe Kernel für Beantragung und Start erzwingt dort ebenfalls Parallelitätsbegrenzungen.
Benutzer berichten jedoch von seltsamem Verhalten, das wie eine Drift der Limits aussehen kann, daher sollten Sie die Laufzeitbedingungen validieren, bevor Sie die Begrenzung selbst beschuldigen.

Ein minimales Beispiel mit einer TOML-ähnlichen Konfiguration könnte so aussehen:

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

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

Wenn Ihre Version andere Schlüsselnamen verwendet, bewahren Sie die gleiche Absicht bei der Zuordnung der Einstellungen bei. Die Befehlsnamen und Operator-Abläufe werden im Hermes Agent CLI Cheat Sheet zusammengefasst:

• eine Begrenzung für insgesamt aktive Aufgaben auf dem gesamten Board
• eine Begrenzung für die Parallelität pro Profil oder pro Worker-Pool
• optionales Dispatch-Takt-Intervall

Bekannte Fallstricke aus Dokumentationen und Community-Threads:

• Führen Sie nicht sowohl den gateway-embedded-Dispatch als auch das veraltete hermes kanban daemon --force auf derselben kanban.db aus, da dies zu Beantragungsraces führt.
• Wenn das Gateway ausgefallen ist, werden ready-Aufgaben überhaupt nicht dispatched und scheinen dann zu stürmen, sobald das Gateway zurückkehrt.
• Ein langes Dispatch-Intervall kann sich wie ungleichmäßige Planung anfühlen, da Beantragungen in Takten und nicht kontinuierlich stattfinden.
• Ältere Kanban-Builds hatten mehrere Randfälle bezüglich Ausführungsstatus und Reklamation, die in nachfolgenden Patches behoben wurden, daher kann das Verhalten je nach Version unterschiedlich sein.

Schnelle Verifikationscheckliste, wenn das Verhalten falsch aussieht:

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

# 2) überprüfen Sie die Dispatch-Flagge im Gateway-Modus
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) inspectieren Sie die Warteschlangenform
hermes kanban list --status ready
hermes kanban list --status active

Wichtige Konzepte:

• max_active_tasks begrenzt, wie viele Kanban-Karten gleichzeitig im Zustand active (aktiv) sein können.
• max_parallel_per_profile stellt sicher, dass auch wenn Sie viele Profile ausführen, nur eine kleine Anzahl schwerer Profile zusammenlaufen.
• Bei einem kleinen, selbst gehosteten Cluster möchten Sie normalerweise Werte zwischen 1 und 4, um eine vorhersehbare Latenz zu gewährleisten.

Wenn Sie Hermes zum ersten Mal in der Nähe Ihres LLM-Gateways bereitstellen, beginnen Sie konservativ:

• Beginnen Sie mit max_active_tasks = 1.
• Beobachten Sie die GPU- und CPU-Auslastung.
• Erhöhen Sie auf 2 oder 3 nur, wenn die Hardware eindeutig unterausgelastet ist.

Strategie 2: Abhängigkeiten für streng sequentielle Flows kodieren

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

• mehrstufige Datenpipelines mit gemeinsam genutzten Zwischenartefakten
• Migrationen oder Infrastrukturänderungen
• Batch-Jobs, die in denselben Objektsspeicher oder dieselbe Datenbank schreiben

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

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

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Kundenlogs für April ingestieren' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'April-Anomaliebericht generieren' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'April-Zusammenfassung auf Dashboard veröffentlichen' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

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

Strategie 3: Automatischen Dispatch deaktivieren und Cron verwenden

Für einige Umgebungen können Sie explizite Zeitfenster für schwere Workloads bevorzugen.
Zum Beispiel möchten Sie vielleicht, dass Forschungsaufgaben und Dokument-Ingestion nach Mitternacht laufen, während die GPUs idle sind.

Es gibt zwei Planungsvarianten, die man in diesem Setup als Cron bezeichnet:

1. Linux-Host-Cron unter Verwendung von crontab.
2. Hermes-interne Scheduler-Cron-Ausdrücke in der Hermes-Konfiguration.

Option A: Linux-Host-Cron

In diesem Modell deaktivieren Sie den automatischen Kanban-Dispatch und lassen das Betriebssystem ein Wrapper-Skript planen.

Ein Beispiel-Skript:

#!/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 "Aufgabe ${id} zu aktiv befördern"
  hermes kanban promote --id "${id}" --column active
done

Fügen Sie dann einen Linux-Cron-Eintrag auf dem Host hinzu, auf dem der Dispatcher oder das Gateway läuft:

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

Dies garantiert, dass nicht mehr als zwei neue Aufgaben alle fünfzehn Minuten aktiv werden, unabhängig davon, wie viele Karten Sie in den Status ready setzen.

Option B: Hermes-interner Cron-Scheduler

Wenn Sie Planungsregeln lieber innerhalb von Hermes selbst behalten möchten, definieren Sie einen geplanten Job mit einem Cron-Ausdruck in der Hermes-Konfiguration und rufen Sie dort denselben Befehl zum Befördern auf.

Beispiel-Muster:

[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"

Wenn Ihr Hermes-Build Befehle zur Scheduler-Verwaltung verfügbar macht, können Sie denselben Job über die CLI registrieren, anstatt Konfigurationsdateien manuell zu bearbeiten:

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

Wenn Ihre installierte Version hermes scheduler jobs ... nicht hat, verwenden Sie weiterhin die oben genannte konfigurationsbasierte Methode und laden oder starten Sie Hermes neu, damit der Scheduler den neuen Job aufnimmt.

Wie man dies sicher verwendet:

• Behalten Sie kanban.dispatcher.enabled = false, wenn der Scheduler-Job Ihr einziger Promoter ist.
• Beginnen Sie mit einem niedrigen --max-Wert wie 1 oder 2.
• Legen Sie Scheduler-Logs in Ihre normale Hermes-Log-Pipeline, damit übersprungene oder fehlgeschlagene Beförderungen sichtbar sind.

Dies gibt Ihnen das gleiche Batch-Verhalten wie Linux-Cron, wird jedoch als Hermes-Konfiguration statt als hostseitige crontab verwaltet.

Strategie 4: Boards und Profile für verschiedene Gateways segmentieren

Wenn Sie mehrere LLM-Backends betreiben — zum Beispiel:

• einen kleinen GPU-Knoten mit einem 7B-Instruct-Modell
• einen nur CPU-Knoten für leichte Klassifizierung
• eine separate High-End-Maschine für schwere Reasoning-Aufgaben

können Sie Kollisionen reduzieren, indem Sie verschiedenen Hermes-Profilen und Boards jedem Gateway zuweisen.

Typisches Muster:

• Erstellen Sie Profile wie research-gpu, summarise-cpu, ops-gateway.
• Konfigurieren Sie jedes Profil mit einer dedizierten Basis-URL und einem API-Schlüssel für sein eigenes Gateway.
• Erstellen Sie separate Kanban-Spuren oder sogar separate Boards für jedes Profil.

In Kombination mit Dispatcher-Begrenzungen hält dies jedes Gateway durch seine eigene Menge an Workern gesättigt, ohne dass eine laustige Workload die anderen verhungern lässt.

Hermes Kanban Überwachung und Optimierung

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

• LLM-Gateway-Metriken — Anfragengeschwindigkeit, Latenz, Fehlerrate, Token-Durchsatz.
• Knotengesundheit — GPU-Auslastung, VRAM-Verbrauch, CPU-Last und RAM.
• Hermes-Metriken — wie viele Aufgaben sich in Backlog, Ready, Aktiv und Erledigt befinden.

Für Produktions-Metrik-Baselines und Dashboards sehen Sie LLM-Inferenz in der Produktion mit Prometheus und Grafana überwachen und die umfassendere LLM-Leistungs-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 Enden, bei denen einige Aufgaben sehr lange aktiv bleiben

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

Wann Kanban das richtige Werkzeug ist

Hermes Kanban glänzt, wenn Sie Folgendes haben:

• langlebige Forschungs- oder Engineering-Rückstände
• Multi-Agent-Zusammenarbeit mit benannten Profilen
• Workflows, die Neustarts und Host-Neustarts überstehen müssen
• Menschen, die ein Dashboard zur Triage von Arbeit wünschen

Wenn Sie nur einen einzelnen Lauf benötigen, um einige temporäre Helper zu erstellen, sind die integrierten Delegat-Aufgaben-Tools normalerweise einfacher.
Sobald Sie Historie, Dashboards und strikte Kontrolle darüber benötigen, wie Ihre Agenten selbst gehostete LLMs treffen, ist das Kanban-Board plus Dispatcher die richtige Grundlage.

Mit einigen Konfigurationsanpassungen und optionaler Cron-basierter Batchung können Sie Hermes Kanban reaktionsfähig halten und dabei Ihr Gateway und Ihre Hardware schützen.