Kanban dans Hermes Agent pour les flux de travail d'LLM auto-hébergés

Hermes Agent est livré avec un tableau Kanban et la passerelle Hermes qui peuvent saturer votre LLM auto-hébergé si trop de tâches sont expédiées simultanément.

Je peux affirmer que vous pouvez facilement provoquer un déni de service (DDoS) sur votre propre LLM de cette manière.

Hermes Kanban est un tableau multi-profil durable, soutenu par ~/.hermes/kanban.db.
Chaque voie représente une phase de travail, et chaque carte est une tâche qui peut être réclamée par un profil Hermes spécifique.
D’origine, l’expéditeur peut promouvoir de nombreuses tâches prêtes en une seule passe. Cela convient aux API cloud élastiques, mais cela peut surcharger un petit cluster GPU auto-hébergé.

Si vous êtes nouveau sur cette pile, commencez par le guide d’installation et d’exploitation de Hermes et le pilier Systèmes IA pour l’architecture environnante.

Cet article montre comment :

• Comprendre comment l’expédition de Hermes Kanban interagit avec votre passerelle LLM.
• Contrôler le parallélisme en toute sécurité pour les tâches lourdes.
• Regrouper les promotions avec cron afin que les tâches en arrière-plan ne collident pas avec l’utilisation interactive.
• Surveiller et ajuster le système afin que les GPUs restent occupés sans surcharge.

Comment fonctionnent Hermes Kanban et l’expéditeur

À un niveau élevé, le système comporte trois couches :

1. Tableau - état SQLite durable pour les tâches, les colonnes, les relations et l’historique.
2. Travailleurs - profils Hermes démarrés dans des espaces de travail isolés pour traiter une tâche.
3. Expéditeur - un processus long terme qui scanne les cartes expédiables et lance les exécutions.

Les tâches créées à partir de la CLI ou du tableau de bord commencent généralement dans backlog ou prêt.
L’expéditeur scanne les cartes éligibles, en réclame une de manière atomique, et démarre le profil assigné avec ses outils et sa mémoire.
Chaque travailleur appelle ensuite votre passerelle LLM ou votre runtime local (par exemple, des points de terminaison compatibles OpenAI soutenus par Ollama, vLLM ou llama.cpp). Pour les choix de déploiement entre ces runtimes, utilisez le guide Hébergement LLM en 2026 : Auto-hébergement local et infrastructure cloud comparés. Si vous ajustez l’éventail de requêtes sur Ollama lui-même, cela s’accorde bien avec Comment Ollama gère les requêtes parallèles.

Si vous ajoutez de nombreuses tâches lourdes et ne plafonnez pas les promotions, votre passerelle peut être inondée de requêtes concurrentes.
Sur un hôte à GPU unique ou limité par le CPU, cela signifie souvent mise en file d’attente, thrashing et timeouts au lieu d’un meilleur débit.

La limitation pratique actuelle

Dans les versions actuelles de Hermes que de nombreuses équipes utilisent, la configuration de l’expéditeur expose seulement deux clés d’expédition Kanban et n’applique pas de plafond global de tâches actives depuis la configuration :

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 10

Pour le contrôle des tâches actives, reposez sur un cadencement d’expédition explicite (hermes kanban dispatch --max ...) ainsi que sur la modélisation des dépendances.

Pièges connus :

• Ne lancez pas l’expédition intégrée à la passerelle et hermes kanban daemon --force sur le même tableau, ou vous pourriez obtenir des courses à la réclamation.
• Si la passerelle est hors ligne, les tâches prêtes ne sont pas expédiées et peuvent exploser plus tard lorsque le service revient.
• Des intervalles d’expédition plus longs semblent irréguliers car la réclamation se produit par ticks.
• Le comportement peut varier selon les versions car les cas limites d’état d’exécution et de réclamation ont été corrigés au fil du temps.

Vérification rapide lorsque le comportement semble incorrect :

