Intel Arc GPU에서 Hermes Agent를 사용하여 구축한 자가 관리형 AI 실험실

이 글은 Hermes Agent Challenge: Hermes Agent에 대해 작성하기 과제의 제출물입니다.

내가 구축한 것

Hermes Agent를 기반으로 하는 자가 관리형 AI 워크스페이스(AI workspace)를 구축했습니다. 여기서 자율 에이전트(autonomous agent)는 Intel Arc GPU 상에서 로컬 추론 스택(local inference stack)을 실행하고, 연구 및 문서화를 자동화하며, 크론 잡(cron jobs)을 관리하고, 인간의 미세 관리(micro-management) 없이 여러 LLM 백엔드를 조정합니다. 인간은 목표를 지시하고, 에이전트가 모든 것을 실행합니다.

하드웨어: GMKtec EVO-T1 미니 PC (Intel Core Ultra 9 285H, Intel Arc 140T iGPU, 64GB DDR5-5600) — 자율 AI 에이전트를 24시간 365일 실행할 수 있는 휴대 가능한 45W 시스템입니다.

이 시스템은 다음을 관리합니다:

로컬 LLM 추론 (Local LLM inference): Intel Arc SYCL (iGPU) 상의 llama.cpp를 통한 추론
자동화된 연구 파이프라인 (Automated research pipelines): 구조화된 문서를 영구 보관소(persistent vault)에 입력
멀티 모델 테스트 및 벤치마킹 (Multi-model testing and benchmarking): 9B에서 35B 파라미터에 이르는 9개 이상의 모델
크론 기반 모니터링 (Cron-driven monitoring): 시장 데이터, 시스템 상태, 메모리 관리
자가 유지 기술 (Self-maintaining skills): 상황이 변할 때 에이전트가 자신의 기술과 문서를 스스로 업데이트

아키텍처 (Architecture)

[ User Goals ]
      │
      ▼
...

에이전트는 다음과 같은 Hermes 세션으로 실행됩니다:

영구 메모리 (Persistent memory): 환경에 대한 노트, 사용자 선호도, 도구의 특이사항, 프로젝트 컨벤션(conventions)
지속 가능한 기술 (Durable skills): DevOps, MLOps, 연구 등을 위한 40개 이상의 전문화된 절차
도구 세트 (Toolsets): 터미널(terminal), 브라우저(browser), 파일(file), 크론(cron), git 등
전체 시스템 액세스 (Full system access): 빌드, 디버그, 튜닝 및 모든 것을 자율적으로 문서화

GMKtec EVO-T1 하드웨어

호스트는 GMKtec EVO-T1 미니 PC입니다:

CPU: Intel Core Ultra 9 285H (Arrow Lake, 16 코어, 최대 5.4GHz)
iGPU: Intel Arc 140T (128 Xe 코어, 시스템 DDR5를 VRAM으로 공유)
RAM: 64GB DDR5-5600 (~58GB를 GPU에서 주소 지정 가능)
전력 (Power): 풀 로드 시 약 45W 지속
폼 팩터 (Form factor): 약 0.6L, 휴대 가능

Intel Arc 140T iGPU는 추론 엔진 (inference engine) 역할을 합니다. llama.cpp SYCL 백엔드 (backend)와 Intel oneAPI 2026.0을 사용하여, 에이전트는 131K 컨텍스트 (context) 크기에서 GGUF 모델을 로컬에서 실행합니다. 대규모 컨텍스트 크기에서 JIT 컴파일 (JIT compilation) 충돌을 방지하기 위해 중요한 커널 수준의 SYCL 수정 사항(CUDA 스타일의 링커 플래그인 -ze-intel-greater-than-4GB-buffer-required를 제거하고 ONEAPI_DEVICE_SELECTOR=level_zero:gpu를 설정하는 작업)이 필요했으며, 이는 에이전트가 직접 진단하고 적용했습니다.

구축 방법

모든 구현은 Hermes Agent에 의해 수행되었습니다. 인간은 상위 수준의 목표를 지시했고, 에이전트가 모든 기술적 단계를 실행했습니다.

1단계: 로컬 추론 서버 (Intel Arc 기반 llama.cpp)

Intel Arc SYCL을 백엔드로 사용하는 llama.cpp 추론 서버를 구축했습니다. 이 서버는 모델 로딩, 모델별 컨텍스트 크기 지정, 그리고 스펙 디코딩 (spec decode) 설정을 처리합니다.

중요한 미묘한 차이점: 모델마다 서로 다른 컨텍스트 크기가 필요합니다. CTX_SIZE는 전역적으로 설정하는 것이 아니라 모델별로 설정되어야 합니다. 9B 코더 (coder) 모델에는 130k를 할당하고, 27B 모델에는 65k를 할당합니다. 에이전트는 모델별 시작 구성 (startup configs)을 통해 이를 처리합니다.

