# Qwen 3.8 27B 表现出色，但默认推理强度过高导致过度思考

- 来源：Simon Willison 博客
- 发布时间：2026-08-17 06:00
- AIHOT 分数：73
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmswesk6a0r2hrovml2edcl2c
- 原文链接：https://simonwillison.net/2026/Aug/16/qwen-38-27b

## 精选理由

把 Qwen 3.8 27B 的推理档位成本量化成时间差异，xhigh 默认让生成同一 SVG 从 137 秒膨胀到 21 分钟，这个默认值比能力更影响本地选型。

## AI 摘要

阿里 Qwen 实验室发布 Apache 2 许可的 27B 参数视觉大模型 Qwen 3.8 27B，官方基准显示其超越前代 Qwen 3.6 27B 及闭源 Qwen 3.7-Plus。

## 正文

周五的重磅发布是 Qwen 3.8 27B，这是阿里巴巴 Qwen 研究实验室推出的一款采用 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。

默认的“超高”设置会导致极其夸张的过度思考

Qwen 的文档将该模型的推理强度描述为默认使用 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：

视频 · 前往原文观看

我说过 Qwen 在 xhigh 设置下容易过度思考，但到底有多严重？

我试了一个简单得多的提示词，同样使用默认的 extra high 设置：

画一个圆形的 SVG

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

用户要求画一个圆形的 SVG。请求很简单——但我想把它做成一件精心打磨的作品。让我做出一些超越单纯 `<circle>` 的东西：一个自包含的 SVG 文件，有性格——也许是一个几何"圆形研究"，带有微妙的动画、层叠的圆环和独特的配色。

控制好范围：他们要求的是圆形的 SVG。所以核心是一个圆。但我可以加入工艺感：同心参考圆（像圆规/几何绘图那样）、刻度标记、主圆上的柔和渐变填充、克制的环境动效（缓慢旋转的虚线圆环、脉动的光晕）。要不要尊重 prefers-reduced-motion？那更多是 CSS 的事；SVG 里的 SMIL 或内嵌 CSS 也能实现。

配色方案：暖纸上的深青色墨水？还是米白底上大胆的朱红圆加海军蓝辅助线——包豪斯/圆规绘图风格。我选"几何研究"的观感：冷石板灰背景，还是明亮的纸白？纸白可以，只要不是奶油色加赤陶色的组合。[……]

几分钟后，它生成了一个绝对漂亮的动画圆，但这完全不是我要求的东西！

视频 · 前往原文观看

我的强烈建议：忽略那个默认设置。先用低推理级别甚至关闭推理来跑 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"} ]

匹配得非常好。下面是将这些边界框叠加在照片上的效果：

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

那个边界框的可视化效果，是用我让 Qwen 3.8 27B 帮我构建的一个新自定义工具生成的，该工具在我笔记本电脑上离线运行。

我忘了调低思考强度，所以它被过度设计了，但它确实仅凭下面这一条提示词就生成了这个完整的界面：

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

构建一个 HTML 页面，其中包含一个用于输入图片 URL 的输入框，以及一个用于接收上述格式 JSON 的文本区域。

它会将图片附加到页面上，测量其宽度和高度，然后将 bbox_2d 中的坐标视为 0-1000 范围内的缩放值，并根据实际宽度和高度进行缩放，最后在图片上渲染带标签的边界框。

这张截图展示了一个我并未要求的功能——一个演示场景，方便你在没有现成照片测试工具时使用：

以下是推理轨迹中的相关片段，它决定自己绘制鹈鹕，纯粹是因为我在提示词中给出的示例 JSON 里使用了“pelicans”这个标签：

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

（我有点担心，世界各地的模型可能会因为将近两年来接触我自己那个愚蠢的基准测试，而产生一种一有机会就画鹈鹕的倾向。）

所有这些过度思考有必要吗？也许有必要，至少有一点。我尝试关闭推理功能，得到了这个版本，()，它几乎可以工作，但框体显示在了错误的位置：

所以没有推理功能时，它没能一次性生成一个可用的工具。我相信通过一些后续提示词它最终能做到，但这很好地说明了推理功能可以带来怎样的不同。

是的，它可以驱动编码智能体

关于本地模型，最大的问题之一是它们是否有足够的算力来成功运行编码智能体循环。编码智能体需要长上下文、强大的代码生成支持和可靠的工具调用。从纸面上看，Qwen 3.8 27B 具备这三者，那么它能胜任这项任务吗？

我对 Pi 的初步实验非常有前景。我选择 Pi 是因为它的系统提示词比大多数其他选项更短，更适合尝试较小的模型。

我通过将以下内容添加到 ~/.pi/agent/models.json，将 Pi 配置为使用在 Spark 上通过 LM Studio 运行的 Qwen 3.8 27B（通过 tailscale serve 共享）：

{ "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，并输入提示词：

认证是如何工作的？

经过一连串的推理和工具调用，访问了多个不同文件之后，它给出了这段回复，质量相当扎实。

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

编写 Python 代码，把这个 jsonl 转换成 markdown

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

对速度的追求

到目前为止，一切看起来都非常有前景。我们有一个 17GB 的模型，能在高端消费级硬件上运行，可以编写代码、驱动工具、标注图像，基本上能完成我从大语言模型那里需要的所有实际工作。

但有一个非常明显的缺点：它感觉有点慢——尤其是在它开始过度思考的时候，不过即使没有这种情况，它也不算特别敏捷。

我从 LM Studio 获得的速率大约在每秒 15-30 个 token。这不算糟糕，但已经慢到很难把我从托管 API 模型那边拉回来——那些模型返回结果的速度要快得多。Artificial Analysis 追踪 token 速度，显示 OpenAI 5.6 Sol 为每秒 74 个 token，而 5.6 Luna 则达到了令人印象深刻的每秒 184 个 token。

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

其中一个最有前景的优化方案已经内置于模型本身。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 上运行起来都感觉相当慢。这就是这类稠密（非混合专家）模型的短板——它们需要极高的内存带宽才能发挥良好性能，而我能用到的这两台机器在这方面都不是顶尖水平。

Qwen 3.8 27B 最重要的意义在于它所展示的可能性。我们可以在一个仅 17GB 的文件里，装下一个具备长上下文、有效工具调用、强大视觉能力和合格代码生成能力的开放权重通用模型。

这个体量的模型仍在以惊人的速度持续进步。我们不再需要花费五十万美元购买数据中心级硬件，才能运行一个像样的模型了。