Kanban in Hermes Agent voor zelfgehoste LLM-workflows

Hermes Agent wordt geleverd met een Kanban-stijl takenbord dat uw zelfgehoste LLM-gateway gemakkelijk kan overbelasten als u alle taken tegelijk laat draaien.

Hermes Kanban is een duurzaam, multiprofielbord dat wordt ondersteund door ~/.hermes/kanban.db.
Elke rij vertegenwoordigt een werkfase en elke kaart is een taak die kan worden opgepakt door een specifiek Hermes-profiel.
Standaard zal de dispatcher-daemon graag agents starten voor elk aantal ready (klaar) taken, wat geweldig is voor cloud-API’s, maar gevaarlijk wanneer u een kleine cluster van zelfgehoste GPUs heeft.

Als u nieuw bent in deze stack, begint u met de bredere Hermes-instellings- en operatiegids en de AI-systemen-pijler voor de omliggende architectuur.

In dit artikel wordt uitgelegd hoe u:

• Begrijpt hoe Hermes Kanban en de dispatcher omgaan met uw LLM-gateway.
• Configureert sequentiële of beperkte parallelle uitvoering voor zware taken.
• Batcht werk met cron, zodat nachtaken niet botsen met interactief gebruik overdag.
• Monitort en fine-tuned het systeem, zodat uw GPUs bezig blijven, maar nooit overbelast raken.

Hoe Hermes Kanban en de dispatcher werken

Op een hoog niveau heeft het systeem drie lagen:

1. Het bord — een duurzame SQLite-database die taken, kolommen, relaties en geschiedenis opslaat.
2. Werknemers — Hermes-profielen die in geïsoleerde werkruimten kunnen worden gestart om een taak te verwerken.
3. Dispatcher-daemon — een langlevend proces dat het bord in de gaten houdt en taken bevordert tot uitvoeringen.

Wanneer u een taak maakt via de CLI of het dashboard, begint deze meestal in een backlog of ready kolom.
De dispatcher scant periodiek naar taken die aan uw filters voldoen, claimt atoom een kaart en start het toegewezen profiel met de juiste tools en geheugen.
Elke werknemer communiceert vervolgens met uw LLM-gateway of lokale runtime — bijvoorbeeld een OpenAI-compatibele proxy voor Ollama, vLLM of llama.cpp. Voor keuzes voor het implementeren van deze runtimes, gebruikt u de LLM-hosting in 2026: Lokaal, Zelfgehost en Cloud-infrastructure vergeleken. Als u de request fan-out op Ollama zelf afstelt, past dit goed samen met Hoe Ollama parallelle verzoeken afhandelt.

Als u niets anders doet en u voegt vijfentwintig zware onderzoekstaken toe, kan de dispatcher proberen om alle vijfentwintig te starten, waardoor uw gateway overstroomt met gelijktijdige verzoeken. Op een node met een enkele GPU of CPU-gebonden taken produceert dit wachtrijen, thrashing en time-outs in plaats van doorvoer.

Strategie 1: Concurrentie beperken bij de dispatcher

De eenvoudigste controle is om een maximum te stellen aan het aantal werknemers dat de dispatcher parallel kan uitvoeren. In uw Hermes-configuratie ziet u meestal een sectie die de Kanban-dispatcher en het werknemerspool regelt.

In huidige Hermes-releases is de dispatcher standaard ingebed in hermes gateway start, en dezelfde claim- en spawn-kernel handhaaft hier ook concurrentielimieten.
Gebruikers rapporteren echter af en toe vreemd gedrag dat er uitziet als limietdrift, dus valideer de runtime-omstandigheden voordat u de limiet zelf de schuld geeft.

Een minimaal voorbeeld met een TOML-stijl configuratie ziet er ongeveer zo uit:

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

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

Als uw versie andere sleutelnamen gebruikt, behoud dan dezelfde intentie bij het toewijzen van de instellingen. De commandonamen en operatorstromen zijn samengevat in het Hermes Agent CLI-cheat sheet:

