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 配置
该测试使用标准单轮 Prompt,直接要求模型输出完整可运行的 HTML 文件。核心约束条件包括:程序化生成 21x21 对称迷宫、动态 Canvas 缩放、游戏状态机(标题/运行/暂停/死亡/通关/结束)、键盘与移动端双端控制、本地 High Score 持久化存储、requestAnimationFrame 结合 delta time 的帧率控制、粒子数量上限保护。这些约束强制模型在有限上下文内完成全栈逻辑编排,非常适合检验本地模型的指令遵循与代码生成能力。
你目前本地跑 Code 生成任务,更看重 tokens/sec 峰值,还是单次输出的有效逻辑密度?主力机型是什么配置?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.