기술은 프롬프트입니다. Hermes Apprentice가 이를 가중치(Weights)로 변환하는 방법

이 글은 Hermes Agent Challenge를 위한 제출물입니다.

내가 만든 것

새벽 2시, Telegram 알림이 울립니다:

[gc-7f3a] 졸업 후보: "SKU 추출" — 14개 예시, 일치율 91%.
학습을 시작하려면 gc-7f3a에 train을 답장하고, 무시하려면 skip gc-7f3a를 답장하세요.

당신은 잠결에 train gc-7f3a라고 답장을 보내고 휴대폰을 내려놓습니다. 40분 후 Grafana를 확인하니, 주황색 선(이 Hermes 에이전트의 시간당 업스트림 토큰 수)이 아래로 꺾여 있습니다. 그 자리에는 _전문가 라우팅 요청(specialist routed requests)_이라고 표시된 초록색 선이 들어와 있습니다. 다음 1만 건의 SKU 추출 요청은 비용이 전혀 들지 않습니다.

기술(Skills)은 프롬프트(Prompts)입니다. Apprentice는 그중 일부를 가중치(Weights)로 변환합니다.

Hermes Agent는 이미 당신이 처리하기를 원하는 첫 10가지 패턴에 대한 해답을 제공합니다. ~/.hermes/skills/<name>/SKILL.md에 저장된 YAML 프론트매터(frontmatter)를 포함한 Markdown 기술 파일입니다. 에이전트의 LLM 판단 기반 선택기(selector)가 요청마다 적절한 기술을 선택하며, 작업은 완료됩니다. 이는 처음 10가지 패턴까지는 잘 작동합니다. 20가지가 되면 힘에 부치기 시작합니다. 30가지가 되면 기능을 작성하는 시간보다 SKILL.md 파일을 편집하는 데 더 많은 시간을 쓰게 되며, 모델은 이미 수천 번이나 본 작업에 대해 여전히 전체 업스트림 비용을 지불하고 있습니다.

명확한 해답은 미세 조정(Fine-tuning)입니다. 하지만 드러나지 않는 비용은 인프라입니다. 세션 기록에서의 쌍 추출(pair extraction), 개인정보(PII) 비식별화, 베이스라인 러너(baseline runner), 승격 게이트(promotion gate), 버전 관리 레지스트리(versioned registry), 요청마다 전문가를 사용할지 아니면 거대 모델로 폴백(fallback)할지 결정하는 라우터(router), 새로운 전문가를 안전하게 배포하는 카나리(canary), 그리고 이 중 어느 하나라도 깨졌을 때 이를 알아낼 방법 등이 필요합니다. 대부분의 팀은 이를 구축하지 못할 것입니다.

Apprentice는 Hermes와 함께 설치하여 사용할 수 있는 도구 형태로 패키징된 인프라입니다. 이 도구는 Hermes의 SQLite 세션 데이터베이스를 관찰하고, 작은 임베딩 모델 (embedding model)을 사용하여 반복되는 패턴을 클러스터링 (clustering)합니다. 패턴이 성숙해지면 Telegram 졸업 메시지를 발송하고, 사용자의 로컬 GPU(또는 RunPod)에서 Unsloth QLoRA 학습 실행을 시작하며, 학습된 모델을 별도의 검증 게이트 (validation gate)를 통해 테스트합니다. 만약 이 전문가 모델이 베이스라인 (baseline)을 능가하면, 프록시 (proxy)가 이를 서비스하기 시작합니다. 이후의 매칭 요청은 해당 로컬 전문가 모델로 라우팅 (routing)됩니다. 매칭에 실패한 요청은 OpenRouter로 전달됩니다.

