1M 컨텍스트의 현실: Qwythos-9B-Claude-Mythos-5 테스트

오픈 소스 세계의 대부분의 "긴 컨텍스트 (long context)" 주장은 마케팅용 미사여구에 불과합니다. README에서 1M 토큰 창을 보게 되고 모델을 로드하지만, 32k 토큰쯤 가면 모델은 자신의 전기(biography)를 환각(hallucinating)하거나 문서의 중간 부분을 완전히 무시해 버립니다.

저는 지난 며칠 동안 empero-ai/Qwythos-9B-Claude-Mythos-5-1M-GGUF를 혹독하게 테스트했습니다. AI 아키텍트로서 저는 "분위기 (vibe)"에는 관심이 없습니다. 저는 검색 정확도 (retrieval accuracy), 지연 시간 예산 (latency budgets), 그리고 컨텍스트 창 (context window)이 포화 상태일 때 모델이 실제로 프롬프트 (prompt)를 준수하는지에 관심이 있습니다.

설정 (The Setup)

지연 시간 (latency)을 예측 가능하게 유지하기 위해 로컬 장비에서 GGUF 양자화 (quant) 버전을 사용하여 실행했습니다. 목표는 1M 토큰을 로드할 수 있는지 여부가 아니라, 로드하는 동안 모델이 "일관성 (coherent)"을 유지하는지 확인하는 것이었습니다. 저는 방대한 코드베이스 (약 400k 토큰)와 세 개의 서로 다른 디렉토리에서 점들을 연결해야 하는 복잡한 아키텍처 질문 세트를 입력했습니다.

"건초더미 속의 바늘 (Needle in a Haystack)"의 현실

표준적인 "건초더미 속의 바늘" 테스트는 너무 쉽습니다. 실제 배포 환경은 "건초더미 위에서의 추론 (reasoning over the haystack)"에 관한 것입니다.

저는 Qwythos에게 제공된 컨텍스트 내의 네 가지 서로 다른 파일에 분산된 분산 잠금 메커니즘 (distributed locking mechanism)에서 논리적 결함을 식별하도록 요청했습니다.

결과: 모델은 단순히 바늘을 찾아낸 것에 그치지 않고, 그 바늘이 제가 구현한 특정 에지 케이스 (edge case)에서 왜 레이스 컨디션 (race condition)을 일으키는지 설명했습니다. 9B 모델로서 이는 매우 인상적입니다. 보통 이 정도 크기의 모델들은 100k를 넘어서면 "표류 (drifting)"하거나 시스템 프롬프트 (system prompt)의 제약 조건을 놓치기 시작합니다. Qwythos는 중심을 잘 잡았습니다.

어려움을 겪는 부분 (트레이드오프)

이것은 마법이 아닙니다. 주의 깊게 살펴봐야 할 두 가지 사항이 있습니다:

1. KV Cache 압박 (KV Cache Pressure): 만약 실제로 1M 제한에 가깝게 밀어붙인다면, VRAM 요구 사항이 급격히 치솟습니다. GGUF를 사용하더라도 컨텍스트를 위한 메모리 오버헤드가 모델 가중치(model weights)보다 주요 병목 현상(bottleneck)이 됩니다. 캐시를 최적화하지 않는다면, 모델이 실패하기 훨씬 전에 한계에 부딪힐 것입니다.
2. 대규모 환경에서의 프롬프트 준수 (Prompt Adherence at Scale): 정보 검색(retrieval)은 날카롭지만, 컨텍스트가 최대치에 도달했을 때 출력의 _형식(formatting)_이 가끔 저하되었습니다.