摘要:8 月 14 日开源的 Qwen3.8-27B,以 27B 稠密模型的身份在 SWE-bench Pro、QwenSWEBench、OSWorld-Verified 等多项评测中反超 Claude Opus 4.6 Max,17GB 的 Q4 量化版本让一张 24GB 显存消费级显卡就能整卡装下。但开发者上手后的第一个共识是:它默认"想太多"——官方把 reasoning_effort 默认值设成了最高的 xhigh,思考 token 直接变成延迟与成本。本文拆解 overthinking 的机制与代价,并给出官方文档和社区实测验证过的调优方法。

事件:27B 开源模型这一周

8 月 14 日,阿里 Qwen 团队发布 Qwen3.8-27B,Apache 2.0 协议,27B 参数的原生多模态稠密模型:能看图、读文档、理解视频,原生支持 262,144 token 上下文(可经 YaRN 扩展到 100 万),并内置多 token 预测(MTP)头。架构沿用 Qwen3.5 起的 Gated DeltaNet 混合注意力——64 层里 48 层是线性注意力、16 层完整 Attention,按"三层线性+一层完整"循环,用线性注意力压低长序列的计算与 KV Cache 压力(官方模型卡)。

官方自报的 benchmark 是这周最热的话题。按模型卡口径(统一用 Claude Code harness、256K 上下文评估),Qwen3.8-27B 在多个编程与 Agent 榜单上反超闭源的 Claude Opus 4.6 Max:SWE-bench Pro 61.7 对 53.4(+8.3),QwenSWEBench 79.0 对 63.8(+15.2),CoWorkBench 70.7 对 68.2,LiveCodeBench v6 90.3 对 88.8,OSWorld-Verified 84.3 对 72.7,AndroidWorld 81.9 对 62.0;DeepSWE 1.1 更是从上一代的 13.3 跳到 42.2。量子位 8 月 15 日以"源神启动"为题报道这份成绩单,InfoQ 8 月 17 日跟进称海外开发者正在"榨干"这只 27B。

热度也直接反映在生态上:据 InfoQ 报道,开源不到 12 小时模型就进入 Hugging Face 历史最受欢迎榜 TOP 4,两天下载超 100 万次、社区贡献约 500 个量化版本 [待验证];NVIDIA、AMD、联发科等芯片厂商快速适配,vLLM、SGLang、Ollama、LM Studio 第一时间跟进。Simon Willison 8 月 16 日的实测长文登上 HN 热榜(558 分/264 评论),标题就是那句著名的评价:“Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things”——优秀,但默认想太多。

对本地玩家来说,最实在的意义是"带得动":除官方 FP8 版外,社区 17GB 的 Q4_K_M 量化(Simon 实测用的就是它)能塞进 24GB 显存的 RTX 3090/4090,苹果 M 系列大内存 Mac 也能跑。多模态一侧同样能打:官方 VL 表里,浏览器操作 WebArena-Verified 从上代的 48.8 涨到 64.8,视觉数学(开启 CI 后)94.6、通用视觉推理 85.6(不开 CI 只有 65.7)。

“excellent but overthinking”:现象与代价

问题出在默认参数上。官方文档写得很明确:Qwen3.8 默认开启 Thinking 模式,reasoning_effort 支持 xhigh / medium / low 三档,默认值是 xhigh——“为需要彻底分析的复杂任务设计”。对一个 27B 稠密模型来说,这是个糟糕的默认值:稠密模型每生成一个 token 都要让全部 270 亿参数参与计算,思考 token 越多,延迟与成本涨得越离谱。

Simon Willison 的实测最有说服力。他用默认设置让模型画一只"骑自行车的鹈鹕"SVG,模型花了 21 分钟、烧掉 22,276 个推理 token,才产出 3,223 个输出 token;同一提示词关掉思考后,137 秒完成。更夸张的是"画一个圆":模型的思考轨迹从"一个圆太简单了"开始,最后脑补出一个带同心圆、刻度、渐变动画的"几何研究"作品——几秒钟的事变成几分钟。他实测中还发现,LM Studio 默认 8,192 token 的上下文窗口会被思考内容直接吃满,必须把上下文拉到 262K 才能正常干活。

