我为什么要自己跑一遍
本地模型的选择常被参数量和排行榜分数带着走。部署以后，还得看它能不能照着复杂指令做事，函数调用会不会出错，长思考能否及时停下，写出的代码又能不能通过测试。
这次我选了五组题。IFEval 看指令遵循，BFCL 测工具调用，MMMU 加入图片，LiveBench 负责综合推理，BigCodeBench 把生成代码送进沙箱执行。
我把两个模型部署在同一台 Apple Silicon 机器上，都只开一个实例和一个并发。题目跑完以后，我再逐条解析停止原因、耗时和评分日志。
怎样保证同题可比
评测使用 Inspect AI 0.3.255 和 Inspect Evals 0.16.0。为了尽量减少模型之外的变量，我固定了整套协议。
- 每项抽取 10 题，共 50 道不重复题目；
sample_shuffle=42，温度为 0；- 五项样本 ID 与顺序逐一核对，完全一致；
- 使用 Inspect 自带的确定性评分器，不用另一个大模型主观打分；
- BigCodeBench 生成代码只在无网络 Docker 沙箱中执行；
- 所有计入成绩的评测均为 10/10 完成，样本错误为 0。
输出上限随任务复杂度变化。BFCL 为 1024 token，IFEval 与 MMMU 为 2048 token，LiveBench 和 BigCodeBench 的最终有效上限为 4096 token。Gemma 使用 Google 官方 Gemma 4 12B 模型及其官方 QAT Q4_0 GGUF，两套服务的上下文均为 32768。
五项成绩，3 胜、1 负、1 平
| 能力 / Benchmark | GlimmerLocal runtime | Gemma 4 12BQAT Q4_0 |
|---|---|---|
| 01指令遵循IFEval · final_acc | 0.917WIN | 0.600 |
| 02工具调用BFCL · accuracy | 0.900 | 1.000WIN |
| 03多模态MMMU CS · accuracy | 0.400WIN | 0.200 |
| 04综合推理LiveBench · accuracy | 0.600WIN | 0.100 |
| 05代码生成BigCodeBench · pass rate | 0.400TIE | 0.400TIE |
IFEval 的 final_acc 是综合指标，不能简单翻译成“答对几题”。附加指标也呈现同样差距。Glimmer 的 prompt strict accuracy 为 0.900，instruction strict accuracy 为 0.933，Gemma 两项均为 0.600。
Gemma 靠工具调用拿下一局
0.900
5 分 31 秒 · 0 截断
1.000
1 分 54 秒 · 0 截断
BFCL 会检查模型选了哪个函数，也会核对传入参数。两个模型的 10 个样本都产生了框架可识别的原生工具调用，没有输出截断。Gemma 的 10 个样本全部正确。
Gemma 只用了 1 分 54 秒，Glimmer 用了 5 分 31 秒。模型如果主要服务于 Agent、自动化脚本或桌面助手，这段延迟差异每天都能感受到。
最大差距在于能不能停止思考
长思考的收敛能力拉开了本轮最大差距。Gemma 在 MMMU 的 10 道题中有 8 道写满 2048 token。到了 LiveBench，即使上限升到 4096，仍有 9 道写满。
| 评测 | 上限 | Glimmer | Gemma 4 |
|---|---|---|---|
| IFEval | 2048 | 1/10 | 4/10 |
| BFCL | 1024 | 0/10 | 0/10 |
| MMMU | 2048 | 3/10 | 8/10 |
| LiveBench | 4096 | 4/10 | 9/10 |
| BigCodeBench | 4096 | 4/10 | 4/10 |
部分 Gemma 输出把预算几乎全部花在内部推理上，最后答案为空或不完整。这类输出会被评分器判错。LiveBench 的 0.100 里，有多少是推理本身不会，有多少是没来得及交答案，这组小样本分不开。当前日志至少说明一件事。在这套 llama.cpp 配置与输出预算下，它经常无法及时把推理收束成可评分答案。
Glimmer 也有同类问题，但程度明显较轻。同样的最终有效预算下，它在 LiveBench 得到 0.600，截断数是 4/10。
代码生成打平，也都不够稳定
BigCodeBench 会把生成结果送进 Docker 沙箱执行隐藏测试。两个模型最终都是 0.400，10 个样本中各有 4 个通过。
这个平局有点出乎我的意料。Glimmer 在推理评测里的优势，没有直接变成更高的代码通过率；Gemma 虽然在长推理上落后，代码任务也没有继续掉队。
用它们写初稿、找思路都可以，直接提交还不行。4/10 的通过率意味着项目测试和人工审查都省不掉。
多模态部署，先确认图片真的进了模型
Gemma 第一次跑 MMMU 时，服务直接返回“不支持图像输入”。模型本身支持视觉，失败出在部署参数。我当时只加载了主 GGUF，漏掉了配套的视觉投影文件 mmproj。
补上同一官方版本的 mmproj 后，我先用一个 MMMU 样本做图片输入冒烟测试。图片经过 OpenAI 兼容接口进入模型并完成评分，我才重新跑完整 10 题。第一次基础设施失败没有计入模型成绩。
Gemma 跑完只用 1 小时 43 分
| 评测 | Glimmer | Gemma 4 12B |
|---|---|---|
| IFEval | 38 分 01 秒 | 18 分 24 秒 |
| BFCL | 5 分 31 秒 | 1 分 54 秒 |
| MMMU 最终完整轮 | 40 分 26 秒 | 18 分 01 秒 |
| LiveBench 最终协议 | 49 分 27 秒 + 71 分 31 秒 | 31 分 27 秒 |
| BigCodeBench 最终协议 | 52 分 52 秒 + 48 分 08 秒 | 33 分 11 秒 |
| 合计 | 5 小时 05 分 56 秒 | 1 小时 42 分 57 秒 |
Glimmer 的 LiveBench 与 BigCodeBench 采用“保留初轮自然停止题，再把截断题提升到 4096 token 复测”的校正方式；Gemma 直接用 4096 token 跑完整 10 题。每题最终有效上限一致，但耗时结构不完全相同。这张表记录的是实际部署成本，不能替代严格的纯吞吐基准。
即便考虑协议差异，Gemma 的速度优势仍然明确。它更适合对等待时间敏感的交互场景；Glimmer 则是在用更多时间，换更高的综合成功率。
到底该选谁
选择 Glimmer，如果你更在意
- 复杂格式与多条件指令；
- 综合推理的一次成功率；
- 图像与文本结合的分析；
- 可以接受更高延迟。
选择 Gemma 4，如果你更在意
- 本地 Agent 与函数调用；
- 更快的交互响应；
- 更小的模型与运行成本；
- 任务结构化、结果可验证。
代码生成方面，这 10 题没有分出胜负。如果代码是核心用途，我会换成与真实技术栈一致的私有测试，直接拿项目 issue、单元测试和实际修复任务来跑。
更稳妥的后续评测，则是把每项扩大到至少 50 题，再加入一套真实工作流数据。公开评测告诉你模型的通用能力，私有评测才能回答“它对我的任务到底有没有用”。
如果只能保留一个，我会把 Glimmer 留作主模型。Gemma 也值得留下。它可以处理高频、结构化、可验证的任务，复杂推理和多模态请求则交给 Glimmer。
模型使用 Gemma 4 12B QAT Q4_0，本机运行时为 llama.cpp，评测日期是 2026-08-11。本文所有分数均来自同机实际日志，未混用厂商榜单。