GLM 5.2 Q1_S vs Qwen 27B Q8 비교

요약(TL;DR): GLM-5.2 Q1_S가 Qwen 3.6 27B Q8을 이겼습니다. 두 모델 모두 KV Q8로 실행되었습니다.

면책 조항: 이것은 n=1인 취미/아마추어 비교이므로 가볍게 봐주시기 바랍니다. 그냥 공유하는 것이 재미있을 것 같다고 생각했습니다.

배경 및 작업 내용
얼마 전, 더 큰 모델의 낮은 양자화(Quantization)가 나은지, 아니면 더 작은 모델의 높은 양자화가 나은지에 대한 많은 논의가 있었습니다. 우리는 꽤 많은 벤치마크와 자체 테스트를 진행했으며, 대부분 일관된 결과—즉, 낮은 양자화의 더 큰 모델이 더 낫다는 결과—를 얻었습니다.

요즘 저는 실제 크기에 상관없이 Q3보다 낮은 모든 것을 '지능이 없다(braindead)'라고 주장하는 것을 자주 봅니다. 또한, 단지 낮은 양자화를 사용했다는 이유로 소비자급 하드웨어에서 거대한 모델을 실행하는 방법을 공유하는 사람들을 비하하는 댓글들도 보았습니다.

그래서 작은 테스트를 해보았습니다. 사랑받는 Qwen 27B Q8 대 '지능이 없다'는 GLM 5.2 Q1_S입니다. Q1_S는 제가 찾을 수 있는 가장 작은 양자화였지만, 어차피 저는 Q2도 실행할 수 없을 것입니다.

제 하드웨어는 2 x RTX 3090(각 24GB VRAM, 200W 전력 제한)과 192GB DDR5 RAM입니다. Qwen은 약 60 tps(초당 토큰 수)로 생성하고, GLM은 낮은 컨텍스트(Context)에서는 약 6 tps, 100k 컨텍스트에 가까워지면 3 tps로 실행됩니다.

지시문의 모호함으로 인한 변수를 최소화하기 위해 간단한 기술 스택과 명확한 지침을 선택했습니다.

두 모델 모두 동일한 설정과 프롬프트로 pi harness 하에서 실행되었습니다. 지침은 Three.js(HTML/CSS/JS)를 사용하여 간단한 3D 게임을 만드는 것이었습니다. 전체 내용은 끝에 첨부되어 있습니다.

이 테스트는 두 번째 시도입니다. 첫 번째 시도는 문서화되지 않았고 다른 기술 스택을 사용했지만, 결과는 사실상 동일했습니다.

Qwen 3.6 27B
확실히 빨랐습니다. 단 몇 분 만에 약 20k 토큰을 소모했습니다. 하지만 작동하는 제품을 만드는 데 실패했습니다. 수정하라고 지시한 후에는 '작동'은 했지만 여전히 플레이할 수 없는 상태였습니다. '완성'시키기 위해서는 추가로 2번의 프롬프트가 더 필요했습니다. 따라서 총합은 초기 1회 + 후속 3회, 총 약 42k 토큰이었습니다.
https://i.redd.it/xz4zwgclk6ah1.gif

GLM 5.2 Q1_S
세상에, 정말 느렸습니다.

몇 시간이 걸리고 75k 토큰을 소모했지만, 모델이 사고 과정 (thought process)을 펼쳐 보이는 모습은 정말 인상적이었으며, 실제로 아주 많은 생각을 했습니다. 이미 설계된 코드뿐만 아니라 모든 가정을 계획하고 재평가하며, 사고 과정 내의 수많은 반복 (iterations)을 통해 이를 개선했습니다. 지난 두 달 동안 Qwen을 일상적인 로컬 드라이버로 사용해 왔지만, GLM의 사고 흔적 (thinking traces)은 매우 다르고 훨씬 더 인상적입니다.

이 모델은 단 한 번의 시도 (one shot) 만에 100% 정확하게, 그리고 제품으로서 제대로 된 '프리미엄' 느낌을 주며 구축해 냈습니다. 또한, 이후의 시도에서 GLM 풀 버전과 Opus조차 생략했던 게임 사운드를 추가하는 데 성공한 유일한 모델이기도 합니다.
https://i.redd.it/8tcd6q2mk6ah1.gif
GLM 5.2 full precision 및 Opus

