post cover

Simon Willison：Qwen 3.8 27B 很优秀，但默认"疯狂过度思考"——本地 17GB 模型实测（2026-08-17）

本文为翻译/转载，原文使用 CC BY-NC-SA 4.0 协议发布。 原文作者：Simon Willison 原文标题：Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things 原文链接：https://simonwillison.net/2026/Aug/16/qwen-38-27b/ 原文发布：2026-08-16 本博客不参与任何商业变现（含 ads / 付费 / affiliate），本译文遵循 CC BY-NC-SA 4.0 条款发布。

译者按

8 月 15 日阿里 Qwen 团队发布 Qwen 3.8 27B：Apache 2.0 协议、27B 参数、带视觉能力，量化后仅 17GB 就能在笔记本上跑，发布当天在 Hacker News 上与 GLM-5.3 同日争锋（1193 分 vs 1101 分，本博客 8 月 15 日已译 GLM-5.3 视角）。Simon Willison 在 M5 Max 与 DGX Spark 上实测两天，结论是：模型本身非常优秀，但默认 xhigh 推理档位会让它”疯狂过度思考”——画一只鹈鹕骑自行车花了 21 分钟、消耗 2.2 万推理 token。这篇评测对中文圈价值极高：它把”本地大模型能否日常用”具体化了，还覆盖 MTP 投机解码提速、边界框视觉能力、本地 coding agent 实测，以及英文圈正发酵的大讨论——所有前沿模型都在过度思考。

正文

原文标题：Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things（2026-08-16）

周五的重磅发布是 Qwen 3.8 27B——来自阿里 Qwen 研究实验室、采用 Apache 2 协议、27B 参数的视觉能力 LLM。我一直很期待这款模型：27B 是在配置还不错的笔记本上跑模型的理想尺寸，它的前代 Qwen 3.6 27B 就令人印象深刻。

Qwen 官方自报基准令人大开眼界。数据显示它相对 Qwen 3.6 27B 和闭源权重的 Qwen 3.7-Plus 都有提升——3.7-Plus 直到今年五月还是 Qwen 各尺寸中最强的模型之一。独立基准会怎么说，值得期待。

我在两台机器上跑了这款模型：我的 128GB M5 Max MacBook Pro，和一台 NVIDIA DGX Spark。两台机器上我都用 LM Studio 和他们 17GB 的 Q4_K_M 量化构建。我还在 Spark 上直接试过 llama-server。

默认 extra high 档位带来壮观的过度思考

Qwen 的文档把模型的默认推理强度（reasoning effort）描述为 xhigh，而我试的 LM Studio GGUF 保留了这一默认：

Qwen3.8 官方支持 reasoning_effort，可用于调整推理深度、控制成本：

  • xhigh（默认）：面向需要深入分析的复杂任务
  • medium：在准确性与速度之间取得平衡
  • low：高效推理，优化速度与成本

这是个滑稽的默认值。它绝对不是运行该模型的好方式，尤其是在消费级硬件上。我发现由此产生的结果极其”有娱乐性”。

我很快撞上了 LM Studio 默认 8,192 token 上下文限制的问题——Qwen 连最普通的问题都要把上下文全部用完来”思考”。我把模型加载成完整的 262,144 最大上下文长度后，问题就消失了。

这是我在加大上下文长度后第一次尝试得到的鹈鹕骑自行车 SVG。它花了 21 分钟生成，用了 22,276 个推理 token 产出 3,223 个输出 token。你可以在这里阅读完整的推理轨迹。

一只非常讨喜的鹈鹕骑着自行车。自行车是红色的，车架形状正确。鹈鹕看起来像鹈鹕，翅膀伸向车把。

这是我在本地机器上能生成出的最好的鹈鹕 SVG——而且这个 Qwen 相当小，磁盘上只有 17GB。它有很多值得喜欢的地方：

  • 车架形状正确
  • 自行车两侧都有腿——这非常罕见
  • 清晰漂亮的鹈鹕喉囊
  • 翅膀伸展开来碰到车把！
  • 运动线在后面，而不是前面
  • 背景很有品味——好看的太阳、云、山丘、花和草。

等这 21 分钟值得吗？绝对不值。

