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

Hermes Agent levereras med ett Kanban-styrt flödessystem och Hermes Gateway, vilket kan mätta din egenhostade LLM om för många uppgifter skickas ut samtidigt.

Jag kan säga att du lätt kan DDoS:a din egen LLM på detta sätt.

Hermes Kanban är ett varaktigt flödessystem med flera profilalternativ, backat av ~/.hermes/kanban.db.
Varje spår representerar en fas i arbetsflödet, och varje kort är en uppgift som kan tas av en specifik Hermes-profil.
Som standard kan dispatchern främja många redo-uppgifter på en gång. Det fungerar bra för elastiska moln-API:er, men det kan överbelasta ett litet egenhostat GPU-kluster.

Om du är ny till denna stack, börja med den bredare Hermes-installations- och driftguiden och AI Systems-pelaren för den omgivande arkitekturen.

Detta inlägg visar hur du:

• Förstår hur Hermes Kanban-dispatch interagerar med ditt LLM-gateway.
• Kontrollerar parallellismen säkert för tunga uppgifter.
• Batchar främjningar med cron så att bakgrundsjobb inte krockar med interaktiv användning.
• Övervakar och finjusterar systemet så att GPU:er hålls upptagna utan överbelastning.

Hur Hermes Kanban och dispatchern fungerar

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

1. Flöessystem - varaktigt SQLite-tillstånd för uppgifter, kolumner, relationer och historik.
2. Arbetare - Hermes-profiler startade i isolerade arbetsutrymmen för att bearbeta en uppgift.
3. Dispatcher - en långvarig process som skannar efter dispatchbara kort och startar körningar.

Uppgifter skapade från CLI eller dashboard startar vanligtvis i backlog eller redo.
Dispatchern skannar efter kvalificerade kort, tar ett atomärt och startar den tilldelade profilen med dess verktyg och minne.
Varje arbetare anropar sedan ditt LLM-gateway eller lokala körning (t.ex. OpenAI-kompatibla ändpunkter backade av Ollama, vLLM eller llama.cpp). För val av deployment över dessa körningar, använd LLM-hostning 2026: Lokal egenhostad och molninfrastruktur jämförd. Om du finjusterar begäran fan-out på Ollama själv, passar detta bra med Hur Ollama hanterar parallella begäran.

Om du lägger till många tunga uppgifter och inte begränsar främjningar, kan ditt gateway översvämmas av samtidiga begäran.
På en host med en enda GPU eller CPU-bunden host innebär det ofta köbildning, thrashing och tidsgränser i stället för bättre genomströmning.

Den praktiska begränsningen idag

I nuvarande Hermes-byggen som många team kör, exponerar dispatchern-konfigurationen endast två Kanban-dispatch-nycklar och tillämpar inte en global aktiv uppgiftsbegränsning från konfigurationen:

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 10

För kontroll av aktiva uppgifter, förlita dig på explicit dispatch-rytm (hermes kanban dispatch --max ...) plus beroendemodellering.

Kända fallgropar:

• Kör inte gateway-inbäddad dispatch och hermes kanban daemon --force mot samma flöessystem, annars kan du få claim-racer.
• Om gateway:n är nere, dispatchas inte redo-uppgifter och kan bursta senare när tjänsten återgår.
• Längre dispatch-intervaller känns ojämn eftersom claiming händer i takt.
• Beteendet kan variera över versioner eftersom kör-tillstånd och reclaim-kantfall patchades över tid.

Snabb verifiering när beteendet verkar felaktigt:

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

# 2) kontrollera de trådade Kanban-dispatch-nycklarna
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) inspektera köformen
hermes kanban list --status redo
hermes kanban list --status running

Viktiga idéer:

• Dispatch-konfigurationen trådar dispatch_in_gateway och dispatch_interval_seconds.
• dispatch --max begränsar nya startar i den passagen, inte totala körande uppgifter.
• För små egenhostade kluster, börja konservativt och öka endast efter att latensen stabiliserats.

Vid första deployment av Hermes nära ditt LLM-gateway:

• Håll endast supported Kanban-dispatch-nycklar i konfigurationen.
• Observera GPU- och CPU-användning under verklig kötryck.
• Använd Strategi 1 eller Strategi 2 för deterministisk takt.

Utredningsfynd och rotorsak

hermes kanban dispatch läser inte config.yaml för max_active_tasks.

I hermes_cli/kanban.py, exponerar dispatch-kommandot --max som en CLI-begränsning (standard None) och skickar endast args.max in i kb.dispatch_once(...). Det finns ingen max_active_tasks-konfigurationssökning i denna väg. Se hermes_cli/kanban.py raw.

