← #806

Qwen 3.8 27B 很出色，但它默认会疯狂过度思考

查看原文 HN 讨论

文章摘要

Simon Willison 在 2026 年 8 月 16 日评测了阿里 Qwen 研究团队刚发布的 Qwen 3.8 27B——一个 Apache 2 许可、270 亿参数、带视觉能力的模型。他一直期待这个尺寸：27B 适合在配置合理的笔记本上跑，而前代 Qwen 3.6 27B 已经很不错。Qwen 自报的基准分数「令人瞠目」，同时超过了 Qwen 3.6 27B 和闭源权重的 Qwen 3.7-Plus（后者在同年 5 月还是 Qwen 全尺寸阵容中最强的模型之一）。

他的测试环境是两台机器：128GB 的 M5 Max MacBook Pro，以及一台 NVIDIA DGX Spark；两台都跑 LM Studio 和官方 17GB 的 Q4_K_M 量化版本，Spark 上还直接试了 llama-server。

核心吐槽：默认 xhigh 推理档位。 Qwen 的文档说这个模型支持 reasoning_effort 参数，档位有 xhigh（默认，用于需要彻底分析的复杂任务）、medium（精度与速度平衡）、low（优化速度和成本），而他用的 LM Studio GGUF 保留了 xhigh 这个默认值。Willison 直呼「这是个搞笑的默认值」，绝对不是跑这个模型的好方式，在消费级硬件上尤其如此。他先撞上 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。

为了量化「过度思考」有多离谱，他用默认 xhigh 试了一个极简提示词：「draw an svg of a circle（画一个圆的 SVG）」。模型的推理轨迹开头大意是：用户要一个圆的 SVG——请求很简单，但我想把它做成精心打造的作品；不只是一个 <circle>，而是一个自包含的、有个性的 SVG 文件，也许是一份几何「圆的研究」，带微妙动画、层叠的环和独特的配色；然后开始纠结要不要加同心辅助圆（像圆规／几何制图那样）、刻度线、主圆上的柔和渐变、克制的环境动效（缓慢旋转的虚线环、脉动的光晕），要不要考虑 prefers-reduced-motion，配色是深青墨水配暖色纸张、还是米白底上的醒目朱红加海军蓝构造线（包豪斯／圆规制图风）。几分钟后它产出了一个「绝对漂亮的动画圆」，而那完全不是他要的东西。他的强烈建议：忽略那个默认值，一开始就用 low 甚至关掉推理。

视觉能力：边界框非常好。 他让模型对一张照片里的鹈鹕返回边界框，用的是他过去发现效果好的 0-1000 归一化尺度提示（通过 llm -a <图片URL> -m lmstudio/qwen/qwen3.8-27b 加一句「Return JSON bounding boxes for the pelicans in this photo, 0-1000 scale for each dimension」）。模型返回了两个 bbox_2d 框，标签都是 pelicans，坐标分别是 [195, 290, 370, 780] 和 [445, 320, 675, 850]，渲染到原图上后「匹配得非常好」。

用来做这个可视化的工具本身也是他让 Qwen 3.8 27B 离线在笔记本上一次性生成的——他忘了调低思考档位，所以工具被「大幅过度工程化」了，但确实从单条提示词产出了完整界面：一个接受图片 URL 的输入框、一个接受上述 JSON 的 textarea，把图片加到页面上、测量宽高、把 bbox_2d 里 0-1000 的坐标按实际宽高缩放，然后渲染带标签的框。模型自己额外加了一个他没要求的功能：演示场景。思考轨迹里能看到它的推理过程——不能依赖外部图片，但可以在 canvas 上画一个简单场景导出为 data URL，自包含且可演示；生成一个 1000x1000 的占位图：渐变水面加两个 blob 状的「鹈鹕」剪影，恰好放在给定的 bbox 位置上（用同一套尺度，很可爱：剪影正好落在 0-1000 位置，显示框是对齐的）。Willison 加了句自嘲式的担忧：「我有点紧张，全世界的模型可能因为接触了将近两年我自己那个愚蠢的基准，而产生了一有机会就画鹈鹕的偏好。」他也承认这次过度思考可能确实有价值：关掉推理后生成的版本几乎能用，但框的位置画错了，说明推理确实能带来差别。

