周五发布的 Qwen 3.8 27B，是阿里巴巴 Qwen 研究实验室推出的一款开放权重视觉语言模型，采用 Apache 2.0 许可证，拥有约 270 亿参数。

我一直期待这个模型，原因很简单：27B 这个规模足够强大，又适合在配置合理的笔记本电脑和桌面工作站上运行。它的前代 Qwen 3.6 27B 已经有不错的表现，而 Qwen 官方公布的初步基准结果显示，新模型相较于 Qwen 3.6 27B，以及此前一度处于 Qwen 系列顶尖位置的闭源 Qwen 3.7-Plus，都有明显提升。接下来，独立基准测试会进一步验证这些提升的幅度。

不过，Qwen 3.8 27B 有一个非常突出的使用问题：默认推理强度过高。它经常为一个简单任务展开长时间、复杂而且完全没有必要的思考。

我的测试环境

我在两台机器上运行了这个模型：

• 128GB 内存的 M5 Max MacBook Pro；
• NVIDIA DGX Spark。

两台机器都使用 LM Studio 和约 17GB 的 Q4_K_M 量化版本。我还在 Spark 上直接使用 llama-server 做了额外测试。

下文的响应时间和生成速度均来自这些本地测试，实际结果会受到量化版本、推理后端、上下文长度和硬件负载影响。

结论先说：这是一个能力非常全面的本地模型，能够处理视觉任务、工具调用、代码生成和编码智能体工作流。但如果直接沿用默认的 xhigh 推理级别，它会慢到让人怀疑自己是不是把一个简单问题交给了一个过于认真的委员会。

默认 xhigh：简单任务也会被反复推演

Qwen 文档将模型的默认推理强度设为 xhigh，LM Studio 中的 GGUF 版本也保留了这一默认设置。官方支持通过 reasoning_effort 调整推理深度：

推理级别	适用场景
xhigh	复杂问题、需要深入分析的任务；默认值
medium	准确性、速度和成本之间的平衡
low	对速度和成本更敏感的常规任务

从实际使用看，xhigh 并不是一个适合所有任务的默认值，尤其是在消费级硬件上。它会显著增加推理 Token 数、响应时间和上下文占用，却不一定带来相称的结果提升。

8,192 个 Token 的上下文很快就会被耗尽

我很快遇到了 LM Studio 默认 8,192 Token 上下文窗口的问题：Qwen 3.8 27B 甚至会在处理普通问题时耗尽整个上下文。

将上下文长度提高到模型支持的 262,144 Token 后，这个问题消失了。需要注意的是，更大的上下文窗口并不能解决过度思考本身，只是避免模型因为推理过程太长而过早撞上上下文上限。

鹈鹕骑自行车：结果很好，但不值得等 21 分钟

我给模型的第一个复杂提示词，是让它生成一幅“鹈鹕骑自行车”的 SVG。结果相当漂亮：

• 自行车车架形状正确；
• 鹈鹕两侧都有腿，这在图像生成和 SVG 生成中并不常见；
• 鹈鹕喉囊的形状清晰；
• 鹈鹕的翅膀伸到了车把；
• 运动线条出现在车后方，而不是车前方；
• 背景包含太阳、云朵、山丘、花朵和草地，整体构图很克制。

但这次生成花了 21 分钟，使用了 22,276 个推理 Token，最后只产出 3,223 个输出 Token。

这可能是我在本地运行的模型中生成效果最好的一幅鹈鹕 SVG，但答案仍然是：不值得等 21 分钟。

关闭推理功能后，模型只花了 137 秒，输出 3,715 个 Token。结果质量有所下降：

• 自行车车架形状变差；
• 鹈鹕仍然可识别，但喉囊不够明显；
• 脚没有踩到踏板；
• 没有尝试抓住车把。

这个对比说明，推理确实能帮助模型处理复杂的空间关系和细节约束。但对于大多数日常任务来说，默认 xhigh 的代价太高。

作为额外对照，我还通过 OpenRouter 运行了更大的 Qwen 3.8 2.4T-A95B。它生成了一段效果漂亮的动画 SVG，说明更大规模的模型在这类视觉创作任务上仍然具有明显优势；但这并不改变 27B 版本“可以在本地运行”的实际价值。