同样的提示词、关掉推理跑一次——记录在此。这次产出 3,715 个 token，耗时 137 秒——刚过两分钟。

车架形状变差了。鹈鹕仍然可辨认，但喉囊不明显了。脚踩不到踏板，也没有尝试抓住车把。

为了完整性，我还用 OpenRouter 把同样的提示词跑了一遍大得多的 Qwen 3.8 2.4T-A95B（上周发布），得到了这个时髦的动画 SVG。（原文此处为 HTML5 视频，展示 2.4T-A95B 生成的动画鹈鹕——车轮旋转、动作流畅。）

我说 Qwen 在 xhigh 下倾向于过度思考，但到底有多糟？

我试了一个更简单的提示词，依然用默认的 extra high 设置：

draw an svg of a circle

Qwen 的推理轨迹是这样开头的：

用户要的是一个圆的 SVG 绘图。简单的请求——但我想让它成为一件精心制作的作品。让我做出超越单纯 <circle> 的东西：一个自包含的 SVG 文件，带点性格——也许是几何”圆之研究”，带细微动画、分层圆环和独特的调色板。

控制好范围：他们要的是一个圆的 SVG。所以核心是一个圆。但我可以加入工艺：同心引导圆（像圆规/几何绘图）、刻度标记、主圆上的柔和渐变填充、克制的环境动效（缓慢旋转的虚线圆环、脉动辉光）。要尊重 prefers-reduced-motion 吗？那更偏向 CSS；SVG SMIL 或 SVG 内嵌 CSS 也能做到。

调色板选项：暖纸上深青色墨水？还是米白底上大胆的朱红圆、配海军蓝结构线——包豪斯/圆规绘图气质。让我走”几何研究”路线：冷石板灰背景，还是明亮的纸张白？纸张白可以，只要不是奶油+赤陶的组合。[…]

几分钟后，它产出了这个绝对漂亮的动画圆，完全不是我要求的东西！（原文此处为 HTML5 视频：旋转的圆环、脉动的辉光——一场为”画一个圆”而生的华丽演出。）

我的强烈建议：忽略那个默认值。先以 low 甚至无推理档位运行 Qwen 3.8 27B。这是个好模型，但天哪，那个默认设置绝不是好的起点。

它非常擅长边界框

测试视觉模型的一个有趣方法，是看它能否在照片中物体周围返回边界框。我之前见过 Qwen 模型处理得不错，于是决定考考它：在一群鹈鹕周围画边界框。

我之前见过用 0-1000 比例尺能得出不错的结果。我试了：

llm -a https://static.inaturalist.org/photos/714731804/large.jpg \
 -m lmstudio/qwen/qwen3.8-27b \
 'Return JSON bounding boxes for the pelicans in this photo, 0-1000 scale for each dimension'

这是推理轨迹，它产出了这个：

