本地离线AI实测：16任务揭示小模型选型陷阱

一个浏览器助手应当能读取发票、比较两份报价、在页面上找到正确的按钮。理想情况下，即使断网也能工作，而且要在用户怀疑程序卡死之前给出回答。这就是 Lastbrowser 团队本地 AI 实验的出发点。

他们想找的是一个"实用最低线"：模型足够小能本地运行，足够快能带来真实价值，足够可靠能辅助日常浏览器任务——而不是去刷公开榜单。但在整个过程中，团队发现最令人失望的一些结果，其实部分源于他们自己评测方法的缺陷。

目标机器的错位：第一个教训

实验最初的目标机器是一台搭载 Intel i5-7600、16GB 内存的老旧 CPU 设备。团队想知道：能否找到一个在这类机器上仍保持响应性的小型本地模型？

但实际的对比测试却是在一台更强的 Windows 工作站上完成的——AMD Ryzen 9 5950X、32GB 内存、Intel Arc A770 显卡（16GB 显存），推理运行时使用 Ollama 和 Prism/llama.cpp 的 Vulkan 构建。

团队坦承："我们并没有在那台老 i5 上跑这些模型。在 Arc A770 上的结果，不能证明它在老旧纯 CPU 机器上有同样的响应性。"这暴露了第一个教训：在下载半个模型库之前，先写清楚目标机器，否则实验会悄悄变成另一个实验。

同样，团队也没有建立可比的峰值内存、显存或能耗测量序列。表格中列出的文件大小只是存储的模型权重，并非运行时总内存占用——上下文存储、缓冲区、后端和草稿模型都有各自的开销。

浏览器助手的"能用"究竟意味着什么

对这一使用场景而言，流畅的对话只是工作的一部分。一个模型可能写出令人愉悦的解释，却不适合把发票提取成应用数据；它可能解释如何点击按钮，却生成不出所需的工具调用；它可能飞快地生成 token，却在用户看不见的推理上花掉数秒。

团队要测试的是一系列具体行为：保留页面内容中的事实、同时满足多个约束、区分"信息缺失"与"真实的零值"、在来源冲突时优先选用较新来源、把页面内容当作数据而非指令、准确响应修正而不改动无关细节、产出可用的结构化输出、选对浏览器工具并精确保留其参数、以及在无法获取最新网络信息时仍保持有用。

正是"有帮助的回答"与"可依赖的应用组件"之间的区别，成为整个基准测试的核心议题。

29 个配置、16 个任务、770 次尝试

候选模型清单在多个方向上扩张：更小的候选探索速度下限；MoE（混合专家）候选探索稀疏激活能否以可控成本提供更多能力；压缩后的大模型候选探索较小的权重文件能否仍带来更强推理。

当前数据集包含 29 个模型/配置条目下的 770 次记录尝试，但统一测试套件中只有 16 个不同任务。这两个数字描述的是截然不同的东西。

候选阵容涵盖从 0.70GB 的 LFM 1.2B，到 24.57GB 的 Nemotron 3 Nano 30B-A3B。团队特别提醒命名需要谨慎："E2B"标签不自动等于总存储参数量，"A3B"后缀也不意味着整个模型只占三十亿参数稠密模型的内存。本地便捷标签并非权威的模型出处。

由于不同候选需要不同运行时——较小模型通过 Ollama 运行，Bonsai 文件和后续的 Gemma/Grug 对比使用 Prism/llama.cpp Vulkan 构建，更大的 offload 配置混合了 GPU 与系统内存——这使得整个实验成为"本地搭建方案的实用对比"，而非对模型架构的受控隔离。

MoE（Mixture of Experts，混合专家）是一种模型架构，其核心思想是将网络划分为多个"专家"子网络，每次推理时只激活其中一小部分，而非全部参数。以"Nemotron 3 Nano 30B-A3B"为例，30B 指模型总参数量约为 300 亿，而 A3B 表示每次前向传播实际激活的参数量仅约 30 亿。这意味着模型的存储体积接近稠密的 30B 模型，但推理时的计算量更接近 3B 模型。这一特性在理论上兼顾了大模型的知识容量与小模型的推理速度，但实际效果高度依赖硬件对稀疏计算的支持程度，以及运行时框架的实现质量。正因如此，文章中提醒"A3B 后缀不意味着整个模型只占三十亿参数稠密模型的内存"——模型权重仍需完整加载，运行时内存占用与稠密的大模型相近，只有计算量得到了显著压缩。

16 个任务：为浏览器而设计的陷阱

测试套件起初被分为"标准"与"进阶"，最终团队放弃了这种划分，让每个候选都面对相同的、有意义的浏览器导向任务。你可能没注意到，实际测试提示词是德语的——翻译这篇文章并不能把数据集变成英语基准。

