Gemma 4 31B vs Qwen 3.6 27B，生成耗时差四倍

33946 tokens 对 6209 tokens，生成时间却是 18 分 04 秒对 3 分 51 秒。在本地算力环境下，参数量与推理速度从来不是线性关系，输出逻辑的紧凑度直接决定工程可用性。

• 吞吐量高不等于交付快， 18 分钟 的冗余输出拖慢整体工作流
• Gemma 4 31B 用 3 分 51 秒 完成游戏状态机与碰撞检测逻辑，代码结构更清晰
• 本地部署应优先评估单次请求的 Token 经济性，而非单纯追求峰值 tokens/sec

从工程落地角度看，这次对比暴露出开源模型在 Code 生成任务上的典型分化。Qwen 3.6 27B 跑出了 32 tokens/sec 的峰值吞吐，但生成了 33946 个 token。大量篇幅消耗在视觉样式的描述与冗余逻辑上，导致整体推理链路拉长。对于需要快速迭代的前端原型开发，这种 verbose 策略反而增加了人工审查成本。Gemma 4 31B 虽然峰值吞吐降至 27 tokens/sec，但总输出严格控制在 6209 tokens。它在 3 分 51 秒内完成了单文件 HTML/CSS/JS 的完整闭环，包含程序化迷宫生成、requestAnimationFrame 帧同步、多实体状态机管理。代码逻辑更紧凑，意味着更低的显存占用波动和更快的冷启动响应。

在本地 LLM 部署场景中，tokens/sec 只是瞬时指标，真正决定生产可用的是有效信息密度。Gemma 4 31B 在处理墙壁碰撞、幽灵寻路、吃豆人转向队列、侧穿隧道逻辑时，指令遵循度更高。粒子特效和 HUD 渲染的边界控制也更稳定，没有出现因无效坐标计算导致的实体卡死或画面撕裂。这种高逻辑密度输出，对边缘侧设备的内存带宽压力更小，更适合集成到自动化 CI/CD 流水线中。

实测跑分与硬件环境参数

测试在统一硬件与 Prompt 条件下进行，排除了系统调度干扰。以下为关键性能指标对照：

- 推理硬件：MacBook Pro M5 Max，统一内存 64GB

- Qwen 3.6 27B：32 tokens/sec，耗时 18m 04s，总输出 33946 tokens

- Gemma 4 31B：27 tokens/sec，耗时 3m 51s，总输出 6209 tokens

- 任务类型：单文件霓虹街机游戏，要求全 Canvas 渲染，无外部依赖

硬件环境：MacBook Pro M5 Max / 64GB RAM 测试结论：31B 模型以更低 Token 消耗实现更强游戏逻辑，点击响应与交互判定更平滑。

该测试使用标准单轮 Prompt，直接要求模型输出完整可运行的 HTML 文件。核心约束条件包括：程序化生成 21x21 对称迷宫、动态 Canvas 缩放、游戏状态机（标题/运行/暂停/死亡/通关/结束）、键盘与移动端双端控制、本地 High Score 持久化存储、requestAnimationFrame 结合 delta time 的帧率控制、粒子数量上限保护。这些约束强制模型在有限上下文内完成全栈逻辑编排，非常适合检验本地模型的指令遵循与代码生成能力。

你目前本地跑 Code 生成任务，更看重 tokens/sec 峰值，还是单次输出的有效逻辑密度？主力机型是什么配置？