로컬 모델을 테스트할 때, 오픈 웨이트 (open-weights) 모델을 일상적인 도구와 함께 사용하여 답변을 평가해 보는 건 어떨까요! 😆

대형 모델이 중요한지, 정밀도가 더 높은 소형 모델이 중요한지, 그리고 여기서 어떤 트레이드오프 (tradeoffs)가 있는지에 대한 질문에 답하고 싶습니다.

태스크는 새로운 리포지토리(repo)에서 개념이 어떻게 작동하는지 이해하는 것에 관한 것이며, 이 경우에는 아주 당연한 샌드박스 대안인 rivet_dev의 agentOS를 대상으로 합니다.

모델: ollama v0.31을 통해 로컬 서빙
프롬프트 (Prompt): agentOS에서 바인딩 (binding)은 어떻게 작동하나요? 코드 예시도 보여주세요.
하네스 (Harness): Pi
평가 모델 (Rating Model): DevinAI를 통한 GLM 5.2

머신: M5 Max 128GB

qwen3.5 122B Q4_K_M:

M5 Max 128GB에서 추론 과정 (reasoning process)이 몇 초 만에 나타나며 37.3초 소요됩니다. 추론 모델 (reasoning model)로서 지금 바로 사용 가능한 수준입니다.
29.2 t/s
81GB
설명, 클라이언트/서버 코드 예시, CLI, 응답 형식, 기능 및 MCP와의 비교를 포함하며, 모든 좋은 부분을 갖추고 있고 읽기 쉬우며 통합 작업을 직접적으로 안내합니다.
평점: 4.5/5

qwen3.6:35b-a3b-coding-mxfp8:

65.3s
42.45 t/s
38GB
품질이 그리 좋지 않습니다. TypeScript 예시를 Python으로 변환하며, 몇 가지 중요한 개념을 틀리게 설명합니다.
평점: 2/5

gemma4:31b-mlx:

10분 이상 소요, Pi가 이를 올바르게 표시하는 데 문제가 있습니다.
9.3 t/s
19GB
품질은 사실 나쁘지 않습니다. 적어도 잘못된 방향으로 안내하지는 않으며, 모든 내용이 실제 코드에 기반하고 있습니다. 하지만 바인딩 (binding)의 기술적 세부 사항 하나를 틀렸습니다. 하지만 보시다시피 너무 느려서 사용할 수 없습니다.
평점: 2/5

gemma4:31b-mxfp8:

5분에 가깝게 소요, Pi가 이를 올바르게 표시하는 데 문제가 있습니다.
10.18 t/s
33GB
탄탄한 품질이며 매우 유용합니다. qwen3.5:122B와 비교했을 때 CLI와 같은 일부 섹션을 놓쳤지만, 제가 그것을 다루라고 요청하지 않았기 때문에 불만은 없습니다. 매우 유용하지만, 소요 시간을 고려하면 사용할 수 없습니다 😂. MXFP8이 (NVFP4를 사용하는) gemma4:31b-mlx보다 거의 두 배 크다는 점을 고려하면, 품질 향상은 이해할 만합니다.

평점: 4/5

qwen3.6:35b-a3b-mlx-bf16:

69초
31.52 t/s
70GB
기본적으로 모든 것을 틀립니다. 우리가 agentOS 리포지토리(repo) 안에 있음에도 불구하고, 바인딩(binding)이 LLM의 기능이라고 믿고 있습니다.
평점: 1/5

gemma4:31b-mlx-bf16:

9.15분
2.23 t/s
63GB
테스트한 모든 모델 중 가장 짧습니다. 읽기는 쉽지만, 개념의 대부분을 잘못 파악하고 있습니다. 제 생각에 이 모델은 "어떻게 작동하는가"라는 제 지침을 실제로 따르려고 노력했던 것 같습니다. 그래서 흐름을 파악하기 위해 코드를 더 깊이 파고들었지만, 안타깝게도 도중에 길을 잃었습니다.
평점: 2.5/5

nemotron-3-super:Q4_K_M:

104초
19.1 t/s
86GB
120B 모델입니다. 모든 출력물 중 가장 길고 포괄적입니다. 기본적으로 agentOS에서 바인딩이 무엇인지 이해하고 있지만, 잘못된 함수/변수 이름과 같은 몇 가지 오류가 있습니다. 개인적으로 GLM 5.2가 이 모델에 대해 너무 엄격했다고 생각합니다.
평점: 3.5/5

GLM 5.2는 qwen3.6을 열정적으로 싫어합니다 😂:
qwen3.6 MXFP8과 비교하면, 이것은 완전히 다른 차원입니다. 실제 리포지토리 문서와 예제에 기반을 두고 있으며, 메커니즘을 정확히 파악하고 코드가 실제와 일치합니다. 감점 요인은 정확성이 아니라 뉘앙스와 완결성 때문입니다. 4.5점입니다. 두 가지 Qwen 3.6 변체(variants)는 이제 최하단을 장식합니다. 같은 계열이지만, 둘 다 근거를 찾지 못했다는 점에서는 같으나 방식은 정반대입니다. 하나는 자신 있게 틀렸고, 하나는 솔직하게 비어 있습니다. 둘 다 리포지토리를 읽지 않았습니다.

