本地跑 Qwen 3.8 等于 Opus 4.6？这个等号有五个前提

先把结论摆在前面。「本地跑 Qwen 3.8 就等于 Opus 4.6」这个说法，在特定配置下是有道理的， 而这个配置有五个前提：量化档别低于社区公认的地板、KV cache 量化档按任务定（有工具调用就别到 4bit）、采样参数按官方 模型卡走、上下文按你的硬件设而不是按模型卡标称设、以及一个大多数人不会想到的——你用哪个 推理运行时本身就是变量。

**两个市场这周说的都对，差别全在配置上。**下面每条前提都挂了实测数字，最后一节回答那个更 有用的问题：不是「本地能不能替代云端」，而是「哪些任务能」。

两个市场，同一个模型，相反的结论

掘金上有篇 639 赞的文章，标题是「本地跑一个 Qwen 3.8，你将拥有一个 Opus 4.6」。 作者用 M5 Max 128GB、Ollama、4bit 量化，讲的是不花 API 钱、没有额度焦虑、代码不出内网。

同一周，Hacker News 上一篇 327 分的帖子叫 「为什么你的本地 LLM 感觉比实际更笨」。 作者做了一件很硬核的事：用 teacher-forced 解码捕获完整 logits，量化同一份权重在不同配置下 的行为差异。

两篇讲的是同一个模型，结论看起来相反。但把两边的前置条件摆出来，矛盾就消失了—— 一个在讲「配置对的时候能做什么」，另一个在讲「配置错的时候会发生什么」。

前提一：量化档

Level1Techs 那篇在 88k 上下文下，测了各量化档相对 BF16 参照的 top-1 token 翻转率：

这里要替原作者说一句限定，因为它决定了这些数字该怎么读：作者明确写了 BF16 只是数值保真的 参照，不是正确性判据——量化模型偏离 BF16，完全可能给出语义上更好的答案。所以上表是 「偏离程度」不是「错误率」，别当质量分用。

看懂这个限定之后，有用的读法是：别盯着 NVFP4 那 50%，那是第一代 4bit 格式，单点数据。 真正该影响决策的是第二行——官方 FP8，模型作者自己发布的精度，长上下文下也有约 20%。

社区侧的经验值是 Q4_K_M 作为地板，Q5_K_M 更稳妥。这个阈值和上面的实测方向一致，可以作为 起点，但记住它是经验共识不是实验结论。

前提二：KV cache 量化到 4bit 之前，先看你跑的是什么任务

这条最容易被牺牲，因为量化 KV cache 省显存的效果最直观。

Level1Techs 单独测了这一项——权重和激活都不动，只量化 KV cache：int8 在工具调用出现分歧 后最终恢复了，int4 再也没恢复。

「再也没恢复」这个说法值得停一下。它不是「回答质量下降」，是这段对话从某个点之后就一直是坏的。

但这里有一组看起来矛盾的证据，值得摊开讲。（本节 2026-08-24 修订，见文末说明）

llama.cpp 的 issue #21385 报告了相反 方向的结果：在 Qwen3.5 上，q4_0 KV cache 完全无损——10 组配置、50 次补全，BLEU 全部 1.000，f16 与 q4_0 逐 token 一致，而压缩率是 4 倍。同一份报告里，GPT-2 这类全层 full attention 的传统架构在同样 4 倍压缩下 BLEU 只有 0.531。

报告给出的解释是架构差异：混合架构里只有一部分层用 full attention，其余的线性注意力层 起到了误差校正的作用。

问题在于——Qwen3.8-27B 自己就是混合架构。 官方模型卡的层布局是 16 × (3 × (Gated DeltaNet → FFN) → 1 × (Gated Attention → FFN))，64 层里只有 16 层是 full attention。而 Level1Techs 测的 Qwen3.6-27B 是同一个 3:1 的模式，作者原文也明说了 「it is still a hybrid model」。

所以这两个结果不是「混合架构安全、dense 危险」那么简单——它们在同一个架构类上给出了 相反结论。差别在测的东西不同：

可以带走的结论：如果你的负载是对话与文本生成，q4_0 KV cache 在混合架构上有实测支持， 省下的显存是真的。如果你的工作流里有工具调用——尤其是长上下文下的多轮 agent—— 那就按 Q8 走，Q4 的风险有实测案例而且失败形态很糟（不可恢复）。

分界线不是架构，是任务。而这两项测量都没有覆盖对方的场景，所以谁也没资格替对方下结论。

前提三：采样参数按官方卡走

Qwen 官方模型卡给了明确的推荐值，两种模式不一样：

思考模式：temperature=1.0  top_p=0.95  top_k=20
指令模式：temperature=0.7  top_p=0.80  top_k=20

