Qwen 3.8 27B 表现优异，但默认启用过度推理模式

# Qwen 3.8 27B 表现卓越，但默认设置却倾向于过度思考 来源：https://simonwillison.net/2026/Aug/16/qwen-38-27b/ 2026年8月16日 星期五 上周五的重大发布是 **Qwen 3.8 27B** (https://huggingface.co/Qwen/Qwen3.8-27B)，这是来自阿里巴巴 Qwen 研究实验室的 Apache 2 许可证下的 27B 参数视觉能力大语言模型。我一直期待这个版本：27B 的规模非常适合在配置合理的笔记本电脑上运行模型，而且它的前代 **Qwen 3.6 27B** (https://simonwillison.net/2026/Apr/22/qwen36-27b/) 就令人印象深刻。Qwen 官方公布的该模型**基准测试结果** (https://huggingface.co/Qwen/Qwen3.8-27B#benchmark-results) 令人瞩目，显示其性能相比 Qwen 3.6 27B 和闭源权重的 Qwen 3.7-Plus 都有提升，后者在今年五月时还是 Qwen 各种规模模型中最强的之一 (https://qwen.ai/blog?id=qwen3.7-plus)。独立基准测试对此模型的评价将会很有趣。 我在这两台不同的机器上运行了该模型：我的 128GB M5 Max MacBook Pro 和一台 NVIDIA DGX Spark (https://simonwillison.net/2025/Oct/14/nvidia-dgx-spark/)。在这两台机器上，我都使用 LM Studio 和他们的 17GB Q4_K_M 量化版本 (https://lmstudio.ai/models/qwen3.8)。我也尝试过直接在 Spark 上使用 `llama-server`。Qwen 的文档将该模型描述为默认使用 `xhigh` 推理强度，我尝试的 LM Studio GGUF 版本保留了该默认设置： > Qwen3.8 官方支持 `reasoning_effort`，可用于调整推理深度并控制开销： > - `xhigh` (默认)：适用于需要深入分析的复杂任务 > - `medium`：平衡准确性与速度 > - `low`：高效推理，优化速度和成本 这是一个*令人啼笑皆非*的默认设置。这绝对不是一个好的运行方式，尤其是在消费级硬件上。我发现其结果极具娱乐性。我很快就遇到了 LM Studio 默认 8,192 token 上下文限制的问题——即使是处理最普通的问题，Qwen 也会把所有 token 都用在思考上。我加载模型时设置了完整的 262,144 最大上下文长度，问题就消失了。以下是我第一次使用增加后的上下文长度生成的 **鹈鹕骑自行车** (https://tools.simonwillison.net/markdown-svg-renderer#url=https%3A%2F%2Fgist.github.com%2Fsimonw%2Ffc909bea4fecf752c7bf9bad0e9dbf2a) SVG 图像。它花费了 **21 分钟**，使用了 22,276 个推理 token 才生成了 3,223 个输出 token。你可以查看这里的 [推理过程](https://tools.simonwillison.net/markdown-svg-renderer#url=https%3A%2F%2Fgist.github.com%2Fsimonw%2Ffc909bea4fecf752c7bf9bad0e9dbf2a)。这是一幅非常赏心悦目的鹈鹕骑自行车图像。自行车是红色的，车架形状正确。鹈鹕看起来像鹈鹕，并且它的翅膀伸到了车把上。这无疑是我在本地机器上运行的模型所能生成的最好的鹈鹕 SVG——而且这个 Qwen 模型相当小，磁盘上只有 17GB 文件。这有很多值得称赞的地方： 1. 自行车车架形状正确 2. 自行车两侧都有脚——这*非常*罕见 3. 良好、清晰的鹈鹕喉囊 4. 翅膀伸展触及车把！ 5. 运动线条在后面，而不是前面 6. 有雅致的背景——漂亮的太阳、云朵、山丘、花朵和草地。 这值得等待 21 分钟吗？绝对不值得。以下是使用相同提示词但关闭推理功能运行的结果——[转录在这里](https://tools.simonwillison.net/markdown-svg-renderer#url=https%3A%2F%2Fgist.github.com%2Fsimonw%2F1265cfa8dce2f9ad5eb160792ff45a49)。这个版本产生了 **3,715 个 token**，耗时 137 秒——刚超过两分钟。现在自行车车架形状很糟糕。鹈鹕仍然可识别，但喉囊不那么明显。脚没有踩到踏板，也没有尝试握住车把。最后，为了完整性，我通过 OpenRouter 用更大的 Qwen 3.8 2.4T-A95B（[上周发布](https://huggingface.co/Qwen/Qwen3.8-2.4T-A95B)）运行了相同的提示词，得到了这个[炫酷的动画 SVG](https://tools.simonwillison.net/markdown-svg-renderer#url=https%3A%2F%2Fgist.github.com%2Fsimonw%2F557016f0895b2abb4b9957caec781734)： （您的浏览器不支持 HTML5 视频。） 我说过 Qwen 在 xhigh 设置下有过度思考的倾向，但到底有多糟糕？我尝试了一个简单得多的提示词，同样使用默认的超高设置： > `画一个圆的 SVG` Qwen 的推理过程是这样的： > 用户要求绘制一个圆的 SVG。简单的请求——但我希望它是一件精心制作的作品。让我做点超越简单 ` ` 的东西：一个独立的 SVG 文件，具有特色——也许是几何的“圆形研究”，带有微妙的动画、分层圆环和独特的配色。把握好范围：他们要求的是一个圆的 SVG。所以核心是一个圆。但我可以添加技巧：同心引导圆（像指南针/几何绘图）、刻度标记、主圆上的柔和渐变填充、克制的环境运动（一个缓慢旋转的虚线圆环、脉动光晕）。需要遵守 prefers-reduced-motion 吗？那更多是 CSS 的事；SVG SMIL 或 SVG 中的 CSS 可以实现。配色选项：深青色墨水在温暖纸张上？还是大胆的朱红色圆圈在灰白色背景上配海军蓝结构线——包豪斯/指南针绘图风格。我选择“几何研究”外观：冷灰背景，还是明亮的纸张白色？只要不是奶油色和赤陶色的组合，纸张白色就可以。[……] 几分钟后，它生成了 [这个](https://tools.simonwillison.net/markdown-svg-renderer#url=https%3A%2F%2Fgist.github.com%2Fsimonw%2F6f9e48293be5c916652d29f0dc0b0657) *极其漂亮的*动画圆，但这完全不是我要求的！ （您的浏览器不支持 HTML5 视频。） 我强烈建议：忽略那个默认设置。一开始运行 Qwen 3.8 27B 时，使用 low 甚至关闭推理强度。这是一个很棒的模型，但哇，那个默认设置真是糟糕的起点。 #### 它在边界框检测方面表现出色 测试视觉模型的一个有趣方法是看它能多好地返回照片中物品的边界框。我之前见过 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' ``` 以下是[推理过程](https://gist.github.com/simonw/a05cc78b2061555bd61d3bb9686e689f)，产生了： ``` [ {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"}, {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"} ] ``` 这个匹配度*非常高*。以下是这些框渲染在照片上的效果： （一张两只鹈鹕在岩石露头上的照片，还有另外三只较小的鸟。鹈鹕的边界框精确地包围着它们，每个都有一个标签写着 pelican。） #### 构建一个标注边界框的工具 边界框的可视化是使用我让 Qwen 3.8 27B 为我构建的一个新定制工具完成的，该工具在我的笔记本电脑上离线运行。我忘了调低思考强度，所以它被*过度工程化*了，但它确实成功地仅凭这[单个提示词](https://gist.github.com/simonw/121ad098860028b2fab603fa12da1fd9)就生成了这个[完整的界面](https://static.simonwillison.net/static/2026/qwen-over-thinking-bbox.html)： > `` [ {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"}, {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"} ] `` `构建一个 HTML 页面，有一个输入框用于接受图片 URL，一个文本区域用于接受上述风格的 JSON。` `它将图片附加到页面上，测量其宽度和高度，然后将 bbox_2d 中的坐标视为按 0-1000 缩放，并根据实际宽度和高度进行缩放，然后在图片上渲染带标签的框。` 这张截图显示了我*并未要求*的一个功能——一个演示场景，用于当你没有照片来测试该工具时： （bbox·lab 截图 - 一个深色主题的 Web 工具，在图像上叠加目标检测边界框，左侧面板，右侧舞台显示两只风格化的鹈鹕周围的两个带标签框，背景是日落插图。标题：bbox·lab — 归一化 0-1000 坐标 → 像素叠加；状态指示：RENDERED · 2 BOXES。面板 01 INPUT (URL + detections) 包含一个 IMAGE URL 字段，内容为 data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA+, 一个 DETECTIONS — JSON 文本区域，内容为 {"bbox_2d": 195, 290, 370, 780, "label": "pelicans"}, {"bbox_2d": 445, 320, 675, 850, "label": "pelicans"} , 一个橙色的 RENDER BOXES 按钮，以及虚线框标签 DEMO SCENE 和 CLEAR。面板 03 STAGE 头部：显示 661 × 661 px · 1 单位 = 0.661px x 0.661px · 天然 1000×1000。舞台显示一幅平面风格插图，两只深色鹈鹕轮廓，橙色喙，站在平静水面上，背景是橙紫色日落天空，浅黄色太阳和远处的鸟；一个橙色边界框标注 1 · pelicans 围绕左边的鹈鹕，一个青色边界框标注 2 · pelicans 围绕右边的鹈鹕。页脚：将光标移到图片上以读取网格坐标；框将 0-1000 映射为显示像素。） 以下是相关的思考过程片段，它决定绘制自己的鹈鹕，仅仅因为我在提示词的示例 JSON 中使用了“pelicans”这个标签： > 另外一个“加载示例”功能，使用已知图片？不能依赖外部图片，但是... 图像 URL 输入是用户提供的；我可以添加一个“用示例试试”按钮[……] 嗯，我可以在画布上绘制一个简单的场景，将其导出为 data URL，然后加载到图片中——这是独立的且可演示的！[……] 但用户的坐标是针对真实的鹈鹕图片；生成的占位符仍然可以演示缩放。生成一个 1000x1000 的占位符：渐变水面 + 两个类似斑点的“鹈鹕”轮廓放置在给定的边界框处（使用相同的比例——可爱：轮廓正好在 0-1000 的位置，显示框是对其的）。这构成了一个有趣、独立的演示。保持简单：天空渐变、太阳、水、两个类似鹈鹕的形状（椭圆身体、圆形头部、喙）。放置在边界框中心。（我有点担心世界各地的模型可能会有在任何可能的机会都绘制鹈鹕的偏见，这是由近两年暴露在我自己愚蠢的基准测试中引起的。） 所有这些过度思考都是必要的吗？也许需要一点。我尝试关闭推理功能，得到了[这个版本](https://static.simonwillison.net/static/2026/qwen-no-thinking-bbox.html)（[转录在这里](https://gist.github.com/simonw/8e78b1c64d9a56d08eedb954aa9445ee)），它几乎可以工作，但框显示在错误的位置： （BBox Studio 截图 - 一个可靠的界面，但黄色和绿色的框没有覆盖鹈鹕。） 所以没有推理，它不能一次成功生成一个可用的工具。我确信经过一些后续提示可以做到，但这是一个很好的例子，说明推理能力可以产生影响。 #### 是的，它可以驱动编码智能体 关于本地模型的最大问题之一是它们是否有足够的算力来成功运行编码智能体循环。编码智能体需要长上下文、强大的代码生成支持和可靠的工具调用能力。从理论上讲，Qwen 3.8 27B 具备这三点，那么它能否胜任这项任务？我与 **Pi** (https://pi.dev/) 的初步实验非常有希望。我选择 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` 并提示： > `auth 是如何工作的？` 经过一系列推理和工具调用（访问了许多不同的文件），它产生了[这个回复](https://gist.github.com/simonw/6693d74a6bd45f641d43ceb9961dd95f#core-idea-actors--plugins-no-built-in-user-accounts)，非常可靠。只有一个问题：我想分享那个转录。所以我将 Pi 和 Qwen 3.8 27B 指向 `~/.pi/agent/sessions/--Users-simon-Dropbox-dev-datasette--` 中的 JSONL 转录文件并提示： > `编写 Python 代码将这个 jsonl 转换为 markdown` 它构建并测试了这个 `pi_jsonl_to_md.py` (https://github.com/simonw/tools/blob/main/python/pi_jsonl_to_md.py)，完全达到了我的要求。以下是使用它创建的工具发布的[会话转录](https://gist.github.com/simonw/491e55ac9d741202ea0af5d9d93775d4)。 #### 追求速度 到目前为止，这一切看起来*非常*有希望。我们有一个 17GB 的模型，可以在高端消费级硬件上运行，能够编写代码、驱动工具、标注图像，通常能完成我为完成实际工作需要从 LLM 中获得的一切。有一个非常显著的缺点：它感觉很慢——尤其是当它开始过度思考时，但即使没有过度思考，它也不算特别快。我通过 LM Studio 获得大约每秒 15-30 个 token 的速度。这不算太糟，但速度慢到很难让我放弃托管 API 模型，后者返回结果快得多。**Artificial Analysis** 跟踪 [token 速度](https://artificialanalysis.ai/models#speed)，显示 OpenAI 5.6 Sol 达到每秒 74 token，5.6 Luna 更是达到令人印象深刻的 184 token/秒。好消息是，自从模型两天前首次发布以来，社区一直在探索加速的方法。最有希望的优化之一就内置在模型本身中。Qwen 支持**多 token 预测** (https://sebastianraschka.com/llm-architecture-gallery/mtp/)，这是一种架构技巧，使用一个更便宜的机制提前猜测几个 token，然后主模型可以快速验证猜测是否正确。这对推理性能可能产生相当显著的影响。基于 `llama.cpp` 创作者 Georgi Gerganov 的[这条推文](https://twitter.com/ggerganov/status/2088340681701925253)，我尝试在 Spark 上这样运行模型： ``` 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 ``` 果然，这给了我显著的速度提升。我让 GPT-5.6 Codex 在 Spark 上运行了[比较基准测试](https://gist.github.com/simonw/b08c7eb9c126c806ba8987e269ea736b)，使用 `--spec-type draft-mtp` 的服务器性能比 LM Studio 默认的 GGUF 提高了大约 72%。我预计未来几周内，围绕更快地服务该模型会出现更多创新。MLX 社区可能也有一些技巧正在酝酿中。 #### 一些观察 一个 17GB 的文件能够在我的家用机器上完成所有这些工作，这是一个*奇迹*。我再次对本地模型今年取得的进步感到欣喜和惊讶。一年前，这还只能与最好、最贵的闭源模型竞争——今天它可以在一台性能良好的笔记本电脑上运行。阻碍它成为日常主力的唯一因素是性能。它在 M5 Mac 和 DGX Spark 上都感觉相当慢。这就是这些稠密（非混合专家）模型的缺点——它们需要大量的内存带宽才能表现出色，而我接触的两台机器在这方面都不是顶级。关于 Qwen 3.8 27B 最重要的一点是**它所证明的**。我们可以拥有一个开源权重的通用模型，具有长上下文、有效的工具调用、强大的视觉能力和胜任的代码生成能力。