Kanban i Hermes Agent för självhostade LLM-arbetsflöden

Hermes Agent levereras med ett Kanban-stilarbetstavs som lätt kan mätta ditt självhostade LLM-gateway om du låter varje uppgift köras samtidigt.

Hermes Kanban är ett hållbart flerrättsligt brädbackat av ~/.hermes/kanban.db.
Varje fil representerar en fas av arbetet och varje kort är en uppgift som kan anspråkas av en specifik Hermes-profil.
Som standard kommer dispatcherdemonen glatt starta agenter för godtyckligt antal ready-uppgifter, vilket är bra för moln-API:er men farligt när du har en liten kluster av självhostade GPU:er.

Om du är ny till denna stack, börja med den bredare Hermes-inställnings- och operationsguide och AI Systems-pelaren för omgivande arkitektur.

Detta inlägg visar hur du:

• Förstår hur Hermes Kanban och dispatchern interagerar med ditt LLM-gateway.
• Konfigurerar sekventiell eller begränsad parallell exekvering för tunga uppgifter.
• Batchar arbete med cron så att nattjobb inte krockar med dagtidens interaktiva användning.
• Övervakar och finjusterar systemet så att dina GPU:er hålls upptagna men aldrig överbelastade.

Hur Hermes Kanban och dispatchern fungerar

På en hög nivå har systemet tre lager:

1. Brädet — en hållbar SQLite-databas som lagrar uppgifter, kolumner, relationer och historik.
2. Arbetare — Hermes-profiler som kan startas i isolerade arbetsutrymmen för att bearbeta en uppgift.
3. Dispatcherdemon — en långlivad process som övervakar brädet och befordrar uppgifter till körningar.

När du skapar en uppgift med CLI:t eller instrumentpanelen börjar den vanligtvis i en backlog- eller ready-kolumn.
Dispatchern skannar periodiskt efter uppgifter som uppfyller dina filter, anspråkar atomiskt ett kort och startar den tilldelade profilen med rätt verktyg och minne.
Varje arbetare pratar sedan med ditt LLM-gateway eller lokala runtime — till exempel en OpenAI-kompatibel proxy som frontar Ollama, vLLM eller llama.cpp. För val av deployment över dessa runtimes, använd LLM-hostning 2026: Lokal, självhostad och molninfrastruktur jämförd. Om du finjusterar begäranutbredning på Ollama själv, passar detta bra med Hur Ollama hanterar parallella begäran.

Om du inte gör något annat och lägger till femtio tunga forskningsuppgifter, kan dispatchern försöka starta alla femtio, och ösa på ditt gateway med samtidiga begäran. På en enskild GPU- eller CPU-bunden nod producerar detta köbildning, thrashing och timeout istället för genomströmning.

Strategi 1 Minska konkurrensen vid dispatchern

Den enklaste kontrollen är att takta hur många arbetare dispatchern kan köra parallellt. I din Hermes-konfiguration ser du vanligtvis en sektion som kontrollerar Kanban-dispatchern och arbetspoolen.

I aktuella Hermes-utgåvor är dispatchern inbäddad i hermes gateway start som standard, och samma anspråk- och startkärna tillämpar konkurrensmässiga tak där också.
Användare rapporterar dock ibland ovanligt beteende som kan se ut som gränsdrift, så validera runtime-villkoren innan du skyller på själva taket.

Ett minimalt exempel med en TOML-liknande konfiguration kan se ut så här:

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

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

Om din version använder andra nyckelnamn, behåll samma avsikt när du mappar inställningarna. Kommandonamnen och operatörsflödena sammanfattas i Hermes Agent CLI-snabbreferens:

• en gräns för totala aktiva uppgifter över hela brädet
• en gräns för parallellitet per profil eller per arbetspool
• valfritt dispatch-taktintervall

Kända fallgropar från dokumentation och community-trådar:

• Kör inte både gateway-inbäddad dispatch och legacy hermes kanban daemon --force på samma kanban.db eftersom det skapar anspråksträffar.
• Om gateway:n är nere, dispatchas inte ready-uppgifter alls, utan verkar explodera när gateway:n returnerar.
• Ett långt dispatch-intervall kan kännas som ojämn schemaläggning eftersom anspråk sker i takt istället för kontinuerligt.
• Äldre Kanban-byggnader hade flera körstatus- och återanspråksgrenfall som åtgärdades i efterföljande patchar, så beteendet kan variera beroende på version.

Snabb verifieringskontrolllista när beteendet ser felaktigt ut:

# 1) bekräfta att exakt en dispatch-sökväg är aktiv
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) kontrollera dispatch-flaggan för gateway-läge
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) inspektera köformen
hermes kanban list --status ready
hermes kanban list --status active

Viktiga idéer:

• max_active_tasks begränsar hur många Kanban-kort som kan vara i active-status samtidigt.
• max_parallel_per_profile säkerställer att även om du kör många profiler, så körs endast ett litet antal tunga samtidigt.
• Med ett litet självhostat kluster vill du vanligt sett värden mellan 1 och 4 för att hålla latensen förutsägbar.

När du först deployar Hermes nära ditt LLM-gateway, börja konservativt:

• Börja med max_active_tasks = 1.
• Observera GPU- och CPU-användning.
• Öka till 2 eller 3 endast om hårdvaran tydligt är underutnyttjad.

Strategi 2 Koda beroenden för strikt sekventiella flöden

Vissa arbetsflöden bör köras strikt efter varandra — till exempel:

