GLM 5.2 Q1_S 对比 Qwen 27B Q8

TL;DR；GLM-5.2 Q1_S 击败了 Qwen 3.6 27B Q8，两者均在 KV Q8 下运行。免责声明：这是一个业余爱好者的比较，样本量 n=1，请轻喷。我只是觉得分享出来会很有趣。 背景与任务 前段时间有不少讨论：大模型的低量化版本和小模型的高量化版本，哪个更好？我们做过一些基准测试和内部测试，结果基本一致——大模型的低量化版本更好。而现在我经常看到有人声称低于 Q3 的量化都是“脑残”，不管模型实际大小。我还注意到一些评论贬低那些分享如何在消费级硬件上运行大模型的人，仅仅因为那是低量化版本。所以，我做了一个小测试。 备受喜爱的 Qwen 27B Q8 对阵“脑残”的 GLM 5.2 Q1_S。Q1_S 是我能找到的最小量化，但反正我也跑不动 Q2。我的硬件是 2 块 RTX 3090，每块 24GB 显存（限制功耗 200W），以及 192GB DDR5 内存。Qwen 生成速度约 60 tps，GLM 在低上下文时约 6 tps，接近 10 万上下文时降至 3 tps。 我选择了一个简单的技术栈和清晰的指令，以尽可能减少因指令歧义导致的差异。两个模型都在 pi 测试框架下运行，使用完全相同的配置和提示词。指令是用 Three.js 构建一个简单的 3D 游戏（HTML/CSS/JS）；完整内容附在文末。这是第二次尝试这个测试。第一次没有记录，使用了不同的技术栈，但结果几乎相同。 Qwen 3.6 27B 速度确实快——只需几分钟，大约 2 万 token。但它未能构建出可用的产品。在指示它修复后，它“工作”了，但仍然不可玩；还需要另外两次提示才使其“完成”。所以总计：1 次初始 + 3 次后续，总共约 4.2 万 token。 https://i.redd.it/xz4zwgclk6ah1.gif GLM 5.2 Q1_S 真慢。花了几个小时和 7.5 万 token，但看到它展示思考过程真的很令人印象深刻，它确实思考了很多。它在思考过程中就规划并重新评估所有假设以及已经设计的代码，通过多次迭代改进。过去两个月我一直在用 Qwen 作为本地日常驱动，但 GLM 的思考痕迹完全不同，更令人印象深刻。它一次就构建成功，100% 正确，产品有真正的‘高级’感。它也是唯一一个成功为游戏添加声音的模型，即使是完整版 GLM 和 Opus 在后续尝试中也忽略了声音。 https://i.redd.it/8tcd6q2mk6ah1.gif GLM 5.2 全精度版和 Opus 为了好玩，我也将相同的指令传给了另外两个模型：Opus 和通过 OpenRouter 使用全精度的 GLM，同样在 pi 框架下。两者都令人印象深刻，但在视觉上只是比本地尝试好一点点，甚至可能没有。尤其是全精度 GLM 让我失望，它把控制键方向弄反了，使得游戏非常难玩——而 Q1_S 版本却是正确的。但是——全精度 GLM 只用了 1.1 万 token 就完成了，包括系统提示。我不知道这是因为 API 提供商对思考 token 的默认限制，还是因为高量化导致模型过度思考，但 Q1 确实在全精度面前表现良好。 https://i.redd.it/fta2d8ymk6ah1.gif 唯一感觉真正更好的尝试是 Opus 4.8，但用的是 Claude Code 而非 pi。这些我就不提供更多细节了，因为它们超出了本文的要点。 LLM 作为评判者：代码质量 我将所有输出提交给 Opus 4.8 和 GPT 5.5，让它们评估代码质量和指令遵循程度；结果如下。 Opus 评分： Qwen — 代码质量: 7.5 | 指令遵循: 9.0 | 扩展/打磨: 8.5 | 总体: 8.3 GLM Q1_S — 代码质量: 9.0 | 指令遵循: 9.0 | 扩展/打磨: 10.0 | 总体: 9.3 GLM FP — 代码质量: 8.0 | 指令遵循: 8.5 | 扩展/打磨: 8.5 | 总体: 8.3 GPT 5.5 评分： Qwen — 代码质量: 6.4 | 指令遵循: 7.0 | 扩展/打磨: 7.0 | 总体: 6.7 GLM Q1_S — 代码质量: 8.5 | 指令遵循: 8.0 | 扩展/打磨: 8.5 | 总体: 8.4 GLM FP — 代码质量: 7.2 | 指令遵循: 6.3 | 扩展/打磨: 7.8 | 总体: 7.1 两者都同意 Q1_S 做得最好。几乎可以肯定这要归功于大量的思考，但即便如此，也证明了 Q1 毕竟是一种有能力的量化。你只需要找到合适的用例，因为我不建议将其用作实时代理后端。 完整指令提示： 构建一个 3D 竞技场游戏，作为一个独立的 .html 文件。 技术栈（必选）： - Three.js 从 CDN 加载（一个 <script> 标签）。无其他 JS 库，无需构建步骤。 - 所有 HTML、CSS 和 JS 都在这个文件中。必须能直接在浏览器中打开运行。 核心规格（必选——精确实现所有内容）： 1. 一个平坦的地面形成一个有边界的竞技场。玩家不能离开边界。 2. 地面上的玩家对象。WASD 移动（相对于摄像机）；移动有动量，不是立即停止/启动。 3. 第三人称摄像机，平滑跟随玩家后方。 4. 可收集的发光球体在随机位置生成。触碰一个收集它（+10 分）并生成一个新球体。 5. 敌人在竞技场边缘生成并向玩家移动。接触玩家损失 1 条生命。 6. 玩家起始有 3 条命。HUD 始终显示分数和生命值。 7. 生命值为 0 时：显示最终分数的游戏结束画面，按任意键重新开始。 8. 难度随时间增加（敌人生成更快和/或移动更快）。 扩展（强烈鼓励——将以此评判）： 在核心功能之上，让它感觉高级。光照、阴影、粒子、效果、流畅摄像机、令人满意的反馈、精致的 HUD、氛围。如果可以改善体验，增加深度或复杂度。目标是真正令人印象深刻——评估标准是视觉质量和感觉，而不仅仅是正确性。 规则： - 在添加扩展功能之前先实现完整核心。 - 输出完整的、可直接运行的 .html 文件。