Kanban no Hermes Agent para Fluxos de Trabalho de LLMs Auto-hospedados

O Hermes Agent vem com um quadro de tarefas estilo Kanban que pode facilmente saturar seu gateway LLM auto-hospedado se você permitir que todas as tarefas sejam executadas simultaneamente.

O Hermes Kanban é um quadro multi-perfil durável, suportado por ~/.hermes/kanban.db.
Cada faixa representa uma fase do trabalho e cada cartão é uma tarefa que pode ser assumida por um perfil específico do Hermes.
Por padrão, o daemon do despachante iniciará agentes para qualquer número de tarefas prontas (ready), o que é ótimo para APIs em nuvem, mas perigoso quando você tem um pequeno cluster de GPUs auto-hospedadas.

Se você é novo nesta stack, comece pelo guia de configuração e operações do Hermes e pelo pilar de Sistemas de IA para entender a arquitetura geral.

Este post mostra como:

• Compreender como o Hermes Kanban e o despachante interagem com seu gateway LLM.
• Configurar execução sequencial ou paralela limitada para tarefas pesadas.
• Agrupar (batch) trabalho com cron para que tarefas noturnas não colidam com o uso interativo diurno.
• Monitorar e ajustar o sistema para que suas GPUs fiquem ocupadas, mas nunca sobrecarregadas.

Como o Hermes Kanban e o despachante funcionam

Em um alto nível, o sistema tem três camadas:

1. O quadro — um banco de dados SQLite durável que armazena tarefas, colunas, relacionamentos e histórico.
2. Trabalhadores — perfis do Hermes que podem ser iniciados em espaços de trabalho isolados para processar uma tarefa.
3. Daemon do despachante — um processo de longa duração que observa o quadro e promove tarefas para execuções.

Quando você cria uma tarefa usando o CLI ou o painel, ela geralmente começa em uma coluna backlog (fila de espera) ou ready (pronta).
O despachante varre periodicamente em busca de tarefas que atendam aos seus filtros, assume atomicamente um cartão e inicia o perfil atribuído com as ferramentas e memória corretas.
Cada trabalhador então se comunica com seu gateway LLM ou runtime local — por exemplo, um proxy compatível com OpenAI na frente do Ollama, vLLM ou llama.cpp. Para escolhas de implantação entre esses runtimes, consulte Hospedagem de LLM em 2026: Local, Auto-hospedado e Infraestrutura em Nuvem Comparados. Se você está ajustando o fan-out de solicitações no próprio Ollama, isso combina bem com Como o Ollama Lida com Solicitações Paralelas.

Se você não fizer nada além disso e adicionar cinquenta tarefas pesadas de pesquisa, o despachante pode tentar iniciar todas as cinquenta, inundando seu gateway com solicitações concorrentes. Em um único nó com GPU ou CPU limitada, isso produz fila, thrashing (trocas excessivas) e timeouts em vez de vazamento.

Estratégia 1: Reduzir a concorrência no despachante

O controle mais simples é limitar quantos trabalhadores o despachante pode executar em paralelo. Na sua configuração do Hermes, você normalmente verá uma seção que controla o despachante do Kanban e o pool de trabalhadores.

Nas versões atuais do Hermes, o despachante está embutido em hermes gateway start por padrão, e o mesmo kernel de reivindicação e início aplica limites de concorrência lá também.
No entanto, os usuários relatam comportamentos estranhos que podem parecer deriva de limite, portanto, valide as condições de tempo de execução antes de culpar o limite em si.

Um exemplo mínimo usando uma configuração no estilo TOML pode parecer com isso:

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

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

Se sua versão usar nomes de chaves diferentes, mantenha a mesma intenção ao mapear as configurações. Os nomes dos comandos e fluxos de operadores são resumidos na folha de dicas do CLI do Hermes Agent:

• um limite para tarefas ativas totais em todo o quadro
• um limite para paralelismo por perfil ou por pool de trabalhadores
• intervalo de tick de despacho opcional

Problemas conhecidos de documentos e tópicos da comunidade:

• Não execute ambos o despacho embutido do gateway e o legado hermes kanban daemon --force no mesmo kanban.db, pois isso cria corridas de reivindicação.
• Se o gateway estiver fora, as tarefas ready não são despachadas em absoluto, e parecem explodir quando o gateway retorna.
• Um intervalo de despacho longo pode parecer agendamento desigual porque as reivindicações acontecem em ticks em vez de continuamente.
• Construções mais antigas do Kanban tinham vários casos de estado de execução e reavaliação corrigidos em patches subsequentes, então o comportamento pode diferir por versão.

Lista de verificação rápida de verificação quando o comportamento parece errado:

# 1) confirme exatamente um caminho de despachante ativo
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) verifique a flag de despacho em modo gateway
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) inspecione a forma da fila
hermes kanban list --status ready
hermes kanban list --status active

Principais ideias:

• max_active_tasks limita quantos cartões Kanban podem estar no estado active (ativo) de uma vez.
• max_parallel_per_profile garante que, mesmo que você execute muitos perfis, apenas um pequeno número de tarefas pesadas seja executado simultaneamente.
• Com um cluster auto-hospedado pequeno, você geralmente deseja valores entre 1 e 4 para manter a latência previsível.

Quando você primeiro implanta o Hermes perto do seu gateway LLM, comece conservadoramente:

• Comece com max_active_tasks = 1.
• Observe a utilização de GPU e CPU.
• Aumente para 2 ou 3 apenas se o hardware estiver claramente subutilizado.

Estratégia 2: Codificar dependências para fluxos estritamente sequenciais

