思考帽（ThinkingCap）系列迎来第五个模型，基于谷歌（Google）的 Gemma-4-26B-A4B-it，在不降低回答质量的前提下减少思考量。十二个基准测试显示，思考 token 最高降 69.1%，平均降 38.9%，准确率仅下降 0.15 个百分点。这是首款用在谷歌模型上的思考帽，也是目前准确率代价最小的一款；循环从原版回复的 3.6% 降至 0.8%。采样设置保持开启思考、temperature 1.0、top_p 0.95，服务栈仍为 vLLM，可作直接替换。此前已发布四款省 token 模型。

要点速览

这是 ThinkingCap 系列的第五个模型。我们减少了 Google gemma-4-26B-A4B-it 的思考量，同时没有降低回答质量。

• 在 12 项基准上，思考 token 最多减少 69.1%，平均减少 38.9%，准确率仅变化 0.15 个百分点。
• 这是首个基于 Google 模型的 ThinkingCap，也是目前所有 ThinkingCap 中准确率代价最小的一个。
• 循环率从原模型的 3.6% 降至我们的 0.8%。
• 采样设置相同（开启思考、temperature 1.0、top_p 0.95），服务栈相同（vLLM），可直接替换。

第五个 ThinkingCap

我们目前已发布四个高效 token 模型：ThinkingCap-Qwen3.6-27B、ThinkingCap-Qwen3.8-27B、ThinkingCap-NVIDIA-Nemotron-3.5-Lightning-30B-A3B 和 ThinkingCap: Qwen3.8-Flash-Next。

gemma-4-26B-A4B 是 Google 的稀疏专家混合模型——26B 参数，每个 token 约激活 4B。这是我们继 Qwen 和 NVIDIA 之后应用该方法的第三个模型系列。在这个模型上，我们额外努力保持准确率不受影响：思考量平均下降 38.9%，代价仅为 0.15pp 准确率，小于该套件中大多数基准的逐次运行波动。

原始模型与 ThinkingCap 模型的对比视频：两个模型接收相同输入，在同一硬件和相同推理设置下运行。

训练目标

我们从 gemma-4-26B-A4B-it 出发。目标是用更少的 token 得到答案，其他一概不变：保留知识、推理能力、回答质量、指令遵循和安全行为。

结果

各任务家庭的准确率上，原模型与 ThinkingCap 模型相比几乎没动，其中两个家庭还有提升。指令遵循与智能体提升 0.65pp，数学提升 0.39pp；代码基本持平，为 0.02pp；知识与推理下降 0.51pp，长上下文与多模态下降 0.92pp。12 项基准平均下来，变化是 −0.15pp。

各任务家庭的平均思考 token 上，变化正体现在这里，每个家庭都变短了。长上下文与多模态缩减最多，为 54.4%；随后是知识与推理 44.4%、数学 36.1%、代码 27.6%；指令遵循与智能体缩减最少，为 17.2%。12 项基准平均缩减 38.9%。