其他开发者的反馈一致。YouTuber Bijan Bowen(Q8 量化、RTX Pro 6000)让模型写一个 C++ 滑板游戏,模型反复"准备写文件又停下来继续思考",至少出现 5-10 次这种循环,一个多小时后仍卡在它自己解决不了的 bug 上(据 InfoQ);HN 上一位用户记录,这是继 Gemma 4 之后第二个通过他私人推理测试的本地模型,但 token 消耗约为前者的 5 倍,即使开启 MTP,整个任务仍耗时 12 分 30 秒(据 InfoQ)。

代价是双重的:对交互式使用,是肉眼可见的"转圈";对 Agent 循环,是每轮工具调用前都要烧掉几千个思考 token——在本地 15-30 token/s 的硬件上,一轮思考就是几十秒到几分钟。

调优实操:把"想太多"按回去

官方把思考控制设计成三个开关,全部支持请求级覆盖。

1. 关掉或降档思考。 简单问答、摘要、翻译、普通工具调用,直接 enable_thinking=False 跳过推理;需要一点推理但别太狠的任务,用 reasoning_effort="low" 或 "medium"。官方 OpenAI 兼容 API 的写法(默认值即问题根源,显式覆盖即可):

from openai import OpenAI
client = OpenAI()  # 通过环境变量配置 base_url / api_key

messages = [{"role": "user", "content": "把这段英文摘要翻译成中文:..."}]

# 简单任务:关思考 + low 档,速度优先
completion = client.chat.completions.create(
    model="Qwen/Qwen3.8-27B",
    messages=messages,
    extra_body={
        "chat_template_kwargs": {
            "enable_thinking": False,    # 默认 True(Thinking 模式)
            "preserve_thinking": False,  # 单轮任务无需保留推理
        },
    },
    reasoning_effort="low",  # 默认 xhigh;可选 xhigh / medium / low
)
print(completion.choices[0].message.content)

2. 管好 preserve_thinking。 这个开关默认开启,作用是把 Agent 前几轮"怎么想的"继续留在后续上下文里,让 Coding Agent 改十几个文件时能沿着之前的决策走,并复用 KV Cache。多轮长任务开着是福利,短任务开着就是白白占上下文——按场景关掉。

3. 用官方推荐的采样参数。 Thinking 模式:temperature=1.0、top_p=0.95、top_k=20;非思考(Instruct)模式:temperature=0.7、top_p=0.80、presence_penalty=1.5。官方还提示:Agent 任务别把输出上限卡太死,建议推理内容上限 262K、最终回答上限 131K,给复杂推理留足空间。

4. 提速:MTP 推测解码。 这是社区验证最有效的工程手段。模型自带多步 MTP 头,可让一个廉价小模型先猜几个 token,主模型批量验证,减少逐 token 串行开销。Simon Willison 转述 llama.cpp 作者 Georgi Gerganov 的命令:

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

他在 DGX Spark 上对比,--spec-type draft-mtp 比 LM Studio 默认 GGUF 快约 72%。社区项目 qwen38-mtp 记录的数字更细:RTX 3090 从 31.0 提到 41.3 token/s,RTX 4090 从 47.7 提到 76.3,RTX A6000 从 26.7 提到 52.5(据 InfoQ);项目启动两天就积累了 21 名贡献者、27 组配置。Apple Silicon 侧,开发者 Kydo 发起的优化挑战在不到 16 小时内把性能相对基线提升了 153%,达到默认 MTP 解码的约 2.5 倍(据 InfoQ)。Ollama 侧,v0.32.13 已支持 qwen3.8 的 developer instructions,本地一键跑的门槛进一步降低。

