周五的重磅发布是Qwen 3.8 27B，这是阿里巴巴通义千问实验室推出的、拥有 270 亿参数、具备视觉能力、采用 Apache 2.0 协议开源的大语言模型。我一直很期待它：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。

默认的 xhigh 导致了惊人的过度思考

Qwen 的文档称，该模型推理强度的默认值为xhigh，而我测试的 LM Studio GGUF 版本也保留了这一默认设置：

Qwen3.8 官方支持reasoning_effort，可用于调节推理深度、控制成本：

• xhigh（默认）：适用于需要深入分析的复杂任务
• medium：兼顾准确率与速度
• low：以速度和成本为优先的高效推理

这个默认值相当搞笑。这绝对不是运行该模型的正确方式，尤其是在消费级硬件上。不过我倒是觉得由此产生的结果非常有意思。

我很快就遇到了 LM Studio 默认 8192 token 上下文限制的问题——哪怕是最平淡无奇的问题，Qwen 也会把这些 token 全用在思考上。我把模型加载到完整的 262144 最大上下文长度后，问题才得以解决。

这是我在调大上下文后第一次尝试得到的鹈鹕骑自行车 SVG，花了21 分钟才生成，用了 22276 个推理 token 来产出 3223 个输出 token。你可以在这里查看推理过程。

这是迄今为止我用能在本地运行的模型生成过的最好的鹈鹕 SVG——而这个 Qwen 其实很小，磁盘上只有 17GB。它有很多可圈可点之处：

1. 自行车车架形状正确
2. 自行车两侧都有腿——那是非常罕见的
3. 鹈鹕的喉囊清晰好看
4. 翅膀延伸到了车把上！
5. 动态线条在后方，而不是前方
6. 背景很有品味——有漂亮的太阳、云朵、山丘、花草

为此等上 21 分钟值得吗？完全不值得。

这是同一个提示词在关闭推理后的结果——记录见此。它共生成了3715 个 token，耗时 137 秒——刚过两分钟。

为了完整起见，我还通过 OpenRouter 用大得多的 Qwen 3.8 2.4T-A95B（上周发布）跑了同一个提示词，得到了这个炫酷的动画 SVG：

我说过 Qwen 在 xhigh 模式下有过度思考的倾向，但到底有多严重呢？

我用那个默认的 xhigh 设置，试了一个简单得多的提示词：

draw an svg of a circle

Qwen 的思考过程是这样开头的：

用户想要一个圆形的 SVG 图。请求很简单——但我想把它做成一件精心打造的作品。不能只是画一个<circle>，我要做一个有格调的、单文件自包含的 SVG——或许是一个几何“圆形习作”，带上微妙的动画、分层圆环和独特的配色。

要把握好分寸：用户要的就是一个圆形的 SVG。所以核心是一个圆。但我可以加点工艺：同心辅助圆（像圆规/几何作图那样）、刻度标记、主圆上柔和的渐变填充、克制的环境动态（缓慢旋转的虚线环、脉冲光晕）。要不要考虑 prefers-reduced-motion？那更多是针对 CSS 的；用 SVG SMIL 或 SVG 内的 CSS 就行。

配色方案：暖色纸张上的深青色墨水？还是米白底色上醒目的朱红色圆，配海军蓝辅助线——包豪斯/圆规绘图风格。我还是走“几何习作”的路线吧：冷灰蓝背景，还是亮白纸张？只要不是奶油色加赤陶色的组合，亮白纸张也不错。[...]

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

我的强烈建议是：别管那个默认值。一开始就把 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'

这是思考过程，它最终给出了这样的结果：

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

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.

这张截图展示了一个我根本没要求的功能——一个演示场景，供你手头没有测试照片时使用：

以下是思考过程的相关片段，它仅仅因为我在提示词示例 JSON 里用了“pelicans”这个标签，就决定自己画几只鹈鹕：

还要做个“加载示例”来用一张已知图片？不能依赖外部图片，但……图片 URL 输入是由用户提供的；我可以加一个“试试示例”按钮 […] 嗯，我可以在 canvas 上画一个简单的场景，导出为 data URL，再加载到图片里——这样就是自包含、可演示的了！[…] 但用户的坐标是针对真实鹈鹕照片的；一个生成的占位图仍能演示缩放。生成一个 1000x1000 的占位图：渐变的水面 + 两个团块状的“鹈鹕”剪影，放在给定的 bbox 位置（用同样的比例——很可爱：剪影正好在 0-1000 的精确位置上，显示框是对齐的）。这样就能做出一个有趣、自包含的演示。保持简单：天空渐变、太阳、水面、两个鹈鹕状图形（椭圆身体、圆形头部、喙）。放在 bbox 中心。

（我有点担心，全世界的模型可能都会一有机会就画鹈鹕，这或许是被我这近两年来那个愚蠢的评测标准影响的。）

所有这些过度思考有必要吗？也许至少有一点必要。我试了关闭推理后的版本（这个版本，记录见此），它几乎能用，但框的位置不对：

所以，不带推理时它没能一次性做出可用的工具。我相信再给几个后续提示词也能做出来，但这很好地说明了推理能带来怎样的差别。

是的，它能驱动编程智能体

围绕本地模型最大的疑问之一，就是它们是否有足够的性能来成功跑通编程智能体的循环。编程智能体需要长上下文、强大的代码生成能力和可靠的工具调用。从纸面上看，Qwen 3.8 27B 三者兼备，那么它能胜任吗？

我用Pi做的初步实验非常有前景。我选择 Pi 是因为相比大多数其他方案，它的系统提示词更短，更适合拿来尝试小模型。

我在 Spark 上的 LM Studio 中运行 Qwen 3.8 27B（通过tailscale serve共享），并通过向~/.pi/agent/models.json添加以下内容来配置 Pi 使用它：

{
  "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 tokens/秒，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 的文件就能装下。

这个尺寸的模型正以惊人的速度持续变强。我们不再需要花上五十万美元购买数据中心级别的硬件，才能运行一个称职的模型。