| 基准 | 准确率（原模型） | 准确率（ThinkingCap） | 准确率变化 | 平均思考 token | 平均思考变化 | 截断 % | 循环 % | | --- | --- | --- | --- | --- | --- | --- | --- | | 数学 | | aime26 | 86.20% ±0.86 | 86.72% ±0.98 | +0.52pp | 14766 → 8963 | -39.3% | 5.2 → 0.5% | 5.5 → 0.9% | | hmmt_nov25 | 81.51% ±1.06 | 80.89% ±1.19 | -0.62pp | 16462 → 10542 | -36.0% | 9.0 → 1.2% | 8.6 → 1.2% | | hmmt_feb26 | 72.92% ±1.08 | 74.20% ±1.16 | +1.28pp | 22005 → 14717 | -33.1% | 18.6 → 4.6% | 17.0 → 4.5% | | 代码 | | livecodebench | 76.98% ±0.56 | 76.96% ±0.67 | -0.02pp | 11560 → 8375 | -27.6% | 6.8 → 1.3% | 2.2 → 0.3% | | 知识与推理 | | gpqa_diamond | 79.92% ±0.57 | 78.96% ±0.67 | -0.96pp | 7699 → 4284 | -44.4% | 0.3 → 0.1% | 0.3 → 0.1% | | mmlu_pro | 84.55% ±0.29 | 84.64% ±0.16 | +0.09pp | 3907 → 1989 | -49.1% | 0.0 → 0.0% | 0.1 → 0.0% | | mmmlu | 84.09% ±0.26 | 83.43% ±0.27 | -0.66pp | 1212 → 731 | -39.7% | 0.0 → 0.0% | 0.0 → 0.0% | | 长上下文与多模态 | | aa_lcr | 64.62% ±2.49 | 60.62% ±2.89 | -4.00pp | 6519 → 2655 | -59.3% | 4.0 → 0.0% | 3.6 → 0.4% | | longbench_v2 | 59.43% ±1.14 | 60.88% ±1.29 | +1.45pp | 9486 → 2934 | -69.1% | 7.7 → 0.5% | 5.9 → 1.2% | | realworldqa | 70.83% ±0.56 | 70.61% ±0.56 | -0.21pp | 819 → 533 | -34.9% | 0.0 → 0.0% | 0.0 → 0.0% | | 指令遵循与智能体 | | ifbench | 76.83% ±0.80 | 78.67% ±0.73 | +1.83pp | 6470 → 5585 | -13.7% | 0.4 → 0.4% | 0.5 → 0.5% | | tau2 | 64.25% ±0.97 | 63.73% ±1.26 | -0.53pp | 4374 → 3466 | -20.8% | 0.0 → 0.0% | 0.0 → 0.0% | | 平均（12 项基准） | 75.18% | 75.03% | -0.15pp | 8773 → 5398 | -38.9% | 4.35 → 0.72% | 3.64 → 0.76% |

每一行都是原版 BF16 模型与 ThinkingCap 模型的对比，在相同 harness、相同设置、相同问题上跑出来。准确率是多种子的均值，± 为种子间波动的 95% 置信区间。最后一行每一格都是 12 项基准的平均，每项计一次——所以其中的「平均思考变化」是 12 个缩减幅度的均值，而不是旁边两个 token 数字的比值（那个是 38.5%）。上面的各家庭条形图同理，画的是各家庭的平均 token。在 τ²-bench 上，思考 token 是按任务计的，累加了 rollout 各轮，而不是按回答计。各列定义见评估方法。

12 项基准的思考都变短了。缩减最深的是 LongBench v2（−69.1%）、AA-LCR（−59.3%）和 MMLU-Pro（−49.1%）；最浅的是 IFBench（−13.7%）和 τ²-bench（−20.8%）。这两项最浅的，恰恰是最不依赖长思考的两类工作：一是遵循一串格式约束，二是通过正确的工具调用执行固定的客服策略。

准确率方面，大多数结果都在噪声范围内：12 项中有 8 项的差距小于逐次运行波动，其中 5 项甚至优于原模型。超出置信区间、变动更大的四项是 IFBench（+1.83pp，对我们有利）、GPQA-Diamond（−0.96pp）、MMMLU（−0.66pp）和 AA-LCR（−4.00pp）。AA-LCR 是套件里唯一的实际代价。

循环在整个套件中都有改善。原模型有 3.64% 的回答出现循环，我们的模型为 0.76%——在循环最多的三项基准 AIME 2026、HMMT Nov 25 和 HMMT Feb 26 上，比例从 5.5%、8.6% 和 17.0% 降至 0.9%、1.2% 和 4.5%。

从左到右看，这是实际部署会问的问题：每个问题给定 token 预算，你能拿到多少准确率？ThinkingCap 的曲线在整个中间区间都位于原模型之上——用更小的预算拿到相同准确率——当预算宽到两个模型都不再受限制时，两者收敛。

评估方法

推理模型评估噪声很大。在推荐温度 1.0 下，回答的内容和长度都会随运行而变，单次种子几乎说明不了问题。下面所有结果都是每个基准跑多种子，准确率报告为跨种子的均值和 95% 置信区间。

两边是同一次运行。 原模型和我们的模型用相同 harness、相同采样与服务设置评估。原模型由我们实测，而非引用已发布数据。配置如下：