5. 知道什么时候该保留思考。 官方文档给了一个反直觉提醒:多轮 Agent 任务中,一味调低 reasoning_effort 不一定缩短总耗时——单轮是快了,但分析不足导致失败和重试,总延迟和 token 消耗可能反而更高。实操建议:简单任务关思考,中等任务 low/medium,复杂代码和长程 Agent 保留 xhigh;先用 preserve_thinking + MTP 解决性能瓶颈,再决定要不要动思考档位。

落地评估:它适合什么 Agent 场景

本地部署的价值分三层。第一是成本:一张二手约 900 美元的显卡就能离线跑,对比按 token 计费的云端 API,高频 Agent 循环的成本结构完全不同(InfoQ 还记录了这个"900 美元二手卡跑赢 Opus"的段子在 X 上传疯,玩笑之外细节都是真的)。第二是隐私与可控:代码、文档不出本机。第三是长任务:262K 原生上下文 + 工具调用 + 视觉能力,Simon Willison 已经用 Pi 把这只 27B 配成编码 Agent,让它回答"auth 怎么工作"时自动翻了一堆文件;他还实测了视觉 bounding box 标注,精度好到专门写了个标注工具。

短板也明确:速度。稠密模型解码速度受内存带宽限制,Simon 在两台机器上只跑到 15-30 token/s,和云端没法比(Artificial Analysis 显示 OpenAI 5.6 Sol 为 74 token/s、5.6 Luna 为 184 token/s)。SGLang 开发者通过 NVFP4 优化把单张 RTX 5090 的 decode 推到 200+ token/s(据 InfoQ),说明服务端推理还有空间,但那是另一套部署方案。社区也验证了高并发下的稳定性:有人把 FP8 版放到单张 NVIDIA GH200 上,同时跑 10 个真实请求、每个最高输出 16K token、上下文拉到 262K,首批流式 token 基本都在 10ms 内返回(据量子位)。Cerebras 则宣布为 27B 提供专属部署并加入其 Shared Tier(据 InfoQ),说明它也已经进入云端推理服务商的视野。

还有一个容易被忽视的结论:对开源模型,“权重不等于体验”。同一个 27B,chat template、sampler、推理后端不同,reasoning 长度、速度和工具调用表现可以差很多——社区甚至出现了专门修订 Qwen3.5/3.6/3.8 Jinja template 的仓库。这正是本文所有调优参数值得逐一验证的原因。

总结

Qwen3.8-27B 是消费级硬件上目前最值得试的 Agent 模型:27B 稠密、原生多模态、262K 上下文、MTP 加速,官方 benchmark 在编程与 Agent 任务上反超 Claude Opus 4.6 Max(同一代想要更大规模,还有上周开源的 2.4T-A95B MoE 可选,OpenRouter 已能调用)。但它的出厂默认参数是个陷阱——xhigh 思考档位会让简单任务慢到无法接受。上手三步走:先关思考或降到 low 跑通流程;复杂任务再按需开回 medium/xhigh 并保留 preserve_thinking;任何场景都优先开 MTP 提速。把"想太多"调成"想得刚好",这只 27B 才能真正成为那张消费级显卡上的主力 Agent。

参考链接

• Qwen3.8-27B 官方模型卡(Hugging Face):https://huggingface.co/Qwen/Qwen3.8-27B
• Simon Willison《Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things》(2026-08-16):https://simonwillison.net/2026/Aug/16/qwen-38-27b/
• Hacker News 讨论(558 分/264 评论):https://news.ycombinator.com/item?id=49324985
• 量子位《源神启动!一张消费级显卡跑"Opus级"Agent,Qwen3.8-27B多项榜单反超Claude》(2026-08-15):https://www.qbitai.com/2026/08/473669.html
• InfoQ《从模型能力到工程优化,海外开发者正在"榨干" Qwen3.8-27B》(2026-08-17):https://www.infoq.cn/article/MljtE2Xk6hVkd061LY7k
• ollama v0.32.13 Release(qwen3.8 developer instructions):https://github.com/ollama/ollama/releases/tag/v0.32.13