Qwen3.8-27B本地部署实测：很好但别用默认设置，社区优化后潜力很大，可稍晚入手！

上一次，我们测试了 Qwen3.8-Max。测完之后，我最期待的其实是 27B 版本。现在，它终于来了。

从小编的角度看，在 DeepSeek 大幅调价的当下，27B 其实是目前最有性价比的端侧 Agent 模型。包括今天中午我们智能体交流群里也有人反馈本地部署的 27B 还挺好用的（使用的显卡是AMD 7900 XTX（24GB显存），在workbuddy上输出速度大概62tok/s）。

无论是个人还是小型团队，只要需要高强度使用 Agent，或对数据安全有很高要求，27B 这个尺寸的模型绝对是不二之选。

以下是原文内容。

上周五，Qwen3.8-27B^[3] 正式发布。这是阿里巴巴 Qwen 团队推出的一款 270 亿参数视觉语言模型，采用 Apache 2 许可证。

我等这款模型很久了。27B 的体量刚刚好，一台配置不错的笔记本电脑就能跑。它的前代 Qwen3.6-27B 已经相当出色，这一代自然更让人期待。

Qwen 自己公布的跑分非常亮眼：不仅超过 Qwen3.6-27B，也超过了闭源的 Qwen3.7-Plus。就在今年 5 月，Qwen3.7-Plus 还是 Qwen 全系列中最强的模型之一。当然，官方跑分只能作为参考，最终还得看后续的独立测试。

我在两台机器上跑了这款模型：一台是 128GB 内存的 M5 Max MacBook Pro，另一台是配备 128GB LPDDR5x 统一内存的 NVIDIA DGX Spark^[4]。两台机器都使用 LM Studio，加载同一个 17GB 的 Q4_K_M 量化版本^[5]。我还在 Spark 上直接试了 llama-server。

这里顺便算一下硬件成本。按照新加坡官网的价格，M5 Max MacBook Pro 14 英寸版 S起，英寸版5,999 起；升级到 128GB 内存后，再考虑屏幕尺寸和硬盘容量，整机大致会落在 S$7,000—9,000，约合人民币 4万—5万元。DGX Spark 的首发价为 3,999 美元，约合人民币 2.9万元。

默认推理开到最高，简单任务也会想个没完

Qwen 的文档写得很清楚：模型默认使用 xhigh 推理强度。我测试的 LM Studio GGUF 版本也沿用了这个设置：

Qwen3.8 正式支持 reasoning_effort，可用来调整推理深度和成本：

• xhigh（默认）：适合需要深入分析的复杂任务
• medium：兼顾准确率和速度
• low：优先考虑速度和成本

这个默认值实在有点好笑，尤其不适合消费级硬件。不过，它折腾出来的结果倒是很有娱乐效果。

我很快就碰到了 LM Studio 默认 8,192 token 的上下文上限。哪怕问题再简单，Qwen 也能把这些 token 全部用来思考。直到我把上下文长度拉到完整的 262,144，这个问题才算解决。

Overthinking 好像是 Qwen 3.8 的通病，小编上次测试在 ZCode 中调用也遇到没完没了思考的状况……

调大上下文后，我先让它画了一张鹈鹕骑自行车的 SVG。这一张图足足跑了 21 分钟：光推理就用了 22,276 个 token，最后又输出 3,223 个 token。完整的思考轨迹在这里^[6]。

这是我用本地模型画过的最好一只鹈鹕。更夸张的是，生成它的模型文件只有 17GB。这张图有不少细节做得很好：

1. 自行车车架的形状基本正确。
2. 鹈鹕的两条腿分别放在自行车两侧，这种情况非常少见。
3. 喉囊画得很清楚。
4. 翅膀一直伸到了车把上。
5. 动感线放在主体后方，没有挡住画面。
6. 背景也很舒服，太阳、云、山丘、花草都有。

但为这张图等上 21 分钟，显然不值。

我随后关掉推理，用同一条提示词又跑了一次（完整记录^[7]）。这次输出 3,715 个 token，只用了 137 秒，也就是两分多钟。

作为对照，我还通过 OpenRouter 测了体量大得多的 Qwen3.8-2.4T-A95B。同样一条提示词，这款上周刚发布的模型生成了一张很漂亮的动态 SVG^[8]：

xhigh 下的 Qwen 到底有多爱多想？我又给了它一条再简单不过的提示词，设置保持默认：

画一个圆的 SVG

结果，它一上来就想了这么多：

用户要求画一个圆的 SVG。任务很简单，但我希望它是一件经过认真设计的作品。不能只放一个 ，可以做成一个有个性的独立 SVG 文件，比如一幅“圆形研究”：加上细微动画、层叠圆环和独特配色。

用户要的是一个圆的 SVG，所以核心仍然是圆。但我可以增加一些设计，例如同心辅助圆（像圆规或几何制图）、刻度、主圆柔和的渐变填充，以及克制的环境动画（缓慢旋转的虚线环、脉动光晕）。要兼容 prefers-reduced-motion 吗？那更偏 CSS；在 SVG 中使用 SMIL 或内嵌 CSS 就可以。

