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

Hermes 에이전트는 자체 호스팅 LLM 게이트웨이에 과부하를 줄 수 있는 칸반 스타일의 작업 보드를 기본 제공합니다. 모든 작업을 동시에 실행하도록 방치하면 말이죠.

Hermes Kanban은 ~/.hermes/kanban.db에 의해 지원되는 내구성 있는 다중 프로필 보드입니다. 각 레인은 작업의 한 단계를 나타내고, 각 카드는 특정 Hermes 프로필이 할당받을 수 있는 작업을 의미합니다. 기본적으로 디스패처 데몬은 ready(준비됨) 상태의 작업 수에 관계없이 에이전트를 기꺼이 시작합니다. 이는 클라우드 API에는 적합하지만, 자체 호스팅된 GPU 클러스터가 소규모인 경우 위험할 수 있습니다.

이 스택에 익숙하지 않으시다면, 먼저 더 넓은 범위인 Hermes 설정 및 운영 가이드와 AI Systems pillar에서 주변 아키텍처를 참고하세요.

이 글에서는 다음 사항을 설명합니다:

• Hermes Kanban과 디스패처가 LLM 게이트웨이와 어떻게 상호작용하는지 이해하기.
• 무거운 작업에 대해 순차적 또는 제한된 병렬 실행을 구성하기.
• 야간 작업이 낮 시간대의 대화형 사용과 충돌하지 않도록 cron을 통해 작업을 배치 처리하기.
• GPU가 바쁘게 유지되지만 과부하가 걸리지 않도록 시스템을 모니터링하고 튜닝하기.

Hermes Kanban과 디스패처의 작동 방식

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

1. 보드 — 작업, 열, 관계 및 기록을 저장하는 내구성 있는 SQLite 데이터베이스.
2. 워커(Workers) — 격리된 워크스페이스에서 시작되어 작업을 처리할 수 있는 Hermes 프로필.
3. 디스패처 데몬(Dispatcher daemon) — 보드를 감시하고 작업을 실행(run)으로 승격시키는 장시간 실행 프로세스.

CLI 또는 대시보드를 사용하여 작업을 생성하면, 해당 작업은 보통 backlog(백로그) 또는 ready(준비됨) 열에서 시작됩니다. 디스패처는 주기적으로 필터 조건을 충족하는 작업을 스캔하고, 원자적으로 카드를 청구(claim)한 후 적절한 도구와 메모리를 갖춘 할당된 프로필을 시작합니다. 각 워커는 이후 LLM 게이트웨이 또는 로컬 런타임(예: Ollama, vLLM, llama.cpp를 프론트하는 OpenAI 호환 프록시)과 통신합니다. 이러한 런타임 간의 배포 선택에 대해서는 LLM 호스팅 2026: 로컬, 자체 호스팅 및 클라우드 인프라 비교를 참고하세요. Ollama 자체의 요청 팬아웃(fan-out)을 튜닝 중이라면, Ollama가 병렬 요청을 처리하는 방법과 함께 사용하는 것이 좋습니다.

다른 조치를 취하지 않고 무거운 연구 작업 50개를 추가하면, 디스패처는 이 50개 작업을 모두 시작하려 할 수 있으며, 게이트웨이에 동시 요청이 홍수처럼 밀려듭니다. 단일 GPU 또는 CPU 바운드 노드에서는 처리량 대신 큐잉, 스래싱 및 타임아웃이 발생합니다.

전략 1: 디스패처에서 동시성 감소

가장 단순한 제어 방법은 디스패처가 병렬로 실행할 수 있는 워커의 수를 제한하는 것입니다. Hermes 구성 파일에서는 보통 Kanban 디스패처와 워커 풀을 제어하는 섹션을 볼 수 있습니다.

현재 Hermes 릴리스에서는 디스패처가 기본적으로 hermes gateway start에 임베딩되어 있으며, 동일한 청구 및 스폰 커널이 여기서도 동시성 한계를 강제합니다. 그러나 사용자들이 제한 드리프트(limit drift)처럼 보이는 이상한 동작을 보고하는 경우가 있으므로, 한계 자체를 비난하기 전에 런타임 조건을 확인해야 합니다.

