저는 셀프 호스팅(self-hosted) 모델이 실제로 에이전트(agent)를 구동할 수 있는지 테스트하는 오픈 소스 도구를 구축해 왔습니다. 제 자신의 환경에서 이를 실행했을 때 예상치 못한 결과가 나왔으며, 이는 일반적인 현상이라고 생각합니다.

사전 공개: 저는 QuantaMind(Apache 2.0, 오프라인 실행, 텔레메트리 없음)를 개발했습니다. 아래 데이터는 이 도구에서 도출되었습니다. 이 포스트는 도구에 관한 것이 아니라 발견한 사실에 관한 것입니다.

설정 (Setup)

• Qwen3.5-9B, Q4_K_M
• llama.cpp, 네이티브 함수 호출 (native function calling)
• 16GB M-series Mac
• 5개의 다단계 에이전트 작업 (multi-step agentic tasks), 각 작업당 k=4회 실행

k=4가 중요한 이유는, 단 한 번의 성공적인 실행으로 에이전트를 평가하는 것은 거의 아무런 정보도 주지 않기 때문입니다. 중요한 것은 매번 성공하느냐 하는 것이며, 따라서 네 번의 실행이 모두 통과해야만 해당 작업이 통과된 것으로 간주합니다.

합계: 80% 통과율 (20회 중 16회), 작업당 평균 4단계, 작업당 약 2,000 토큰.

컨텍스트 절벽 (The context cliff)

저는 프롬프트에 의미론적으로 관련 없는 산문을 채워 넣고, 도구 정의(tool definitions) 앞에 삽입한 뒤, 깊이가 증가함에 따라 도구 호출(tool-call) 정확도를 다시 측정했습니다.

프롬프트 깊이 (Prompt depth)	정확도 (Accuracy)
704 tok	100% (5/5)
...

약 6k까지는 평탄하게 유지되었습니다. 그러다 8.8k 지점에서 20포인트 하락했습니다.

이것이 메모리 문제가 아닌 이유

이 부분이 제가 논쟁하고 싶은 지점인데, 왜냐하면 대부분의 사람들이 로컬 에이전트의 규모를 산정하는 방식과 상충하기 때문입니다.

• 모델 가중치 (Model weights): 5.3GB
• GPU 주소 지정 가능 메모리 (GPU-addressable memory): macOS Metal 제한 하에 16GB 중 약 11.8GB
• f16 KV 캐시(KV cache) 기준 컨텍스트 용량: 약 53,000 토큰 (q8_0 ~107k, q4_0 ~214k)
• 에이전트 실행 중 실제로 사용된 피크 컨텍스트 (Peak context): 1,890 토큰 — 제가 시작했던 16,384 윈도우의 12%

따라서 메모리는 모델이 안정적으로 추론할 수 있는 양보다 약 5배 더 많은 컨텍스트를 수용할 수 있습니다. VRAM 계산기는 저에게 여유 공간이 있다고 알려주었습니다. 하지만 모델은 그 한계에 근접하기도 훨씬 전에 무너졌습니다.

실질적인 함의는 다음과 같습니다: "얼마나 많은 컨텍스트가 들어가는가"는 에이전트가 얼마나 많은 컨텍스트를 사용할 수 있는지를 결정하는 숫자가 아닙니다. 이 둘은 서로 다른 두 개의 한계치(ceiling)이며, 행동적 한계치(behavioral ceiling)는 훨씬 더 낮고 훨씬 더 파악하기 어렵습니다. 이는 명시적으로 나타나지 않습니다. 정확도가 그저 조용히 저하될 뿐입니다.

나를 더 두렵게 만든 실패

5개의 작업 중 4개는 4번의 실행 모두를 통과했습니다. 하나는 4번 모두 실패했습니다.

실패한 작업은 인시던트 롤백 체인(incident-rollback chain)이었습니다: get_incident → get_feature_flag → flag_off → rollback_release → schedule_fix. 모든 실행이 동일하게 실패했습니다. 모델이 체인 중간에 완료 신호(completion signal)를 내보내고 멈춰버린 것입니다.