결론:
저는 거대 모델이 중요한지, 더 높은 정밀도를 가진 소형 모델이 중요한지, 그리고 여기서의 트레이드오프(tradeoffs)는 무엇인지에 대한 질문에 답하고 싶습니다:

더 큰 것이 더 좋습니다.

qwen3.5:122B는 4.5/5점을 기록하며 테스트된 모든 31–35B 모델을 이겼습니다. 81GB라는 용량을 고려할 때 이 모델은 분명 압축/양자화(quantized)된 버전으로 실행되고 있지만 말입니다 (fp16 122B 모델은 200GB를 훨씬 넘을 것입니다). 따라서 얻을 수 있는 교훈은 단순히 "거대 모델이 승리한다"가 아니라, 규모(scale)가 사람들이 생각하는 것보다 더 많은 양자화 손실(quantization loss)을 흡수할 수 있다는 것입니다. 심하게 양자화된 122B 모델이 여전히 풀 정밀도(full-precision) 35B 모델(qwen3.6:35b-mlx-bf16, 1/5)과 약하게 양자화된 35B 모델(qwen3.6:35b-coding-mxfp8, 2/5)을 모두 이겼습니다.

nemotron-3-super의 경우도 마찬가지입니다. GLM 5.2로부터 낮은 평가를 받았음에도 불구하고, 개인적으로는 최소 4점은 되어야 한다고 생각합니다. 모델이 범한 오류들은 변수/함수 이름과 같은 사소한 오류들이었을 뿐, 근본적으로 무언가가 틀린 것은 아니었으며 개념을 깊이 있게 이해하고 있었습니다.

bf16 !== 더 나음.

가장 깔끔한 테스트는 동일한 모델의 세 가지 포맷에 대한 gemma4:31b 테스트입니다:

양자화 크기 (Quant Size)	평점 (Rating)	속도 (Speed)
mlx (NVFP4) 19GB	2/5	9.3 t/s
mxfp8 33GB	4/5	10.18 t/s
mlx-bf16 (full precision) 63GB	2.5/5	2.23 t/s

"손실이 가장 적은" 옵션인 Full bf16은 최상위가 아닌 중간에 머물렀습니다. mxfp8이 품질 면에서 이를 앞섰으며 토큰당 속도는 약 5배 더 빨랐습니다. 동일한 패턴이 Qwen 3.6 쌍에서도 나타납니다. mxfp8 (2/5)이 여전히 bf16 (1/5)을 근소하게 앞섰습니다. 두 번 모두 이런 결과가 나왔다는 것은 이것이 단순한 노이즈가 아님을 시사합니다. mxfp8은 이 하드웨어/백엔드에서 진정으로 잘 튜닝된 양자화 포맷(quantization format)으로 보이며, 반면 MLX에서의 bf16은 느릴 뿐만 아니라 더 나은 답변을 안정적으로 제공하지도 못합니다. 하지만 이는 여러 요인에 크게 좌우되며, 주의해서 받아들여야 합니다.

최신 !== 더 나음.

Qwen 3.6 35B 변체들은 Qwen 3.5보다 최신 세대임에도 불구하고 서로 다른 방식으로 작업에 실패했습니다 (하나는 환각(hallucination)을 일으켰고, 하나는 모호함을 유지했습니다). 이는 3.6 버전의 이 특정 리포지토리 기반 작업(repo-grounding task)에서 무언가 퇴보했음을 시사합니다. 이는 "최신"이나 "동일 제품군"이 단조로운 개선을 보장하지 않는다는 점을 상기시켜 주며, 크기/양자화 비교는 세대 간 비교가 아닌 동일 제품군 내에서 이루어져야 함을 보여줍니다.

로컬 모델을 선택하려는 사람을 위한 결론:
작은 모델의 정밀도(precision)를 높이는 것보다 더 큰 모델을 사용하는 것이 품질을 높이는 데 있어 더 신뢰할 수 있는 지렛대입니다. 용량이 제한되어 있다면, 데이터는 "작은 규모의 전체 정밀도(full precision)"보다 "더 큰 규모의 적절한 양자화(moderate quantization)"를 지지합니다. 122B의 압축된 형태가 31B의 비압축 형태를 모든 측면에서 이겼기 때문입니다. 또한 고정된 크기 클래스 내에서는 정밀도의 최적 지점(sweet spot, mxfp8)이 존재하는 것으로 보이며, 여기서 정밀도를 더 높이는 것(bf16)은 얻는 것은 없고 비용만 많이 들게 합니다.

주의해야 할 점 한 가지: 이것은 하나의 저장소(repo)에서 하나의 모델(GLM 5.2)에 의해 판단된 단일 프롬프트 결과입니다. 실제 유의미한 신호(signal)이기는 하지만, "양자화 형식 (quantization format)"과 "모델 제품군/세대별 특성 (family/generation quirks)" (예: 정밀도와 상관없이 전반적으로 성능이 낮은 Qwen 3.6 라인업)을 완전히 분리해내기에는 실행 횟수가 충분하지 않습니다.
/u/albertgao 에 의해 r/LocalLLaMA 에 제출됨
[link] [comments]