나는 Qwen2.5-Coder-7B를 Q8과 Q4 양자화(Quantization) 버전으로 동일한 다단계 에이전트(Agent) 테스트에 실행했습니다. 모든 단계에서 통과율은 동일했습니다. 하지만 가장 어려운 단계에서 두 모델은 완전히 다른 방식으로 실패했으며, 그 차이가 점수보다 더 많은 것을 말해줍니다.

만약 에이전트용으로 로컬 모델을 실행한다면, 여러분은 수백 번도 더 이런 고민을 했을 것입니다: 큰 용량의 Q8을 유지할 것인가, 아니면 VRAM을 아끼고 속도를 높이기 위해 Q4로 낮출 것인가?
일반적인 결정 방식은 벤치마크(Benchmark) 점수입니다. 둘 다 실행해 보고, 숫자를 비교한 뒤, 점수가 더 높은 것을 선택합니다. 만약 점수가 같다면, 어깨를 으쓱하며 더 작은 모델을 선택하죠.
이번 주에 나는 Qwen2.5-Coder-7B로 정확히 그렇게 했습니다. 그리고 점수는 나에게 거의 아무것도 알려주지 않았습니다. 하지만 실패 방식은 모든 것을 알려주었습니다.

동일한 모델, 두 가지 양자화(Quant): q8_0 (7.6 GB) 및 q4_k_m (4.6 GB). 동일한 기기 (16 GB Apple Silicon). 동일한 작업. 나는 단순한 채팅 프롬프트(Chat prompt)를 테스트한 것이 아닙니다. 도구 호출, 결과 읽기, 다음 단계 결정, 반복 등 함정과 실패 요소가 포함된 실제 에이전트 루프(Agent loop)를 통해 각 작업을 실행했습니다. 각 작업은 여러 번 실행되며, 모든 실행을 통과해야만 통과로 간주됩니다.

결과는 다음과 같았습니다.

점수만 놓고 보면 이 둘은 쌍둥이와 같습니다. Easy와 Medium 단계는 둘 다 깔끔합니다. Hard 단계에서는 둘 다 무너졌으며, 4개 작업 중 1개만 통과했습니다. 만약 숫자에서 멈췄다면, 여러분은 "실질적인 차이가 없으니, 더 작고 두 배 더 빠른 Q4를 선택하자"라고 말했을 것입니다.

[

]

하지만 그런 결론은 틀렸습니다. 그 이유는 다음과 같습니다.

동일한 점수, 두 가지 다른 실패 방식

Hard 단계에서 두 양자화(Quant) 모델은 정반대의 방식으로 고장 났습니다.

Q8의 주요 실패 원인은 금지된 호출(forbidden call)이었습니다. 어려운 작업 중 하나는 함정을 설치합니다. 모델이 결정 경계(decision boundary)에서 사용하지 말라고 명시적으로 지시받은 도구가 있는 식입니다. 예를 들어 "기록 삭제"나 "운영 환경(prod) 배포"처럼, 모델이 직접 수행하는 것이 아니라 게이트키핑(gate)을 해야 하는 동작을 생각해보세요. Q8은 문제에 정면으로 다가갔고, 결단력 있게 행동했으며… 건드려서는 안 될 대상의 방아쇠를 당겨버렸습니다. 그 순간 실행은 실패했습니다.

Q4의 주요 실패 원인은 루프 제한(loop cap)이었습니다. 동일한 종류의 작업이었지만, Q4는 함정에 빠질 만큼 멀리 나아가지 못했습니다. 모델은 같은 호출을 반복하며 작업을 해결하지 못한 채, 할당된 단계(steps)를 모두 소진할 때까지 제자리에서 맴돌며 갇혀버렸습니다. 잘못된 행동을 한 것이 아니라, 아무것도 할 수 없었던 것입니다.

이 두 가지를 나란히 비교해 보십시오:

Q8 — 유능하지만 무모합니다. 계획을 세우고 실행할 수 있습니다. 다만 가드레일(guardrail)을 무시하고 지나쳤을 뿐입니다.
Q4 — 계획을 유지하지 못합니다. 제자리에서 루프를 돌며 아무런 진전도 이루지 못했습니다.

