Simon Willison 9小时前 · 2026-08-18 07:57:43 · 2 阅读

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

Qwen 3.8 27B 表现优异，但默认设置会导致过度思考 2026年8月16日周五发布的大作是阿里巴巴 Qwen 研究实验室推出的 Qwen 3.8 27B。这是一个基于 Apache 2 协议的 270 亿参数视觉模型。我一直在期待这款产品：27B 的参数量非常适合在配置合理的笔记本上运行，而且它的前作 Qwen 3.6 27B 也令人印象深刻。该模型的官方基准测试成绩相当亮眼。相比 Qwen 3.6 27B 以及今年 5 月发布的闭源强模型 Qwen 3.7-Plus，性能都有显著提升。我们很期待看到独立基准测试的结果。我在两台机器上测试了该模型：一台是 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 默认 8192 token 上下文限制的问题——Qwen 会在处理最普通的问题时就把上下文全部用光。我将模型加载到 262,144 的最大上下文长度后，这个问题就消失了。这是我第一次尝试使用更长上下文长度生成的 SVG：一只骑自行车的鸬鹚。它耗时 **21 分钟**，消耗了 22,276 个推理 token 才输出了 3,223 个 token。你可以在这里查看推理过程。 A very pleasing image of a pelican riding a bicycle. The bicycle is red and has the correct frame shape. The pelican looks like a pelican and has its wing extended to the handlebars.

A very pleasing image of a pelican riding a bicycle. The bicycle is red and has the correct frame shape. The pelican looks like a pelican and has its wing extended to the handlebars.

这是目前我在本地机器上运行模型能生成的最好的鸬鹚 SVG——而且这个 Qwen 模型其实很小，磁盘上只有 17GB。这个结果有很多值得称赞的地方：

自行车车架形状正确
车子两侧都有腿——这 **非常** 难得
鸬鹚的喉囊清晰可见
翅膀延伸到了车把上！
运动线在后面，而不是前面
背景设计得体——有漂亮的太阳、云朵、小山、花朵和草地。

这值得等 21 分钟吗？绝对不值得。这是关闭推理功能后运行同一提示词的结果——[查看转录记录](https://tools.simonwillison.net/markdown-svg-renderer#url=https%3A%2F%2Fgist.github.com%2Fsimonw%2F1265cfa8dce2f9ad5eb160792ff45a49)。这次输出了 **3,715 个 token**，耗时 137 秒——仅两分多钟。 The bicycle frame is a bad shape now. The pelican remains recognizable but has a less obvious pouch. The feet miss the pedal, there is no attempt to hold the handlebars.

The bicycle frame is a bad shape now. The pelican remains recognizable but has a less obvious pouch. The feet miss the pedal, there is no attempt to hold the handlebars.

为了完整性，我通过 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)：

Your browser does not support HTML5 video.

我说过 Qwen 在 xhigh 模式下容易想太多，但到底有多严重呢？我换了个更简单的提示词，依然使用默认的超高推理设置： ``` draw an svg of a circle ``` Qwen 的推理过程开头是这样的：用户要求画一个圆形的 SVG。请求很简单——但我想把它做得精雕细琢。不能只给个 `` 标签：我要一个自包含的 SVG 文件，带点“性格”——也许是一个几何“圆的研究”，带有微妙的动画、分层圆环和独特的配色方案。保持范围正确：他们要的是圆形的 SVG。所以核心是圆。但我可以增加工艺感：同心辅助圆（像圆规/几何绘图那样）、刻度线、主圆的柔和渐变填充、克制的环境运动（缓慢旋转的虚线环、脉冲发光）。尊重 prefers-reduced-motion？那是给 CSS 的；SVG SMIL 或 SVG 内的 CSS 都可以。调色板选项：深青色墨水配暖色纸张？还是大胆的朱砂圆配米白底色配海军蓝辅助线——包豪斯/圆规绘图的感觉。那就选“几何研究”风格：冷板岩背景，或者明亮的纸张白？如果不是奶油色和赤陶色组合，纸张白也可以。 [...] 几分钟后，它生成了这个**绝对漂亮**的动画圆，完全不是我要的！ Your browser does not support HTML5 video. 我的强烈建议：忽略那个默认设置。先用低推理甚至无推理模式运行 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"} ] ``` 这匹配得太好了。这是在照片上渲染的框： A photograph of two pelicans on a rocky outcrop, with three other smaller birds. The pelicans both have bounding boxes exactly surrounding them, each with a label that says pelican.

A photograph of two pelicans on a rocky outcrop, with three other smaller birds. The pelicans both have bounding boxes exactly surrounding them, each with a label that says pelican.

构建标注框的工具

这些框的可视化效果是使用一个新工具实现的，我让 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 中心。

（我有点担心，因为全球的模型可能都有一种倾向，就是一有机会就画鹈鹕，这大概是我自己那个愚蠢的基准测试让它们暴露了将近两年的结果。）这种过度思考有必要吗？也许有一点。我尝试关闭推理功能，得到了这个版本（[查看转录内容](https://gist.github.com/simonw/8e78b1c64d9a56d08eedb954aa9445ee)），它几乎能用，但框的位置不对： BBox Studio 截图 - 界面很扎实，但黄绿框没有覆盖住鹈鹕。

所以，没有推理功能它就没法一次性生成一个能用的工具。我确信通过后续提示词它能做到，但这很好地说明了推理功能能带来多大的差别。是的，它能驱动编码代理关于本地模型的一个最大疑问是，它们是否有足够的算力来成功运行编码代理循环。编码代理需要长上下文、强大的代码生成支持和可靠的工具调用。从纸面参数看，Qwen 3.8 27B 拥有这三项能力，那它能否胜任呢？我在 Pi 上的初步实验非常有前景。我选择 Pi 是因为它比大多数其他选项的系统提示词更短，更适合用来测试较小的模型。我通过在 ~/.pi/agent/models.json 中添加以下内容，将 Pi 配置为使用在 Spark 上通过 tailscale serve 共享的 LM Studio 里的 Qwen 3.8 27B：

{
  "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?

在经历了一系列推理和工具调用，访问了多个不同文件后，它输出了这个回复（[查看详情](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 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 tokens/秒，5.6 Luna 则令人印象深刻地达到了 184/秒。好消息是，自从两天前模型发布以来，社区一直在探索加速的方法。最令人期待的优化之一已经内置在模型本身。Qwen 支持 Multi-Token Prediction（多 token 预测），这是一种架构技巧，利用更廉价的机制提前猜测多个 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

果然，这给了我显著的提升。我让 GPT-5.6 Codex 在 Spark 和带 `--spec-type draft-mtp` 参数的服务器上运行了基准测试，结果显示前者比 LM Studio 默认的 GGUF 性能高出约 72%。我预计未来几周，围绕如何更快地部署该模型，会有大量创新涌现。MLX 社区可能也酝酿着一些技巧。

一些观察

一个 17GB 的文件能在我的家用机器上完成所有这些操作，简直是个奇迹。我再次为今年本地模型取得的巨大进步感到欣喜和惊叹。一年前，这还只能与最昂贵、最顶尖的专有模型一较高下；而今天，它已经可以在一台性能不错的笔记本电脑上运行了。阻碍它成为主力工具的唯一因素是性能。在 M5 Mac 和 DGX Spark 上，它的感觉都很慢。这就是这些密集型（非 MoE）模型的弊端——它们需要大量的内存带宽才能发挥良好性能，而我目前能访问的两台机器在这方面都不是顶尖水平。 Qwen 3.8 27B 最重要的是它所证明的：我们可以拥有一个开源权重、通用、长上下文、具备有效工具调用能力、强视觉能力以及胜任代码生成的模型，而且整个模型只需一个 17GB 的文件就能装下。这个规模的模型仍在以惊人的速度不断进步。我们不需要花费 50 万美元购买数据中心级硬件，仅仅是为了运行一个合格的大模型。

原始来源： Simon Willison

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

它在边界框方面表现极佳

构建标注框的工具

追求速度

一些观察

评论 (0)