Gemma 4砍掉七成思考Token

Gemma 4开始解决“想得太多”

Gemma-4-26B-A4B最近被测出可以在准确率保持不变的情况下，将思考Token减少39%—69%。这项结果来自Bottlecap AI近期公布的ThinkingCap实验，重点不是让模型回答得更聪明，而是压缩模型在给出最终答案前生成的内部推理内容。

思考Token是推理模型为分析问题、验证步骤和修正答案而生成的中间Token。它们通常不会全部展示给用户，却依然会消耗解码时间、KV Cache和计算资源；对于按Token计费的服务，它们还会直接进入成本账单。

这项实验最值得关注的地方，是Gemma-4-26B-A4B减少的并非输入上下文或最终答案长度，而是最容易失控的推理预算。39%—69%的降幅意味着，原本需要生成1000个思考Token的任务，现在可能只需要310—610个，而最终准确率没有因推理过程缩短而下降。

这不是一个新的模型能力纪录，而是一次更接近生产环境的效率优化。过去一年，推理模型普遍通过“多想一会儿”换取更高准确率，但当模型把简单问题也做成数学证明，继续增加Token就会迅速进入边际收益递减区间。

39%—69%究竟意味着什么

39%—69%的思考Token降幅首先意味着解码阶段的工作量显著减少。大模型生成Token通常是串行过程，下一个Token需要等待上一个Token完成，因此输出阶段很难像提示词预填充那样充分并行；少生成数百个Token，往往比少输入数百个Token更直接地改善响应时间。

准确率保持不变是指测试集上的最终答题正确率没有因减少思考量而下降。这不等于每一道题的回答完全相同，也不意味着模型在所有真实业务中都能稳定复现相同结果，更不能理解为思考Token越少越好。

| 指标 | 实验结论 | 对开发者的实际意义 | 不能直接推出的结论 | |---|---:|---|---| | 思考Token | 减少39%—69% | 降低串行解码量与KV Cache增长 | 所有任务都能减少69% | | 准确率 | 测试条件下保持不变 | 可在不牺牲基准成绩的前提下节省预算 | 每个样本、每次采样都完全一致 | | 首Token延迟 | 不一定明显变化 | Prompt预填充阶段基本不受影响 | 用户一定能更快看到第一个字 | | 完整响应延迟 | 通常有机会下降 | 长推理任务收益最明显 | 延迟一定按Token比例线性下降 | | 服务成本 | 取决于部署方式 | 云端按输出计费或高并发部署更受益 | 本地电费会固定下降69% |

端到端延迟不会自动下降同样的39%—69%。如果一次请求的总时间由模型加载、长上下文预填充、图像编码、工具执行或网络传输主导，减少思考Token只能优化其中的解码部分；只有在推理生成占主要耗时的任务中，Token降幅才会接近体感速度提升。

成本收益同样取决于服务的计费与调度方式。按输出Token计费时，减少1000个思考Token几乎可以直接换算成账单下降；自建服务则更看重GPU占用时间、并发吞吐和KV Cache容量，收益不会体现在一张单次调用账单上，却可能让同一张卡同时容纳更多请求。

Gemma-4-26B-A4B为什么适合做这件事

Gemma-4-26B-A4B是Google DeepMind推出的混合专家模型，拥有约25.2B总参数，但每个Token推理时只激活约3.8B参数。混合专家模型（MoE）是把模型拆成多个专家网络，并由路由器为每个Token选择少量专家参与计算的架构。

A4B中的“A4B”可以理解为每个Token激活约40亿参数，而不是模型总共只有40亿参数。这让它在能力上接近更大的稠密模型，同时把单Token计算量压低，但模型权重仍需完整装入内存，因此“计算轻”和“占用小”不能画等号。

Gemma-4-26B-A4B的官方成绩说明，它并不是一款只追求速度的小模型。根据Hugging Face官方模型卡，该模型在MMLU Pro上取得82.6%，AIME 2026无工具测试为88.3%，LiveCodeBench v6为77.1%，GPQA Diamond为82.3%，MMMU Pro为73.8%。