• één limiet voor het totaal aantal actieve taken op het bord
• één limiet voor parallelisme per profiel of per werknemerspool
• optionele dispatch-tick-interval

Bekende valkuilen uit documentatie en community-threads:

• Voer niet zowel de in de gateway ingebedde dispatch als de legacy hermes kanban daemon --force uit op dezelfde kanban.db, omdat dit claim-races creëert.
• Als de gateway offline is, worden ready taken helemaal niet gedispacht, en lijken ze te pieken wanneer de gateway terugkeert.
• Een lange dispatch-interval kan voelen als ongelijkmatige planning, omdat claims plaatsvinden in ticks in plaats van continu.
• Oudere Kanban-builds hadden verschillende runstate- en reclaim-edge cases die zijn opgelost in follow-up patches, dus het gedrag kan per versie verschillen.

Snelle verificatie-controlelijst wanneer het gedrag verkeerd lijkt:

# 1) bevestig dat exact één dispatcherpad actief is
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) controleer de dispatch-in-gateway-vlag
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) inspecteer de wachtrijvorm
hermes kanban list --status ready
hermes kanban list --status active

Belangrijke concepten:

• max_active_tasks beperkt hoeveel Kanban-kaarten tegelijk in de active (actieve) staat kunnen zijn.
• max_parallel_per_profile zorgt ervoor dat zelfs als u veel profielen draait, slechts een klein aantal zware taken samen worden uitgevoerd.
• Met een kleine zelfgehoste cluster wilt u meestal waarden tussen 1 en 4 om de latentie voorspelbaar te houden.

Wanneer u Hermes voor het eerst implementeert in de buurt van uw LLM-gateway, begint u conservatief:

• Begin met max_active_tasks = 1.
• Observeer GPU- en CPU-gebruik.
• Verhoog naar 2 of 3 alleen als de hardware duidelijk onderbenut is.

Strategie 2: Afhankelijkheden coderen voor strikt sequentiële flows

Sommige workflows moeten strikt na elkaar worden uitgevoerd — bijvoorbeeld:

• meervoudige stap-data pipelines met gedeelde tussentijdse artefacten
• migraties of infrastructurele wijzigingen
• batchtaken die schrijven naar dezelfde objectopslag of database

Hermes Kanban ondersteunt ouder-kind-afhankelijkheden tussen taken, zodat een kindkaart alleen dispatchbaar wordt wanneer de ouder klaar is.

U kunt dit modelleren met een kleine helper-script rondom de Hermes CLI:

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

Met een passend boardbeleid en lage dispatcherlimieten wordt alleen de parent-taak eerst uitgevoerd.
Zodra deze is afgerond, worden de kindtaken geleidelijk ready, en haalt de dispatcher ze één voor één op zonder ooit uw concurrentielimieten te overschrijden.

Strategie 3: Automatische dispatch uitschakelen en cron gebruiken

Voor sommige omgevingen kiest u misschien voor expliciete tijdvensters voor zware werklasten.
Misschien wilt u bijvoorbeeld dat onderzoekstaken en documentingestie na middernacht worden uitgevoerd, terwijl GPUs ongebruikt zijn.

Er zijn twee varianten die mensen cron noemen in deze setup:

1. Linux-host cron met behulp van crontab.
2. Hermes-interne scheduler cron-uitdrukkingen in de Hermes-configuratie.

Optie A: Linux-host cron

In dit model schakelt u automatische Kanban-dispatch uit en laat u het besturingssysteem een wrapper-script plannen.

Een voorbeeldscript:

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

Voeg vervolgens een Linux-cron-invoer toe op de host waar de dispatcher of gateway draait:

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

Dit garandeert dat niet meer dan twee nieuwe taken elke vijftien minuten actief worden, ongeacht hoeveel kaarten u in ready zet.

Optie B: Hermes-interne cron-scheduler