能驱动编码 agent。 他用 Pi 做测试，选它是因为 Pi 的系统提示词比大多数选择都短，更适合试小模型。配置方式是往 ~/.pi/agent/models.json 里加一个 provider，指向通过 tailscale serve 共享出来的 Spark 上的 LM Studio 端点（api 设为 openai-responses，模型 id qwen3.8-27b，reasoning: true），然后在 ~/dev/datasette 目录里跑 pi --provider spark --model qwen3.8-27b，问「how does auth work?」。经过一串推理和访问多个文件的工具调用后，它给出了「非常扎实」的回答。接着他想分享那份 transcript，于是把 Pi 指向 session 的 JSONL 文件，提示「Write Python code to convert this jsonl to markdown」，模型写并测试了一个 pi_jsonl_to_md.py，「完全满足我的需要」。

唯一的大问题是速度。 LM Studio 上他只拿到大约 15-30 tokens/秒——不算糟，但慢到很难把他从托管 API 模型那里挖走；作为对比，他引用 Artificial Analysis 的数据：OpenAI 5.6 Sol 是 74 tokens/秒，5.6 Luna 是 184/秒。好消息是社区在模型发布两天内就已经在找加速办法。最有希望的一项优化烘进了模型本身：Qwen 支持 Multi-Token Prediction（MTP），即用一个更便宜的机制预测几个 token，主模型再快速验证猜得对不对。根据 llama.cpp 作者 Georgi Gerganov 的一条推文，他在 Spark 上用 llama serve 配合 --spec-default --spec-type draft-mtp --reasoning-preserve（同时拉 Q4_K_M 主模型和 Q4_0 草稿模型）跑起来，并让 Codex 里的 GPT-5.6 做了对比基准：--spec-type draft-mtp 的服务端比 LM Studio 默认 GGUF 快约 72%。他预期未来几周会有更多推理加速创新，MLX 社区大概也在酝酿。

结论：一个 17GB 的文件能在家用机器上做到这些事「是个奇迹」。唯一拖后腿的是性能，而这是稠密（非 MoE）模型的通病——它们需要极高的内存带宽，而他手上这两台机器在这方面都不是顶级。他认为这个模型最重要的意义在于它证明了什么：一个开放权重的通用模型，可以同时具备长上下文、有效的工具调用、强视觉能力和称职的代码生成，而整个东西能塞进 17GB。「这个尺寸的模型在以令人印象深刻的速度持续变好。我们不需要花五十万美元买数据中心级硬件才能跑一个称职的模型。」

HN 评论精华

这条帖子拿到 800 分、约 385 个节点。讨论几乎全部围绕「过度思考」这一个点展开，且异常务实——大家不是在争论模型好不好，而是在交换具体的抑制手段：调 reasoning_effort、设 thinking budget 加打断消息、用 LoRA 砍思考 token，以及和另一个以极简思考著称的模型 Muse Glimmer 做对比。Simon Willison 本人在场，多次追加实测。

