셀프 호스팅 LLM 워크플로우를 위한 Hermes 에이전트의 칸반

Hermes Agent는 칸반 스타일의 보드와 Hermes Gateway를 함께 제공하며, 너무 많은 작업이 한 번에 배포되면 자체 호스팅 LLM을 포화 상태로 만들 수 있습니다.

이렇게 하면 자신의 LLM을 쉽게 DDoS(서비스 거부) 공격에 노출시킬 수 있다고 말씀드릴 수 있습니다.

Hermes 칸반은 ~/.hermes/kanban.db로 뒷받침되는 내구성 있는 다중 프로필 보드입니다.
각 레인은 작업의 단계를 나타내고, 각 카드는 특정 Hermes 프로필이 할당받을 수 있는 작업입니다.
기본 제공 기능으로 디스패처는 한 번에 여러 ready(준비됨) 상태를 가진 작업을 승진(promote)시킬 수 있습니다. 이는 탄력적인 클라우드 API에는 적합하지만, 소규모 자체 호스팅 GPU 클러스터에서는 과부하를 유발할 수 있습니다.

이 스택를 처음 사용하신다면, 더 넓은 Hermes 설정 및 운영 가이드와 주변 아키텍처에 대한 AI Systems pillar를 참조하십시오.

이 포스트에서는 다음 방법을 안내합니다:

• Hermes 칸반 배포가 LLM 게이트웨이와 어떻게 상호 작용하는지 이해하기.
• 무거운 작업에 대해 병렬 처리를 안전하게 제어하기.
• 크론(cron)을 사용하여 승진을 배치하여 백그라운드 작업이 인터랙티브 사용과 충돌하지 않도록 하기.
• 시스템 모니터링 및 튜닝을 통해 GPU가 과부하 없이 바쁘게 유지되도록 하기.

Hermes 칸반 및 디스패처의 작동 방식

높은 수준에서 시스템은 세 가지 레이어로 구성됩니다:

1. 보드 - 작업, 열, 관계 및 이력을 위한 내구성 있는 SQLite 상태.
2. 워커 - 작업을 처리하기 위해 격리된 워크스페이스에서 시작되는 Hermes 프로필.
3. 디스패처 - 배포 가능한 카드를 스캔하고 실행을 시작하는 장수명 프로세스.

CLI 또는 대시보드에서 생성된 작업은 일반적으로 backlog(백로그) 또는 ready(준비됨) 상태로 시작합니다.
디스패처는 자격이 있는 카드를 스캔하여 원자적으로 하나를 클레임(claim)하고, 해당 도구 및 메모리와 함께 할당된 프로필을 시작합니다.
각 워커는 그 후 LLM 게이트웨이 또는 로컬 런타임(예: Ollama, vLLM, llama.cpp로 뒷받침되는 OpenAI 호환 엔드포인트)을 호출합니다. 이러한 런타임 간의 배포 선택 사항에 대해서는 LLM Hosting in 2026 Local Self-Hosted and Cloud Infrastructure Compared를 참조하십시오. Ollama 자체에서 요청 팬아웃(request fan-out)을 튜닝하는 경우, 이는 How Ollama Handles Parallel Requests와 잘 맞습니다.

많은 무거운 작업을 추가하고 승진을 제한하지 않으면 게이트웨이에 동시 요청이 홍수처럼 몰릴 수 있습니다.
단일 GPU 또는 CPU 바운드 호스트의 경우, 이는 종종 더 나은 처리량 대신 큐잉, 스레싱(thrashing), 타임아웃을 의미합니다.

오늘날의 실용적 한계

현재 많은 팀이 사용하는 Hermes 빌드에서는 디스패처 구성이 두 가지 칸반 배포 키만 노출하며, 구성에서 전역 활성 작업 상한(global active-task cap)을 적용하지 않습니다:

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 10

활성 작업 제어에는 명시적 배포 주기(hermes kanban dispatch --max ...)와 의존성 모델링에 의존하십시오.

알려진 주의사항:

• 게이트웨이 내장 배포와 hermes kanban daemon --force를 동일한 보드에서 실행하지 마십시오. 클레임 경쟁(race)이 발생할 수 있습니다.
• 게이트웨이가 다운되면 ready 작업은 배포되지 않으며, 서비스가 복귀할 때 나중에 폭발적으로 발생할 수 있습니다.
• 긴 배포 간격은 클레임이 틱(tick) 단위로 발생하기 때문에 불규칙하게 느껴질 수 있습니다.
• 런 상태 및 재할당 엣지 케이스가 시간이 지남에 따라 패치되었기 때문에 버전 간에 동작이 달라질 수 있습니다.

동작이 이상해 보일 때 빠른 확인 방법:

# 1) 정확히 하나의 디스패처 경로가 활성 상태인지 확인
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) 배선된 칸반 디스패처 키 확인
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) 큐 모양 검사
hermes kanban list --status ready
hermes kanban list --status running

핵심 개념:

• 디스패처 구성은 dispatch_in_gateway 및 dispatch_interval_seconds를 배선합니다.
• dispatch --max는 총 실행 중인 작업이 아니라 해당 패스에서 새로 생성되는 스폰(spawn)을 제한합니다.
• 소규모 자체 호스팅 클러스터의 경우, 보수적으로 시작하고 지연 시간이 안정화된 후에만 증가시키십시오.

Hermes를 LLM 게이트웨이 근처에 처음 배포할 때:

• 구성에 지원되는 칸반 디스패처 키만 유지하십시오.
• 실제 큐 압력 하에서 GPU 및 CPU 사용률을 관찰하십시오.
• 결정론적인 속도를 위해 전략 1 또는 전략 2를 사용하십시오.

조사 결과 및 근본 원인

hermes kanban dispatch는 max_active_tasks를 위해 config.yaml을 읽지 않습니다.

hermes_cli/kanban.py에서 dispatch 명령은 --max를 CLI 상한(기본값 None)으로 노출하고 args.max만 kb.dispatch_once(...)로 전달합니다. 이 경로에는 max_active_tasks 구성 조회가 없습니다. hermes_cli/kanban.py raw를 참조하십시오.

그 후 kanban_db.dispatch_once에서 유일한 상한은 max_spawn이며, 논리는 다음과 동등합니다:

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

해당 배포 경로에는 이미 실행 중인 작업에 대한 확인이나 max_active_tasks 참조가 없습니다. hermes_cli/kanban_db.py raw를 참조하십시오.

유효한 동작:

hermes kanban dispatch

해당 패스에서 무제한(준비된 큐 크기로 제한됨).

hermes kanban dispatch --max 2

총 실행 중인 작업이 아니라 해당 패스에서 새로 생성되는 스폰만 제한합니다.

게이트웨이 배포 주변의 배선된 구성 노브(knob)는 kanban.dispatch_in_gateway 및 kanban.dispatch_interval_seconds입니다.
따라서 이 배포 경로에서 max_active_tasks는 구현되지 않았으므로 무시됩니다.

전략 1 - 엄격한 순차적 흐름을 위한 의존성 인코딩

일부 워크플로우(예: 다음 사례)는 엄격히 하나씩 이어져서 실행되어야 합니다:

• 공유 중간 아티팩트가 있는 다단계 데이터 파이프라인
• 마이그레이션 또는 인프라 변경
• 동일한 객체 스토어 또는 데이터베이스에 작성하는 배치 작업

Hermes 칸반은 작업 간의 부모-자식 의존성을 지원하므로, 자식 카드는 부모가 완료될 때까지 배포 가능해지지 않습니다.

Hermes CLI 주변의 작은 헬퍼 스크립트로 이를 모델링할 수 있습니다:

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Ingest customer logs for April' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'Generate April anomaly report' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'Publish April summary to dashboard' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

적절한 보드 정책과 낮은 디스패처 한계로 인해 부모 작업만 먼저 실행됩니다.
완료되면 자식 작업이 점차 준비 상태로 바뀌며, 디스패처는 동시성 상한을 초과하지 않으면서 하나씩 이를 가져옵니다.

전략 2 - 실행 인식 배포 상한을 가진 Linux cron 사용

결정론적인 속도를 원한다면 호스트 크론과 작은 래퍼 스크립트를 사용하십시오.
항상 dispatch --max 2를 호출하는 대신, 먼저 현재 실행 중인 작업 수를 센 다음 남은 슬롯만 배포하십시오.

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

# or where your hermes is installed
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 "Already at limit 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"

실행 가능하게 만드십시오:

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