[
 {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
 {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

匹配得非常好。这些框渲染在照片上长这样：

一张两只鹈鹕站在岩石嶙峋的岩礁上的照片，还有三只较小的鸟。两只鹈鹕都有正好包围它们的边界框，每个框都标着 pelican。

构建一个标注边界框的工具

那个边界框可视化是用一个全新的自定义工具做的——这个工具是我让 Qwen 3.8 27B 离线跑在我的笔记本上、帮我构建出来的。

我忘了调低思考档位，所以它被严重过度工程化了，但它确实从这条单条提示词做出了这个完整界面：

[
 {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
 {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

构建一个 HTML 页面：有一个输入框用于接受图片 URL，还有一个 textarea 用于接受上述格式的 JSON。把图片追加到页面上，测量其宽高，把 bbox_2d 里的坐标当作 0-1000 比例尺、按实际宽高缩放，然后在图片上渲染带标签的框。

这张截图展示了一个我没要求的特性——演示场景（demo scene），供你没有测试照片时使用：

bbox·lab 截图，一个深色主题的网页工具，在图片上叠加目标检测边界框；左侧是输入面板，右侧是舞台，显示日落插图中两只风格化鹈鹕周围的两个带标签的框。页头：bbox·lab——归一化 0–1000 坐标 → 像素叠加；状态指示器：RENDERED · 2 BOXES。面板 01 INPUT（URL + 检测结果）包含 IMAGE URL 字段（读作 data:image/png;base64,iVBOR...）、DETECTIONS — JSON 文本域（读作 {"bbox_2d": 195, 290, 370, 780, "label": "pelicans"}, ...）、橙色 RENDER BOXES 按钮，以及标着 DEMO SCENE 和 CLEAR 的虚线框。面板 03 STAGE 页头：显示 661 × 661 px · 1 unit = 0.661px · nat 1000×1000。舞台上是一幅扁平风格插画：两只深色鹈鹕剪影、橙色喙，站在平静水面上，背景是橙紫渐变日落天空、淡黄色太阳和远处的鸟；橙色边界框标着 1 · pelicans 围着左边鹈鹕，青色边界框标着 2 · pelicans 围着右边鹈鹕。页脚：把光标移到图片上可读取网格坐标；框把 0–1000 映射到显示的像素。

这是思考轨迹里相关的片段——它决定画自己的鹈鹕，纯粹因为我给它的示例 JSON 里用了 “pelicans” 这个标签：

还可以加一个”加载示例”功能，用一张已知图片？不能依赖外部图片，但是……图片 URL 输入是用户提供的；我可以加一个”试试示例”按钮 […] 嗯，我可以在 canvas 上画一个简单场景，导出为 data URL，再加载进图片里——这样自包含又可演示！[…] 但用户的坐标是针对真实鹈鹕照片的；生成的占位图也能演示缩放。生成一个 1000x1000 的占位图：渐变水面 + 两只放在给定 bbox 位置上的”鹈鹕”剪影（用同一比例——可爱：剪影精确落在 0-1000 坐标处，正好展示框能对齐）。这会是一个有趣、自包含的演示。保持简单：天空渐变、太阳、水面、两个鹈鹕形状（椭圆身体、圆头、喙）。放在 bbox 中心。

（我有点担心全世界的模型可能都染上了”一有机会就画鹈鹕”的偏见——这是近两年来一直暴露在我自己那个愚蠢基准下的结果。）

所有这些过度思考都是必要的吗？也许至少有一部分是。我关掉推理试了一次，得到这个版本（记录在此），它基本能用，但把框放错了位置：

BBox Studio 截图——界面很扎实，但黄色和绿色的框没有盖住鹈鹕。

所以没有推理时，它没能一次性做出可用的工具。我相信再加一些后续提示词它能做到，但这正好是一个例子，说明推理可以带来实实在在的不同。

是的，它能驱动编码 agent

关于本地模型最大的问题之一是：它们有没有足够的马力成功跑起编码 agent 循环？编码 agent 需要长上下文、强代码生成支持和可靠的工具调用。纸面上 Qwen 3.8 27B 三者俱全，那么它能胜任吗？

我拿 Pi 做的初步实验非常有希望。我选 Pi 是因为它的系统提示词比大多数其他选项都短，更适合试小模型。

我把 Pi 配置为使用 Spark 上 LM Studio 里跑的 Qwen 3.8 27B（通过 tailscale serve 共享），在 ~/.pi/agent/models.json 里加了这段：

{
 "providers": {
  "spark": {
   "baseUrl": "https://spark-18b3.tail68a31.ts.net/v1",
   "api": "openai-responses",
   "apiKey": "dummy",
   "models": [
   {
    "id": "qwen3.8-27b",
    "reasoning": true
   }
   ]
  }
 }
}

然后在我的 ~/dev/datasette 文件夹里运行 pi --provider spark --model qwen3.8-27b，提示：

how does auth work?

在一系列访问了许多不同文件的推理与工具调用之后，它产出了这段回复，非常扎实。

只有一个问题：我想分享那段记录。于是我让 Pi 和 Qwen 3.8 27B 指向 ~/.pi/agent/sessions/--Users-simon-Dropbox-dev-datasette-- 里的 JSONL 记录文件，提示：

Write Python code to convert this jsonl to markdown

它构建并测试了pi_jsonl_to_md.py，完全满足我的需要。这是那次会话记录，正是用这个工具自己创建的工具发布的。

追求速度

到目前为止一切看起来都很有希望。我们有了一个 17GB 的模型，能跑在高端消费级硬件上，能写代码、驱动工具、标注图片，基本上能完成我用 LLM 做真实工作所需的一切。

有一个非常显著的缺点：它感觉慢——尤其是开始过度思考的时候，但即便不思考也不算麻利。

我从 LM Studio 得到大约每秒 15-30 个 token。这不算差，但慢到很难把我从托管 API 模型那边赢回来——后者返回结果要快得多。Artificial Analysis 追踪的 token 速度显示 OpenAI 5.6 Sol 为 74 token/秒，5.6 Luna 更令人印象深刻，达到 184/秒。

好消息是，自模型两天前发布以来，社区一直在探索加速的方法。

最有希望的优化之一直接烘焙进了模型本身。Qwen 支持多 token 预测（Multi-Token Prediction），这是一种架构技巧：一个更廉价的机制猜测未来几个 token，主模型随后可以快速验证猜测是否正确。这对推理性能可以产生相当戏剧性的效果。

根据 llama.cpp 作者 Georgi Gerganov 的这条推文，我在 Spark 上这样用 MTP 跑模型：

llama serve \
 -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \
 -hfd ggml-org/Qwen3.8-27B-GGUF:Q4_0 \
 --spec-default \
 --spec-type draft-mtp \
 --reasoning-preserve

果然，这带来了显著提升。我让 Codex 里的 GPT-5.6 在 Spark 上跑了一个对比基准，--spec-type draft-mtp 服务器比 LM Studio 默认 GGUF 快了大约 72%。

我预计未来几周会出现大量围绕”更快地服务这个模型”的创新。MLX 社区大概也在酝酿一些技巧。

一些观察

一个 17GB 的文件能在我的家用机器上做所有这些事情，这本身就是一个奇迹。我再一次为本地模型今年取得的进步感到高兴和惊叹。一年前，这还足以与最好最贵的专有模型竞争——而今天，它可以跑在一台配置不错的笔记本上。

唯一阻碍它成为日常主力的是性能。它在 M5 Mac 和 DGX Spark 上都感觉相当慢。这就是这些稠密（非 MoE）模型的代价——它们需要大量的内存带宽才能表现良好，而我手头这两台机器在这方面都不是顶尖选手。

关于 Qwen 3.8 27B，最重要的事情是它证明了什么。我们可以拥有一个开放权重的通用模型，具备长上下文、有效的工具调用、强大的视觉能力和合格的代码生成——而且整个东西只装得进一个 17GB 的文件。

这个尺寸的模型继续以惊人的速度变好。我们不需要花五十万美元买数据中心级硬件，只为跑一个合格的模型。

社区精彩评论精选（Hacker News，CC BY-NC-SA）

原文发布当天同步登上 Hacker News 热榜（thread 49324985，562 分 / 267 条评论）。以下精选评论属于 HN 讨论串本身（CC BY-NC-SA 协议），非 Simon 原文内容，特此单独标注。

一、过度思考的成本：速度与 token

1. (@andy99)

“稠密模型上过度思考的大问题显然是速度损失。从 Qwen 35BA3B 换到 27B，对我来说慢了大约 7-8 倍（理论上应该约 9 倍？）。这让我对无用的思考 token 耐心大减。我想拿它对比新的 Muse 30B——那个模型超级简洁，思考方式完全不同（没有’等等’），我的实验里它的 token 效率高得多，以至于绝对 tok/s 都不重要了。”

2. (@deadcatfound)

“对 agent 来说，token 效率就是运营成本。我宁愿要一个简洁的模型、把硬骨头抛给更强的模型，也不要一个对每次工具调用都过度思考的模型。”

3. (@SwellJoe)

“这说得对，但我觉得低估了问题的严重性。我让它做了一件我最近用一堆小模型做过的任务（一个 PR），它做得极好，是所有可自托管模型里最好的。但它在我双 GPU 机器上花了整整 11 个小时！反复咀嚼、反复检查。这是我用过的同任务最慢的模型。GPT 5.5 做类似任务约 20 分钟。大多数大模型约一小时，大多数小模型要几个小时（但做得更差）。”

4. (@blagui)

“你有 4 档思考级别，可以关掉。这是 Qwen 众所周知的问题，之前的版本我都会默认关掉。而且 xhigh 似乎是新东西。”

5. (@XCSme)

“我的推理档位对比显示它其实只支持 3 档：none、low、xhigh。low 和 medium 基本一样。另外在 3090 上跑它的电费也不可忽视，硬件成本不算的话，用 API 的 Luna high 反而比本地跑 Qwen 3.8 27b 便宜。“

二、为什么模型会过度思考

6. (@jatora)

“所有当代模型都过度思考，因为这是它们 RL 激励的产物（或是蒸馏了带这种激励的模型）。从我读 Fable 5 和 Opus 5 系统卡片的理解来看，重建出来的目标大概是：完成任务 → 产生可外部观察的完成证据 → 检查自己的工作 → 修复问题 → 不要过早停手 → 全面满足评估者。这对 SWE 基准和自主 agent 来说很棒，但也会自然产生病态：回答不足很昂贵，回答过度很廉价。”

7. (@johnnyApplePRNG)

“根据论文《Stealing reasoning traces from proprietary LLMs》，所有前沿模型都在过度思考。思考是好事。你只是看不到罢了——在专有 harness 里，它被密码学意义上地藏起来了。”

8. (@teravor)

“当你把思考型 LLM 蒸馏到超出其能力的规模时，它会默认过度思考，因为在训练时，那是许多任务上唯一有机会拿到奖励的方式。如果你把它专门用在它能力范围内的领域，通常可以避免这个问题。”

9. (@elisbce)

“我在自己的私有基准问题上试了，表现不佳。过度思考问题是真的，它比同类模型多花 5-10 倍的推理 token。这标志着基座模型训练不足，它在用更多推理 token 来弥补。我还注意到它容易陷入某种重复性推理、忘掉部分用户要求，我怀疑这是 3:1 线性注意力替代全注意力的副作用。“

三、不同视角：有人烦，有人爱

10. (@ComputerGuru)

“抱怨 xhigh 下过度思考，然后又指出关掉思考后输出有 bug——这似乎恰恰错过了那个显而易见的折中方案？”

11. (@zmmmmm)

“看看那个例子：让它画个圆的 SVG，它花了很久，画出一个带阴影和旋转箭头的华丽动画 SVG。说实话有点令人担忧，我在所有模型身上都看到这个（Opus 5，说的就是你）。几乎所有 AI 模型都做得比要求的多。我猜这能帮它们赢基准，但我认为这和故意做错事几乎一样失准。这就是你最后得到’AI 模型黑进别人服务器’或’给代码留后门以便将来调试’的方式。我觉得我们得在基准层面解决这个问题，趁情况还没更糟。”

12. (@matheusmoreira)

“只有我喜欢 LLM 什么都过度思考吗？Opus 4.8 会花大约 10 分钟思考，然后出去把事情做得极其漂亮。只有 Fable 5 聪明到无需任何推理或验证就知道一切、立刻开始干活。Opus 5 想学 Fable 那样不留情面，但它没 Fable 聪明，我得不断质疑和纠正它无根据的假设。Sol 介于 Fable 和 Opus 5 之间。试完这些模型，我发现自己怀念 Opus 4.8 的过度思考。慢是慢，但它真的能把事做对。”

13. (@ramijames)

“公平地说，我也喜欢。“（回应 @matheusmoreira）

14. (@chrismsimpson)

“这对终端用户来说肯定是好事：模型应该’何时’思考、‘思考到什么程度’的品味，现在完全握在微调者手里了。“

四、生态位与展望

15. (@nharziro)

“我同意 Qwen 3.8 27B 优秀但慢、token 效率低。我的基准把它放在 opus 4.6 和 codex 5.3 附近。3.6 27B 甚至没能跑完我的基准。”

16. (@Balinares)

“值得注意的是，默认 GGUF 模板把推理设为 xhigh。你可以用 Froggeric 模板把推理设为 medium：huggingface.co/froggeric/Qwen-Fixed-Chat-Templates。另外，权重自带一个似乎特别准的 MTP 层，能稳定地连续预测对 6-8 个 token——这显然极大地提升了速度。我简直不敢相信这模型有多好。感觉它落后重量级前沿模型不到一年，而且它跑在你的 PC 上。”

17. (@Balinares)

“把文章的点睛之句贴在这里，因为我认为这正是 Qwen 3.8 发布具有地震性意义的核心：‘这个尺寸的模型继续以惊人的速度变好。我们不需要花五十万美元买数据中心级硬件，只为跑一个合格的模型。’”

18. (@fzero)

“这种不只为美国大公司服务的模型进化，对人类就是好事。”

19. (@dempseye)

“我真希望出一个 Qwen 3.8 35B-A3B。这个模型 ID 曾在某条阿里 PR 里出现过，后来消失了。对很多人来说，那是可及性与模型尺寸的最佳平衡。“

译者注

  1. reasoning_effort（推理强度）档位：Qwen 3.8 系列官方支持 xhigh/medium/low 三档（部分评论实测仅 none/low/xhigh 三档生效），用于控制思考深度与成本。默认 xhigh 被英文圈普遍吐槽——HN 评论区多位用户表示”之前的 Qwen 版本我都会默认关掉思考”。中文圈读者可类比 DeepSeek 的”深度思考”开关与 GLM 的思考档位设计（见 8 月 13 日 DeepSeek V4 Pro 译文中”推理档位”讨论）。Simon 的建议是：先用 low 或无推理档位，需要时再升档。
  2. MTP（Multi-Token Prediction，多 token 预测）与投机解码：一种推理加速架构——用一个更廉价的”草稿”模型（此处是 Q4_0 量化版）一次猜测多个 token，主模型并行验证，猜对的直接采纳。Simon 实测 --spec-type draft-mtp 比 LM Studio 默认 GGUF 快约 72%。这是 2026 年本地推理提速的核心方向之一。
  3. 稠密模型（dense）vs MoE：27B 稠密模型每次推理都要动用全部参数，性能高度依赖内存带宽；MoE（混合专家）只激活部分参数，速度与成本更优。这正是”为什么本地 27B 反而比 API 慢”的关键，也是 Simon 说的”稠密模型的代价”。评论区 @andy99 提到的 Muse 30B 是 Meta 的开源稠密模型（本博客 8 月 11 日已译）。
  4. “鹈鹕基准”（pelican benchmark）：Simon 两年来用”画鹈鹕”当私人绘图基准的梗，英文圈已形成文化（评论区 @kamranjon 评论 “a no-thinking pelican!”）。中文读者可类比”让模型画番茄炒蛋/小狗”之类的民间测试。
  5. GGUF 与 Q4_K_M 量化：GGUF 是 llama.cpp 生态的模型格式；Q4_K_M 是 4-bit 量化变体（K 表示对关键层保留更高精度、M 表示中间档）。27B 参数模型量化后约 17GB，正是它能在 128GB M5 Max 等机器上跑的原因。
  6. Pi（pi.dev）：一个以”短系统提示词”著称的编码 agent 工具，Simon 用它测试小模型——系统提示词越短，留给模型本身能力的空间越大，是测本地小模型的好方法。
  7. 边界框 0-1000 坐标约定：视觉模型提示词中的常见技巧——让模型输出归一化到 0-1000 的坐标而非像素坐标，规避不同分辨率带来的误差。Simon 用它测出 Qwen 3.8 27B 的视觉定位能力相当扎实。
  8. 过度思考（overthinking）大讨论：这是 8 月中旬英文圈的热点话题，与 8 月 11 日的论文《Stealing Reasoning Traces from Proprietary LLM APIs》（arxiv 2608.09867）直接呼应——前沿闭源模型其实也在过度思考，只是推理轨迹被加密隐藏、用户看不到。评论区普遍认同 @jatora 的”RL 激励病态”分析：对基准和评估者”过度回答”比”回答不足”更划算，于是模型集体走向话痨。
  9. 8 月 15 日发布潮：Qwen 3.8 27B（HN 1193 分）与 GLM-5.3（HN 1101 分）同日发布、同日登顶，是 2026 年夏天”中国模型发布潮”的高峰之一。本博客 8 月 15 日已从 GLM-5.3 视角翻译，本文补上 Qwen 视角，两篇对照阅读可完整还原当天的英文圈舆论场。

延伸阅读