• andy99 指出稠密模型上过度思考的代价是速度：从 Qwen 35B-A3B 换到 27B 对他来说慢了 7-8 倍（他觉得理论上应该是 ~9 倍），这让他对无用的思考 token 耐心大减。他建议对比新的 Muse 30B——那个模型措辞极简、思考方式完全不同（没有那个招牌的「Wait,」），在他的实验里 token 效率高得多，以至于绝对的 tokens/秒都不太重要了。
• simonw 立刻照做，用完全相同的「生成边界框标注 HTML 工具」提示词跑了 Glimmer 30B 和 Qwen 3.8 27B：Qwen 用了 17,576 个推理 token，Glimmer 只用了 1,021 个。两个应用都能正确工作、都满足要求；Qwen 那个（用默认 xhigh）「被大幅过度工程化」，Glimmer 那个「难看但可用」，他会说是「稍微欠工程化了一点」。有个有意思的细节：Glimmer 版本处理其他域名的图片会因 CORS 报错失败，而加载图片并检测宽高本来不需要 CORS——原因是 Glimmer 多加了一行不必要的 img.crossOrigin = 'anonymous';，Qwen 版本则能正常处理同一个 URL。
• NitpickLawyer 做了并行对比，观察的是风格：他用「解释这个 repo」+「有什么安全问题」做 vibe check，两个模型都解释得不错，都接受了安全问题的提问，也都标出了几个故意留下的问题（硬编码 token、单一认证、无日志等）。他更喜欢 Glimmer 的风格——用语简洁得多、没有形容词、没有 Claude 式的软绵语言（「Images are written to…」「Tasks are stored in SQLite…」）；Qwen 则更华丽（「无界的图像处理／资源耗尽——preprocess() 在 VAE 编码前打开任何下载到的东西，没有大小／尺寸／格式校验……」「SQLite 当队列——这个规模下没问题，但……」「调试信息泄漏——异常被重新抛出为……」）。但两者标出的东西基本一致，只是排序和风格不同。「对一个我能在本地跑的东西来说，理解力相当惊人。」他的部署是 Qwen 用 fp8 加完整 KV 缓存、Glimmer 用 w4a16（fp8 权重不知为何起不来），都在 48GB VRAM 里跑满支持的上下文。lostmsu 唱反调说 Glimmer 比 3.6 27B 更笨，不能只比速度就下结论。bogzz 一句概括 Glimmer 的思考风格：「Why use many word when few do trick?」
• SwellJoe 提供了本场最触目的数字：他跑了一个此前用一批小模型做过的任务（一个 GitHub PR），Qwen 3.8 27B 完成得非常好，是所有可自托管模型里最好的——但在他的双 GPU 配置上花了 11 个小时。它反复检查、再检查，是他用过最慢的模型；GPT 5.5 做类似任务约 20 分钟，多数大模型约 1 小时，多数小模型两三小时（但做得更差）。他的配置是 Unsloth 的 8_K_XL 量化、双 Radeon V620、全默认无调优。后续更新很有价值：在 llama.cpp 里启用张量并行后他看到 25-33 t/s，把 reasoning effort 设为 medium 后同一任务从 11 小时降到三个多小时——仍是多数大模型（含 Opus 4.8）的三倍以上、最快的 GPT 5.5 的九倍，「还是不够快到让人舒服，但比第一次快多了。而且我猜，还是比我自己写代码快。」他对硬件的判断很明确：这个模型在当前 AMD 或 NVIDIA 的 128GB AI 机器上远不算可用，它们内存带宽不够，尤其因为它每个任务都要嚼掉那么多 token；要跑这个模型，正确做法是两块（或更多）带宽不错的 32GB GPU，64GB 就够装 8-bit 量化模型加完整上下文，它并不受益于 Strix Halo 的更大内存。他还顺带点评了一圈：MoE 模型更适合 Spark 和 Strix Halo，Nemotron 3.5 Lightning 的 MXFP4 量化在 Strix Halo 上飞快（65-80 t/s）「但它很笨」，而这些模型在编码上都弱于 Qwen 3.8 27B。他最后加了句时代注解：「现在是买硬件最糟的时候……当时真正聪明的钱是干脆用云模型，别管自托管。」
• bitexploder 给出了最被追问的工程方案：他在 35B-A3B 上就得修这个问题——写了一个代理，思考 token 到 2K 就掐断，注入一句类似「我们已经想得够多了，开始干活」的消息，之后它几乎总能完成这一轮。「它很少需要超过 2K 思考 token，如果真需要，总还有下一轮。」permalac 和 logicallee 都要求他分享代理和配置。不过 dofm 泼了盆冷水：在 xhigh 档位下它连要点概览都没列完就烧穿 2K token 了，「它真的很密集、很偏执，你可能需要十倍」；这个策略在 medium 档位更有用（那里它会陷入 Qwen 典型的循环），而在 low 档位他没见过循环。
• cyanydeez 指出 llama.cpp 里 --thinking-budget 和 --thinking-message 就够了：过度思考往往是一堆递归，所以停下来并重定向即可；构建 harness 的话可以按消息设置，从而动态监控思考轨迹的膨胀并重定向。他自己用那条消息告诉模型去用子 agent、加日志、以及用 opencode 的动态上下文剪枝，结尾自嘲式地加了句「我们就在这里悄悄说一句：skill issue」。dofm 反驳说 xhigh 下它是极端深度优先地钻兔子洞，你无论选在哪里掐断，都很可能它连提示词的一半都还没想到；它在 xhigh 下不明显循环，所以「过度思考守卫」代理没什么信号可依据，但它会强迫性地反复咀嚼边缘情况——他见过它因此把简单代码搞复杂。他的结论是：配置 reasoning effort 比设 thinking budget 更对，即使在 low 档它表现依然很好，medium 反而会像 3.6 那样卡循环；「xhigh 作为默认值是个荒唐的选择，同样荒唐的是没把 chat template 搞好以便 LM Studio 提供 reasoning effort 下拉框。」他后来还发现可以直接在提示词里写 “Reasoning level: low”，在他的 M1 Max 上跑 10-13 t/s，解题速度和 Qwen 35B 一样快，其中一个三步测试还快了 40 秒——「这非常引人注目。」
• CapsAdmin 贡献了唯一一条 LoRA 实测：他找到有人为 3.6 27B 做的 ThinkingCap LoRA（声称在保持输出质量的同时把思考 token 砍半），由于 3.6 和 3.8 架构相同，这个 LoRA 可以套用。用「create a fancy circle in html」对比 xhigh、medium、low、以及 xhigh + ThinkingCap：他判断纯 xhigh 比 xhigh+LoRA 稍好一点，但 LoRA 版本少了 40% 的思考 token，两者都倾向于添加未被明确要求的随机细节；medium 和 low 彼此接近但结果简单得多。他还跑了鹈鹕骑车测试的三档对比，token 数分别是 33,170 / 18,125 / 12,960，认为 scale 35 有点嘈杂不连贯而 30 比较好。他用一个 Python 脚本把答案渲染成 HTML 页并附上 llama-cli 日志、启动参数、聊天记录和脚本本身，「为了最大透明度」。
• fermuch 从原理上解释了档位差别：xhigh 是在告诉它过度思考并复查一切，low 是只做最少必要的思考；他建议给 medium（它不注入任何思考指令），并尽量给足上下文，理想是 50 万甚至 100 万 token，因为大而复杂的任务会频繁触发压缩，导致模型把同一件事反复重想。kennywinker 质疑上下文不是只有 256k 吗，SwellJoe 引模型卡回答：「原生 262,144，可扩展到 1,010,000 tokens」（支持 YaRN），但他的双 32GB 配置最多只能装约 256k，而且到 256k 会慢得离谱——「我觉得说服它少嚼多做才是对 Qwen 3.8 27B 的正解，不过我们大概需要一些基准来感受选择更低推理档位会损失多少智能。」
• dofm 在 simonw 的建议下第一次认真测了关掉推理，结论相当细致：结果看起来几乎和 Qwen 3.6 35B A3B 在中等思考模式下一样好，只是会稍微自我怀疑、答案更宽泛更思辨，还漏掉了他一个提示词里的细微之处。但他后来重看输出后自我修正：「我说 3.8 27B 的无思考输出那么好，是有点过于乐观了。我发现了几个细微错误，而 low 思考没有犯。它很好，但还没到 Qwen 3.6 35B 带思考的水平。」
• xscott 提供了一个绕过问题的低技术手法：设 {"reasoning_effort":"none"} 然后手把手牵着走——先让它「制定计划，但先别写代码」，拿到简短合理的计划后再说「现在按那个计划写代码，别的话都不要说」，就能在合理时间内拿到合理的代码。「也许这能用 Jinja 模板之类的修好，也许它只是对你的 harness 打个补丁，但它说明你可以让这个模型合理地推理。」adam_arthur 补充说把推理设为 none 后你能强制思考的粒度，它真的会遵守「最多三句」这类要求，而思考模式会覆盖提示词里的指令；这在大量流水线、图像识别等场景里效果很好。
• scotty79 给了个反向观点：花两三倍时间换最好的结果，代价不算大。hedgehog 泼冷水说公平一点，很多模型都有怪癖，「我从没找到过一次透明的模型替换」。bitexploder 也说句公道话：「跟小模型打交道是不同的游戏，电池不是全都随包附赠的。」
• 一支硬件小分支：LoganDark 希望 Apple 最终转向 HBM——统一内存是天赐之物，但低内存带宽实在是杀手，「尤其在 M5 上，可用算力在 ML 负载上开始严重饿死」。他提到有报道称 Apple 在考虑干脆跳过高端 M6 芯片，这可能给一年多后的高端 M7 留出时间用上 HBM；kennywinker 反问「是在考虑，还是因为硬件紧缺被迫考虑？」LoganDark：「谁在乎？只要高端 M7 带 HBM 出来并且真能和这个十年的 GPU 竞争，我就非常开心。我也希望笔记本上能有超过 128GB 的统一内存。」
• kamranjon 对那个「无思考版鹈鹕」很有好感：「希望看到更多，只花两分钟的话好得出人意料。」bellowsgulch 感叹 thinking budget 这类控制「真是个很酷的功能，希望云厂商也能暴露出来」。