주요 SYCL 수정 사항: SYCL 백엔드에 심각한 버그가 있었습니다. ggml-sycl/CMakeLists.txt에 있는 -ze-intel-greater-than-4GB-buffer-required 링커 플래그는 어떤 연산이 GPU에서 CPU SYCL 장치로 폴백 (fallback)될 때 JIT 컴파일 실패를 유발했습니다. 이 플래그를 제거하고 ONEAPI_DEVICE_SELECTOR=level_zero:gpu를 설정하여 GPU 전용으로 제한함으로써, 131K 컨텍스트에서 모델 로딩을 방해하던 RMS_NORM 충돌을 제거했습니다. 에이전트가 이를 찾아내어 진단하고 수정했습니다.

2단계: Hermes Agent 구성

다음과 같이 Hermes를 구성했습니다:

기본 제공자(default provider)로 OpenRouter 설정 (클라우드 폴백 (cloud fallback))
로컬 제공자(local provider)로 로컬 llama-server 설정 (개인정보 보호가 중요한 작업의 기본 수단)
반복적인 작업 패턴을 위한 스킬 시스템 (skills system)
세션 간 메모리 지속성 (memory persistence)

3단계: 자동화를 위한 크론 잡 (Cron Jobs)

에이전트는 예약된 연구, 커밋/푸시 (commit/push) 사이클, 그리고 상태 점검 (health checks)을 실행하기 위해 Hermes cron을 사용합니다:

시장 데이터 모니터링 (Market data monitoring) (Polymarket, Kalshi 피드)
워크스페이스 백업 자동화 (Workspace backup automation)
코드베이스 품질 스캔 (Codebase quality scans)
보안 모니터링 (Security monitoring) (SSH 무차별 대입 공격 (brute-force), 시스템 상태, CVE 피드)

Step 4: 연구 파이프라인 (research vault)

에이전트는 자율적인 연구를 수행하고 그 결과를 구조화된 볼트 (vault)에 기록합니다:

research-vault/
├── challenges/       # 개발 챌린지 연구, 호환성 패치
├── research/         # 하드웨어, 모델, 호환성 연구
...

모델 라인업 (Model Lineup)

시스템은 작업 유형에 따라 여러 GGUF 모델을 조정합니다:

모델	아키텍처 (Architecture)	파라미터 (Params)	컨텍스트 (Context)	양자화 (Quant)	역할 (Role)	비고 (Notes)
Qwen3.5-9B-Sushi-Coder-RL	Qwen 3.5 MoE	9B	130K	Q4_K_M	데일리 드라이버 (Daily driver)	RL 튜닝됨, 최상의 에이전트 품질, 깔끔한 JSON 출력
...

이 모델들을 선택한 이유

Sushi 9B는 이 하드웨어에서 에이전트 작업(agentic work)을 수행할 수 있는 유일한 프로덕션 가능 9B 모델입니다. 6개의 모든 에이전트 테스트를 통과했으며, HTTP 500 에러가 0건이었고, 유효한 JSON을 생성하며, 다회차 컨텍스트 (multi-turn context)를 정확하게 유지했습니다.
Coder 30B는 MoE 모델(총 30B, 활성 파라미터 3B)이므로 파라미터 수가 많음에도 불구하고 디코딩 (decode) 속도가 빠릅니다. 9B 모델의 8.24 t/s 대비 11.52 t/s의 디코딩 속도를 보여줍니다.
DS-V4-Flash는 구조화된 출력이 필요하지 않은 빠른 추론 작업에 유용합니다. 190 t/s의 프리필 (prefill) 속도로 짧은 프롬프트에 대해 매우 빠릅니다.
27B급 모델들은 9B와 35B 사이의 간극을 메워줍니다. 공유 메모리 풀 (shared memory pool)에서 더 큰 모델의 VRAM 오버헤드 없이 합리적인 품질을 제공합니다.

에이전트 벤치마크 결과 (Agentic Benchmark Results)

131K 컨텍스트에서 모든 9B 모델을 대상으로 종합적인 에이전트 평가를 실행했습니다:

모델	테스트 통과 (Tests Pass)	HTTP 500	JSON 유효성 (JSON Valid)	총 소요 시간 (Total Time)	품질 (Quality)
Sushi 9B	6/6	0	예 (3/3)	561s	최상 (Best)
...

주요 발견 사항 (Key Findings)

Sushi 9B (프로덕션 데일리 드라이버):

오류 없이 6개의 에이전트 테스트 (agentic tests)를 모두 통과한 유일한 모델
3턴에 걸친 정확한 다회차 문맥 유지 (multi-turn context retention)
유효한 구조화된 JSON 출력 (T2: 3/3 점수)
정확한 VRAM 계산 (모든 9B 모델: 130K 컨텍스트 (ctx) 기준 약 9.7GB, 58GB 여유 공간에서 OOM (Out of Memory) 위험 없음)
최상의 지시 이행 능력 (10개의 제약 조건, 4개의 단락)

Qwopus MTP (사용 중단됨):