이것은 점수가 약간 낮은 동일한 모델이 아닙니다. 이것은 완전히 다른 종류의 모델입니다.

실패 방식(failure mode)이 수치보다 중요한 이유

루프(looping)는 결정적인 신호입니다. 모델이 행동을 반복하면서 전혀 앞으로 나아가지 못한다면, 이는 대개 다단계 계획(multi-step plan)의 맥락을 놓쳤기 때문입니다. 즉, 자신이 무엇을 했고 무엇이 남았는지 추적하지 못하는 것입니다. 그리고 이러한 계획/상태 추적(state-tracking) 능력은 길고 어려운 작업에서 저비트 양자화(lower-bit quantization)가 가장 먼저 깎아먹는 부분입니다.

따라서 Q8에서 Q4로 낮춘 것은 단순히 점수를 몇 점 깎은 것이 아닙니다(두 모델 모두 4점 만점에 1점에 그쳤습니다). 그것은 모델이 실패하는 방식 자체를 바꾸어 놓았습니다. "행동은 하지만 가드레일을 위반함"에서 "전혀 진전을 보이지 못함"으로 말입니다. 전자는 더 나은 프롬프팅(prompting)이나 더 엄격한 도구 권한 설정을 통해 해결할 수 있는 규율(discipline)의 문제일 수 있습니다. 하지만 후자는 프롬프팅만으로는 거의 해결할 수 없는 능력(capability)의 문제입니다.

만약 통과율(pass rate)만 보았다면, 당신은 결코 이를 발견하지 못했을 것입니다. 1/4로 동률을 기록한 두 모델은 리더보드 상에서 동일해 보입니다. 하지만 실제 운영 환경(production)에서 이들은 사용자에게 완전히 다른 두 가지 방식으로 실패할 것이며, 당신은 이들을 완전히 다른 방식으로 디버깅해야 할 것입니다.

**솔직한 주의사항 (The honest caveats)

저는 이 내용을 과장해서 말하지 않겠습니다. 왜냐하면 이 모든 과정의 핵심은 정직하게 측정하는 것이기 때문입니다:

• 두 양자화(Quant) 모델 모두 여기서 실제 코딩 에이전트(Coding Agent)로 사용하기에는 "준비"되지 않았습니다. 두 모델 모두 베이스라인 단계에서 컨텍스트 절벽(Context-cliff) 테스트를 통과하지 못했습니다. 이는 컨텍스트 길이(Context-length)의 제한이 아니라, 도구 호출(Tool-call)의 실패였습니다. 핵심은 "Q8이 프로덕션 환경에 적합하다"가 아니라, Hard 난이도에서의 실패 방식(Failure-mode) 차이입니다.
• 이것은 하나의 모델을 하나의 머신에서 테스트한 결과입니다. 16GB 환경에서의 Qwen2.5-Coder-7B 결과입니다. 당신의 모델, 당신의 하드웨어, 당신의 작업에 따라 결과는 달라질 수 있습니다. 이것이 바로 타인의 결과를 신뢰하는 대신 자신만의 조합을 테스트해야 하는 이유입니다.
• Hard 난이도의 샘플 수가 적습니다 (4개 작업). 이 차이는 강력한 신호(Signal)이지, 통계적 증명은 아닙니다.

결론 (The takeaway)

점수만 확인한다면 "어떤 양자화 모델을 사용해야 하는가"는 잘못된 질문입니다. 두 양자화 모델은 점수가 같더라도 내부적으로는 여전히 다른 모델일 수 있습니다. 숫자는 모델이 실패했는지 여부를 알려줍니다. 하지만 실패 방식(Failure mode)은 실제로 무엇이 고장 났는지를 알려주며, 그것이 바로 제품을 출시하기 전에 당신이 알아야 할 사항입니다.

저는 바로 이 점을 테스트하기 위해 제가 개발 중인 오픈 소스 도구인 QuantaMind를 사용하여 이를 측정했습니다. QuantaMind는 로컬 모델을 실제 에이전트 루프(Agent loop)에서, 당신의 하드웨어로 실행하며, 실패 원인을 점수 뒤에 숨기지 않고 유형별로 분석해 줍니다. 이 도구는 무료이며 완전히 오프라인으로 작동합니다.