Qwen3.8-27B 的第三方实测：模型很好，出厂默认值不好

本站 08-16 发布 Qwen3.8-27B 时把编辑判断放在尺子上：领先幅度最大的那一项跑在一把以厂商自己命名的基准上，而所有对比都由厂商自跑。这条是第三方拿真机器跑出来的那把尺子——128GB M5 Max MacBook Pro 与一台 NVIDIA DGX Spark，LM Studio 的 17GB Q4_K_M 量化构建，另在 Spark 上直接试过 llama-server。

出厂默认档是错的起点

官方文档写明 reasoning_effort 默认 xhigh，而 LM Studio 的 GGUF 保留了这个默认。代价是可测的：

• 同一道画图题，默认档跑了 21 分钟，用掉 22,276 个思考 token，产出 3,223 token。
• 关掉思考重跑同一题：3,715 token，137 秒。
• 更极端的一次，提示词只有「画一个圆的 SVG」，模型花了几分钟产出一幅带动画、同心辅助圆和渐变配色的「几何习作」——完全不是被要求的东西。

还有一个很实际的坑：LM Studio 默认 8,192 的上下文上限会被思考过程整个吃光，哪怕问题再普通；把上下文加载到 262,144 之后问题消失。

作者的建议直白：忽略那个默认值，先用 low 甚至完全关掉思考跑。

这一条正落在本站《交互系统中的延迟权衡》上：速度永远是「在什么条件下的速度」，而这里决定条件的不是硬件，是一个出厂开关。

视觉与工具使用是真的强

拿边界框考视觉模型：给一张照片，要求以 0–1000 的比例返回鹈鹕的 JSON 边界框。返回的两个框与照片吻合得很好。他随后让模型离线写了一个网页工具，把这类 JSON 叠加到图片上渲染——一句提示词，成品可用。

作为智能体也站得住：通过 Pi 接上跑在 Spark 上的模型，在一个真实代码库里问「鉴权是怎么工作的」，模型经过一串推理与工具调用给出了扎实的回答；再让它把会话记录从 JSONL 转成 Markdown，它写出并测试了可用的脚本。

顺带一个有意思的细节：那个网页工具自作主张加了一个示例场景，因为提示词里给的示例 JSON 标签写着 pelicans——它就自己画了两只鹈鹕。

真正的门槛是吞吐

LM Studio 上大约 15–30 token/秒。 作者的原话是这不算糟，但慢到很难让他放弃托管 API 模型。

这个数字值得和本站昨天那条并排看。那条引了一位网友在单张 GH200 上的实测：并发 10 个请求、首批流式 token 在 10 毫秒内返回。两个数都对，但一个是数据中心加速卡，一个是一台高端笔记本——而后者才是「27B 能本地跑」这句话面向的读者。

边界

这是一位开发者的动手记录，不是系统评测：没有对照组、没有重复运行、没有跨模型的统一口径。它的价值在于给出了厂商公告里没有的三件事——默认档的真实代价、消费级硬件上的吞吐量级、以及视觉定位在真实任务里能用。作者本人也写明，接下来值得看的是独立基准怎么说。