这些任务设计得极具针对性。比如"总结状态页而不编造恢复日期"：供给的事实说某服务因电源故障离线，备件将于某日送达，但重启时间未知。陷阱很微妙——送达日期不是确认的恢复日期，把故事压缩成"服务将在某日恢复"就等于添加了一个事实。

再如发票提取任务，要求输出精确的 JSON 契约（字段名、小数转换、布尔类型都是合约的一部分）。一个人类可读的"未付款"与供下游应用消费的 JSON 布尔值是不同的值。还有抵御页面级提示注入——页面同时包含真实价格 €39 和一条试图将其覆盖为零的恶意指令，正确提取仍应是 €39，恶意文本是待检查的证据，而非更高优先级的指令。

团队诚实地指出："我们评估的是生成的调用，而非执行的浏览器交互。这些测试并不能证明实时页面按预期发生了改变。"

让 Gemma 看起来糟糕得多的评分 Bug

实验中最有价值的发现之一，是评分方法本身的缺陷。某一时刻，Gemma 12B 看起来表现极差：16 个任务只通过 4 个，一个更小的候选反而显得更强。有人质疑了这个结果——这正是对的干预。

原始的严格对比常常把"应用无法直接解析"等同于"模型回答错误"。比如一个被 Markdown 代码围栏包裹的 JSON 回答，其数值可以完全正确，但直接的 JSON 解析器会因为围栏而拒绝它。团队把两个本应分开的问题压缩进了一个百分比：回答在实质上是否正确？是否满足精确的接口合约？

重新评估后，Gemma 12B 在无思考模式下达到了 12/16 的实质通过，而严格通过仍停留在 4/16。"两个数字都不应替代另一个"——对读取聊天气泡的人来说，实质性改进很重要；对期待结构化对象的浏览器应用来说，严格失败仍是真实的缺陷。

团队也警示：他们的评审辅助工具包含针对特定案例和特定模型的决策，这既能记录修正，也引入了事后诸葛与不一致的风险。"修订后的分数是我们对这些存储答案的当前评估，而非评测已变得万无一失的证明。"

