本地跑大模型为何「变笨」：一篇推理精度实验拆解

在论坛和社交平台上，「某模型惊艳」「下载后却拉胯」是本地 LLM 玩家的高频吐槽。本文作者认为，这种落差并非模型本身的问题，而是参考实现与本地部署之间的「推理精度漂移」造成的——硬件指令集、推理引擎、采样参数、量化方案中的任何一环，都可能让同一份权重的输出偏离官方基线。文章以 Qwen3.6-27B 为对象，启动了一系列对照实验，本文呈现的是其方法论与第一个测试的开头。

本地部署为何天然「偏」

作者指出，所谓「参考实现」是指模型实验室自有的、跑出原始 benchmark 的环境，其硬件、软件栈与普通玩家的机器几乎不可能完全一致。同一个权重文件，在不同 GPU 代次、不同 CUDA 内核、不同推理框架下，可能走出完全不同的推理路径。即便不做量化，只是把温度调到零、跑三道测试题，也不足以模拟长上下文、工具调用等真实 agent 场景。

要判断本地部署「偏离多少」，一类做法是跑覆盖工作负载的标准 benchmark，例如 TerminalBench、HLE、SWE 系列、MMLU 等；另一类则是从数学层面度量输出分布相对参考实现的偏移量，作者后续会沿着后者展开。

采样器设置：被忽视的偏差源

模型在 Hugging Face 的 Model Card 通常会明确标注推荐采样参数，例如 temp=1.0、top-p=0.95，并附带对应的 chat template。偏离这些设置，输出分布就会出现可观测的漂移。作者特别提示：把 temp 调得过低，是许多 Qwen 用户看到模型陷入「THINK 输出循环」的常见原因。

衡量这种漂移的常见指标是 KL 散度（KLD）：把 logits 转成概率分布后，与选定的参考分布比较距离。KLD 越低代表越接近参考基线，但作者强调「不等于更聪明」。KLD 是有方向性的量，比较顺序会影响数值；同时，模型卡上标注的极低 KLD 数字若未披露参考 checkpoint、运行环境、校准数据、上下文长度、采样位置、词汇表裁剪与聚合方式，几乎无法解读。

推理软件栈的复杂度

以 vLLM 为例，作者抓取的某个 nightly 镜像包含 734 个软件包，其中 252 个来自 uv/pip 的 Python 依赖。每个软件包都有自己的 bug 与未文档化的特性，最终在本机走过的执行路径会与参考实现截然不同。这也是为什么「同一份权重，跑出来不一样」会频繁发生。

Test 1：注意力后端精度对比

作者给出的第一个实验聚焦 prefill（提示处理）阶段的注意力后端选择。测试条件如下：

• 模型：Qwen3.6-27B（dense 非 MoE，但属于混合架构），BF16 官方 checkpoint
• 硬件：单卡 RTX PRO 6000 Blackwell
• 推理框架：pinned nightly 版 vLLM
• 配置：eager 执行，禁用 CUDA graphs、prefix caching 与 MTP；KV cache 为 BF16，未对权重、激活或 KV cache 做量化；prefill 采用 2k token 分块

Qwen3.6-27B 的 64 层以「3 层 Gated DeltaNet（线性注意力）+ 1 层全注意力」的模式重复。实验中只有 16 层全注意力会受注意力后端切换影响，Gated DeltaNet 路径保持不变。不同 GPU 家族与 SM 计算能力对应不同的 CUDA 内核，这意味着切换后端既影响速度，也影响 prefill 的数值精度。

作者在原文中以「The work…」收尾，详细结果与结论尚未给出，因此本次仅整理其实验设置与思路，待后续补全后再做跟进报道。