这里有个流传很广的说法——「温度设太低是 Qwen 卡在 think 里出不来的原因」。需要说明的是， 这句话来自 Level1Techs 作者的旁注，官方模型卡并没有这条警告。我把出处摆明，你自己 判断要不要采信。

值得一提的是，HN 那个讨论串里有条评论认为，很多人遇到的问题根本不是量化，而是 chat template 丢失或者采样参数配错了。这条来自讨论区而不是我们，但它说得对——量化只是变量之一， 不是唯一变量。

前提四：上下文按硬件设，不按模型卡标称设

Qwen 官方卡写的是原生 262,144，可扩展到 1,000,000。这是架构能力，不是你那台机器的能力。

KV cache 的显存占用随上下文长度线性增长。128K 上下文在 70B 模型上，FP16 的 KV cache 可能 超过 40GB——比模型权重本身还大。

HN 那个串里有人列了 Ollama 的若干问题，其中一条是默认上下文窗口只有 2K/4K。这解释了 一个很常见的现象：很多人抱怨「本地模型记不住前面说了什么」，真因不是模型笨，是超出窗口的 内容被静默截断了，而且大多数工具不会给你任何警告。

前提五：runtime 本身是变量

这条是读者最想不到的。

Level1Techs 的测试里，权重、prompt、seed 全部固定，只换 vLLM 的 attention 后端 （FlashAttention 2 / Flash Inference / Triton），就能产生可复现的、bit 级一致的差异。

其中一个案例：FlashAttention 2 选错了 Cisco 接口——本该操作 GigabitEthernet0/0/1.201， 实际选了 GigabitEthernet0/1/4，然后对着错误的接口执行了补救命令。这里没有任何量化参与， 同一份权重，换个 attention 实现，操作对象就错了。

HN 上还有一条相关观察：llama.cpp 的 Q8_0 表现优于 vLLM 的 FP8——这是两个运行时之间的差异， 不是两种精度之间的差异。

这个现象不止出现在推理运行时这一层。Qwen 官方在发布 3.8-Max 时给了一张「跨 harness 泛化」 的对比，测的是同一个模型挂在不同 agent 框架下的得分：

以 JobBench 那组为例，同一个模型在五个 harness 下从 53.4 分到 59.8 分，跨度 6.4 分。 这跟量化档、KV cache 都没关系——纯粹是外层框架怎么组织上下文、怎么处理工具调用带来的差异。

所以「runtime 是变量」这条前提其实有两层：底层的推理运行时（llama.cpp / vLLM / Ollama， 以及它们各自的 attention 实现），和上层的 agent harness。两层都会动结果，而两层都不在 模型名里。

那速度呢：25 tok/s 是什么体感

另一篇掘金文章「这个本地模型，让我 token 自由了」 给了具体数字，也给了这轮讨论里最诚实的一句话。把它和 AMD 官方在 Day 0 那天发的实测放在一起看：

这些数字不能脱离硬件前提引用。M5 Max 那个 25 tok/s 是 128GB 内存 + 4bit 量化下的结果； AMD 两行是厂商 2026 年 8 月的初步测试数据，取三次以上运行的平均 token 生成吞吐， 原文标注「All values up to. Performance may vary」。

值得注意的是两个独立来源的交叉印证：社区在 M5 Max 上自测约 25 tok/s，AMD 官方在 Ryzen AI Max+ 395 上测到最高 24 tok/s——不同硬件、不同栈、不同测试方，落在同一量级。 这比任何单一来源都更能说明「集成显卡/统一内存这一档，27B 就是 20 多 tok/s 的水平」。 想要三位数，得上独立显卡。

而那句诚实的话是掘金作者自己写的：**「真正做项目，我还是会打开云端。」**他给的理由是长推理 任务云端更稳定。写「token 自由」的人自己划了边界——本地不是替代，是分流。

等号在哪些任务上成立

所以回到开头那个等号。它不是真假问题，是范围问题。

把这张表填完，比争论「本地能不能追平闭源」有用得多。两位掘金作者的做法都没问题——一个在讲 配置对的时候本地能干什么，另一个直接说了自己什么时候会打开云端。真正的坑在中间：以为装完 就等于换了个模型，然后在工具调用上踩坑还不知道为什么。

如果你想从路由层看同一件事——这些看不见的变量对模型选路意味着什么——今天英文刊有一篇 Your quantization tier is a product spec， 以及此前的同一份权重，多种价格。

修订说明（2026-08-24）：前提二原本写作「KV cache 别量化到 4bit，Q4 不要碰」， 这是一刀切。补入 llama.cpp issue #21385 的实测（混合架构上 q4_0 BLEU 1.000）后重写为按任务分档——并指出该实测与 Level1Techs 的工具调用结论在同一架构类上相反，差别在测量对象而非架构。原结论对 agent 场景仍成立， 但不该推广到文本生成场景。