TOML 스타일 구성을 사용한 최소 예시는 다음과 같습니다:

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

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

사용하는 버전에 다른 키 이름이 사용되는 경우, 설정을 매핑할 때 동일한 의도를 유지하세요. 명령어 이름과 운영자 흐름은 Hermes Agent CLI 치트시트에 요약되어 있습니다:

• 보드 전체의 활성 작업 총수에 대한 한계
• 프로필별 또는 워커 풀별 병렬 처리에 대한 한계
• 선택적 디스패치 틱 간격

문서 및 커뮤니티 스레드에서 알려진 주의 사항:

• 같은 kanban.db에서 게이트웨이 임베디드 디스패치와 레거시 hermes kanban daemon --force를 동시에 실행하지 마세요. 이렇게 하면 청구 경쟁(race)이 발생합니다.
• 게이트웨이가 다운되면 ready 작업은 전혀 디스패치되지 않으며, 게이트웨이가 복구되면 갑자기 폭주하는 것처럼 보입니다.
• 긴 디스패치 간격은 청구가 연속적으로 일어나지 않고 틱 단위로 일어나기 때문에 불균형한 스케줄링처럼 느껴질 수 있습니다.
• 이전 Kanban 빌드에서는 후속 패치에 걸쳐 여러 실행 상태 및 재청격(reclaim) 경계 사례가 수정되었으므로, 동작이 버전마다 다를 수 있습니다.

동작이 이상해 보일 때의 빠른 검증 체크리스트:

# 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 active

핵심 개념:

• max_active_tasks는 한 번에 active(활성) 상태일 수 있는 Kanban 카드의 수를 제한합니다.
• max_parallel_per_profile은 여러 프로필을 실행하더라도 일부 무거운 프로필만 소수 함께 실행되도록 보장합니다.
• 소규모 자체 호스팅 클러스터의 경우 지연 시간을 예측 가능하게 유지하기 위해 보통 1에서 4 사이의 값을 원합니다.

LLM 게이트웨이 근처에 Hermes를 처음 배포할 때는 보수적으로 시작하세요:

• max_active_tasks = 1로 시작합니다.
• GPU 및 CPU 사용률을 관찰합니다.
• 하드웨어가 명확하게 과소 사용되고 있는 경우에만 2 또는 3으로 증가시킵니다.

전략 2: 엄격한 순차적 흐름을 위한 종속성 인코딩

일부 워크플로우(예: 다음 사례)는 엄격하게 한 가지씩 순차적으로 실행되어야 합니다:

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

Hermes Kanban은 작업 간의 부모-자식 종속성을 지원하므로, 자식 카드가 부모가 완료된 후에만 디스패치 가능해집니다.

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

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

전략 3: 자동 디스패치 비활성화 및 cron 사용

일부 환경에서는 무거운 워크로드에 대해 명시적인 시간 창을 선호할 수 있습니다. 예를 들어, GPU가 유휴 상태인 자정 이후에 연구 작업과 문서 수집이 실행되도록 원할 수 있습니다.

이 설정에서 사람들이 cron이라고 부르는 스케줄링 변형은 두 가지입니다:

1. crontab을 사용하는 Linux 호스트 cron.
2. Hermes 구성 내의 Hermes 내부 스케줄러 cron 표현식.

옵션 A: Linux 호스트 cron

이 모델에서는 자동 Kanban 디스패치를 비활성화하고 OS가 래퍼 스크립트를 스케줄링하도록 합니다.

예제 스크립트:

#!/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 "Promoting task ${id} to active"
  hermes kanban promote --id "${id}" --column active
done

그리고 디스패처 또는 게이트웨이가 실행되는 호스트에 Linux cron 항목을 추가합니다:

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

이것은 준비 상태에 카드를 얼마나 많이 넣든 관계없이 매 15분마다 최대 두 개의 새 작업만 활성 상태가 됨을 보장합니다.

