我的笔记本电脑光顾着“思考”就卡死了
讲述了在笔记本电脑上运行 Qwen 3.8 27B 却迟迟等不到回答的经历。探讨了过高的推理默认值和运行工具的上下文限制如何对输出结果产生影响。
AI与科技笔记本电脑迟迟没有回答，屏幕上只有“正在思考”在一直打转
上周末，我在笔记本电脑上下载了一个开源模型。那就是阿里巴巴于 14 日发布的 Qwen 3.8 27B。文件大小只有 17GB。如今只要占用比一款普通游戏还小的容量，就能运行一个既能写代码、看图片，又能调用工具的模型，我觉得非常神奇，于是立刻下载了下来。
可是提问之后等了半天，回答却迟迟没有出现。屏幕上只有“正在思考”的提示一直在转。无论是用 gguf 运行，还是用 Mac 专用的 mlx 运行，情况都一样。它卡在了一种说不清是崩溃了还是超时了的模糊状态中。
排查原因后发现，并不是模型出了故障。问题在于默认设置并非针对个人笔记本电脑的环境而设计。于是，我探究了这个模型的默认值究竟是以什么条件为基准设定的。
只要一个圆，它却画出了动态几何图形
遇到这种情况的不止我一个人。
开发者西蒙·威利森（Simon Willison）于 16 日公开了在两台设备上运行该模型的记录：一台 128GB MacBook Pro 和一台英伟达 DGX Spark，运行的都是 17GB 大小的 4-bit 量化1版本。
他给出的第一个提示词是要求用 SVG 绘制一只骑自行车的鹈鹕。结果据说是他在本地模型中见过的最好的：自行车车架结构精准，两条腿分列两侧，翅膀甚至够到了车把。
问题在于，得出这个结果足足花了 21 分钟。推理消耗了 22,276 个 token，而最终输出仅为 3,223 个 token。推理消耗的 token 大约是输出的七倍。在关闭推理的情况下运行同一提示词，仅用了 137 秒。虽然质量有所下降，但他认为那点差距根本不值多花 21 分钟。
更耐人寻味的是接下来的实验。这次他提出了一个极其简单的请求：用 SVG 画一个圆。模型的思考过程是这样开头的：
虽然请求很简单，但我希望能交出一件精心制作的作品。让我们超越单纯的 circle 标签，做一些带有几何习作性质、包含细腻动画、层层圆环以及独特配色的东西。
几分钟后呈现出来的，是一个带有同心引导线、刻度、渐变色以及缓慢旋转的虚线环的动态图形。看起来确实很棒，但用户要的只是一个圆。
在编写代码时，它也表现出了同样的倾向。当要求它制作一个可以在照片上绘制坐标框的简单网页工具时，模型自行添加了许多未被要求的特性。它甚至还内置了一个示例画布，供没有现成测试照片的用户自行涂鸦。从它的思考记录中可以看到这样一句话：“因为自成体系且具备演示性，这样会很有趣”。模型擅自增加了并未被要求的任务。
我遇到的卡顿也与这一点有关。威利森写道，在 LM Studio 默认的 8,192 token 上下文限制下，模型立刻就卡住了。即使是非常微不足道的问题，模型单靠推理过程就能把这个上限消耗殆尽。当他将限制提高到 262,144 token 后，问题才得以解决。并不是模型无法生成答案，而是上下文上限被推理占满了，以至于根本没有空间容纳答案。
推理默认值被设为最高档的原因
大多数报道到这里都会归咎于“中国模型的成熟度问题”。我并不认同这种解读。在我看来，这并非开发过程中疏忽导致的失误，而是为了迎合评测条件而特意选择的设定。
Qwen 3.8 官方支持调节推理深度的配置项。共有 xhigh、medium、low 三档，而默认值正是最高的 xhigh。文档中也明确写着，该档位适用于复杂任务的彻底分析。
为什么要把这个设为默认值？看看基准测试（Benchmark）的评测条件，答案就显而易见了。
上一代 Qwen 3.6 的模型卡（Model Card）中，详细公开了其评测条件。终端任务基准测试设置了 3 小时超时，配备 32 核 CPU、48GB 内存、最大输出 8 万 Token、上下文 25.6 万 Token，并取 5 次运行的平均值。软件工程基准测试则是在 20 万 Token 上下文中使用其专有的 Agent Harness2 进行的。
在这样的条件下，最优策略显而易见：尽可能想得更久、想得更深。既然给了 3 个小时，就完全没有理由在 3 分钟内草草结束。因为打分系统只看答案是否正确，根本不在乎花了多少时间。
这一策略确实奏效了。按 Qwen 官方公布的数据，3.8 相比上一代，在终端基准测试中提升了 10 分，在计算机操作评测中提升了 20 分，在 Web 任务中提升了 16 分，在 Android 任务中提升了 12 分。尽管需要考虑到这是在单一测试框架下测得的自有数据，但大方向是一清二楚的。
现在，我们把普通用户的环境摆在一起看看：一台笔记本电脑，默认上下文 8,192 Token，只试一次，能容忍的等待时间充其量也就几分钟。在基准测试环境中拉高分数的设定，到了笔记本电脑环境中，却成了迟迟拿不到回答的罪魁祸首。
社区的反应耐人寻味。尽管 3.8 在基准测试中领先，但在本地用户群体中，4 个月前发布的 3.6 依然被称为“主力日常工具”。理由是 3.6 更加冷静沉稳，很少出现给不出答案而一味拉长推理的情况。事实上，3.6 在四个月内的下载量已突破 700 万次。基准测试得分高的模型，与本地实际常用的模型，正在走向分化。
防止重复的设置反而引发语言混杂
默认值是为评测条件量身定制的，这一点在模型文档中早有端倪。
Qwen 3.8 的模型卡片（Model Card）中有这样一段说明：如果出现无限重复，可以尝试将重复抑制值3从 0 调至 2 之间。然而紧接着的下一句话便发出警告：提高该数值可能会间歇性导致语言混杂，并可能使性能略微下降。
我认为，这两句话并排放在一起，最精准地揭示了这次发布的本质。这意味着厂商心知肚明遏制死循环的处方会引发其他症状，却依然选择在这一状态下发布了模型。
实际上，我在用韩语提问时，就目睹过回答中夹杂着日语和阿拉伯语的情况。关于这种情况为何会发生，有一项研究很值得参考。在一篇量化双语推理中语言混杂现象的论文中提到，某推理模型在解答数学题时，如果用中文提问，回答中有 77.4% 出现了语言混杂，每道题平均切换语言 7.22 次；而用英文提问时，这一比例仅为 0.6%。这表明该系列模型的主导思维语言是英语。
换言之，使用韩语提问的用户更容易遭遇回答中混入其他语言的问题。然而，这个问题并没有列入基准测试表的衡量指标中。既然无法被衡量，在敲定默认值时自然也就没有理由被纳入考量。
默认值的问题并不仅仅存在于模型本身。运行模型的推理工具本身的设置，也会极大改变输出结果。
参考一位用户用各种配置折腾了一整天同一模型的记录，单张 RTX 5090 上的推理速度从每秒 12 个 token 到 137 个 token 不等，差距超过了十倍。而且在开启了通过提前预测多个 token 来提速的功能4的配置下，全部发生了超时。该用户补充说明，这属于运行环境的兼容性问题，并非模型的过错。相反，威利森开启同样的功能后，却获得了比默认构建版本快 72% 的结果。
开启同一项功能，一边快了 72%，另一边的请求却全部以超时告终。我在 gguf 和 mlx 两端遭遇的卡顿死机，极大概率也与此有关。开放权重模型的实际性能并非仅由权重本身决定，更取决于搭载在其上的运行栈；而决定该运行栈默认值的，又是另一拨人。训练模型的团队、上传量化构建版本的团队、开发运行工具的团队全都各自独立。没有任何人是以我的笔记本电脑为基准来制定设置的。
如果您现在正亲自尝试运行这个模型，我建议按如下顺序进行调整：首先将上下文上限留足充裕空间，调低推理步数以遏制过度思考，并将采样的候选数量上限（Top-K）5明确指定为 20。至于靠提高重复抑制值来阻断死循环，请留作最后的手段，因为这个数值正是招致语言混杂的元凶。
当然，为了保持客观，有一点需要补充说明：过度思考并非该模型独有的问题。在社区的对比实验中，谷歌的 Gemma 4 26B 在面对同样的问题时甚至消耗了更多的 token。而且在 Hugging Face 上，关于这一现象究竟属于权重本身的结构性缺陷，还是该分析纯属伪造的争论至今仍未平息——尽管这是一个权重完全公开的模型。
Oswarld视角
我在制定 GTM 战略时，曾多次参加围绕产品默认设置展开争论的会议。每次都能看到一种反复出现的格局。
决定默认设置的场合，总会面临两种压力。 一种是“让初次使用者顺利成功”，另一种则是“把我们展现得最出色”。后者胜出的情况远比想象中要多。在演示中表现出色、评测人员会开启、以及能在对比表格中胜出的设置，往往就直接成了出厂默认设置。
问题在于，这种选择并不会显露出来。既没有删减功能，也没有虚报性能。无非是将某项设置定在了哪里而已。然而从用户的角度来看，默认设置实际上就等于产品本身。因为绝大多数人根本不会打开设置界面。
因此我认为，默认设置最能体现这款产品究竟是为谁而打造的。营销文案可以同时针对多个用户群体，但默认设置却只能选定一个。
在这次的案例中，这种选择体现得尤为明显。开源权重模型能够拿得出手的依据，几乎仅限于基准测试分数。既没有销售团队，也没有分销协议，更没有积累的用户数据，只能依靠排行榜名次来证明性能。这样一家公司选择迎合评分条件的默认设置，并不是什么奇怪的事。倒不如说在那种处境下，这反而是自然而然的选择。
只不过，理解其中的原委与直接沿用默认设置，完全是两码事。这周当我在笔记本电脑上多次遭遇无法获得回答、程序直接卡死之后，才真正认识到了这一点。
结语
在这次测试中确认了三点。
- Qwen 3.8 27B 的推理默认设置为最高档位 xhigh。哪怕只是要求画一个圆，它也会制作带有动画的复杂图形；如果上下文上限较小，它就会把 token 全部耗费在思考推理上，导致没有空间容纳最终答案。
- 这不是失误，而是迎合评分条件所做的选择。因为在允许 3 小时超时和 8 万 token 输出的评测中，思考时间更长的一方往往会胜出。
- 个人用户的条件则恰恰相反。正因如此，基准测试中领先的模型与本地实际常用的模型之间出现了分歧，四个月前发布的 3.6 依然被用作日常主力模型。
同样的审视并不只适用于这一款模型。不妨打开您现在正在使用的 AI 工具的设置界面看一看。**这个默认值究竟是为您而定，还是为了评测这款产品的人而定？**两者的答案截然不同的工具，恐怕比想象中要多得多。
读者，您是否也有过因为沿用 AI 工具的默认设置而吃亏的经历？那是哪款工具的什么设置？调整之后又发生了什么变化？欢迎在评论区分享您的经历。
💬 欢迎在评论区分享您因默认设置遇到的问题 · 📨 如果有正在评估本地模型的同事，欢迎转发这篇文章
参考资料与延伸阅读
核心来源
- Simon Willison, “Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things”, Simon Willison’s Weblog, 2026. 8. 16. 链接 ··· 21分钟与22,276个Token的数据来源。里面附有画圆案例的完整思维记录链接，建议至少点开看一眼。
- Qwen, “Qwen3.8-27B Model Card”, Hugging Face, 2026. 8. 14. 链接 ··· 推理步骤默认设置与重复抑制参数警告的出处。非常适合用来确认厂商当时究竟知晓哪些问题。
- Qwen, “Qwen3.6-27B Model Card”, Hugging Face, 2026. 4. 链接 ··· 3小时超时上限与8万Token的基准测试测定条件就记录在这里。也是本文的核心依据。
- “Why Qwen3.8-27B overthinks? Here the reason”, Hugging Face Community Discussion #76, 2026. 8. 链接 ··· 围绕结构性缺陷展开争论与反驳的讨论帖。这也是一个即便权重开源、其行为机制依然难以达成共识的典型案例。
背景知识
- Yihao Wang et al., “The Impact of Language Mixing on Bilingual LLM Reasoning”, arXiv:2507.15849, 2025. 链接 ··· 语言混用比例77.4%与0.6%的数据来源。解释了为什么非英语母语用户的体验会截然不同。
推荐阅读往期内容
📝 术语说明
注释
-
量化（Quantization）：将模型内部的数值压缩至更低精度，以减少文件体积和内存占用的操作。类似于将高分辨率照片稍微压缩画质后保存。正因如此，27B模型才能缩减至17GB，塞进笔记本电脑运行。 ↩
-
评测脚手架（Harness）：在评测或运行模型时包裹在外层的一套调度框架。由它来决定允许使用哪些工具、尝试多少次以及何时停止。即使是同一个模型，运行在不同的Harness上，得分也会有所不同。 ↩
-
重复抑制参数（presence_penalty）：用于降低已出现词汇再次出现概率的设置项。它可以减少反复说车轱辘话的现象，但如果把这个值设得太高，模型在刻意回避原有用词的过程中，可能会冷不丁蹦出无关语言的词汇。 ↩
-
多Token预测（MTP, Multi-Token Prediction）：由轻量化组件预先猜出接下来的几个词，再由主模型快速核验是否正确的机制。如果命中率高，生成速度会大幅提升；但如果运行环境未能妥善支持该功能，反而可能直接导致卡死。 ↩
-
Top-K采样（top_k）：决定在预测下一个词时，按概率从高到低只保留前几个候选词的设置项。如果不限制该数值，概率极低的生僻词也会留在候选列表中，有时就会莫名其妙冒出意料之外的字符。 ↩