Qwen 3.8 27B:能力出色,但默认推理过度
Qwen 3.8 27B:能力出色,但默认推理过度
Qwen 3.8 27B 是阿里巴巴通义千问团队发布的一款 270 亿参数、支持视觉输入的语言模型,采用 Apache 2.0 许可证。模型量化后约 17GB,理论上可以在配置较好的笔记本电脑上运行。
测试环境包括一台配备 128GB 内存的 M5 Max MacBook Pro 和一台 NVIDIA DGX Spark,主要通过 LM Studio 运行 Q4_K_M 量化版本,也在 DGX Spark 上直接测试了 llama-server。
默认的 xhigh 推理并不适合日常任务
Qwen 3.8 27B 支持通过 reasoning_effort 调整推理深度:
xhigh:默认设置,面向需要深入分析的复杂任务medium:在准确性和速度之间取得平衡low:优先考虑效率、速度和成本
问题在于,模型默认使用 xhigh,即使面对非常简单的请求,也可能消耗大量时间进行推理。在 LM Studio 的默认 8192 token 上下文限制下,模型甚至会因为思考普通问题而耗尽上下文。将上下文长度提高到最大 262144 token 后,这一问题有所缓解。
一个典型例子是让模型生成“骑自行车的鹈鹕”SVG。开启默认高强度推理后,模型花费 21 分钟,使用了 22276 个推理 token,最终生成 3223 个输出 token。结果在自行车结构、鹈鹕外形、翅膀与车把的关系等方面表现出色,但等待时间显然不值得。
关闭推理后,同一提示词生成了 3715 个 token,用时 137 秒,也就是两分钟多。图像质量有所下降:自行车车架形状较差,鹈鹕的脚没有踩到踏板,也没有尝试握住车把,但速度明显更实用。
另一个更简单的测试是让模型“绘制一个圆形 SVG”。在 xhigh 模式下,模型没有直接输出简单的 <circle> 元素,而是自行设计了带有同心圆、刻度、渐变、动画和背景的复杂作品。最终效果很漂亮,却偏离了原始需求。
因此,使用 Qwen 3.8 27B 时,更适合先尝试 low 或关闭推理,再根据任务需要提高推理强度。
视觉定位能力表现突出
测试还包括让模型识别照片中的鹈鹕,并以 0 到 1000 的归一化坐标返回边界框。模型输出了两个边界框:
[
{"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
{"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]
将这些坐标绘制到原图后,两个边界框都较为准确地覆盖了鹈鹕,表现出良好的视觉定位能力。
模型还根据一段简短需求,在本地生成了一个用于标注边界框的 HTML 工具。工具可以接收图片地址和 JSON 检测结果,读取图片尺寸,将 0 到 1000 的坐标换算为实际像素,并在图片上显示带标签的边界框。
不过,开启高强度推理也带来了明显的过度设计。用户并未要求示例场景,模型却自行加入了一个包含夕阳、海水和鹈鹕剪影的演示画面。关闭推理后,生成的界面更简单,但边界框位置出现了错误。这个对比说明,推理过程确实可能帮助模型一次生成更可靠的工具,但也会增加无关功能和耗时。
可以驱动编码代理
Qwen 3.8 27B 还具备运行编码代理所需的几个关键能力:较长上下文、代码生成和工具调用。
在 Pi 编码代理中接入运行于 LM Studio 的 Qwen 3.8 27B 后,模型能够读取项目文件,并通过多轮推理和工具调用回答项目中的身份认证实现方式。测试结果被认为较为扎实。
随后,模型又根据一份 JSONL 会话记录,编写并测试了一个 Python 脚本,将会话内容转换为 Markdown,结果符合预期。
这些测试表明,Qwen 3.8 27B 不只是能够回答问题,也可以参与读取代码、调用工具和编写辅助脚本等完整工作流。
性能仍是主要限制
模型的主要短板是速度。在 LM Studio 中,测试得到的生成速度约为每秒 15 到 30 个 token。这个速度对于本地模型并不算差,但与托管 API 相比仍然偏慢。
Qwen 3.8 27B 支持多 token 预测(Multi-Token Prediction,MTP)。该机制会由一个成本较低的预测模块提前猜测多个 token,再由主模型快速验证,从而提升推理速度。
在 DGX Spark 上使用 llama.cpp 的 MTP 草稿模式进行测试时,速度相比 LM Studio 默认 GGUF 配置提升了约 72%。后续围绕模型服务和硬件加速的优化,可能还会进一步改善本地运行体验。
总结
Qwen 3.8 27B 展示了当前中等规模本地模型的能力边界:一个约 17GB 的文件,就可以同时完成视觉理解、边界框识别、代码生成、工具调用和编码代理任务。
它的关键问题不是能力不足,而是默认推理强度过高,以及在消费级硬件上的生成速度有限。对于普通任务,建议从低推理强度或关闭推理开始;面对复杂分析、代码修改或工具调用任务,再逐步提高推理深度。
这款模型也说明,具备较长上下文、视觉能力和工具调用能力的通用模型,已经可以在不依赖数据中心级硬件的情况下运行。