Därefter i kanban_db.dispatch_once, är den enda begränsningen max_spawn, med logik ekvivalent till:

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

Det finns ingen kontroll av redan körande uppgifter och ingen max_active_tasks-referens i den dispatch-vägen. Se hermes_cli/kanban_db.py raw.

Effektivt beteende:

hermes kanban dispatch

obegränsat för den passagen (begränsad av redo-köstorlek).

hermes kanban dispatch --max 2

begränsar endast nya startar i den passagen, inte totala körande uppgifter.

De trådade konfigurationsknopparna kring gateway-dispatch är kanban.dispatch_in_gateway och kanban.dispatch_interval_seconds.
Så max_active_tasks ignoreras i den dispatch-vägen eftersom den inte implementeras där.

Strategi 1 - Koda beroenden för strikt sekventiella flöden

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

• flerstegs datapipelines med delade intermediära artefakter
• migrationer eller infrastrukturella förändringar
• batchjobb som skriver till samma objektstore eller databas

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

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

#!/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 april-anomali rapport' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

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

Med en lämplig flöessystemspolicy och låga dispatch-begränsningar kör endast föräldrauppgiften först.
När den är klar blir barnuppgifterna gradvis redo, och dispatchern drar dem en efter en utan någonsin att överstiga dina konkurrensbegränsningar.

Strategi 2 - Använd Linux cron med en körande-medveten dispatch-begränsning

Om du vill ha deterministisk takt, använd host cron plus ett litet wrapper-skript.
I stället för alltid att anropa dispatch --max 2, räkna först för närvarande körande uppgifter, dispatcha sedan endast de återstående platserna.

Skapa 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

# eller där din hermes är installerad
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 "Redan vid gränsen 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"

Gör den körbar:

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

Kör den med:

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

För ett specifikt flöessystem:

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

Schema den en gång per minut med cron:

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

Operativa anteckningar:

• Cron har ofta en minimal PATH, så om hermes inte hittas, använd dess fulla sökväg inuti skriptet (t.ex. /usr/local/bin/hermes).
• Om du loggar till /var/log/hermes/..., skapa den katalogen först och se till att cron-användaren har skrivåtkomst.

Exempel:

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

Skapa eller redigera cron-poster med:

crontab -e

Verifiera sedan med:

crontab -l

Sub-minut takt med en cron-post

Cron tickar en gång per minut, men du kan fortfarande dispatcha mer frekvent genom att köra en kort loop inuti skriptet.

Exempel 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 körningar => var 15:e sekund
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

Gör den körbar:

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

Schema den en gång per minut:

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

Detta ger en effektiv sub-minut takt medan flock förhindrar överlappande körningar.

Varför detta fungerar:

• list --status running ger aktuell körande belastning.
• dispatch --max N begränsar endast nya startar för den passagen.
• Att beräkna N som återstående platser håller totala körande uppgifter nära ditt målgräns.

Viktig varning: denna begränsning fungerar endast för dispatch som görs genom detta skript.
Inaktivera gateway-inbäddad dispatch, annars kan den fortfarande främja uppgifter oberoende:

kanban:
  dispatch_in_gateway: false

De officiella dokumenten beskriver både kommandokapaciteter och noterar gateway-dispatch-standardvärden i Kanban-funktionsguiden: Hermes Kanban-dokument.

Intern Hermes Cron

Använd den inte. Vill du verkligen att din LLM ska bearbeta regelbundna prompter som Kör i terminal kommandot /path/hermes-kanban-dispatch-capped.sh, särskilt när den är upptagen med att göra något användbart arbete?

Hermes Kanban-övervakning och finjustering

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

• LLM-gateway-mätningar — begäran hastighet, latens, felhastighet, token-genomströmning.
• Nodhälsa — GPU-användning, VRAM-användning, CPU-belastning och RAM.
• Hermes-mätningar — hur många uppgifter som är i backlog, redo, aktiv och klar.

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

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

• stigande latens vid konstant genomströmning
• ökande tidsgräns- eller hastighetsbegränsningsfel
• 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 din standard.

När Kanban är rätt verktyg

Hermes Kanban skiner när du har:

• långlivade forsknings- eller engineering-backlogs
• multi-agent-samarbete med namngivna profiler
• arbetsflöden som måste överleva omstarter och host-omstart
• människor som vill ha en dashboard för att triagera arbete

Om du bara behöver en enskild körning för att skapa några tillfälliga hjälpare, är de inbyggda delegera-uppgiftsverktygen vanligtvis enklare.
När du behöver historik, dashboards och strikt kontroll över hur dina agenter träffar egenhostade LLM:er, är Kanban-flöessystemet plus dispatchern rätt grund.

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