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

周五的重磅发布是 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 连思考最普通的问题都会把 token 全部用完。我给模型加载了完整的 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.

这是迄今为止我用能在本地机器上运行的模型生成过的最好的鹈鹕 SVG——而且这个 Qwen 相当小，磁盘上只是一个 17GB 的文件。它有很多值得称道的地方：

自行车车架形状正确
自行车两侧都有腿——这非常罕见
好，清晰的鹈鹕喉囊
翅膀伸展开来碰到了车把！
运动线条在后方，而不是在前方
它有一个雅致的背景——漂亮的太阳、云朵、山丘、花朵和草地。

这值得等 21 分钟吗？绝对不值得。

这是关闭推理后运行同一个提示词的结果——。这一次生成了 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. 另外，为了完整性，我还用 OpenRouter 通过更大的 Qwen 3.8 2.4T-A95B（上周发布）运行了同一个提示词，得到了这个时髦的动画 SVG：

我说过 Qwen 在 xhigh 设置下倾向于过度思考，但实际情况到底有多严重？

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

draw an svg of a circle

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"}
]

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

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"}
]
Build an HTML page which has an input box for accepting the URL to an image and a textarea for accepting the above style of JSON.

It appends the image to the page, measures its width and height, then treats the coords in the bbox_2d as scaled from 0-1000 and scales them against the actual width and height, then it renders labelled boxes over the image.

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

$Screenshot of bbox·lab, a dark-themed web tool that overlays object-detection bounding boxes on an image, with an input panel on the left and a stage on the right showing two labeled boxes around stylized pelicans in a sunset illustration. Header: bbox·lab — normalized 0–1000 coords → pixel overlay; status indicator: RENDERED · 2 BOXES. Panel 01 INPUT (URL + detections) contains an IMAGE URL field reading data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA+, a DETECTIONS — JSON textarea reading {"bbox_2d": 195, 290, 370, 780, "label": "pelicans"}, {"bbox_2d": 445, 320, 675, 850, "label": "pelicans"} , an orange RENDER BOXES button, and dashed boxes labeled DEMO SCENE and CLEAR. Panel 03 STAGE header: display 661 × 661 px · 1 unit = 0.661px x 0.661px · nat 1000×1000. The stage shows a flat-style illustration of two dark pelican silhouettes with orange beaks standing in calm water against an orange-to-purple sunset sky with a pale yellow sun and distant birds; an orange bounding box labeled 1 · pelicans surrounds the left pelican and a cyan bounding box labeled 2 · pelicans surrounds the right pelican. Footer: move the cursor over the image to read grid coords; boxes map 0–1000 → displayed px.$

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

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

（我有点担心，全世界的模型可能都倾向于一有机会就画鹈鹕，这源于它们近两年来接触了我那个愚蠢的基准测试。）

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

BBox Studio screenshot - a solid UI but the yellow and green boxes do not cover the pelicans.

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

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

关于本地模型，最大的问题之一在于它们是否有足够的算力来成功运行编码智能体的循环流程。编码智能体需要长上下文、强大的代码生成支持以及可靠的工具调用能力。从纸面参数来看，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?

经过一系列推理和工具调用，访问了多个不同的文件后，它生成了这条回复，内容非常扎实。

只有一个问题：我想分享那段对话记录。于是我将 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 的模型，能在高端消费级硬件上运行，可以写代码、驱动工具、标注图像，基本上能完成我从大语言模型那里需要的所有实际工作。

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

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

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

其中最有前景的优化之一就内置于模型本身。Qwen 支持多 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

果不其然，这给我带来了显著的提升。我让 Codex 中的 GPT-5.6 在 Spark 上运行了一个对比基准测试，结果 --spec-type draft-mtp 服务器的性能比 LM Studio 默认的 GGUF 高出约 72%。

我预计在未来几周内，我们会看到更多围绕如何更快地服务该模型的创新。MLX 社区很可能也在酝酿一些技巧。

一些观察

一个 17GB 的文件就能在我家里的机器上完成所有这些事情，这简直是一个奇迹。我再次对本地模型今年取得的巨大进步感到欣喜和惊叹。一年前，这样的能力足以与最好、最昂贵的专有模型一较高下——而今天，它可以在性能不错的笔记本电脑上运行。

唯一阻碍它成为日常主力工具的是性能。它在 M5 Mac 和 DGX Spark 上都感觉相当慢。这就是这些稠密（非混合专家）模型的缺点——它们需要极大的内存带宽才能表现良好，而我能接触到的这两台机器在这方面都不是顶尖水平。

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

这个量级的模型仍在以惊人的速度持续进步。我们不必花费五十万美元购置数据中心级硬件，也能运行一个能力不俗的模型。