• Harness——内部评估套件，两个模型都跑在 vLLM 上。
• 上下文——每个基准上单条回答生成上限为 65,536 token；τ²-bench 为每轮上限。
• 采样——开启思考；temperature 1.0，topp 0.95，topk 64。我们的模型原样继承 Google 推荐预设，因此对比中没有任何解码改动。
• 准确率——跨种子的均值，附 95% t 区间，表示只改采样种子时答案会移动多远。
• 种子数——AIME 2026、HMMT Nov 2025、HMMT Feb 2026 为 64；GPQA-Diamond 和 LiveCodeBench 为 32；RealWorldQA、IFBench 和 τ²-bench 为 16；AA-LCR 和 LongBench v2 为 8；MMLU-Pro 和 MMMLU 为 4，这两个基准题量足够大，问题采样不是主要噪声。
• 问题集——AIME 2026（30 题）、HMMT Nov 2025（30）、HMMT Feb 2026（33）、LiveCodeBench（175）、GPQA-Diamond（198）、MMLU-Pro（12,032）、MMMLU（9,996）、AA-LCR（100）、LongBench v2（370）、RealWorldQA（765）、IFBench（300）和 τ²-bench（横跨 airline、retail 和 telecom 的 278 个任务）。
• 评分——对提取出的答案做精确匹配，例外：LiveCodeBench 会把生成的代码拿去跑题目测试；IFBench 由程序化验证器评分；τ²-bench 和 AA-LCR 为判定评分。τ²-bench 还面对模拟用户运行，并报告为三个域的未加权均值。

各列含义

• 准确率（原模型） / 准确率（ThinkingCap）——同上；准确率变化是两者差值，单位为百分点。
• 平均思考变化——核心指标：思考 token 的变化量，按整个基准汇总后除以题目数，因此长题权重大于短题。
• 平均思考 token——推理结束前的 token 数，对基准中每个问题和种子取平均，写作 原模型 → ThinkingCap。
• 截断 %——思考始终未结束的回答占比，这些回答得 0 分。
• 循环 %——被基于压缩的循环检测器捕获的回答占比；如果回答的文本压缩程度远超普通行文，就会被标记。

获取模型

模型可在 bottlecapai/ThinkingCap-gemma-4-26B-A4B-it 获取，同时发布了 GGUF 版本。

讨论聚焦于减少思考 token 的 Qwen 优化版是否真的划算。多数试用者认为这些版本明显更笨、审查更严，省下的 token 不值；但也有人从成本场景出发支持缩短推理，还有人反感商家将开源模型优化后封闭收费，并用旧瓶装新酒的玩笑讽刺这种卖性能选项的行为。

认为减少思考 token 的优化版明显更笨

• 多个试用者反馈，为节省 token 推出的 ThinkingCap、Swift 等版本在相同任务上表现不如原版，能力明显下降，其中 Swift 版本笨到让人只用一天就弃坑；有人怀疑这只是基准测试好看、实际任务拉胯。（较多人）
• 优化版除了变笨，内容审查也明显更严格，露骨请求会被直接拒答，而原版会继续处理，体验反而更差，导致用户换回原版。（较多人） > 为了省 token，它在基准测试上理论上不错，但在你自己的任务上其实没那么能干。（@PaulKeeble）

认为在成本敏感场景应优先缩短推理

• 在代码审查等任务中，成本几乎全部来自思考 token，因此相比追求峰值分数，能在相同准确率下大幅缩短推理过程更符合实际需求。（少数人） > 对我而言，重要的是在准确率不变的前提下推理更短，而不是分数稍微高一点。（@mehdi_zare）

反对将开源模型优化后闭源牟利

• 有用户反感公司基于开源权重模型做微小优化后便设门槛限制访问或收费，呼吁原模型方修改许可证以杜绝此类做法。（少数人） > 我真不喜欢这些公司拿开源权重模型，然后对自家那点微小改进设起门槛、限制使用。（@jacquesm）

嘲讽效率优化版是“卖性能选项”的老套路

• 有人引用官方“PRO 版减少最多 87.6% 思考 token 并招揽企业客户”的宣传，讽刺软件行业又开始像多核时代初期那样兜售性能选项，属于旧瓶装新酒。（代表社区情绪）

有价值的补充

• 小模型并非真的“更高效”，而是把本该由模型参数承担的计算转移到了推理时，用更多 token 或循环迭代来完成；任务难度是守恒的，很多小 MoE 的高吞吐并没有转化成更好的结果。
• 在自有硬件上，通过改进推理引擎和 harness 往往能带来 1.5 倍以上的每秒 token 提升，因此比起费力减少思考 token，让输出本身跑得更快可能是更直接的优化方向。
• 有用户提到 Qwen 的 Byteshape's Quant 量化版本在人文类任务上又快又好，小模型的表现远超预期，侧面说明社区对“小而强”的模型仍有惊喜感。