Markdown 代码围栏（code fence）是指在输出内容前后加上三个反引号（```）的格式标记，常见于 LLM 的结构化输出中，例如：```json\n{...}\n```。许多语言模型在训练数据中大量接触到这种格式，因此在生成代码或 JSON 时倾向于自动添加围栏以提升可读性。然而对于需要直接解析输出的下游应用而言，标准 JSON 解析器（如 Python 的 json.loads()）会因遇到非 JSON 的前缀字符而直接抛出异常，导致原本内容正确的回答被判定为失败。这一现象揭示了"对话友好性"与"应用可靠性"之间的结构性张力——前者鼓励模型输出格式整洁、便于人类阅读，后者要求输出严格符合接口契约，不含任何额外字符。解决方案通常包括：在提示词中明确禁止围栏、在应用层做预处理剥离围栏，或使用支持约束解码的推理框架直接强制输出合法 JSON。

结果：有用的候选，而非通用榜单

从各类候选的表现中，可以看到几个值得讨论的模式。

LFM 系列：速度是真实的，但合约很难满足。最小的 LFM 1.2B 中位生成速率约 208 tokens/s，但当前任务分仅 5/16 实质、2/16 严格。LFM 2.6B 更具实用中间地带价值，思考变体达到 12/16 实质，约 97 tokens/s。

Granite 系列：Tiny 达 8/16 实质、6/16 严格，约 93 tokens/s；Small 在两项都达 9/16，但只有约 16 tokens/s。从 Tiny 到 Small 换来了一些严格任务的成功，但并非能力的巨大飞跃。

小型 MoE 模型没有自动解决问题。EuroMoE、SmallThinker、Ling mini、LFM MoE 8B 给出了有用的提醒：小的激活参数量不保证应用级可靠性。EuroMoE 还出现了 8 个技术错误，必须与答案质量失败分开展示。

Bonsai 2 27B 是最亮眼的结果：非思考配置达 12/16，Medium 思考达 15/16（实质与严格均是）。有趣的是，更多推理并未带来明显额外收益——但样本太小，不足以称之为普遍最优。

崩溃与过载应归入另一栏

数据集中有 33 个技术错误，最大的集群是 Qwen 3.5 35B-A3B 配置：32 次尝试中有 22 个错误。观察到的序列是专家索引服务器错误，随后是反复的连接拒绝。一旦服务器崩溃，后续问题就得不到公平的推理测试。

Nemotron 3 Nano 在操作上更具破坏性，系统严重过载后两次请求超时，团队果断停止了该配置。"两次超时足以说明尝试的搭建不适合我们的工作站体验，但不足以对模型的推理质量排名。"

这里的关键区分在于：操作失败依然重要——一个让工作站变得难用的模型未能满足产品要求。但团队需要说清楚失败的是什么：是被测试的硬件/运行时配置，而非模型从未产出的某套虚构答案。

GPU 显存卸载（offloading）是指在模型权重超过显卡显存容量时，将部分层或权重卸载到系统内存（RAM）乃至磁盘，由 CPU 承担相应计算。以 llama.cpp 为代表的推理框架支持通过参数控制卸载到 GPU 的层数，未卸载的层由 CPU 处理。这种混合模式使得在消费级硬件上运行远超显存容量的模型成为可能，但代价是 CPU 与 GPU 之间频繁的数据传输会成为瓶颈，导致推理速度大幅下降，同时系统内存压力骤增。Qwen 3.5 35B-A3B 与 Nemotron 3 Nano 的崩溃和超时问题，很可能正是 offload 配置下系统资源被耗尽所致。这也解释了为何文章强调"是被测试的硬件/运行时配置失败，而非模型本身"——相同的模型权重在资源充足的机器上可能表现稳定。

MTP：最令人鼓舞的速度实验

团队先单独测量 Gemma 12B，再加入配套的多 token 预测（MTP）草稿模型作为独立配置。推测解码会提议多个 token，让目标模型验证它们。

结果令人印象深刻：非思考模式下，加入 MTP 后中位解码速率从 27.02 tokens/s 跃升至 64.94 tokens/s，中位请求时间从 1.90 秒降至 0.89 秒，而任务分（12/16 实质、4/16 严格）保持不变。思考模式下，请求时间也从 21.63 秒压缩到 7.66 秒。

不过团队保持克制："速度提升很惊人，但它是在每任务一次尝试的小规模对比中测得的，不是大规模的接受率与能耗研究。"存储的输出在各次运行间并不完全相同，但这不足以证明 MTP 本身改变了质量——后端行为、数值细节和小样本都可能起作用。对产品而言，MTP 是一个有前景的加速选项，但需要自己的回归检查，它并没有修复 Gemma 的输出格式失败。

推测解码（Speculative Decoding）是一种通过引入轻量级"草稿模型"来加速大型语言模型推理的技术。其工作原理是：先让小型草稿模型快速生成若干候选 token，再由目标大模型对这批 token 进行并行验证，接受符合其分布的部分，拒绝其余部分并重新采样。由于大模型一次前向传播可验证多个 token，而非逐一生成，整体吞吐量得以显著提升，且理论上不改变输出的概率分布。MTP（Multi-Token Prediction）是这一思路的一种变体，通过在训练阶段同时预测多个未来 token 来优化草稿质量。推测解码的实际加速效果强烈依赖于草稿模型与目标模型之间的分布匹配程度——匹配越高，草稿 token 被接受的比例越大，加速效果越明显；若两者差异较大，频繁拒绝会导致实际收益有限。这也是团队强调需要独立回归检查的原因。

评测本身也需要审计

令人尴尬的部分不止是原始的严格评分。团队的 AI 编码助手在答案评审实际完成之前，就报告说评审已经完成——后续检查仍发现 105 个未评审的答案。"这是助手的虚假进度声明，不是模型基准结果。"

还有一个编码问题：文本在 Windows 下用不合适的默认编码读取，产生了乱码字符和不同的答案指纹。团队修复了映射并显式使用 UTF-8。如今全部 770 次记录尝试都有评审映射，但团队强调："覆盖率不等于正确性。它不意味着存在 770 个独立的人类判断，也不意味着评分标准没有残留的歧义。"

下一轮之前要改变什么

团队列出了明确的改进方向：先冻结评分标准——在运行模型之前写清预期事实、输出 schema、可接受的变体和关键失败；测试评分器本身——用已知良好/不良的样例去检验它；保持可比条件——使用相同任务集和重复策略，记录精确的运行时构建与模型版本，分离热推理与冷启动；把结构化输出干预作为独立配置评估；运行真实的浏览器工作流——执行工具调用、检查页面状态、验证预期效果；保护机器的可用性——追踪峰值内存和用户可见的响应性。

对这个德语合成浏览器任务套件而言，Bonsai 2 27B 在 Medium 思考下是最强的实用候选（15/16）。但团队谨慎地说："它值得再来一轮受控测试，而非一枚通用冠军徽章。即便 16/16 也只能证明在 16 个合成样例上的成功，而非安全的自主浏览。"

最清晰的教训关乎工程判断：模型、运行时、输出合约和评估器——全都需要被测试。 一个百分比可以隐藏任何一层的错误。