다음으로 실행하십시오:

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

특정 보드의 경우:

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

크론으로 분당 한 번 예약하십시오:

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

운영 참고 사항:

• 크론은 종종 최소한의 PATH를 가지므로, hermes가 발견되지 않으면 스크립트 내에서 전체 경로(예: /usr/local/bin/hermes)를 사용하십시오.
• /var/log/hermes/...로 로그를 기록하려면 먼저 해당 디렉토리를 생성하고 크론 사용자가 쓰기 접근 권한을 갖도록 하십시오.

예시:

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

다음으로 크론 항목을 생성 또는 편집하십시오:

crontab -e

그런 다음 확인하십시오:

crontab -l

하나의 크론 항목으로 분 단위 미만의 주기

크론은 분당 한 번 틱(tick)하지만, 스크립트 내에서 짧은 루프를 실행하여 더 자주 배포할 수 있습니다.

예시 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 runs => every 15 seconds
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

실행 가능하게 만드십시오:

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

분당 한 번 예약하십시오:

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

이것은 flock이 중복 실행을 방지하면서 유효한 분 미만 주기를 제공합니다.

왜 이것이 작동하는가:

• list --status running은 현재 실행 부하를 제공합니다.
• dispatch --max N은 해당 패스에서의 새로운 스폰만 제한합니다.
• N을 남은 슬롯으로 계산하면 총 실행 중인 작업이 목표 상한 근처에 유지됩니다.

중요한 주의사항: 이 상한은 이 스크립트를 통한 배포에만 적용됩니다.
게이트웨이 내장 배포를 비활성화하지 않으면, 여전히 독립적으로 작업을 승진시킬 수 있습니다:

kanban:
  dispatch_in_gateway: false

공식 문서에서는 두 명령 기능과 칸반 기능 가이드의 게이트웨이 배포 기본값을 설명합니다: Hermes Kanban docs.

내부 Hermes 크론

사용하지 마십시오. 정말 LLM이 /path/hermes-kanban-dispatch-capped.sh 실행과 같은 정기 프롬프트를 처리하도록 하고 싶으신가요? 특히 유용한 작업을 열심히 하고 있을 때요?

Hermes 칸반 모니터링 및 튜닝

선택한 전략에 상관없이 다음을 모니터링해야 합니다:

• LLM 게이트웨이 메트릭 — 요청률, 지연 시간, 오류율, 토큰 처리량.
• 노드 건강 — GPU 사용률, VRAM 사용량, CPU 부하 및 RAM.
• Hermes 메트릭 — 백로그, 준비, 활성, 완료된 작업 수.

프로덕션 메트릭 베이스라인 및 대시보드에 대해서는 Monitor LLM Inference in Production with Prometheus and Grafana 및 더 넓은 LLM Performance hub를 참조하십시오.

낮은 동시성으로 시작한 다음, 다음을 관찰하면서 한계를 점진적으로 높입니다:

• 일정 처리량에서 지연 시간 증가
• 타임아웃 또는 속도 제한 오류 증가
• 일부 작업이 매우 오랜 시간 활성 상태로 머무는 긴 꼬리(long tails)

이러한 증상이 나타나면 즉시 이전 안정적인 구성으로 롤백하고 이를 기본값으로 유지하십시오.

칸반이 적합한 도구일 때

Hermes 칸반은 다음이 있을 때 빛을 발합니다:

• 장기간 유지되는 연구 또는 엔지니어링 백로그
• 명명된 프로필을 가진 다중 에이전트 협업
• 재시작 및 호스트 재부팅을 견뎌야 하는 워크플로우
• 대시보드를 통해 작업을 분류(triage)하려는 인간

일회성 실행으로 몇 개의 임시 헬퍼만 생성해야 한다면, 내장 대리(delegate) 작업 도구가 일반적으로 더 간단합니다.
일단 이력, 대시보드 및 자체 호스팅 LLM을 에이전트가 어떻게 타격(hit)하는지에 대한 엄격한 제어가 필요하면, 칸반 보드와 디스패처가 올바른 기반이 됩니다.

몇 가지 구성 트윅과 선택적 크론 기반 배치를 통해 게이트웨이와 하드웨어를 보호하면서 Hermes 칸반을 반응적으로 유지할 수 있습니다.