Qwen 3.8 27B 实测：性能出色但默认过度思考

2026年8月16日

上周五，阿里云Qwen实验室发布了重磅模型Qwen 3.8 27B。这是一款采用Apache 2许可协议、拥有270亿参数的多模态大语言模型（LLM），支持视觉能力。我一直对它期待已久：270亿参数的规模非常适合在配置尚可的笔记本电脑上运行，而它的前代产品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默认8192上下文窗口的限制——哪怕是处理最普通的问题，Qwen都会把所有token耗尽在思考上。加载模型时我开启了其最大支持的262144上下文长度，这才解决了问题。

调高上下文长度后，我第一次尝试生成了鹈鹕骑自行车的SVG图。生成耗时21分钟，模型用22276个token进行推理，最终输出3223个token。你可以查看完整推理过程。

这是我用本地运行的模型生成过的最棒的鹈鹕SVG——而这款Qwen模型体积很小，磁盘上仅占17GB空间。它的优点数不胜数：

• 自行车车架造型准确
• 自行车两侧都有支撑腿，这在生成图中极为罕见
• 鹈鹕的喉囊清晰可见
• 翅膀自然搭在车把上
• 运动线条在后方而非前方
• 背景设计雅致：有太阳、云朵、小山、花草

但花21分钟等这个结果值得吗？完全不值得。

我关闭推理模式后重新运行了同一个提示词，对话记录见此。这次生成了3715个token，耗时仅137秒——刚过两分钟。

为了全面对比，我还通过OpenRouter用更大的Qwen 3.8 2.4T-A95B（上周发布）运行了同一个提示词，得到了一个精致的动态SVG。

我说Qwen在超高推理模式下会过度思考，但到底有多夸张？

我用一个简单得多的提示词测试了默认超高设置： 画一个圆形的SVG

Qwen的推理过程是这样开始的： 用户需要一个圆形的SVG，看似简单，但我要做出精心打磨的作品。不能只输出<circle>标签，要做一个有特色的独立SVG文件——比如一个几何风格的"圆形研究"，加入微妙动画、多层圆环和独特配色。核心必须是圆形，但可以增添细节：同心圆辅助线（像圆规画的几何图）、刻度标记、主圆的柔和渐变填充、低调的动态效果（缓慢旋转的虚线环、脉动光晕）。要不要考虑"减少动画"偏好？这更多是CSS的范畴，用SVG SMIL或内嵌CSS即可。 配色方案：暖色调背景配深青色？还是米白色背景配朱红色主圆和深蓝色辅助线，包豪斯/几何绘图风格？就用"几何研究"风格吧：冷灰色背景还是亮白色纸张？如果不用奶油色+赤陶色组合，亮白色就不错。[...]

几分钟后，它生成了一个精美绝伦的动态圆形——但完全不是我要的东西！

我的强烈建议：别用默认设置。一开始就把Qwen 3.8 27B设为低推理甚至关闭推理模式。这是个很棒的模型，但默认设置绝对是糟糕的起点。

目标框识别能力出色

测试视觉模型的一个有趣方式，是看它能否准确识别照片中物体的边界框（bounding box）。之前的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的占位图：渐变水面+两个blob状的"鹈鹕"剪影，放在给定的边界框位置（用相同比例——这样很有意思：剪影在0-1000坐标上的位置完全对应，能展示框的对齐效果）。这样做出来的演示有趣又独立。保持简洁：天空渐变、太阳、水面、两个鹈鹕形状（椭圆身体、圆形头部、喙），放在边界框中心位置。

（我有点担心，过去两年我一直在用这个傻气的基准测试，会不会让全球的模型都产生"有机会就画鹈鹕"的偏见。）

这种过度思考有必要吗？或许有几分必要。我关闭推理模式后得到了这个版本（对话记录见此），功能基本可用，但框的位置完全不对：

可见关闭推理模式后，模型无法一次性生成可用工具。我相信通过后续提示词可以修正，但这恰好说明推理能力能带来关键性差异。

可驱动代码代理

本地模型最大的疑问之一，是能否胜任代码代理循环。代码代理需要长上下文、强大的代码生成能力和可靠的工具调用能力。从参数来看Qwen 3.8 27B三者兼具，它能胜任吗？

我用Pi进行的初步实验结果喜人。我选择Pi是因为它的系统提示词比其他工具更短，更适合测试小型模型。

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

{
"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个token。

好消息是，模型发布两天来，社区已经在探索提速方案。

其中最有前景的优化是模型本身支持的多token预测（Multi-Token Prediction）。这是一种架构优化：用轻量机制提前预测多个token，主模型只需快速验证预测是否正确，能大幅提升推理性能。

根据llama.cpp开发者Georgi Gerganov的推文，我在Spark上用以下命令开启多token预测运行模型：

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

效果显著。我让GPT-5.6在Codex上对比测试Spark上的两种运行方式，开启--spec-type draft-mtp的服务器比LM Studio默认的GGUF版本速度提升约72%。

我预计未来几周会出现更多加速方案，MLX社区想必也在酝酿优化技巧。

几点观察

一个17GB的文件能在我的家用设备上实现这么多功能，简直是奇迹。我再次为今年本地模型的进步感到惊喜和震撼。放在一年前，这样的性能足以与最顶尖、最昂贵的闭源模型抗衡；而如今，它能在一台性能不错的笔记本电脑上运行。

唯一阻碍它成为日常主力工具的是性能。无论是M5芯片的Mac还是DGX Spark，运行起来都偏慢。这是密集型（非混合专家）模型的通病——它们需要极高的内存带宽才能高效运行，而我手头的两台设备在这方面都不算顶尖。

Qwen 3.8 27B最重要的意义在于它证明了一件事：我们可以拥有一款开源通用模型，具备长上下文、高效工具调用、出色视觉能力和可靠代码生成能力，而体积仅需17GB。

这个参数规模的模型还在以惊人的速度进步。我们不必花费数十万美元购买数据中心级硬件，也能运行一款能力完备的模型。