| 模型 | MMLU Pro | AIME 2026无工具 | LiveCodeBench v6 | GPQA Diamond | MMMU Pro | |---|---:|---:|---:|---:|---:| | Gemma 4 31B | 85.2% | 89.2% | 80.0% | 84.3% | 76.9% | | Gemma 4 26B A4B | 82.6% | 88.3% | 77.1% | 82.3% | 73.8% | | Gemma 4 12B Unified | 77.2% | 77.5% | 72.0% | 78.8% | 69.1% | | Gemma 3 27B（非思考） | 67.6% | 20.8% | 29.1% | 42.4% | 49.7% |

这组数据表明，26B A4B和31B旗舰版之间的差距多数只有几个百分点，但前者每个Token仅激活约3.8B参数。对于需要本地部署、批量处理代码或运行智能体的团队，它比单纯追求最高跑分的31B版本更容易找到性能、显存与吞吐量之间的平衡。

思考压缩会进一步放大MoE架构的效率优势。MoE已经减少了每个Token参与计算的参数量，ThinkingCap一类策略则减少需要生成的Token数量，两项优化分别作用于“每一步有多贵”和“总共走多少步”。

这更像推理预算管理，而不是剪掉模型能力

ThinkingCap可以理解为对模型推理预算进行约束和校准的方法。它解决的问题不是模型不会推理，而是模型缺乏可靠的停止意识：简单问题已经得到答案后，仍可能继续复述、检查、推翻并重新推导。

推理冗余在数学和代码任务中尤其常见。模型可能先找到正确思路，再用多段文字重复验证；也可能在答案已经足够确定时主动寻找不存在的反例，最终不仅浪费Token，还增加把正确答案改错的风险。

减少思考Token却不降低准确率，说明被删除的部分至少在当前测试中主要属于低价值推理。它们可能是重复表述、过度检查、无效分支或答案已经收敛后的继续生成，而不是决定正确答案所必需的关键步骤。

这个结论也解释了为什么“给模型更多思考预算”并非总是有效。推理预算从100个Token增加到1000个Token，可能让模型补全缺失步骤；从5000个增加到10000个Token，则可能只是让它绕更远的路，甚至陷入自我怀疑和思考循环。

开发者应该怎样验证

开发者不应该只看平均准确率，而应同时记录正确率、思考Token、完整响应时间和失败模式。平均值可能掩盖长尾问题：大多数简单请求减少80%，少数难题却因为预算不足直接失败，最终平均准确率仍可能看起来变化不大。

一套可用的内部评测至少应包含以下指标：

• 任务准确率：最终答案是否正确，代码任务还应实际执行测试用例。
• 思考Token中位数：比平均数更能反映典型请求的消耗。
• P95思考Token：用于发现思考循环和极端长输出。
• 端到端延迟：从请求进入到最终答案完成，而不只是模型解码时间。
• 首次Token延迟：判断优化是否真正改善交互体验。
• 每秒生成Token数：用于区分模型变快和单纯生成变短。
• 多次采样方差：同一问题至少运行多次，避免一次随机采样造成误判。
• 格式与工具成功率：智能体任务不能只看文本答案，还要检查工具参数是否可执行。

测试集必须贴近真实业务，而不能只使用AIME或GPQA等标准基准。数学竞赛适合衡量复杂推理，但企业知识问答、代码修改、结构化抽取、工具调用和长文档分析对思考预算的敏感度完全不同。

开发者还应把任务按难度分层，而不是给所有请求设置同一预算。分类、改写和简单检索可以采用较短思考；代码调试、多约束规划和高难数学题则保留更高上限；当首次推理的置信度不足或执行验证失败时，再触发第二轮深度推理。

这种动态策略比“一刀切砍掉一半Token”更可靠。真正成熟的推理预算管理，应让模型在简单问题上尽快停止，在难题上保留继续搜索的空间，而不是把固定Token上限当成唯一控制手段。

量化可能比思考压缩更容易破坏效果

Gemma-4-26B-A4B的本地运行门槛仍然主要由权重内存决定。公开部署资料显示，该模型采用4位量化时通常需要约16—18GB总内存，8位量化约需28—30GB，而BF16或FP16版本约需52GB。