# 1) confirmer qu'un seul chemin d'expéditeur est actif
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) vérifier les clés de l'expéditeur Kanban câblées
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) inspecter la forme de la file d'attente
hermes kanban list --status ready
hermes kanban list --status running

Idées clés :

• La configuration de l’expéditeur câble dispatch_in_gateway et dispatch_interval_seconds.
• dispatch --max limite les nouvelles créations dans cette passe, pas le total des tâches en cours.
• Pour les petits clusters auto-hébergés, commencez de manière conservatrice et augmentez uniquement après que la latence soit stable.

Lors du premier déploiement de Hermes près de votre passerelle LLM :

• Gardez uniquement les clés de l’expéditeur Kanban supportées dans la configuration.
• Observez l’utilisation du GPU et du CPU sous une pression de file d’attente réelle.
• Utilisez la Stratégie 1 ou la Stratégie 2 pour un rythme déterministe.

Résultats de l’enquête et cause racine

hermes kanban dispatch ne lit pas config.yaml pour max_active_tasks.

Dans hermes_cli/kanban.py, la commande d’expédition expose --max comme un plafond CLI (par défaut None) et ne passe que args.max dans kb.dispatch_once(...). Il n’y a pas de recherche de configuration max_active_tasks dans ce chemin. Voir hermes_cli/kanban.py raw.

Ensuite, dans kanban_db.dispatch_once, la seule limite est max_spawn, avec une logique équivalente à :

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

Il n’y a pas de vérification des tâches déjà en cours et aucune référence à max_active_tasks dans ce chemin d’expédition. Voir hermes_cli/kanban_db.py raw.

Comportement effectif :

hermes kanban dispatch

non borné pour cette passe (limité par la taille de la file d’attente prête).

hermes kanban dispatch --max 2

plafonne uniquement les nouvelles créations dans cette passe, pas le total des tâches en cours.

Les boutons de configuration câblés autour de l’expédition de la passerelle sont kanban.dispatch_in_gateway et kanban.dispatch_interval_seconds.
Ainsi, max_active_tasks est ignoré dans ce chemin d’expédition car il n’y est pas implémenté.

Stratégie 1 - Encoder les dépendances pour des flux strictement séquentiels

Certains flux de travail doivent s’exécuter strictement l’un après l’autre — par exemple :

• pipelines de données multi-étapes avec des artefacts intermédiaires partagés
• migrations ou changements d’infrastructure
• travaux par lots qui écrivent dans le même objet store ou base de données

Hermes Kanban prend en charge les dépendances parent-enfant entre les tâches afin qu’une carte enfant ne devienne expédiable que lorsque son parent est terminé.

Vous pouvez modéliser cela avec un petit script d’assistance autour de la CLI Hermes :

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Ingestion des logs clients pour avril' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'Générer le rapport d'anomalie d'avril' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'Publier le résumé d'avril sur le tableau de bord' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

Avec une politique de tableau appropriée et des limites d’expéditeur faibles, seule la tâche parent s’exécute en premier.
Une fois qu’elle est terminée, les tâches enfant deviennent progressivement prêtes, et l’expéditeur les extrait une par une sans jamais dépasser vos plafonds de concurrence.

Stratégie 2 - Utiliser Linux cron avec un plafond d’expédition conscient des tâches en cours

Si vous souhaitez un rythme déterministe, utilisez le cron de l’hôte plus un petit script wrapper.
Au lieu d’appeler toujours dispatch --max 2, comptez d’abord les tâches en cours actuellement, puis expédiez uniquement les slots restants.

Créez 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

# ou là où votre hermes est installé
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 "Déjà à la limite running=$running_count max=$MAX_PARALLEL expédition sautée"
  exit 0
fi

echo "running=$running_count max=$MAX_PARALLEL slots=$slots expédition jusqu'à $slots"

hermes kanban "${board_args[@]}" dispatch --max "$slots"