6개 테스트 중 4개에서 HTTP 500 내부 서버 오류 (internal server errors) 발생
중국어와 영어가 섞인 가짜 텍스트 (pseudotext)가 포함된 깨진 출력
KV 캐시 오염 (KV cache contamination) — 손상된 출력이 후속 요청을 오염시킴
이는 MTP 병합 (merge) 과정에서의 모델 품질 문제이며, 설정으로는 해결할 수 없음

DS-V4-Flash (보조):

안정적이지만, 모든 출력이 reasoning_content에만 포함됨 (content 필드는 비어 있음)
추론은 일관적이지만, content 필드 내에 유효한 구조화된 JSON을 생성하지 못함
빠른 프리필 (prefill, 190 t/s) 속도를 보이나 디코딩 (decode)은 8.24 t/s

검증된 기술적 결정 사항

로컬 우선, 클라우드 폴백 (Local-first, cloud-fallback): 모든 추론은 기본적으로 로컬에서 실행됩니다. 클라우드는 로컬에서 실행되지 않는 모델에 대해서만 사용됩니다.
모델별 컨텍스트 크기 지정 (Per-model context sizing): 컨텍스트 창 크기는 전역 설정이 아닌 모델별로 지정됩니다. 이는 Arc GPU의 공유 VRAM에서 OOM이 발생하는 것을 방지합니다.
프롬프팅보다 스킬 우선 (Skills over prompting): 모든 반복되는 워크플로우는 스킬 파일 (skill file)로 인코딩됩니다. 시스템이 스스로를 유지 관리합니다.
Git 기반 볼트 (Git-backed vault): 모든 연구 결과는 GitHub에 자동으로 커밋됩니다. 워크스페이스 자체가 결과물 (artifact)입니다.
자동 보안 모니터링 (Automated security monitoring): 에이전트가 침입을 감시하고, CVE 피드를 모니터링하며, Discord에 경고를 게시합니다 — 워크스페이스가 스스로를 방어합니다.

보안 인프라 (Security Infrastructure)

서버는 Hermes Agent에 의해 설정된 자동 보안 모니터링을 실행합니다:

UFW 방화벽 (UFW firewall) — 기본적으로 모든 인바운드(incoming) 차단, LAN 및 Tailscale을 통한 SSH 접속만 허용
fail2ban — 3회 SSH 로그인 실패 시 자동 차단
Cron: security-monitor — 30분마다 무차별 대입 공격(brute-force), 신규 장치, 방화벽, 서비스, 게이트웨이 점검
Cron: vulnerability-feed-monitor — 12시간마다 Ubuntu, 커널(kernel), Docker, Freebox OS에 대한 CVE 모니터링 수행
Discord 알림 (Discord alerts) — CRITICAL(심각) 및 HIGH(높음) 등급의 보안 위협 발견 시 자동 게시
침투 테스트 도구 (Pentest tools) — nmap, masscan, tcpdump, arp-scan, netcat, wireshark

주요 수치 (Key Numbers)

58GB Intel Arc 140T의 공유 VRAM
130K 컨텍스트 윈도우 (context window) (Sushi 9B)
9.7GB 9B 모델의 130K 컨텍스트 사용 시 총 VRAM 사용량 (가중치(weights) + KV 캐시(KV cache))
48GB 130K 컨텍스트 사용 시 남는 VRAM 여유 공간 (headroom)
8.24 t/s 디코딩 속도 (decode speed) (Sushi 9B)
166 t/s 프리필 속도 (prefill speed) (Sushi 9B)
190 t/s 프리필 속도 (prefill speed) (DS-V4-Flash)
~36-37초 생성 턴당 소요 시간 (Sushi 9B, max_tokens 256 기준)
0개 6회의 에이전트 테스트(agentic tests) 동안 발생한 HTTP 500 오류 (Sushi 9B)
9개 이상 테스트된 GGUF 모델 (9B에서 35B 파라미터 규모)
6개월 이상 Hermes Agent에 의해 지속된 로컬 추론(local inference) 개발
자동 보안 모니터링 (Automated security monitoring) — 로그 분석, 침입 탐지(intrusion detection), CVE 피드 모니터링, Discord 알림

데모 / 재현 방법 (Demo / How to Replicate)

llama.cpp SYCL 빌드, Hermes Agent 설정, 벤치마크 제품군(benchmark suite), 그리고 문서화에 이르는 전체 설정은 Hermes Agent에 의해 구축되고 유지 관리되었습니다.

최소 설정:

# 1. SYCL을 사용하여 llama.cpp 클론 및 빌드
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp && cmake -B build -DGGML_SYCL=ON && cmake --build build
...

모든 로컬 모델 연구, SYCL GPU 디버깅, 프로덕션 추론 설정, 벤치마크 설계, 보안 강화(security hardening), 그리고 이 블로그 게시물은 Hermes Agent에 의해 구현되었습니다. 인간은 목표를 지시하고 결과를 검증했습니다. 에이전트는 커널 플래그 수정(kernel flag surgery)부터 최종 문서화에 이르기까지 모든 단계를 실행했습니다.