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

Hermes Agent est livré avec un tableau de tâches de type Kanban qui peut facilement saturer votre passerelle LLM auto-hébergée si vous laissez toutes les tâches s’exécuter simultanément.

Hermes Kanban est un tableau multi-profil durable, soutenu par ~/.hermes/kanban.db.
Chaque file 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.
Par défaut, le démon du répartiteur (dispatcher) lancera joyeusement des agents pour n’importe quel nombre de tâches prêtes, ce qui est idéal pour les API cloud mais dangereux lorsque vous avez un petit cluster de GPU auto-hébergés.

Si vous êtes nouveau sur cette stack, commencez par le guide général d’installation et d’exploitation de Hermes et le piliers des Systèmes IA pour l’architecture environnante.

Cet article montre comment :

• Comprendre comment Hermes Kanban et le répartiteur interagissent avec votre passerelle LLM.
• Configurer l’exécution séquentielle ou parallèle limitée pour les tâches lourdes.
• Regrouper le travail avec cron afin que les jobs nocturnes n’entrent pas en conflit avec l’utilisation interactive diurne.
• Surveiller et ajuster le système pour que vos GPU restent occupés mais jamais surchargés.

Comment fonctionnent Hermes Kanban et le répartiteur

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

1. Le tableau — une base de données SQLite durable stockant les tâches, colonnes, relations et historique.
2. Les travailleurs — des profils Hermes qui peuvent être démarrés dans des espaces de travail isolés pour traiter une tâche.
3. Le démon du répartiteur — un processus de longue durée qui surveille le tableau et promeut les tâches vers des exécutions.

Lorsque vous créez une tâche en utilisant l’interface en ligne de commande (CLI) ou le tableau de bord, elle commence généralement dans une colonne backlog (file d’attente) ou prête.
Le répartiteur scanne périodiquement les tâches qui correspondent à vos filtres, réclame atomiquement une carte et lance le profil assigné avec les outils et la mémoire appropriés.
Chaque travailleur communique ensuite avec votre passerelle LLM ou votre runtime local — par exemple un proxy compatible OpenAI devant Ollama, vLLM ou llama.cpp. Pour les choix de déploiement entre ces runtimes, utilisez le guide Hébergement LLM en 2026 : Infrastructure Locale, Auto-hébergée et Cloud Comparée. Si vous ajustez la diffusion des requêtes sur Ollama lui-même, cela s’accorde bien avec Comment Ollama Gère les Requêtes Parallèles.

Si vous ne faites rien d’autre et que vous ajoutez cinquante tâches de recherche lourdes, le répartiteur peut essayer de lancer les cinquante, inondant votre passerelle de requêtes concurrentes. Sur un nœud limité par un seul GPU ou par le CPU, cela produit mise en file d’attente, thrashing et timeouts au lieu de débit.

Stratégie 1 : Réduire la concurrence au niveau du répartiteur

Le contrôle le plus simple est de limiter le nombre de travailleurs que le répartiteur peut exécuter en parallèle. Dans votre configuration Hermes, vous verrez généralement une section qui contrôle le répartiteur Kanban et le pool de travailleurs.

Dans les versions actuelles de Hermes, le répartiteur est intégré par défaut dans hermes gateway start, et le même noyau de réclamation et de lancement impose les limites de concurrence là-bas également.
Cependant, les utilisateurs signalent parfois des comportements étranges qui peuvent ressembler à un décalage de limite, alors validez les conditions d’exécution avant de blâmer la limite elle-même.

Un exemple minimal utilisant une configuration style TOML pourrait ressembler à ceci :

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

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

Si votre version utilise des noms de clés différents, conservez la même intention lors du mappage des paramètres. Les noms de commandes et les flux d’opérateurs sont résumés dans la cheat sheet CLI de Hermes Agent :

• une limite pour le total des tâches actives sur tout le tableau
• une limite pour le parallélisme par profil ou par pool de travailleurs
• intervalle de tick de dispatch optionnel

Pièges connus issus de la documentation et des threads communautaires :

• Ne lancez pas à la fois le dispatch intégré à la passerelle et le legacy hermes kanban daemon --force sur le même kanban.db car cela crée des courses à la réclamation.
• Si la passerelle est hors service, les tâches prêtes ne sont pas dispatchées du tout, puis semblent exploser lorsque la passerelle revient.
• Un intervalle de dispatch long peut donner l’impression d’un planning inégal car les réclamations se produisent par ticks plutôt que continuellement.
• Les anciennes versions de Kanban avaient plusieurs cas limites d’état d’exécution et de réclamation corrigés dans les correctifs suivants, donc le comportement peut varier selon la version.

Liste de vérification rapide lorsque le comportement semble incorrect :

# 1) confirmer qu'un seul chemin de répartiteur est actif
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) vérifier le drapeau de dispatch en mode passerelle
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 active

Idées clés :