충돌(crash)도 없었습니다. 잘못된 형식의 JSON(malformed JSON)도 없었습니다. 전체 배치(batch)에 걸쳐 스키마(schema)는 깨끗했습니다. 거부(refusal)도 없었습니다. 모델은 작업이 끝났다고 선언했지만, 실제로는 끝나지 않았습니다.

k=1(샘플링 개수 1) 상황이라면 이를 일시적인 실패(flaky miss)로 기록하고 넘어가겠지만, k=4 상황에서는 이것이 명백히 구조적인 문제입니다. 모델이 운이 없는 것이 아니라, 작업이 언제 완료되는지에 대해 일관되게 잘못된 믿음을 가지고 있는 것입니다.

이것이 바로 제가 프로덕션(production) 환경에서 가장 우려하는 실패 모드(failure mode)입니다. 정확히 아무런 에러도 발생하지 않기 때문입니다. 오케스트레이터(orchestrator)는 성공적인 완료를 확인하고 상태(state)의 절반이 누락된 채 다음 단계로 진행합니다. 당신이 가진 모든 모니터링 계층은 '정상(green)'이라고 보고할 것입니다.

대부분의 평가 도구(eval tooling)는 통과/실패(pass/fail) 점수를 매깁니다. 통과/실패 방식으로는 "모델이 충돌했는지"와 "모델이 완료했다고 거짓말을 했는지"를 구분할 수 없으며, 이 둘은 완전히 다른 해결책이 필요합니다.

지연 시간(Latency)에 대하여 짧게

5개 작업 전체 배치는 실제 시간(wall time)으로 39분 10초가 소요되었습니다. 가장 최악이었던 단일 작업은 4번의 실행 동안 16분 16초가 걸렸으며, 그중 14분 51초는 디코딩(decode)이었고 1분 19초는 프리필(prefill)이었습니다.

만약 로컬 에이전트 루프(local agent loops)를 최적화하고 있다면, 당신은 디코딩을 최적화하고 있는 것입니다. 프롬프트 캐싱(Prompt caching)이나 프리필(prefill) 트릭은 수치를 거의 변화시키지 못합니다.

내가 답할 수 없는 것들

저에게는 한 대의 머신과 하나의 모델 제품군(model family)뿐입니다. 미해결 과제들은 다음과 같습니다:

1. ~9k 절벽(cliff)이 이 양자화(quant) 모델에만 국한된 것인가요, 아니면 8–10B 계층 전반에 나타나는 현상인가요?
2. VRAM 여유 공간(headroom)이 더 많으면 이 지점이 이동할까요? 제 추측은 '아니오'입니다. 만약 이 절벽이 메모리가 아닌 어텐션(attention) 문제라면, 24GB 그래픽 카드를 사용하더라도 아무것도 변하지 않을 것입니다. 저는 이를 테스트할 수 없습니다.
3. 패딩 유형(padding type)에 따라 절벽의 위치가 이동할까요? 저는 관련 없는 산문(prose)을 사용했습니다. 구조화된 JSON 패딩은 다르게 동작할 수도 있습니다.

만약 유사한 실험을 수행하신다면, 그 수치를 공유해 주시면 감사하겠습니다.

재현 (Reproducing)

GitHub: github.com/QuantaMinds/QuantaMind — Apache 2.0, 완전 로컬 실행, 계정 불필요, 텔레메트리(telemetry) 없음.

qm cliff --backend llama_cpp --model <model> \
  --collection medium-coding-v2 --max-tokens 12288 \
  --steps 5 --source corporate_policy --mode native

점수 산정(Scoring)은 결정론적(deterministic)입니다. 올바른 도구와 올바른 인자를 사용하여 고정된 정답지(answer key)와 대조하여 확인합니다. LLM 판정관(LLM judge)은 사용하지 않는데, 모델을 사용하여 모델의 도구 호출(tool calls)을 채점하는 것은 바로 이 테스트가 측정하고자 하는 종류의 오류를 정확히 유발하기 때문입니다.

만약 방법론이 잘못되었다면, 차라리 지적을 받는 편이 낫습니다.

링크:
웹사이트: https://www.quantamind.co/
Discord: https://discord.com/invite/6CjSJyZTfG
X: https://x.com/QuantaMind_2025