옵션 B: Hermes 내부 cron 스케줄러

스케줄링 규칙을 Hermes 내부에 유지하고 싶다면, Hermes 구성에서 cron 표현식으로 예약된 작업을 정의하고 그곳에서 동일한 promote 명령을 호출합니다.

예제 패턴:

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

Hermes 빌드가 스케줄러 관리 명령을 노출한다면, 구성 파일을 수동으로 편집하는 대신 CLI에서 동일한 작업을 등록할 수 있습니다:

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

설치된 버전에 hermes scheduler jobs ...가 없으면, 위에 있는 구성 기반 방법을 계속 사용하고 스케줄러가 새 작업을 인식하도록 Hermes를 다시 로드하거나 재시작하세요.

안전하게 사용하는 방법:

• 스케줄러 작업이 유일한 프로모터라면 kanban.dispatcher.enabled = false를 유지하세요.
• 1 또는 2와 같은 낮은 --max 값으로 시작하세요.
• 건너뛰거나 실패한 프로모션이 가시화되도록 스케줄러 로그를 일반적인 Hermes 로그 파이프라인에 두세요.

이것은 Linux cron과 동일한 배치 동작을 제공하지만, 호스트 수준의 crontab 대신 Hermes 구성으로 관리됩니다.

전략 4: 다른 게이트웨이를 위한 보드 및 프로필 세분화

여러 LLM 백엔드를 운영한다면(예: 다음과 같은 경우):

• 7B 인스트럭션 모델을 갖춘 소규모 GPU 노드
• 경량 분류를 위한 CPU 전용 노드
• 무거운 추론을 위한 별도의 고급 기기

각 게이트웨이에 다른 Hermes 프로필과 보드를 할당하여 경쟁을 줄일 수 있습니다.

일반적인 패턴:

• research-gpu, summarise-cpu, ops-gateway와 같은 프로필을 생성합니다.
• 각 프로필을 자체 게이트웨이에 대한 전용 기본 URL 및 API 키로 구성합니다.
• 각 프로필에 대한 별도의 Kanban 레인 또는 별도의 보드를 생성합니다.

디스패처 한계와 결합하면, 이는 각 게이트웨이가 다른 워크로드가 굶주리지 않도록 자체 워커 세트로 포화 상태를 유지하게 합니다.

Hermes Kanban 모니터링 및 튜닝

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

• LLM 게이트웨이 메트릭 — 요청률, 지연 시간, 오류율, 토큰 처리량.
• 노드 건강 상태 — GPU 사용률, VRAM 사용량, CPU 부하 및 RAM.
• Hermes 메트릭 — backlog, ready, active, done 상태에 있는 작업 수.

프로덕션 메트릭 기준 및 대시보드에 대해서는 Prometheus 및 Grafana로 프로덕션 LLM 추론 모니터링 및 더 넓은 LLM Performance hub를 참조하세요.

낮은 병렬 처리로 시작한 다음, 다음 사항을 관찰하면서 한계를 점진적으로 높입니다:

• 처리량이 일정할 때 지연 시간 증가
• 타임아웃 또는 속도 제한 오류 증가
• 일부 작업이 매우 긴 시간 동안 활성 상태를 유지하는 긴 꼬리(long tails)

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

Kanban이 적합한 도구인 경우

Hermes Kanban은 다음과 같은 경우에 빛을 발합니다:

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

일회성 실행으로 몇 가지 임시 헬퍼를 생성하는 것만 필요하면, 내장된 대리(delegate) 작업 도구가 일반적으로 더 단순합니다. 하지만 기록, 대시보드 및 자체 호스팅 LLM에 에이전트가 접근하는 방식에 대한 엄격한 제어가 필요해지면, Kanban 보드와 디스패처가 올바른 기반이 됩니다.

구성 설정 몇 가지와 선택적 cron 기반 배치를 통해 Hermes Kanban을 반응 있게 유지하면서 게이트웨이와 하드웨어를 보호할 수 있습니다.