Qwen 3.8 27B 过度思考：为了击败 Opus 4.6，必须如此

是的，光是等待16K+推理令牌就很烦人。但问题是，这只是一个270亿参数的模型，试图与1T+参数的模型相媲美。必须做出牺牲，而牺牲的就是推理或轨迹令牌的数量。这对大语言模型来说并非新鲜事。Andrej Karpathy 本人就说过，大语言模型需要令牌来思考。他在自己的 "Let's build GPT" / GPT 视频系列中提到过这一点，虽然我不记得具体何时，如果我没记错的话，是在他展示 Llama 基础模型时。SWE-Rebench 也指出了这一点：https://swe-rebench.com/?insight=feb_2026 "Qwen Next，以及 Step 3.5，都是需要大量令牌的极端例子"。顺便提一下，Qwen Next 也是第一个具有 GDA 的 Qwen 模型。SWE-Rebench 指出它 "平均每题约 8.12M 令牌"。另一个题外话是 VibeThinker 3B。这个模型专为解决逻辑和数学问题而构建，而非代理工作负载或工具调用。我个人测试过，它基本上是一个浓缩在30亿参数中的研究生级数学模型。但再次强调，它绝对喜欢消耗令牌。而且，它是一个30亿参数的模型。天啊，我甚至可以在手机上运行它。至于期望，在大语言模型浪潮之前，查找和修复一个错误可能需要3小时，有时甚至几天或几周。现在，使用 n-shot 提示，通常可以在一小时内完成。我假设我们大多数人最初都是从 GPT / Claude 模型开始，然后才接触到这些本地模型，因此我们已经被快速的令牌生成宠坏了。我不知道你们的情况，但我的许多用例实际上是日常搜索任务。我可能会使用 Gemma 4 26B A4B，或者，甚至老式的 GPT-OSS 20B（这篇文章的语法本身已被我的 GPT OSS 修正），因为当我查看网关中的令牌使用情况时，大部分是 RAG 和代码搜索，而不是实际的代码生成。浪费令牌就是浪费时间，这没错，但你可以在 Qwen 27B 查找错误时做其他事情。这就是大语言模型归还给你的空闲时间。是的，如果你在 4060 Ti 上运行，可能需要一小时，但再次强调，它就像扫地机器人一样。它花时间，但不是你的时间。这也是为什么我可以接受以 6 tok/s 运行 DSv4 Flash。归根结底，Qwen 在技术和哲学上几乎是反 OpenAI 的。它是 Apache 许可的，它像没有明天一样吞噬令牌（GPT 模型是那些倾向于在 API 表面暴露相对较少推理令牌的 SOTA 模型之一），它是你的，它可以接受 llmfan46 处理，当然，16 GB 显存的显卡加上系统内存可以实际运行它。而且，如果你愿意，可以在 llamacpp 和 vllm 中将推理硬限制为 8192。