所有教科书都告诉你 Softmax 是对的——但浮点数不这么想，Gemini 翻出了两个埋了多年的 Bug
AI飞行客 所有教科书都告诉你 Softmax 是对的——但浮点数不这么想，Gemini 翻出了两个埋了多年的 Bug
先说清楚这件事的级别。
Softmax 和交叉熵——这是深度学习里用得最多的两个函数。图像分类、文本生成、语音识别、强化学习……几乎所有带”监督”二字的训练流程都依赖它们。API 调用它们是调包的一行代码，教科书里它们的数学公式写过无数遍，那行代码在过去十年里没几个人怀疑过。
上周，Google DeepMind 首席研究科学家 Jonathan T. Barron 在 arXiv 上提交了一篇论文《A Fix for Softmax and Cross-Entropy》（arXiv: 2610.31642）。
指出：PyTorch、JAX、TensorFlow 等所有主流框架里，Softmax 和交叉熵的标准实现，藏着两个数值精度 Bug。
平时难以察觉。但会在模型训练的特定阶段悄悄改变梯度，造成损失突然飙升，甚至让模型学到的能力出现退化。
而发现这两个 Bug 的，是一整套由 Gemini 参与的流程——从发现问题、修复方案设计、跑实验到写论文初稿。
等于说，模型不仅发现了教科书的公式在计算机上有问题，还自己设计出了修复方案，自己做了验证，自己写了论文。
两个 Bug，分别是什么
Bug 一：Softmax Collapse（Softmax 坍缩）
Softmax 负责把网络输出的原始分数（Logit）变成概率。比如猫 99%，狗 0.5%，鸟 0.5%。模型越自信，正确的那个 Logit 和其他 Logit 之间的差距就越大。
为了在计算机上做数值稳定处理，标准实现会先从所有 Logit 里减去最大值，再做指数计算。这原本是为了防止溢出。
但问题来了：当正确类别的 Logit 远大于其他类别的 Logit 时，减去最大值之后，正确类别的指数值变成了 1，其他类别变成了一些极小的正数。
Softmax 的分母是 1 + 一堆极小的数。
在 fp32 精度下，当这个”极小的数”小到一定程度，计算机在加法里会直接把它舍去。结果是：分母直接算成了 1。正确类别的预测概率 = 精确的 1。交叉熵损失 = 精确的 0。正确类别的梯度被算成了 0。
但其他错误类别的梯度还保留着微小的非零值。数学上，所有类别梯度之和应该为 0，这个约束被打破了。
论文给出了一条精确的临界线：
| 精度格式 | 精度悬崖位置 | |—|—| | bf16 | Logit Margin ~5.5 | | fp32 | Logit Margin ~16.6 | | fp64 | Logit Margin ~36.7 |
什么是 Logit Margin？就是正确类别 Logit 比其他类别合计的优势有多大。在 fp32 下，一旦这个优势超过约 16.6（对应的正确概率约 99.9999938%），梯度就碎了。
Bug 二：Softmax Cancellation（Softmax 相消误差）
这个 Bug 发生在知识蒸馏场景。
蒸馏时，教师模型给学生模型提供目标概率分布。学生学教师，当学生已经学到和教师一样的 Logit 时，梯度在数学上应该为 0——学生已经跟教师一样了，不需要再更新了。
但标准实现里：分别计算教师和学生的 Softmax 概率，再相减得到梯度。当两组概率非常接近时，浮点运算会吃掉它们之间的极其微小的差异。前向的 Softmax 和反向的 Log-Softmax 用了不同的运算顺序，产生的舍入误差不抵消，留下了一个本不该存在的梯度。
这个残余梯度看起来微乎其微。但 Adam 优化器会用它的历史梯度记录来放大小变化。
实验证明：在模 53 加法蒸馏任务中，直接把教师的权重复制给学生（学生和教师完全相同），用标准实现继续训 2000 步。bf16 下，学生明显偏离了教师，测试准确率也随之下降。修复版本下，学生一直保持与教师一致。
为什么 Adam 的默认参数卡在了悬崖边上
这篇论文里最让我头皮发麻的一处。
Adam 优化器有一个常用超参数 ε（epsilon），默认通常是 10⁻⁸。它实际上是用在梯度归一化的分母里，防止除零。
论文发现：在模型已经记住训练集、并且使用权重衰减的条件下，Logit Margin 的增长会受到权重衰减与 Adam 更新之间的平衡关系的限制。这个平衡值大约满足：
m ≈ ln(1/ε)
当 ε = 10⁻⁸ 时，m ≈ 18.4。
而 fp32 的精度悬崖在哪里？16.6。
也就是说，模型在自然训练中接近平衡位置之前，就已经走到了精度悬崖的边上。
Adam 的默认设置，恰好把模型推到了悬崖边缘。
很多研究者可能遇到过训练不稳定，抱怨”Adam 不好调”、”loss 突然崩了”——却从来没想过，问题可能不在架构、不在数据、不在超参，而在那行所有人都在用的标准实现里。
这个修复方案本身：不升精度，改计算顺序
Barron 团队没有选择用 fp64 跳过问题，也没有重新设计损失函数或者替换 Softmax。他们选择保留原有的数学定义，重新组织计算过程——把最大 Logit 对应的项从指数求和中单独分离，用数值稳定的 softplus 函数完成计算。
对于第一个 Bug，修复后的公式能让自动微分直接得到正确的梯度关系。
对于第二个 Bug，从学生与教师的 Logit 差值出发，直接在对数空间中计算概率差——使用了 expm1 和 log1p 两个专门处理接近零的小值运算函数。
修复后不需要升精度，不需要换函数，不需要改现有训练流程。代价极小，解决清晰。
Gemini 在这件事里干了什么
这是论文的方法论本身也值得说。
按 Barron 的说法：
– Softmax Cancellation 最早由 Gemini Flash 3.7 发现并给出修复方案 – 论文里的大部分实验由 Gemini Flash 3.8 完成 – 论文初稿是 Gemini 4 Argon 写的
Barron 的原话是：Argon 完成了论文以及图表的初稿；他严格审查并反复修改了技术内容，但对文字表达仍然不太满意。
你看这段话的信息量有多大——AI 已经不是在帮人类找 Bug 了，它参与了完整的科研闭环：发现问题、设计方案、跑实验、写论文。
Barron 的团队在做的是审核和把关。
再往回看一遍那篇论文的标题：《A Fix for Softmax and Cross-Entropy》。
一个最基础的深度学习函数。一篇由一个人类加几个 AI 合作完成的论文。耿直到连一个”炫”字都没有的标题。
这才是 2026 年 AI 研究的标准姿势。
但这件事的实际影响有多大？说点实话
论文承认：实验中让梯度崩掉的极端 Logit Margin，在常规大规模训练里并不常见。所以不能直接下结论说”主流模型的训练都深受其害”。 更不能直接说”修掉 Bug 就能让训练整体提速”。
但这项工作的价值不取决于”它能不能让大模型训练更快”。
它的价值在于：
– 那些”loss 突然崩了”的问题，至少有一部分是能解释的了 – 那些”我怎么调 Adam 都调不好”的抱怨，可能有答案了 – 那些科研工作者在写论文时提到”Grokking”和”弹弓机制”时，对信号和噪声的区分，可能因为这个发现而更清晰了
无论你用什么框架，至少在理解训练为什么会出各种意外时，你可以再往前多走一步了。
还有一个实际价值：论文给的修复方案加在自己的代码里，代价很低——它没有对神经网络的正向计算造成任何影响，而是在反向传播的过程中使用更精准的数值计算方法。对于用到知识蒸馏或对数值稳定性有较高要求的场景，这个改动几乎是零成本升级。
我的判断
第一，这件事最值得记住的，不是 Bug 本身，而是”数学正确”不等于”实现正确”。
你写一行 `cross_entropy(pred, target)`，数学公式是对的，API 文档是对的，调用方式是标准的——但计算机在浮点数层面舍入了一部分信息。然后你的模型莫名其妙不收敛了，你换了三个架构、调了两周参数、刷了一百遍学习率，没找到原因。
这不是你个人的问题，是工具链的暗角。
第二，Adam 默认 ε 恰好卡在精度悬崖这个发现，是最好的科普级故事。
它用一个简单公式告诉你：你的优化器默认参数，刚好把模型推到了陷阱边上。 一个简单的 m ≈ ln(1/ε) 关系，把精度问题、优化器行为、训练稳定性串了起来。
不解释 Slingshot 的完整理论，也足够让人重新检查自己的 Adam 设置。
第三，Gemini 在这件事里的角色，已经超越”找 Bug”。
它不是在扫描代码找逻辑错误——它是先发现了数值问题，再设计了修复方案，再自己跑实验验证，再写论文初稿。这是完整的科研链路，不是工具辅助。
Barron 的团队仍然在做技术审计和质量把关。但 AI 在科研流程中的占比，已经从”配角”变成了”不分座的合作者”。
而二作的作者栏里，写的到底是谁的名字？
—
*论文：A Fix for Softmax and Cross-Entropy — arXiv: 2610.31642 (2026-10-22)* *团队：Jonathan T. Barron (Google DeepMind), Dan Gnanapragasam, Michael Tschannen* *参与模型：Gemini Flash 3.7（发现 Bug）、Gemini Flash 3.8（实验）、Gemini 4 Argon（论文初稿）* *影响：PyTorch / JAX / TensorFlow / Optax 等框架标准实现均受波及* *来源：机器之心 / AITNT / 新智元综合报道*