“画一个圆形的 SVG”也能变成设计项目

为了确认过度思考到底有多严重，我又给了模型一个极其简单的提示词：

画一个圆形的 SVG

模型的推理过程大致是这样的：它先判断用户真正想要的不是一个简单的 <circle>，而是一件“精心打磨的作品”，然后开始规划：

• 同心参考圆和几何刻度；
• 渐变填充；
• 旋转的虚线圆环；
• 脉动光晕；
• 纸张、墨水和包豪斯风格的配色；
• 是否需要尊重 prefers-reduced-motion；
• 是否用 SMIL 或内嵌 CSS 实现动画。

几分钟后，它确实生成了一个漂亮的动画圆，但这完全不是用户要求的东西。

这是 Qwen 3.8 27B 默认行为的缩影：它很擅长把任务做得“完整”，却不一定擅长判断什么时候应该保持简单。

视觉能力：它非常擅长绘制目标边界框

测试视觉模型的一个实用方法，是要求它识别照片中的目标，并以固定坐标格式返回边界框。

我使用了一张包含多只鸟的照片，让模型找出其中的鹈鹕，并把坐标归一化到 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"}
]

边界框与照片中的两只鹈鹕匹配得非常好。对需要目标检测结果、图像标注或视觉问答的本地应用来说，这种坐标输出能力相当有用。

它甚至能独立构建边界框标注工具

我把上面的 JSON 结果交给 Qwen 3.8 27B，让它生成一个可以离线运行的 HTML 工具。提示词要求工具具备以下功能：

1. 提供一个图片 URL 输入框；
2. 提供一个用于粘贴检测结果 JSON 的文本区域；
3. 读取图片的实际宽高；
4. 将 0 到 1000 的归一化坐标换算成像素坐标；
5. 在图片上绘制带标签的边界框。

模型仅凭这一条提示词，就生成了一个完整的深色主题界面，并实现了图片加载、坐标换算、边界框渲染和标签显示等功能。

问题在于，它又一次过度设计了需求。因为示例 JSON 的标签里出现了 pelicans，它自行添加了一个“加载示例”功能，并在 Canvas 上绘制一幅带有夕阳、湖面和两只鹈鹕剪影的演示场景。这个功能没有被要求，但模型认为用户可能需要它来测试工具。

这个例子很有代表性：xhigh 能让模型主动补齐大量细节，但也会让它越过需求边界。

关闭推理后，边界框反而没有一次成功

为了对比，我关闭推理功能后重新生成同一个工具。结果界面仍然像样，但边界框位置不正确，无法准确覆盖照片中的鹈鹕。

这说明推理并不是毫无价值。对于坐标换算、图像尺寸和前端 Canvas 渲染这类需要多步推导的任务，额外推理确实能提高一次成功率。更合理的做法不是永久关闭推理，而是根据任务复杂度调整推理级别：

• 简单绘图和格式转换：low，甚至关闭推理；
• 多步骤视觉处理和工具构建：medium；
• 复杂代码调试或需要严谨规划的任务：视情况使用 xhigh。

编码智能体：本地运行也足够有用

本地模型能否驱动编码智能体，关键不只是代码生成质量，还包括：

• 足够长的上下文；
• 稳定的工具调用；
• 能够持续完成“思考—执行—检查—修改”的循环。

从纸面条件看，Qwen 3.8 27B 同时具备这些能力。我的 Pi 初步测试也很有前景。之所以选择 Pi，是因为它的系统提示词比多数编码智能体更短，更适合小型本地模型。

配置 Pi 使用本地 Qwen 服务

下面是配置思路。示例中的地址和密钥均为占位符，实际使用时应替换为受控的服务地址，并通过密钥管理机制注入凭据：

{
  "providers": {
    "local-qwen": {
      "baseUrl": "https://YOUR_LM_STUDIO_ENDPOINT/v1",
      "api": "openai-responses",
      "apiKey": "INJECTED_API_KEY",
      "models": [
        {
          "id": "qwen3.8-27b",
          "reasoning": true
        }
      ]
    }
  }
}