Als u de planningsregels liever binnen Hermes zelf houdt, definieert u een geplande taak met een cron-uitdrukking in de Hermes-configuratie en roept u daar hetzelfde promote-commando aan.

Voorbeeldpatroon:

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

Als uw Hermes-build scheduler-beheercommando’s blootlegt, kunt u dezelfde taak registreren via de CLI in plaats van configuratiebestanden handmatig te bewerken:

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

Als uw geïnstalleerde versie geen hermes scheduler jobs ... heeft, gebruikt u dan de hierboven beschreven configuratiegebaseerde methode, en herlaadt of start u Hermes opnieuw zodat de scheduler de nieuwe taak oppikt.

Hoe u dit veilig gebruikt:

• Houd kanban.dispatcher.enabled = false als de scheduler-taak uw enige promotor is.
• Begin met een lage --max waarde, zoals 1 of 2.
• Plaats scheduler-logs in uw normale Hermes-logpijplijn, zodat overgeslagen of mislukte promoties zichtbaar zijn.

Dit geeft u hetzelfde batchgedrag als Linux-cron, maar beheerd als Hermes-configuratie in plaats van host-niveau crontab.

Strategie 4: Segmenteer borden en profielen voor verschillende gateways

Als u meerdere LLM-backends exploiteert — bijvoorbeeld:

• een kleine GPU-node met een 7B instruct-model
• een CPU-only node voor lichtgewicht classificatie
• een aparte high-end box voor zwaar redeneren

u kunt concurrentie verminderen door verschillende Hermes-profielen en borden toe te wijzen aan elke gateway.

Typisch patroon:

• Maak profielen aan zoals research-gpu, summarise-cpu, ops-gateway.
• Configureer elk profiel met een dedicate basis-URL en API-sleutel voor zijn eigen gateway.
• Maak aparte Kanban-rijen of zelfs aparte borden voor elk profiel.

Wanneer dit wordt gecombineerd met dispatcherlimieten, blijft elke gateway verzadigd door zijn eigen set werknemers, zonder dat één lawaaierige werklast de anderen uitput.

Hermes Kanban-monitering en afstemming

Welke strategie u ook kiest, u moet monitoren:

• LLM-gatewaymetrieken — verzoeksfrequentie, latentie, foutenpercentage, token-doorvoer.
• Nodegezondheid — GPU-gebruik, VRAM-gebruik, CPU-belasting en RAM.
• Hermes-metrieken — hoeveel taken zich in backlog, ready, active en done bevinden.

Voor productie-metrikbaselines en dashboards, zie Monitor LLM-inferentie in productie met Prometheus en Grafana en de bredere LLM-prestatieshub.

Begin met lage concurrentie en verhoog dan geleidelijk de limieten terwijl u kijkt naar:

• stijgende latentie bij constante doorvoer
• toenemende time-out- of rate-limitfouten
• lange staarten waarbij sommige taken zeer lang actief blijven

Zodra u deze symptomen ziet, gaat u terug naar de vorige stabiele configuratie en behoudt u deze als uw standaard.

Wanneer Kanban het juiste hulpmiddel is

Hermes Kanban blinkt uit wanneer u:

• langdurige onderzoeks- of engineeringbacklogs heeft
• multi-agent samenwerking met genoemde profielen
• workflows die herstarts en host-opstarts moeten overleven
• mensen die een dashboard willen om werk te triagelen

Als u slechts één run nodig heeft om een paar tijdelijke helpers te maken, zijn de ingebouwde delegatetaaktools meestal eenvoudiger.
Zodra u geschiedenis, dashboards en strikte controle nodig heeft over hoe uw agents zelfgehoste LLMs raken, is het Kanban-bord plus dispatcher de juiste basis.

Met een paar configuratieaanpassingen en optionele cron-gebaseerde batchtaken kunt u Hermes Kanban responsief houden terwijl u uw gateway en hardware beschermt.