重启 174 次后，他删掉了 12 个大模型参数：本地推理不是念咒

一台 2016 年的 Xeon E5-2620 v4，8 核 16 线程，128GB DDR3，没有 GPU，没有 swap。作者拿它跑 Gemma 4 26B Q8_0，不换显卡，不换模型，只拆启动参数。

他把原来 25 个 flag 的命令逐项消融。每次只关一个参数，重启、加载、测试。总共跑了 174 次。

表面上，这次折腾只是删掉 12 个参数，换来大约 4 tokens/s 的差别。真正扎眼的不是这点速度，而是它把本地大模型推理里一件尴尬事摊开了：很多“高级参数”并不高级，只是把硬件限制、任务差异和引擎沉默包成了调优幻觉。

174 次消融后，真正稳的变量很少

这次测试的价值在方法。完整配置不变，每次只关闭一个 flag，看 chat、长文总结、代码生成三个任务的速度变化。

作者也明确提醒：这些差值不能线性相加。参数之间有交互，一个 flag 的收益可能来自另一个机制被它撑住了。

flash attention 是这张表里最硬的变量。关掉它，速度接近腰斩。它还会影响 speculative decoding 的接受率，所以收益不是孤立的。

线程数更有现实感。很多人看到 16 线程，第一反应就是 -t 16。但这台机器上，-t 8 更快。

原因不神秘。每个 token 都要读大量权重，瓶颈撞在 DDR3 内存带宽上。超线程不会凭空变出带宽，只会增加调度和争用。

这对折腾 llama.cpp、ik_llama.cpp 的用户很直接：先测物理核心，再测逻辑线程。不要把线程数写满当成优化完成。

drafter 的问题，不是开不开，是给谁用

drafter，也就是 speculative decoding 里的草稿模型，是这次最能说明问题的参数。

它在代码生成里有用，速度约 +28%。但在长文总结里，关掉反而更快。

差别来自接受率。代码任务更容易被草稿模型猜中，verifier 接受得多，收益就出来。长文总结更发散，草稿被拒得多，最后多跑一层模型，变成额外成本。

这件事对本地 AI 工程用户的动作很明确：不要把 drafter 写成全局默认。至少要按任务分配置。

--spec-autotune 也露出限制。至少在 256 tokens 这类短生成里，固定 draft 长度比自动调参更快。

这不能推出 autotune 永远不行。长生成可能会给它更多收敛空间。但短交互正是很多本地模型的日常：问一句，等几百个 token。这里慢一点，用户马上能感到。

“工欲善其事，必先利其器。”但这里的“器”不是参数越多越利，而是能不能按工作负载分流。

早期 PC 超频也有类似教训。外频、倍频、电压、散热，每个旋钮都像捷径。最后能稳定跑的，往往不是旋钮最多的方案，而是知道哪块板、哪颗 CPU、哪种负载先崩。今天本地推理换了皮，逻辑没变。

真正该紧张的，是引擎太沉默

我更在意的是反馈系统。

--mla-use 对 Gemma 4 实际未接线，却能被接受，还没有足够清楚的提示。用户以为自己启用了优化，实际只是命令行里多了一段装饰。

--mlock 又是另一类问题。它不是参数本身无效，而是依赖宿主机 memlock 配置。重启后配置没有持久化，它就会退化。

多设备 split 相关参数，在单 CPU、无 GPU 机器上当然也跑不出收益。问题不在用户不知道硬件，而在引擎没有把“没触发”“被忽略”“受宿主限制”讲清楚。

这对两类人影响最大。

如果你在老 CPU 上跑模型，采购也该慢半拍。别先问“要不要换机器”，先问当前瓶颈是什么：内存带宽、量化格式、上下文长度、线程调度，还是任务本身不适合 speculative decoding。

如果你在做推理引擎，接下来最该补的不是再加十个 flag，而是日志和可观测性。参数有没有接线，是否触发，受什么限制，在哪个阶段带来收益，都该明说。

这次测试不能推广到所有 CPU、所有量化、所有模型。它只是一台老 Xeon 上的手工消融。

但它至少说明一件事：本地 AI 优化不是抄命令行咒语。真正可靠的路径很笨，量一次，删一次，再量一次。

本地推理的分水岭，也许不在谁的参数更多，而在谁更快承认物理约束。