v0.2 인터페이스는 두 그룹으로 구성됩니다. 배포 (rollout) 측면에서는, 새로운 전문가 모델이 트래픽의 5%에서 시작하여 상위 모델 (upstream model)과의 섀도우 비교 (shadow-comparison) 일치도가 임계값 이상으로 유지됨에 따라 15%, 25%, 50%, 100%로 자동 승급합니다. 일치도가 떨어지면 자동 강등 및 격리 (quarantine)가 트리거됩니다. 트레이너 (trainer)는 기본적으로 세 가지 베이스 모델 (기본값은 Qwen2.5-1.5B, 그리고 Qwen2.5-3B, Llama-3.2-3B)을 지원하며, 이는 사용자가 편집 가능한 trainer/supported_models.yaml 파일에 정의된 패턴별 선택에 따릅니다. 두 개의 연관된 전문가 모델은 MCP가 제안하는 병합 (merge)을 통해 하나로 통합될 수 있으며, 이 과정에는 Telegram 승인이 필요하고 두 부모 베이스라인 모두에 대한 회귀 게이트 (regression gate)를 통과해야 합니다.

운영 (operations) 측면에서, 프록시는 X-Apprentice-Tenant 헤더와 API 키 헤더를 통해 요청마다 인증을 수행하고, 테넌트 (tenant)별 토큰 버킷 (token-bucket) 속도 제한을 적용하며, 할당량 (quota)을 추적합니다. 전역 패턴 (global patterns)은 모든 테넌트에게 공개됩니다. 월간 예산은 80%, 95%, 100% 지점에서 Telegram 알림을 게시하며, budget increase 10 명령어를 통해 복구 경로를 제공합니다. 로컬 GPU가 사용 중일 때, 오케스트레이터 (orchestrator)는 동일한 예산 범위 내에서 학습 작업을 RunPod의 A100, A6000 또는 L40S 스팟 인스턴스 (spot instances)로 넘깁니다. Grafana는 요청률, 지연 시간 (latency) p50/p95/p99, 에러율, 절감된 비용, 상위 패턴, 전문가 모델 대 상위 모델 지연 시간, 상태, 그리고 24시간 카운터를 보여주는 8개의 패널을 제공합니다. OpenRouter가 상위 트래픽을 처리하며, Fireworks, MiniMax, Together가 폴백 (fallback) 계층으로 작동합니다.

이 모든 것들은 저장소(repo) 내의 실제 명명된 모듈로 존재합니다. 이는 슬라이드 덱에 담긴 로드맵상의 약속이 아닙니다.

데모 (Demo)

단 하나의 명령어로 시드(seeded)된 피스처(fixture)를 대상으로 전체 루프를 실행할 수 있습니다:

bash scripts/demo-run.sh

해당 스크립트는 합성된 Hermes 세션 로그를 시딩하고, 탐지기(detector)를 실행하며, 패턴을 승격(graduate)시키고, 전체 파이프라인(데이터셋 빌더(dataset-builder), 트레이너(trainer), 병합(merge), 검증(validate), 승격(promote))을 실행합니다. 그 후 서빙(serving)과 프록시(proxy)를 시작하고, 새로운 전문가(specialist) 모델과 일치하는 테스트 요청을 보내며, 마지막에 요약 테이블과 함께 Grafana 대시보드 URL을 출력합니다. 이 모든 과정은 2080 Ti 환경에서 1시간이 채 걸리지 않아 완료됩니다.

데모 중에 가장 중요한 Grafana 뷰는 비용 절감(cost-saved) 패널입니다. 주황색

apprentice-setup --apply
apprentice-setup --apply --profile docker     # Firecracker를 실행하고 싶지 않은 경우
bash scripts/demo-run.sh                       # 엔드 투 엔드 (end-to-end) 스모크 테스트

모든 설정은 ~/.apprentice/.env에 유지됩니다. 설치 프로그램을 다시 실행하면 제공된 내용만 업데이트됩니다.

나의 기술 스택 (My Tech Stack)