재미 삼아 동일한 지침을 동일한 pi harness 환경에서 OpenRouter를 통해 Opus와 full precision 버전의 GLM, 이렇게 다른 두 모델에도 전달해 보았습니다. 두 모델 모두 인상적이었지만, 시각적으로는 로컬 시도들보다 아주 약간 더 나은 수준이거나 거의 차이가 없었습니다. 특히 full precision 버전의 GLM은 제어 키의 방향을 반대로 설정하여 플레이하기 매우 어렵게 만들었기에 실망스러웠습니다. Q1_S 버전은 이를 정확하게 수행했음에도 말이죠. 하지만 — FP 버전의 GLM 5.2는 시스템 프롬프트를 포함하여 단 11k 토큰 만에 작업을 완료했습니다. 이것이 API 제공업체의 사고 토큰 (thinking tokens)에 대한 기본 제한인지, 아니면 높은 양자화 (quantization)로 인해 모델이 과도하게 생각하게 된 것인지는 모르겠으나, Q1 버전이 FP 버전에 맞서 매우 잘 버텨냈습니다.

GLM full precision 출력 결과:
https://i.redd.it/fta2d8ymk6ah1.gif

진정으로 더 낫다고 느껴진 유일한 다른 시도는 pi 대신 Claude Code를 사용한 Opus 4.8이었습니다. 이들에 대해서는 이번 게시물의 범위를 벗어나므로 더 자세한 내용은 제공하지 않겠습니다.

LLM as a judge: 코드 품질 (Code Quality)
모든 출력물을 Opus 4.8과 GPT 5.5에 전달하여 코드 품질과 지침 준수 (instruction following) 여부를 평가하게 했으며, 결과는 다음과 같습니다.

두 모델 모두 Q1_S가 가장 뛰어난 작업을 수행했다는 점에 동의합니다. 이는 거의 확실히 많은 사고(thinking) 과정 덕분일 것이나, 그럼에도 불구하고 Q1이 결국 유능한 양자화(quant) 모델임을 증명합니다. 다만 실시간 에이전트 백엔드(real-time agentic backend)로 사용하는 것은 권장하지 않으므로, 적절한 사용 사례를 찾기만 하면 됩니다.

전체 지침 프롬프트 (Full instruction prompt):
단일 독립형 .html 파일로 3D 아레나 게임을 제작하세요. 스택 (STACK, 필수): - CDN에서 로드된 Three.js (하나의 <script> 태그). 다른 JS 라이브러리나 빌드 단계 금지. - 모든 HTML, CSS, JS는 이 하나의 파일에 포함되어야 함. 브라우저에서 직접 열었을 때 실행되어야 함. 핵심 사양 (CORE SPEC, 필수 — 다음 사항을 정확히 구현할 것): 1. 경계가 있는 아레나를 형성하는 평평한 지면(ground plane). 플레이어는 경계를 벗어날 수 없음. 2. 지면 위의 플레이어 객체. WASD로 이동 (카메라 상대적); 이동 시 즉각적인 정지/시작이 아닌 관성(momentum)이 적용됨. 3. 플레이어 뒤를 부드럽게 따라가는 3인칭 카메라. 4. 수집 가능한 빛나는 구체(orbs)가 무작위 위치에 생성됨. 구체를 터치하면 수집되며 (+10 점), 새로운 구체가 생성됨. 5. 적 객체는 아레나 가장자리에서 생성되어 플레이어를 향해 이동함. 플레이어와 접촉 시 생명력 1 감소. 6. 플레이어는 3개의 생명력으로 시작함. HUD는 항상 점수와 생명력을 표시함. 7. 생명력이 0이 되면: 최종 점수를 보여주는 게임 오버 화면이 나타나며, 키를 누르면 재시작됨. 8. 시간이 지남에 따라 난이도가 상승함 (적이 더 빨리 생성되거나 더 빨리 이동함).

STRETCH (강력 권장 — 이 부분이 평가 대상입니다): 핵심 기능(Core)을 넘어, 프리미엄(PREMIUM) 느낌이 나도록 만드세요. 조명(Lighting), 그림자(Shadows), 파티클(Particles), 주스(Juice, 게임의 생동감), 부드러운 카메라(Smooth camera), 만족스러운 피드백(Satisfying feedback), 다듬어진 HUD(Polished HUD), 분위기(Atmosphere) 등을 구현하세요. 경험을 개선할 수 있다면 깊이나 복잡성을 추가하세요. 단순히 정확성을 넘어, 진심으로 감동을 주는 것을 목표로 하세요 — 이 부분은 시각적 품질과 느낌(Feel)을 기준으로 평가됩니다. 규칙: - 확장 기능(Stretch features)을 추가하기 전에 전체 핵심 기능(Full core)을 먼저 구현하세요. - 즉시 실행 가능한 완전한 .html 파일을 출력하세요.
제출자: /u/SnooPaintings8639 / 커뮤니티: r/LocalLLaMA
[link] [comments]

GLM 5.2 Q1_S vs Qwen 27B Q8 비교

요약

핵심 포인트

댓글