Algumas workflows devem rodar estritamente uma após a outra — por exemplo:

• pipelines de dados multi-etapa com artefatos intermediários compartilhados
• migrações ou mudanças de infraestrutura
• tarefas em lote que escrevem no mesmo object store ou banco de dados

O Hermes Kanban suporta dependências pai-filho entre tarefas, para que um cartão filho se torne despachável apenas quando seu pai estiver concluído.

Você pode modelar isso com um pequeno script auxiliar em torno do CLI do Hermes:

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Ingestar logs de clientes de abril' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'Gerar relatório de anomalias de abril' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'Publicar resumo de abril no dashboard' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

Com uma política de quadro apropriada e limites baixos de despachante, apenas a tarefa pai é executada primeiro.
Uma vez concluída, as tarefas filho gradualmente ficam prontas, e o despachante as puxa uma por uma sem nunca exceder seus limites de concorrência.

Estratégia 3: Desativar o despacho automático e usar cron

Para alguns ambientes, você pode preferir janelas de tempo explícitas para cargas de trabalho pesadas.
Por exemplo, você pode querer que tarefas de pesquisa e ingestão de documentos rodem após a meia-noite enquanto as GPUs estão ociosas.

Existem duas variantes de agendamento que as pessoas chamam de cron nesta configuração:

1. Cron do host Linux usando crontab.
2. Expressões cron do agendador interno do Hermes na configuração do Hermes.

Opção A: Cron do host Linux

Neste modelo, você desativa o despacho automático do Kanban e deixa o OS agendar um script wrapper.

Um exemplo 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 "Promovendo tarefa ${id} para ativa"
  hermes kanban promote --id "${id}" --column active
done

Em seguida, adicione uma entrada cron Linux no host onde o despachante ou gateway roda:

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

Isso garante que não mais de duas novas tarefas fiquem ativas a cada quinze minutos, independentemente de quantos cartões você soltar em pronto.

Opção B: Agendador cron interno do Hermes

Se você preferir manter as regras de agendamento dentro do próprio Hermes, defina uma tarefa agendada com uma expressão cron na configuração do Hermes e chame o mesmo comando de promoção lá.

Padrão de exemplo:

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

Se sua construção do Hermes expõe comandos de gerenciamento de agendador, você pode registrar a mesma tarefa do CLI em vez de editar arquivos de configuração manualmente:

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

Se sua versão instalada não tiver hermes scheduler jobs ..., continue usando o método baseado em configuração acima, e então recarregue ou reinicie o Hermes para que o agendador pegue a nova tarefa.

Como usar isso com segurança:

• Mantenha kanban.dispatcher.enabled = false se a tarefa do agendador for seu único promotor.
• Comece com um valor --max baixo, como 1 ou 2.
• Coloque os logs do agendador em seu pipeline de logs normal do Hermes para que promoções puladas ou falhas sejam visíveis.

Isso dá a você o mesmo comportamento de agrupamento que o cron Linux, mas gerenciado como configuração do Hermes em vez de crontab em nível de host.

Estratégia 4: Segmentar quadros e perfis para diferentes gateways

Se você opera múltiplos backends LLM — por exemplo:

• um nó de GPU pequeno com um modelo instruct de 7B
• um nó apenas de CPU para classificação leve
• uma caixa de alta performance separada para raciocínio pesado

você pode reduzir a contenção atribuindo diferentes perfis e quadros do Hermes a cada gateway.

Padrão típico:

• Crie perfis como research-gpu, summarise-cpu, ops-gateway.
• Configure cada perfil com uma URL base e chave de API dedicadas para seu próprio gateway.
• Crie faixas Kanban separadas ou até mesmo quadros separados para cada perfil.

Quando combinado com limites de despachante, isso mantém cada gateway saturado por seu próprio conjunto de trabalhadores, sem que uma carga de trabalho barulhenta prive as outras de recursos.

Monitoramento e Ajuste do Hermes Kanban

Qualquer estratégia que você escolher, você deve monitorar:

• Métricas do gateway LLM — taxa de solicitação, latência, taxa de erro, vazamento de tokens.
• Saúde do nó — utilização de GPU, uso de VRAM, carga de CPU e RAM.
• Métricas do Hermes — quantas tarefas estão em backlog, pronto, ativo e concluído.

Para linhas de base de métricas de produção e dashboards, veja Monitorar Inferência de LLM em Produção com Prometheus e Grafana e o hub de Desempenho de LLM.

Comece com baixa concorrência, e então gradualmente aumente os limites enquanto observa por:

• latência crescente com vazamento constante
• aumento de erros de timeout ou limite de taxa
• caudas longas onde algumas tarefas permanecem ativas por muito tempo

Assim que você ver esses sintomas, faça rollback para a configuração estável anterior e mantenha-a como seu padrão.

Quando o Kanban é a ferramenta certa

O Hermes Kanban brilha quando você tem:

• filas de espera de pesquisa ou engenharia de longa duração
• colaboração multi-agente com perfis nomeados
• workflows que devem sobreviver a reinícios e reinicializações de host
• humanos que querem um dashboard para triar trabalho

Se você só precisa de uma execução única para criar alguns ajudantes temporários, as ferramentas de tarefa delegada integradas são geralmente mais simples.
Uma vez que você precisa de histórico, dashboards e controle estrito sobre como seus agentes atingem LLMs auto-hospedados, o quadro Kanban mais o despachante é a base certa.

Com algumas configurações e agrupamento opcional baseado em cron, você pode manter o Hermes Kanban responsivo enquanto protege seu gateway e hardware.