配色可以选暖纸色上的深青墨色，也可以用米白底、朱红圆和海军蓝辅助线，营造包豪斯或圆规制图的感觉。我选“几何研究”风格：冷色石板背景还是明亮纸白？……

几分钟后，它交出了一幅非常漂亮的动态圆形——只是我根本没要求这些。

所以我的建议很直接：第一次用 Qwen3.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'

这是它的思考轨迹^[9]，最后返回了这组坐标：

[
  {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
  {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

结果非常准。把边界框叠到原图上，可以看到两只鹈鹕都被稳稳框住了：

顺手让它写了一个 bbox 工具

上面那张可视化图片，来自 Qwen3.8-27B 在我笔记本电脑上离线写的一个小工具。

我忘了调低推理强度，于是一个简单工具被它做成了大工程。不过只靠以下这一条提示词，它确实一次做出了完整界面^[10]：

[
  {"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，再加载到图片中。这样工具就能独立运行，也方便演示！……不过，用户给出的坐标对应真实的鹈鹕照片；生成的占位图仍然可以演示缩放。生成一个 1000×1000 的占位图：渐变水面，加上两个团块状的“鹈鹕”轮廓，位置使用示例中的边界框坐标。同一套 0—1000 坐标正好可以显示边界框对齐效果，还挺可爱。做得简单一些：天空渐变、太阳、水面，再放两个类似鹈鹕的形状，用椭圆表示身体、圆形表示头部、再加鸟嘴。放在边界框中心。

（我有点担心，全世界的模型可能都养成了逮到机会就画鹈鹕的习惯。过去快两年里，它们大概看了太多我这个愚蠢的基准测试。）

这些思考也不全是多余。我关闭推理后又跑了一次同样的提示词，得到了下面这个版本（完整记录^[11]）。界面看起来像模像样，但边界框的位置却错了：

关掉推理后，它没能一次写对。多追问几轮应该可以修好，但这个对比也说明，适量推理确实有用。

27B 模型也能带动 Coding Agent

本地模型能不能跑完整的 Coding Agent 循环，是很多人最关心的问题。要做到这一点，模型需要长上下文、扎实的代码能力，还得能稳定调用工具。参数表上，Qwen3.8-27B 三项都表现不错，接下来就看实战。

我用 Pi 做了几次初步测试，结果相当不错。之所以选 Pi，是因为它的系统提示词比大多数同类工具更短，对小模型更友好。

我先在 ~/.pi/agent/models.json 中加入下面的配置，让 Pi 连接 Spark 上由 LM Studio 运行的 Qwen3.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 和 Qwen3.8-27B 读取 ~/.pi/agent/sessions/--Users-simon-Dropbox-dev-datasette-- 中的 JSONL 会话文件，并输入：

编写 Python 代码，将这个 jsonl 转换成 markdown

它随后写出并测试了 pi_jsonl_to_md.py^[12]，功能完全符合要求。更有意思的是，我又用它刚写好的工具发布了这份完整会话记录^[13]。

能力够了，速度还差一点

测到这里，Qwen3.8-27B 已经很让人惊喜。一个大小 17GB 的模型，在高端消费级硬件上就能写代码、调用工具、标注图片，基本覆盖了我日常使用 LLM 的主要场景。

短板也很明显：慢。开启高强度推理后尤其慢，就算把推理关掉，响应速度也谈不上轻快。

LM Studio 的实测速度大约是每秒 15—30 个 token。这个成绩不算差，但和托管 API 一比，等待感就很明显。Artificial Analysis 记录的速度显示，OpenAI 5.6 Sol 可以达到每秒 74 个 token，5.6 Luna 更是达到每秒 184 个。

好在模型发布才两天，社区已经开始研究各种提速方法。

其中最有希望的一项优化，其实已经藏在模型里：Qwen 支持多 Token 预测（Multi-Token Prediction，MTP）^[14]。它会先用一个成本较低的机制猜出后面的多个 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 上跑了一组对比测试^[15]，启用 --spec-type draft-mtp 后，速度比 LM Studio 的默认 GGUF 提高了约 72%。

接下来几周，这款模型应该还会冒出更多加速方案。MLX 社区多半也不会缺席。

最后说几句

一个 17GB 大小的模型文件（Q4 量化版本），放在家里的机器上就能完成这些任务，依然让人觉得不可思议。本地模型今年进步得太快了。放在一年前，这样的能力足以和最强、最贵的闭源模型竞争；今天，一台性能不错的笔记本电脑就能把它跑起来。

它距离我的日常主力只差速度。无论在 M5 Mac 还是 DGX Spark 上，体感都偏慢。 这类稠密模型对内存带宽要求很高，而我手头的两台机器在这方面都称不上顶尖。

Qwen3.8-27B 最重要的意义，是证明了开放权重的通用模型也能同时拥有长上下文、可靠的工具调用、出色的视觉理解和实用的代码能力，而整个模型只占 17GB。

这个尺寸的模型还在飞快进步。想在本地运行一个真正能干活的模型，已经不需要先花 50 万美元买一套数据中心级硬件了。

小编还观察到，许多网友反馈：Qwen3.8-27B 不同量化版本之间的表现差异很大，这里只测试了 Q4 版本，有条件的同学可以自己试试 Q8 或全量，有惊喜！