# 本地跑 Qwen 3.8 等于 Opus 4.6？这个等号有五个前提 > 同一周，中文社区在说「本地模型追平闭源」，英文社区在说「你的本地模型没你以为的聪明」。两边都没说错——差别在配置。把 88k 上下文下的实测翻转率、KV cache 精度、官方采样参数和硬件速度摆在一起，等号成立需要五个前提，以及一句更有用的话：不是能不能，是哪些任务能。 - Published: 2026年8月22日 - Updated: 2026年8月24日 - Author: Leo Kaka, Engineering - Tags: local-llm, quantization, cost - Canonical: https://pirouter.ai/zh/blog/local-qwen-equals-opus-preconditions --- 先把结论摆在前面。「本地跑 Qwen 3.8 就等于 Opus 4.6」这个说法，在**特定配置下**是有道理的， 而这个配置有五个前提：量化档别低于社区公认的地板、KV cache 量化档按任务定（有工具调用就别到 4bit）、采样参数按官方 模型卡走、上下文按你的硬件设而不是按模型卡标称设、以及一个大多数人不会想到的——**你用哪个 推理运行时本身就是变量**。 **两个市场这周说的都对，差别全在配置上。**下面每条前提都挂了实测数字，最后一节回答那个更 有用的问题：不是「本地能不能替代云端」，而是「哪些任务能」。 ![五个前提的清单卡：量化档 ≥Q4_K_M、KV cache 按任务定档、采样参数按官方模型卡、上下文按显存设、runtime 两层都算，每条附对应的实测数据依据](/blog/images/local-qwen-preconditions-checklist.png "图 1 — 五个前提各自的判据与数据依据。任何一条踩空，最先坏的都是工具调用。") ## 两个市场，同一个模型，相反的结论 掘金上有篇 639 赞的文章，标题是[「本地跑一个 Qwen 3.8，你将拥有一个 Opus 4.6」](https://juejin.cn/post/7674574367976341567)。 作者用 M5 Max 128GB、Ollama、4bit 量化，讲的是不花 API 钱、没有额度焦虑、代码不出内网。 同一周，Hacker News 上一篇 327 分的帖子叫 [「为什么你的本地 LLM 感觉比实际更笨」](https://forum.level1techs.com/t/why-your-local-llm-feels-dumber-than-it-is/253917)。 作者做了一件很硬核的事：用 teacher-forced 解码捕获完整 logits，量化同一份权重在不同配置下 的行为差异。 两篇讲的是同一个模型，结论看起来相反。但把两边的**前置条件**摆出来，矛盾就消失了—— 一个在讲「配置对的时候能做什么」，另一个在讲「配置错的时候会发生什么」。 ## 前提一：量化档 Level1Techs 那篇在 88k 上下文下，测了各量化档相对 BF16 参照的 top-1 token 翻转率： | 量化档 | 类型 | 88k 翻转率 | |---|---|---| | TheHouseOfTheDude INT8 | W8A16 | 约 15% | | 官方 FP8 | W8A8 | 约 20% | | AWQ W4A16 | group size 32 | 约 30% | | NVIDIA NVFP4 | 混合 FP8/FP4 | 约 50% | 这里要替原作者说一句限定，因为它决定了这些数字该怎么读：作者明确写了 **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](https://github.com/ggml-org/llama.cpp/issues/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 危险」那么简单——它们在同一个架构类上给出了 相反结论**。差别在测的东西不同： | | llama.cpp #21385 | Level1Techs | |---|---|---| | 测什么 | 纯文本补全与 f16 的逐 token 一致性 | 10 万 token 真实工作流里的**工具调用** | | 指标 | BLEU（1.000 = 完全一致） | 工具调用是否出错、出错后能否恢复 | | 结果 | q4_0 无损 | int4 出错后**再也没恢复** | **可以带走的结论**：如果你的负载是对话与文本生成，q4_0 KV cache 在混合架构上有实测支持， 省下的显存是真的。如果你的工作流里有**工具调用**——尤其是长上下文下的多轮 agent—— 那就按 Q8 走，Q4 的风险有实测案例而且失败形态很糟（不可恢复）。 分界线不是架构，是**任务**。而这两项测量都没有覆盖对方的场景，所以谁也没资格替对方下结论。 ## 前提三：采样参数按官方卡走 [Qwen 官方模型卡](https://huggingface.co/Qwen/Qwen3.8-27B)给了明确的推荐值，两种模式不一样： ```text 思考模式：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 框架下的得分： ![Qwen 官方的跨 harness 泛化对比图：同一个 Qwen3.8-Max 在 QwenWork、Claude Code、Codex、OpenClaw、Hermes 五个 harness 下，于 CoWorkBench、WorkspaceBench、JobBench 三个基准上的得分](/blog/images/local-qwen-preconditions-cross-harness.png "图 2 — 同一份权重，换个 harness 就是另一条分数线。以 JobBench 为例，Qwen3.8-Max 在五个 harness 下从 53.4 到 59.8，跨度 6.4 分。注意这里测的是 Qwen3.8-Max（2.4T 闭源 API 版），不是本文讨论的 27B 开源版——引用它是因为「同权重不同 harness」这个机制与模型规格无关。来源：[Qwen 官方博客](https://qwen.ai/blog?id=qwen3.8)。") 以 JobBench 那组为例，同一个模型在五个 harness 下从 53.4 分到 59.8 分，跨度 6.4 分。 这跟量化档、KV cache 都没关系——纯粹是外层框架怎么组织上下文、怎么处理工具调用带来的差异。 所以「runtime 是变量」这条前提其实有两层：**底层的推理运行时**（llama.cpp / vLLM / Ollama， 以及它们各自的 attention 实现），和**上层的 agent harness**。两层都会动结果，而两层都不在 模型名里。 ## 那速度呢：25 tok/s 是什么体感 另一篇掘金文章[「这个本地模型，让我 token 自由了」](https://juejin.cn/post/7676709710489419786) 给了具体数字，也给了这轮讨论里最诚实的一句话。把它和 AMD 官方在 Day 0 那天发的实测放在一起看： | 硬件 | 配置 | 速度 | 来源 | |---|---|---|---| | M5 Max 128GB | Ollama，4bit | 约 25 tok/s | 掘金作者自测 | | Ryzen AI Max+ 395（128GB，VGM 设 64GB） | llama.cpp + Vulkan，MTP=4，Q4_K_M | 最高 24 tok/s | [AMD 官方](https://www.amd.com/en/blogs/2026/run-qwen-3-8-27b-on-amd-ryzen-ai-max-and-radeon-graphics-cards-day-0.html) | | Radeon AI PRO R9700（Ryzen 9 9950X，64GB） | llama.cpp + Vulkan，MTP=2 | 最高 51 tok/s | 同上 | | RTX 5090 | 开 MTP | 90–120 tok/s | 掘金作者自测 | 这些数字**不能脱离硬件前提引用**。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 自由」的人自己划了边界——本地不是替代，是分流。 ## 等号在哪些任务上成立 所以回到开头那个等号。它不是真假问题，是范围问题。 | 任务类型 | 建议 | 理由 | |---|---|---| | 可等待的批处理 | ✓ 本地 | 25 tok/s 在无人值守时不是问题，省下的是真金白银 | | 代码不能出内网 | ✓ 本地 | 这是合规约束，速度是次要的 | | 探索性问答、草稿 | ✓ 本地 | 容错高，偶尔的偏差无所谓 | | 交互式编码 | ⚠ 看耐心 | 25 tok/s 等一个长回答是分钟级 | | 长推理任务 | ✗ 云端 | 上下文越长翻转率越高，且本地稳定性更差 | | 依赖工具调用的 agent | ✗ 云端 | 上面五个前提任何一条踩空，坏的都是工具调用 | 把这张表填完，比争论「本地能不能追平闭源」有用得多。两位掘金作者的做法都没问题——一个在讲 配置对的时候本地能干什么，另一个直接说了自己什么时候会打开云端。真正的坑在中间：**以为装完 就等于换了个模型，然后在工具调用上踩坑还不知道为什么。** 如果你想从路由层看同一件事——这些看不见的变量对模型选路意味着什么——今天英文刊有一篇 [Your quantization tier is a product spec](/blog/quantization-is-a-product-spec/)， 以及此前的[同一份权重，多种价格](/blog/one-weight-many-prices/)。 --- **修订说明（2026-08-24）**：前提二原本写作「KV cache 别量化到 4bit，Q4 不要碰」， 这是一刀切。补入 llama.cpp [issue #21385](https://github.com/ggml-org/llama.cpp/issues/21385) 的实测（混合架构上 q4_0 BLEU 1.000）后重写为按任务分档——并指出该实测与 Level1Techs 的工具调用结论在**同一架构类上相反**，差别在测量对象而非架构。原结论对 agent 场景仍成立， 但不该推广到文本生成场景。 --- ## Sources ### juejin.cn - [「本地跑一个 Qwen 3.8，你将拥有一个 Opus 4.6」](https://juejin.cn/post/7674574367976341567) - [「这个本地模型，让我 token 自由了」](https://juejin.cn/post/7676709710489419786) ### forum.level1techs.com - [「为什么你的本地 LLM 感觉比实际更笨」](https://forum.level1techs.com/t/why-your-local-llm-feels-dumber-than-it-is/253917) ### github.com - [issue #21385](https://github.com/ggml-org/llama.cpp/issues/21385) ### huggingface.co - [Qwen 官方模型卡](https://huggingface.co/Qwen/Qwen3.8-27B) ### qwen.ai - [Qwen 官方博客](https://qwen.ai/blog?id=qwen3.8) ### amd.com - [AMD 官方](https://www.amd.com/en/blogs/2026/run-qwen-3-8-27b-on-amd-ryzen-ai-max-and-radeon-graphics-cards-day-0.html)