然后在项目目录中运行：

pi --provider local-qwen --model qwen3.8-27b

我让它回答“认证是如何工作的？”。经过多轮推理和工具调用，它读取了多个文件，最后给出了一份质量相当扎实的回答。

接着，我让它编写 Python 程序，把 Pi 保存的 JSONL 对话记录转换成 Markdown：

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

它生成并测试了 pi_jsonl_to_md.py，结果完全满足需求。这说明 Qwen 3.8 27B 不只是能写一段孤立的代码，也能在一个真实的编码智能体循环中完成任务。

速度是它成为日常主力工具的最大障碍

到目前为止，Qwen 3.8 27B 的能力表现令人兴奋：一个约 17GB 的模型文件，就能在高端消费级硬件上完成视觉识别、图像标注、代码生成、工具调用和智能体工作流。

但它确实偏慢，尤其是在 xhigh 推理级别下。即使关闭过度推理，它也谈不上敏捷。

我在 LM Studio 中测得的生成速度大约为每秒 15 到 30 个 Token。这个速度并不差，但已经慢到很难替代响应更快的托管 API 模型。作为参考，Artificial Analysis 的数据中，OpenAI 5.6 Sol 约为每秒 74 个 Token，5.6 Luna 则达到每秒 184 个 Token。

MTP 为本地推理带来明显加速

好消息是，社区已经开始寻找更快运行 Qwen 3.8 27B 的方法。其中一个很有潜力的方向是模型原生支持的多 Token 预测（Multi-Token Prediction，MTP）。

MTP 使用一个更轻量的机制提前猜测多个 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 中进行的对比基准测试显示，启用 --spec-type draft-mtp 的服务，比 LM Studio 默认 GGUF 配置的性能高出约 72%。

这很可能只是开始。随着模型发布后的适配工作继续推进，llama.cpp、MLX 以及其他本地推理框架还会出现更多优化方案。

使用建议：不要把 xhigh 当成万能默认值

基于这些测试，我更推荐采用分级策略：

任务类型	建议推理级别	原因
简单问答、摘要、格式转换	low 或关闭	避免无意义的长推理
普通代码生成、视觉问答	medium	在质量和速度之间取得平衡
多步骤调试、复杂规划、智能体循环	high 或 xhigh	复杂任务更可能从额外推理中受益
需要严格控制响应时间的服务	low 或 medium	限制延迟和 Token 消耗

同时建议：

• 将上下文窗口设置得足够大，避免推理过程被 8,192 Token 的默认上限截断；
• 不要仅因为模型支持 262,144 Token，就在所有请求中盲目开启超长上下文；
• 对简单任务优先降低推理强度，而不是一味增加硬件；
• 在支持 MTP 的推理框架中启用草稿模型或 speculative decoding，并用实际基准验证收益；
• 对编码智能体保留一定推理预算，因为工具调用和多步修改通常确实需要额外规划。

最后的判断

一个约 17GB 的模型文件，如今已经能在家用机器上完成过去需要大型专有模型才能完成的工作：它拥有长上下文、有效的工具调用、强大的视觉能力和合格的代码生成能力，还能驱动编码智能体完成真实任务。

这件事本身就足够令人惊叹。仅仅一年前，类似的能力还可能需要昂贵的专有模型和数据中心级硬件；现在，一台配置不错的笔记本电脑就能运行一个相当有竞争力的开放权重模型。

Qwen 3.8 27B 当前最大的短板不是能力，而是速度。它在 M5 Max MacBook Pro 和 DGX Spark 上都显得偏慢，这也是稠密模型的典型问题：它们需要非常高的内存带宽才能充分发挥性能，而这两类机器在内存带宽上都不是最理想的平台。

因此，Qwen 3.8 27B 最重要的意义不只是基准分数，而是它展示了本地模型的可能性：一个 17GB 左右的文件，就能容纳一个真正通用、具备视觉和工具能力的模型。随着推理强度控制、MTP 和其他推理优化逐渐成熟，它距离成为日常主力工具还会更近一步。

一句话总结：Qwen 3.8 27B 值得用，但请先把默认的 xhigh 调低。