我为什么要自己跑一遍
本地模型的选择常被参数量和排行榜分数带着走。部署以后，还得看它能不能照着复杂指令做事，函数调用会不会出错，长思考能否及时停下，写出的代码又能不能通过测试。
这次我选了五组题。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。
五组题的本机成绩
| 能力 / 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 的 10 个样本全部通过
0.900
5 分 31 秒 · 0 截断
1.000
1 分 54 秒 · 0 截断
BFCL 会检查模型选了哪个函数，也会核对传入参数。两个模型的 10 个样本都产生了框架可识别的原生工具调用，没有输出截断。Gemma 的 10 个样本全部正确。
这组 BFCL 样本里，Gemma 用了 1 分 54 秒，Glimmer 用了 5 分 31 秒。这个差异值得在实际 Agent 工作流中继续测，但 10 道函数调用题不能覆盖全部交互场景。
截断影响了推理题的评分
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 个通过。
推理评测的分差没有直接延续到 BigCodeBench：两边都是 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 值得继续验证的场景
- 复杂格式与多条件指令；
- 综合推理的一次成功率；
- 图像与文本结合的分析；
- 可以接受更高延迟。
Gemma 4 值得继续验证的场景
- 本地 Agent 与函数调用；
- 更快的交互响应；
- 更小的模型与运行成本；
- 任务结构化、结果可验证。
代码生成方面，这 10 题没有分出胜负。如果代码是核心用途，我会换成与真实技术栈一致的私有测试，直接拿项目 issue、单元测试和实际修复任务来跑。
下一轮可以扩大每项样本，再加入真实工作流。公开评测与项目私有任务提供不同信息，两者都需要保留输入、运行参数和失败记录。
按这轮样本，我倾向继续用 Glimmer 验证复杂任务，同时保留 Gemma 测结构化工具调用。最终是否保留哪一个，还要看自己的任务分布和资源预算；这 50 题先提供了一组可追查的起点。
模型使用 Gemma 4 12B QAT Q4_0，本机运行时为 llama.cpp，评测日期是 2026-08-11。本文所有分数均来自同机实际日志，未混用厂商榜单。