• 언어: Go 1.26 (proxy, observer, detector, dataset-builder, registry, burst), Python 3.10+ (trainer, validator, serving, orchestrator, telegram, installer).
• 기본 모델 (Base model): Qwen2.5-1.5B-Instruct (Apache 2.0). QLoRA 학습 및 동일한 카드의 fp16 서빙을 위해 11 GB의 VRAM에 적합합니다. Qwen2.5-3B 및 Llama-3.2-3B가 대체 구성으로 설정되어 있습니다.
• 학습 (Training): Unsloth QLoRA, 4-bit 베이스 및 LoRA rank 16, trainer/profiles/profile_*.yaml을 통해 GPU별로 크기 조정.
• 서빙 (Serving): --enable-lora --max-loras 4 옵션을 사용한 vLLM 0.21. 여러 전문가(specialists)가 하나의 워밍업된 기본 모델(warm base model)을 공유하며, 어댑터(adapters)는 각각 약 18 MB의 추가 VRAM을 사용하여 핫스왑(hot-swap)됩니다.
• 라우팅 (Routing): ONNX 런타임을 통한 BGE-small (Apache 2.0), 384차원 L2 정규화 임베딩 (L2-normalized embeddings), 패턴별 중심점(centroids)에 대한 코사인 유사도 매칭.
• 개인정보 보호 (Privacy): dataset-builder 내 PII(개인 식별 정보) 삭제를 위한 Microsoft Presidio 사이드카 (sidecar). 학습 전 비밀번호 스캐너(Secrets scanner) 실행. 패턴별 데이터 카드(data cards)가 출처(provenance)를 기록.
• 관측 가능성 (Observability): 프록시의 /metrics에 대한 Prometheus 스크랩 (scrape), deploy/docker/compose.monitoring.yml에 있는 Grafana 대시보드.
• 클라우드 버스트 (Cloud burst): burst/에서 서명된 작업(signed jobs)에 의해 할당되는 RunPod A100 스팟 인스턴스. 예산 제한 적용.
• 업스트림 (Upstream): OpenRouter 기본, 멀티 프로바이더 폴백 체인 (Fireworks, MiniMax, Together).
• 격리 (Isolation): Hermes 프로세스의 기본값은 Firecracker 마이크로VM (microVM)이며, Docker Compose는 휴대 가능한 대안입니다.
• 제어 평면 (Control plane): 오케스트레이터(orchestrator) 내 MCP 서버가 dispatch_training, propose_merge, cost_summary, roi, demote 및 예산 도구들을 노출합니다.
• 운영자 UX (Operator UX): 졸업 승인, 병합(merge) 승인 및 예산 증액을 위한 Telegram.

Apprentice는 호스트에서 별도의 봇 프로세스를 실행하는 대신 Hermes 자체의 Telegram 어댑터(adapter)를 활용합니다.

Hermes Agent를 사용한 방법

Apprentice는 다른 에이전트 런타임(runtime)에서는 동일한 방식으로 작동하지 않을 것입니다.
이것이 바로 이번 챌린지를 위해 이를 구축한 핵심 이유입니다. 우리가 기반으로 삼은 Hermes의 기질(substrate)은 다음과 같습니다: SQLite 세션 데이터베이스(session database), Markdown 스킬 레지스트리(skill registry), no_agent 크론 잡(cron jobs), 그리고 기존의 Telegram 어댑터(adapter)입니다.

세션 DB가 입력값입니다

Hermes는 모든 채팅을 WAL 모드의 SQLite 데이터베이스인 ~/.hermes/state.db에 기록합니다. 스키마는 간단합니다: id, source, model, system prompt, 토큰 수(token counts)를 포함하는 sessions 테이블; role, content, tool_calls, 타임스탬프를 포함하는 messages 테이블; 그리고 전체 텍스트 검색(full-text search)을 단일 쿼리로 가능하게 하는 FTS5 가상 테이블이 있습니다. Apprentice의 observer (Go)는 이 데이터베이스를 테일링(tailing)하며 각 세션을 깨끗한 (user-input, big-model-output) 쌍으로 정규화합니다. Hermes의 패치나 스키마 마이그레이션, 에이전트의 포크(fork)는 전혀 필요하지 않습니다. observer는 Hermes가 이미 쓰고 있는 내용을 읽을 뿐입니다.

