GLM 5.2 Q1_S vs Qwen 27B Q8 성능 비교

GLM 5.2 Q1_S

Damn, it was slow. It took a couple of hours and 75k tokens, but it was really impressive to see it lay out its thought process, and it did think A LOT. Planning and reassessing all its assumptions as well as the already-designed code, improving it over many iterations in the thinking process alone. I've been using Qwen as my daily local driver for the last two months, but the GLM thinking traces are something very different and much more impressive.

It built it in one shot, 100% correct, with a proper 'premium' feel to the product. It's also the only one that managed to add sound to the game, which was omitted even by full GLM and Opus in later attempts.

GLM 5.2 full precision and Opus

Just for fun, I also passed the same instruction to two other models: Opus, and GLM in full precision via OpenRouter, under the same pi harness. Both were impressive, but only a tiny bit better than the local attempts visually, if at all. Especially GLM in full precision disappointed me, as it inverted the direction of the control keys, which makes it really hard to play — even though the Q1_S version got it right. BUT — GLM 5.2 in FP did it in 11k tokens only, including system prompts. I don't know if this is the API provider's default restriction on thinking tokens, or if the high quantization made the model overthink a lot, but the Q1 really held up well against the FP.

The GLM full precision output:

The only other attempt that felt genuinely better was Opus 4.8, but under Claude Code instead of pi. I won't provide more details on these, as they're beyond the point of this post.

LLM as a judge: Code Quality

I passed all the outputs to Opus 4.8 and GPT 5.5 for them to rate code quality and instruction following; the results are as follows.

Opus rating:

Qwen — Code Quality: 7.5 | Instruction Following: 9.0 | Stretch/Polish: 8.5 | Overall: 8.3
GLM Q1_S — Code Quality: 9.0 | Instruction Following: 9.0 | Stretch/Polish: 10.0 | Overall: 9.3
GLM FP — Code Quality: 8.0 | Instruction Following: 8.5 | Stretch/Polish: 8.5 | Overall: 8.3

GPT 5.5 rating:

Qwen — Code Quality: 6.4 | Instruction Following: 7.0 | Stretch/Polish: 7.0 | Overall: 6.7
GLM Q1_S — Code Quality: 8.5 | Instruction Following: 8.0 | Stretch/Polish: 8.5 | Overall: 8.4
GLM FP — Code Quality: 7.2 | Instruction Following: 6.3 | Stretch/Polish: 7.8 | Overall: 7.1

Both agree that Q1_S did the best job. It is nearly sure that's thanks to the thinking a lot, but nonetheless, prove that Q1 is a capable quant after all. You just need to find the proper use cases for it, as I wouldn't suggest using it as real-time agentic backend.

Full instruction prompt:

Build a 3D arena game as a SINGLE self-contained .html file.

STACK (mandatory):
- Three.js loaded from a CDN (one <script> tag). No other JS libraries,
  no build step.
- All HTML, CSS, and JS in this one file. It must run by opening it
  directly in a browser.

CORE SPEC (mandatory — implement all of this exactly):
1. A flat ground plane forming a bounded arena. The player cannot leave
   its bounds.
2. A player object on the ground. WASD moves it (camera-relative);
   movement has momentum, not instant stop/start.
3. A third-person camera that smoothly follows behind the player.
4. Collectible glowing orbs spawn at random positions. Touching one
   collects it (+10 score) and spawns a new one.
5. Enemy objects spawn at the arena edges and move toward the player.
   Contact with the player costs 1 life.
6. Player starts with 3 lives. A HUD shows score and lives at all times.
7. At 0 lives: a game-over screen showing final score, with a key press
   to restart.
8. Difficulty ramps over time (enemies spawn faster and/or move faster).

STRETCH (strongly encouraged — you will be judged on this):
Beyond the core, make it feel PREMIUM. Lighting, shadows, particles,
juice, smooth camera, satisfying feedback, polished HUD, atmosphere.
Add depth or complexity if it improves the experience. Aim to genuinely
impress — this is evaluated on visual quality and feel, not just
correctness.

RULES:
- Implement the full core before adding stretch features.
- Output the complete, ready-to-run .html file.