• flerstegs datapipelines med delade mellanliggande artefakter
• migrationer eller infrastrukturregler
• batchjobb som skriver till samma objektstore eller databas

Hermes Kanban stöder föräldra-barn-beroenden mellan uppgifter så att ett barnkort blir dispatchbart först när dess förälder är klar.

Du kan modellera detta med ett litet hjälpskript runt Hermes CLI:t:

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Ingestera kundloggar för april' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'Generera aprils anomali-rapport' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'Publicera aprils sammanfattning till instrumentpanel' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

Med en lämplig brädpolicy och låga dispatchgränser körs endast föräldrauppgiften först.
När den är klar blir barnuppgifterna gradvis redo, och dispatchern hämtar dem en efter en utan någonsin att överskrida dina konkurrensmässiga tak.

Strategi 3 Inaktivera automatisk dispatch och använd cron

I vissa miljöer kan du föredra explicita tidsfönster för tunga arbetsbelastningar.
Till exempel kan du vilja att forskningsuppgifter och dokumentinhämtning körs efter midnatt när GPU:erna är lediga.

Det finns två schemaläggningsvarianter som folk kallar cron i denna uppsättning:

1. Linux-värdcron med crontab.
2. Hermes interna schemalägningscron-uttryck i Hermes-konfigurationen.

Alternativ A Linux-värdcron

I denna modell inaktiverar du automatisk Kanban-dispatch och låter OS:t schemalägga ett wrapper-skript.

Ett exempel på 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 "Befordrar uppgift ${id} till aktiv"
  hermes kanban promote --id "${id}" --column active
done

Lägg sedan till en Linux-cron-post på värden där dispatchern eller gateway:n körs:

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

Detta garanterar att inte mer än två nya uppgifter blir aktiva var femtonde minut, oavsett hur många kort du lägger i redo.

Alternativ B Hermes interna cron-schemaläggare

Om du föredrar att behålla schemaläggningsregler inuti Hermes självt, definiera ett schemalagt jobb med ett cron-uttryck i Hermes-konfigurationen och anropa samma promote-kommando där.

Exempel på mönster:

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

Om din Hermes-byggd exponerar schemaläggningskommandon kan du registrera samma jobb från CLI:t istället för att redigera konfigurationsfiler manuellt:

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

Om din installerade version inte har hermes scheduler jobs ..., fortsätt använda konfigurationsbaserad metod ovan, och ladda om eller starta om Hermes så att schemaläggaren tar upp det nya jobbet.

Hur du använder detta säkert:

• Håll kanban.dispatcher.enabled = false om schemaläggningsjobbet är din enda promotör.
• Börja med ett lågt --max-värde som 1 eller 2.
• Placera schemaläggningsloggar i din normala Hermes-loggpipeline så att utelåtna eller misslyckade befordringar blir synliga.

Detta ger dig samma batchbeteende som Linux-cron, men hanterat som Hermes-konfiguration istället för värdnivå crontab.

Strategi 4 Segmentera bräden och profiler för olika gateways

Om du driver flera LLM-backendar — till exempel:

• en liten GPU-nod med en 7B-instruktionsmodell
• en CPU-enbart-nod för lättviktsklassificering
• en separat högkvalitativ box för tung resonemang

kan du minska konkurrensen genom att tilldela olika Hermes-profiler och bräden till varje gateway.

Typiskt mönster:

• Skapa profiler som research-gpu, summarise-cpu, ops-gateway.
• Konfigurera varje profil med en dedikerad bas-URL och API-nyckel för sin egen gateway.
• Skapa separata Kanban-filar eller till och med separata bräden för varje profil.

När detta kombineras med dispatchertak håller det varje gateway mättad av sin egen uppsättning arbetare utan att ett bullrigt arbetsflöde svälter de andra.

Hermes Kanban-övervakning och finjustering

Oavsett vilken strategi du väljer bör du övervaka:

• LLM-gateway-mått — begäranfrekvens, latens, felrate, token-genomströmning.
• Nodhälsa — GPU-användning, VRAM-användning, CPU-belastning och RAM.
• Hermes-mått — hur många uppgifter som är i backlog, ready, active och done.

För produktionsmässig måttnivå och dashboards, se Övervaka LLM-inferens i produktion med Prometheus och Grafana och den bredare LLM-prestandahubben.

Börja med låg konkurrens, och höj sedan gradvis gränserna medan du tittar efter:

• stigande latens vid konstant genomströmning
• ökande timeout- eller rate limit-fel
• långa svansar där vissa uppgifter förblir aktiva under mycket lång tid

Så snart du ser dessa symtom, rulla tillbaka till den tidigare stabila konfigurationen och behåll den som standard.

När Kanban är rätt verktyg

Hermes Kanban skiner när du har:

• långlivade forsknings- eller engineering-backlogs
• flermagent-samarbete med namngivna profiler
• arbetsflöden som måste överleva omstarter och värdomstarter
• människor som vill ha en instrumentpanel för att triagera arbete

Om du bara behöver en enskild körning för att skapa några tillfälliga hjälpmedel, är de inbyggda delegera-uppgift-verktygen vanligtvis enklare.
När du behöver historik, instrumentpaneler och strikt kontroll över hur dina agenter träffar självhostade LLM:er är Kanban-brädet plus dispatchern rätt grund.

Med några konfigurationstilljusteringar och valfri cron-baserad batching kan du hålla Hermes Kanban responsivt samtidigt som du skyddar din gateway och hårdvara.