Rendez-le exécutable :

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

Exécutez-le avec :

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

Pour un tableau spécifique :

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

Planifiez-le une fois par minute avec cron :

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

Notes opérationnelles :

• Cron a souvent un PATH minimal, donc si hermes n’est pas trouvé, utilisez son chemin complet à l’intérieur du script (par exemple /usr/local/bin/hermes).
• Si vous journalisez dans /var/log/hermes/..., créez ce dossier d’abord et assurez-vous que l’utilisateur cron a accès en écriture.

Exemple :

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

Créez ou modifiez les entrées cron avec :

crontab -e

Puis vérifiez avec :

crontab -l

Cadence inférieure à la minute avec une entrée cron

Cron tick une fois par minute, mais vous pouvez toujours expédier plus fréquemment en exécutant une boucle courte à l’intérieur du script.

Exemple 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 exécutions => toutes les 15 secondes
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

Rendez-le exécutable :

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

Planifiez-le une fois par minute :

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

Cela donne une cadence effective inférieure à la minute tandis que flock empêche les exécutions chevauchantes.

Pourquoi cela fonctionne :

• list --status running donne la charge en cours actuelle.
• dispatch --max N plafonne uniquement les nouvelles créations pour cette passe.
• Calculer N comme slots restants maintient le total des tâches en cours près de votre limite cible.

Avertissement important : ce plafond ne fonctionne que pour les expéditions faites via ce script.
Désactivez l’expédition intégrée à la passerelle, sinon elle peut toujours promouvoir des tâches indépendamment :

kanban:
  dispatch_in_gateway: false

La documentation officielle décrit les capacités des deux commandes et note les valeurs par défaut de l’expédition de la passerelle dans le guide des fonctionnalités Kanban : Docs Hermes Kanban.

Cron interne Hermes

Ne l’utilisez pas. Voulez-vous vraiment que votre LLM traite des prompts réguliers comme Exécuter dans le terminal la commande /path/hermes-kanban-dispatch-capped.sh, surtout lorsqu’il est occupé à faire quelque chose d’utile ?

Surveillance et ajustement de Hermes Kanban

Quelle que soit la stratégie que vous choisissiez, vous devez surveiller :

• Métriques de la passerelle LLM — taux de requête, latence, taux d’erreur, débit de tokens.
• Santé du nœud — utilisation du GPU, utilisation de la VRAM, charge CPU et RAM.
• Métriques Hermes — combien de tâches sont en backlog, prêtes, actives et terminées.

Pour les références de métriques de production et les tableaux de bord, consultez Surveiller l’inférence LLM en production avec Prometheus et Grafana et le hub Performance LLM.

Commencez par une faible concurrence, puis augmentez progressivement les limites tout en surveillant :

• une latence croissante à débit constant
• des erreurs de timeout ou de limite de taux augmentant
• des queues longues où certaines tâches restent actives pendant une très longue période

Dès que vous voyez ces symptômes, revenez à la configuration stable précédente et conservez-la comme valeur par défaut.

Quand Kanban est l’outil approprié

Hermes Kanban brille lorsque vous avez :

• des backlogs de recherche ou d’ingénierie de longue durée
• une collaboration multi-agent avec des profils nommés
• des flux de travail qui doivent survivre aux redémarrages et aux redémarrages de l’hôte
• des humains qui souhaitent un tableau de bord pour trier le travail

Si vous avez seulement besoin d’une seule exécution pour créer quelques assistants temporaires, les outils de délégation de tâche intégrés sont généralement plus simples.
Une fois que vous avez besoin d’historique, de tableaux de bord et d’un contrôle strict sur la manière dont vos agents frappent les LLM auto-hébergés, le tableau Kanban plus l’expéditeur est la bonne fondation.

Avec quelques ajustements de configuration et un regroupement optionnel basé sur cron, vous pouvez garder Hermes Kanban réactif tout en protégeant votre passerelle et votre matériel.