Qwen 3.8 27B 表现出色，但默认过度思考问题

Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things

二〇二六年八月十七日 · 英文原文

摘要

阿里巴巴Qwen研究实验室发布Qwen 3.8 27B，一款采用Apache 2许可、270亿参数的视觉语言模型。作者在128GB M5 Max MacBook Pro和NVIDIA DGX Spark上测试，发现默认“超高”推理强度导致严重过度思考，生成简单SVG需21分钟。关闭推理后速度提升至137秒。模型在边界框标注和编码代理任务中表现良好，支持多token预测（MTP），配合llama.cpp可提速约72%。

周五的重磅发布是 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 版本也保留了这一默认设置：Qwen 3.8 官方支持 reasoning_effort 参数，可用于调整推理深度并控制成本：

xhigh（默认）：适用于需要深入分析的复杂任务
medium：在准确性和速度之间取得平衡
low：针对速度和成本进行高效推理

这是一个滑稽的默认设置。它绝对不是运行该模型的好方式，尤其是在消费级硬件上。我发现结果非常有趣。我很快遇到了 LM Studio 默认上下文限制（8,192 tokens）的问题——Qwen 在思考即便是最平凡的问题时也会耗尽这些 token。我将模型加载为完整的 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 视频。

我说过 Qwen 在“超高”模式下倾向于过度思考，但实际情况到底有多糟？我尝试了一个更简单的提示，再次使用默认的“超高”设置：draw an svg of a circle。Qwen 的推理轨迹是这样开始的：

用户要求绘制一个圆形的 SVG。简单的请求——但我想让它成为一件精心制作的作品。让我做一些超越简单圆形的东西：一个独立的 SVG 文件，带有特色——也许是几何“圆形研究”，带有微妙的动画、分层圆环和独特的调色板。保持范围正确：他们要求一个圆形的 SVG。所以核心是一个圆。但我可以添加工艺：同心参考圆（像圆规/几何绘图）、刻度标记、主圆上的柔和渐变填充、克制的环境运动（缓慢旋转的虚线环、脉动光晕）。尊重 prefers-reduced-motion？那更多是 CSS 的事；SVG SMIL 或 SVG 内的 CSS 都可以。调色板选项：暖纸上的深青色墨水？或者米白背景上的醒目朱红色圆环搭配海军蓝构造线——包豪斯/圆规绘图风格。让我采用“几何研究”外观：凉爽的板岩背景，还是明亮的纸白？纸白没问题，只要不是奶油色和赤陶色的组合。[...]

几分钟后，它生成了这个绝对美丽的动画圆形，完全不是我要求的东西！

您的浏览器不支持 HTML5 视频。

我的强烈建议：忽略那个默认设置。首先在“低”甚至“无”推理级别下运行 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 输入是用户提供的；我可以添加一个“尝试示例”按钮 [...] 嗯，我可以在画布上绘制一个简单场景，将其导出为数据 URL，然后加载到图片中——这样既自包含又可演示！[...] 但用户的坐标是针对真实鹈鹕图片的；生成的占位图仍然可以演示缩放。生成一个 1000x1000 的占位图：渐变水面 + 两个放置在给定边界框处的模糊“鹈鹕”剪影（使用相同比例——可爱：剪影正好位于 0-1000 位置，显示框对齐）。这构成了一个有趣、自包含的演示。保持简单：天空渐变、太阳、水面、两个鹈鹕形状（椭圆身体、圆形头部、喙）。放置在边界框中心。

（我有点担心世界各地的模型可能会倾向于在任何可能的机会绘制鹈鹕，这源于近两年来接触我自己愚蠢的基准测试。）

所有这些过度思考都是必要的吗？也许至少有一点必要。我尝试关闭推理，得到了这个版本（此处为记录），它几乎可以工作，但框显示在错误的位置：

所以没有推理，它没能一次性生成一个可用的工具。我确信通过一些后续提示它可以做到，但这是一个很好的例子，说明推理可以产生不同。

是的，它可以驱动编码代理

围绕本地模型的最大问题之一是它们是否有足够的马力来成功运行编码代理循环。编码代理需要长上下文、强大的代码生成支持和可靠的工具调用。从纸面上看，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，并提示：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 个 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 的文件中。这个尺寸的模型继续以惊人的速度变得更好。我们不需要花费五十万美元购买数据中心级硬件来运行一个合格的模型。

标签：ai, generative-ai, local-llms, llms, qwen, pelican-riding-a-bicycle, llm-reasoning, llama-cpp, llm-release, coding-agents, lm-studio, ai-in-china, nvidia-spark, pi

译自 Simon Willison · 博客 · 录于二〇二六年八月十七日