| 精度 | 26B A4B预计内存需求 | 适合场景 | 主要风险 | |---|---:|---|---| | 4-bit | 16—18GB | 单张消费级显卡、统一内存设备 | 工具调用与代码精度可能下降 | | 8-bit | 28—30GB | 高端工作站、追求稳定输出 | 内存要求明显提高 | | BF16/FP16 | 约52GB | 服务器或多卡环境 | 成本高、部署复杂 |

MoE模型对量化误差可能更敏感，因为路由决策和专家权重共同决定每个Token的输出。社区已有用户反馈，Gemma-4-26B-A4B在较激进的IQ4量化下仍能完成普通对话，但工具调用、结构化输出和代码任务更容易暴露问题；这类经验尚不能替代系统测试，却足以提醒开发者不要把“能加载”误认为“能上线”。

量化误差与思考预算还可能相互放大。模型在低精度下如果需要更多步骤修正早期偏差，过度压缩思考Token就可能提前截断纠错过程；相反，一个接近原始精度的Q6、Q8或BF16模型，更有机会在较短推理中一次走对。

因此，生产部署的测试顺序应该是先确定可接受的量化精度，再优化思考预算。否则开发者很难判断准确率下降究竟来自Token不足、采样参数变化，还是量化本身已经破坏了路由与指令遵循能力。

“准确率不变”仍有三层限制

准确率不变只对实验覆盖的任务分布成立。模型在数学题上可以删掉重复验算，并不代表它在智能体规划、复杂工具调用或长上下文取证中也能安全减少相同比例。

统计波动也可能掩盖小幅能力变化。如果测试集只有几百道题，少量样本的得失就会让准确率上下浮动；只有报告多次运行结果、置信区间和逐类别表现，才能判断“不变”是严格等价，还是变化尚未达到统计显著性。

Token数量也不是推理质量的完整代理指标。两个模型都使用500个思考Token，其中一个可能在关键约束上逐步收敛，另一个可能重复同一句话；开发者最终要优化的是单位延迟和单位成本下的任务成功率，而不是单独追求最低Token数。

这项优化最适合哪些场景

高并发本地服务会最先感受到思考Token下降的价值。每个请求少占用一段解码时间和KV Cache，调度器就能更快释放资源，尤其适合代码补全、内部知识问答和批量数据处理。

智能体应用也会从更短的单步推理中获益。一个任务如果需要模型连续执行10次规划、搜索和工具调用，每一步少生成几百个Token，累计节省可能远高于单轮聊天；不过工具参数准确率必须单独评估，不能只检查最终文本看起来是否合理。

普通闲聊的收益反而可能有限。简单对话本来就不需要长推理，如果主要延迟来自模型加载和首Token等待，减少隐藏思考对体感速度的影响不会像数学、代码和规划任务那样明显。

判断：这比再涨两个跑分更实用

Gemma-4-26B-A4B减少39%—69%思考Token的意义，在于它把开源推理模型的竞争从“谁愿意想得更久”推进到“谁知道什么时候该停”。对于已经达到可用准确率的模型，控制冗余推理通常比继续堆计算更有现实价值。

这项结果目前更适合作为部署优化方向，而不是一条可以无条件套用的性能承诺。开发者需要在自己的任务、量化版本、采样参数和硬件环境中复测，尤其要观察长尾失败、工具调用和P95延迟。

Gemma-4-26B-A4B本身也因此成为一个颇有吸引力的本地模型：约25.2B总参数提供了足够的知识与能力，每Token约3.8B激活参数控制了计算量，再叠加更克制的思考预算，它比单纯缩小模型更可能守住准确率。

截至2026年10月23日，开发者真正应该关注的已不是模型能否生成更长的推理链，而是每一个额外Token有没有带来可测量的正确率收益。能少想39%—69%却不答错，至少说明推理模型的下一轮优化空间，很可能藏在“停止”而不是“继续”里。

参考来源

• Gemma-4-26B-A4B-it 官方模型卡：Google发布的模型参数、能力说明与官方基准成绩。
• Reddit：Gemma 4 26B本地使用讨论：社区用户对模型速度、思考循环和本地部署表现的经验反馈。