本地模型测速差距可能来自默认参数

同一个 GGUF、同一台电脑，Llama-Windows 比 Ollama 慢约 15%，能说明推理引擎有差距吗？作者连续两次修正结论：先发现漏开了推测解码，再发现采样参数没对齐。两项补齐后，速度基本相当。

这份测试值得看的，是它展示了本地模型跑分怎样被默认配置带偏。对于准备接入本地 LLM、比较工具速度的程序员，先看清每次请求到底用了什么参数，比盯着 tokens/sec 排名更有用。

同一个模型文件，为什么还不算公平比较

测试使用 Surface Laptop Ultra，环境是 Windows on Arm、RTX Spark，模型为 Qwen3.6-35B-A3B，量化格式 Q4_K_M。按应用出厂设置运行，Llama-Windows 的速度约为 Ollama 的 85%，GPU 利用率却更高。

作者没有直接归因于引擎，而是检查 Ollama 实际调用了什么。Ollama 0.40.7 的日志显示 using llama-server for model，ollama ps 的 RUNNER 列为 llamacpp。GPU 库是 cuda_v13 下的 ggml-cuda.dll，没有附带 Vulkan 构建。

也就是说，这次比较的两边都在跑 llama.cpp。通过 --version 输出和提交记录，作者发现，Ollama 捆绑的版本只比 Llama-Windows 使用的 llama.cpp b11706 新 32 个提交。

这里还要分清应用和引擎。第一次测试比较的是 Ollama 与 Llama-Windows 两个应用的默认行为；后续为了控制配置，作者手动启动 llama.exe 作为服务器，再与 Ollama 对比。后面的结果不能直接当作 Llama-Windows 应用默认体验的成绩。

相同模型文件只是起点，运行时配置也属于比较对象。

两次改判，分别漏掉了什么

第一项差异是多词元预测（MTP）支持的推测解码。Qwen3.6 内置 MTP 层，可以先猜后续 token，再集中验证，不需要额外加载一个独立草稿模型。

Ollama 默认就使用它。运行 ollama show，参数里能看到 draft_num_predict 2，表示提前猜 2 个 token；在 API options 中设为 draft_num_predict: 0 可以关闭。Llama-Windows 应用默认不开启，手动运行 llama.exe 时，要传入 --spec-type draft-mtp --spec-draft-n-max 2。

作者观察到，开启后会额外占用约 1.5–2 GB 显存，但 GPU 利用率下降、生成速度提高。原先「更忙却更慢」的现象因此有了解释：两边执行的解码流程不同。

只对齐这一项，llama.exe 反而快了 7–8%。然而，作者随后发现采样默认值也不一致，这个结论仍然下早了。

正式比较使用两组采样设置。S1 是模型推荐值，也与此次 Ollama 默认值相同：temperature 1.0、top_k 20、top_p 0.95、min_p 0、presence_penalty 1.5、repeat_penalty 1.0。S2 使用 temperature 0 的贪心解码，每步选择概率最高的 token。

双方 seed 固定为 42，生成上限为 1024 tokens，对应 Ollama 的 num_predict 和 llama.exe 的 max_tokens。参数逐请求传入，没有修改配置文件。每种组合先预热一次并丢弃，再测 5 次，同时停止另一套引擎。

对齐后，无推测解码的贪心设置下，两边分别为 81.69 和 80.44 tokens/sec，已经相当接近。各组 5 次测量的标准差为 0.38–1.90。

剩下的异常集中在 presence_penalty。这个参数用于抑制已经出现过的 token。设为 1.5 时，llama.exe 从 80.44 降到 74.75 tokens/sec，约慢 7%；Ollama 从 81.69 变成 81.45，变化很小。

作者没有查明原因。32 个提交之间的修改、调用方式差异，都只是候选解释。

提前多猜一个 token，为什么没有更快

提前猜 2 个 token 时，两边都获得了明显加速：Ollama 约提高 22–27%，llama.exe 约提高 30–38%。在推荐采样设置下，后者通过推测解码补回了前面的速度损失，最终与 Ollama 大致持平。

贪心解码加 2-token 推测时，llama.exe 达到 110.85 tokens/sec，Ollama 为 104.04。但两边输出不同，草稿接受率也分别为 0.835 和 0.819。作者因此没有把这组领先归结为引擎优势。

推测解码依赖「猜中的收益」覆盖「猜错的成本」。把草稿长度从 2 调到 3，在四种组合里都没有更快，结果相同或更慢。2-token 的接受率为 0.71–0.84，3-token 则降到 0.65–0.71，第三个猜测更难命中。

固定 seed 前，3-token 设置曾在 103–113 tokens/sec 之间波动，因为每次生成的文本不同。固定后，5 次运行产生相同 token 数，原先的波动消失了。

这也限定了结果的含义：它衡量的是重复输出下的速度稳定性，没有覆盖不同答案带来的变化。跨配置的生成长度仍在 739–1024 tokens 之间；即使贪心解码，两边答案也会中途分叉，同一引擎开关推测解码后也可能输出不同文本。

我的判断

作者最有价值的做法，是把结论收回到证据能支持的范围：这台机器、这个模型、这个提示词下，最初约 15% 的差距主要来自默认设置。它支持「先检查配置」，不足以证明两个产品在所有负载下都一样快。

测试只有一个提示词、一台电脑，没有长上下文、其他模型或回答质量对照。因此，2-token 足够、3-token 无收益，是这里的实测结果，不能直接升级成通用调参规则。固定 seed 也没有让不同运行时输出完全一致。

与直接打开两个应用跑一次相比，这种逐请求控制参数的方式更适合定位差异；应用默认设置测试则仍有价值，它回答的是用户安装后能直接获得怎样的体验。两类结果需要分别标明。

版本边界同样不能省略：数据来自 Ollama 0.40.7、Llama-Windows 0.13.0 和 llama.cpp b11706。2026 年 11 月，作者机器上的 Ollama 已自动更新到 0.40.10，但没有复查默认值。

安装检查还揭示了另一层差别。Llama-Windows 的 MSIX 有签名，哈希与发布记录一致；应用会下载 install.ps1 并在内存中执行，再从 Hugging Face 获取对应 GPU 的引擎，本次为 CUDA aarch64 构建。下载的 llama.exe 没有签名，也没有哈希校验，仅通过 HTTPS 获取。作者安装前阅读脚本，安装后记录引擎哈希；服务器默认只监听 127.0.0.1。应用包的验证结果，不能自动覆盖后续下载的引擎。

能拿来做什么

• 给 Node 本地模型接口做对比时，把模型文件、运行时版本、推测长度、完整采样参数、seed 和生成上限一起记录，并保留每次实际生成的 token 数。
• 调整生成速度时，可以先比较关闭推测解码与提前猜 2 个 token 的结果，同时观察显存占用和接受率；不要预设草稿越长越快。
• 比较日常 AI 编程表现时，把固定提示词的速度测试与答案质量检查分开进行。这里没有质量对照，无法据此判断哪个工具写代码更可靠。
• 复现这些数据时，先核对当前版本及默认值，再按原文的预热、重复测量和停止另一引擎的流程运行，避免直接套用旧版本结论。