• max_active_tasks limite le nombre de cartes Kanban qui peuvent être dans l’état active à la fois.
• max_parallel_per_profile s’assure que même si vous exécutez plusieurs profils, seul un petit nombre de profils lourds s’exécutent ensemble.
• Avec un petit cluster auto-hébergé, vous souhaitez généralement des valeurs entre 1 et 4 pour garder la latence prévisible.

Lorsque vous déployez Hermes pour la première fois près de votre passerelle LLM, commencez de manière conservatrice :

• Commencez avec max_active_tasks = 1.
• Observez l’utilisation du GPU et du CPU.
• Augmentez à 2 ou 3 uniquement si le matériel est clairement sous-utilisé.

Stratégie 2 : 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
• jobs 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 soit dispatchable que lorsque son parent est terminé.

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

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Ingest journal clients pour Avril' \
  --profile 'etl-worker' \
  --column backlog)"

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

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

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

Stratégie 3 : Désactiver le dispatch automatique et utiliser cron

Pour certains environnements, vous pouvez préférer des fenêtres de temps explicites pour les charges de travail lourdes.
Par exemple, vous pourriez vouloir que les tâches de recherche et l’ingestion de documents s’exécutent après minuit tandis que les GPU sont inactifs.

Il y a deux variantes de planification que les gens appellent cron dans cette configuration :

1. Cron de l’hôte Linux utilisant crontab.
2. Expressions cron du planificateur interne Hermes dans la configuration Hermes.

Option A : Cron de l’hôte Linux

Dans ce modèle, vous désactivez le dispatch automatique Kanban et laissez le système d’exploitation planifier un script wrapper.

Un exemple de script :

#!/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 "Promotion de la tâche ${id} vers active"
  hermes kanban promote --id "${id}" --column active
done

Ajoutez ensuite une entrée cron Linux sur l’hôte où le répartiteur ou la passerelle s’exécute :

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

Cela garantit qu’au maximum deux nouvelles tâches deviennent actives toutes les quinze minutes, indépendamment du nombre de cartes que vous déposez dans prêt.

Option B : Planificateur cron interne de Hermes

Si vous préférez garder les règles de planification à l’intérieur de Hermes lui-même, définissez un job planifié avec une expression cron dans la configuration Hermes et appelez la même commande de promotion là-bas.

Exemple de pattern :

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

Si votre build Hermes expose des commandes de gestion du planificateur, vous pouvez enregistrer le même job depuis la CLI au lieu de modifier manuellement les fichiers de configuration :

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

Si votre version installée n’a pas hermes scheduler jobs ..., continuez à utiliser la méthode basée sur la configuration ci-dessus, puis rechargez ou redémarrez Hermes pour que le planificateur prenne en compte le nouveau job.

Comment utiliser cela en toute sécurité :

• Gardez kanban.dispatcher.enabled = false si le job du planificateur est votre seul promoteur.
• Commencez avec une valeur --max faible telle que 1 ou 2.
• Placez les logs du planificateur dans votre pipeline de logs Hermes normal afin que les promotions sautées ou échouées soient visibles.

Cela vous donne le même comportement de regroupement que le cron Linux, mais géré comme une configuration Hermes au lieu de crontab au niveau de l’hôte.

Stratégie 4 : Segmenter les tableaux et profils pour différentes passerelles

Si vous opérez plusieurs backends LLM — par exemple :

• un petit nœud GPU avec un modèle instruct de 7B
• un nœud CPU uniquement pour la classification légère
• une machine haute performance séparée pour le raisonnement lourd

vous pouvez réduire la contention en assignant différents profils et tableaux Hermes à chaque passerelle.

Pattern typique :

• Créez des profils comme research-gpu, summarise-cpu, ops-gateway.
• Configurez chaque profil avec une URL de base et une clé API dédiées pour sa propre passerelle.
• Créez des files Kanban séparées ou même des tableaux séparés pour chaque profil.

Lorsqu’il est combiné avec les limites du répartiteur, cela maintient chaque passerelle saturée par son propre ensemble de travailleurs sans qu’une charge de travail bruyante ne prive les autres.

Surveillance et ajustement de Hermes Kanban

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

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

Pour les lignes de base de métriques de production et les tableaux de bord, consultez Surveillez l’inférence LLM en production avec Prometheus et Grafana et le plus large hub Performance LLM.

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

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

Dès que vous voyez ces symptômes, revenez à la configuration stable précédente et gardez-la comme votre 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-agents avec des profils nommés
• des flux de travail qui doivent survivre aux redémarrages et aux reboot de l’hôte
• des humains qui veulent un tableau de bord pour trier le travail

Si vous n’avez besoin que d’une seule exécution pour créer quelques helpers temporaires, les outils de tâche déléguée 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 façon dont vos agents touchent les LLM auto-hébergés, le tableau Kanban plus le répartiteur 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.