탐지기(detector) (Go, ONNX를 통한 BGE-small)는 observer로부터 쌍 스트림(pair stream)을 입력받아, 각 쌍의 사용자 측(user side)에 대해 384차원 임베딩(embeddings)을 계산하고 HDBSCAN으로 클러스터링(clustering)합니다. 클러스터가 샘플 임계값을 넘어서고 일관된 상향-응답(upstream-response) 형태를 보이면, 이는 오케스트레이터(orchestrator)의 작업 상태(job state) 내의 한 행인 _졸업 후보(graduation candidate)_가 됩니다.

Hermes 스킬이 출력값입니다

전문가가 승진 관문(promotion gate)을 통과하면, 검증기(validator)는 ~/.hermes/skills/<pattern-id>/SKILL.md 경로에 Markdown 스킬 파일을 작성합니다. Firecracker 프로필 하에서 해당 파일은 microVM으로 scp 전송되며, Hermes는 다음 /reload-skills 호출 또는 세션 시작 시 이를 스킬 레지스트리(skill registry)에 등록합니다. 이는 두 가지 작업을 동시에 수행합니다. 먼저, Hermes의 LLM 판단 선택기(LLM-judged selector)에 해당 패턴이 존재함을 알려주어 (hermes skills list에 나타나도록 함), 스킬의 프론트매터(frontmatter)에 저장된 패턴 ID를 통해 프록시(proxy)가 올바른 어댑터(adapter)를 가리키도록 합니다. 라우팅 자체는 LLM 선택기가 아닌, 임베딩(embedding)에 대한 코사인 유사도 매칭(cosine match)을 통해 프록시 내에서 결정론적(deterministically)으로 발생합니다. SKILL.md는 생태계 가시성을 위해 존재하며, 센트로이드(centroid)는 정확성을 위해 존재합니다.

hermes cron no_agent 작업은 심장 박동입니다

Apprentice의 자율적인 측면은 Hermes microVM 내에 등록된 hermes cron --no-agent 작업으로 실행됩니다:

ssh root@GUEST 'hermes cron create --name apprentice-telegram --no-agent \"    --script apprentice-telegram-dispatch.sh --deliver telegram "every 5m"'"
ssh root@GUEST 'hermes cron create --name apprentice-poll-replies --no-agent \"...

no_agent 모드가 중요한 이유는 Hermes의 LLM이 이러한 cron 작업을 해석하도록 원치 않기 때문입니다. 이들은 정해진 일정에 따라 실행되고 종료되는 셸 스크립트(shell scripts)입니다. 디스패치(dispatch) 스크립트는 졸업 알림(graduation notifications), 병합 제안(merge proposals), 예산 경고(budget alerts)의 아웃박스(outbox)를 비웁니다. 폴(poll) 스크립트는 Hermes의 getUpdates 어댑터를 통해 Telegram 답장을 읽고, train gc-7f3a를 오케스트레이터(orchestrator)를 위한 구조화된 작업 요청(structured job request)으로 변환합니다. 오케스트레이터의 watcher.tick은 대기 중인 요청을 읽고 파이프라인(pipeline)을 실행하는 세 번째 cron 작업입니다.

이를 통해 Apprentice 프로세스 모델을 작게 유지할 수 있었습니다. 호스트에서 python-telegram-bot을 실행하거나 별도의 웹훅(webhook) 서버를 세울 필요가 없었습니다. 루프의 운영자 대면(operator-facing) 구성 요소는 모두 Hermes가 이미 노출하고 있는 인프라를 활용합니다.

졸업, 엔드 투 엔드(end to end)

전체 루프의 구체적인 경로는 다음과 같습니다: