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

2026年8月16日

周五的重磅发布是 Qwen 3.8 27B，这是阿里巴巴 Qwen 研究实验室推出的一款采用 Apache 2 许可、拥有 27B 参数、具备视觉能力的 LLM。我一直很期待这款模型：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 的文档将该模型的推理强度（reasoning_effort）默认值描述为 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 或 SVG 内的 CSS 也可以。
>
> 配色选项：暖纸上的深青色墨水？还是米白底加醒目的朱红圆形与海军蓝辅助线——包豪斯/圆规绘图风格。让我采用“几何研究”的外观：凉爽的石板色背景，还是明亮的纸白色？纸白色可以，只要不是奶油色加赤陶色的组合。[...]

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

我的强烈建议：忽略那个默认设置。一开始就用 low 甚至完全不启用推理级别来运行 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 的模型，可以在高端消费级硬件上运行，能够编写代码、驱动工具、标注图像，基本上能完成我用 LLM 来做实际工作所需的一切。

但有一个非常显著的障碍：它感觉很慢——尤其是当它开始过度思考时，即使没有过度思考，它也不算特别敏捷。

我从 LM Studio 获得大约每秒 15-30 个 token 的速度。这不算糟糕，但已经慢到难以让我放弃托管 API 模型，后者的返回结果要快得多。Artificial Analysis 追踪 token 速度，显示 OpenAI 5.6 Sol 为每秒 74 个 token，而 5.6 Luna 达到了令人印象深刻的每秒 184 个。

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

最有希望的优化之一已经内置于模型本身。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 的文件中。

这个尺寸的模型继续以惊人的速度变得更好。我们不需要花费五十万美元购买数据中心级别的硬件，就能运行一个能干的模型。