我把帖子里的两个"实验阈值"抄下来，用计算器按了一遍。fp32 的 -103.27，bf16 的 -92.18。按完发现，这俩数根本不用跑实验。IEEE 754 规范里写着呢。fp32 的最小次正规数是 2^-149，取自然对数：-149 × ln2 = -103.279。bf16 尾数只有 7 位，最小次正规数是 2^-133，-133 × ln2 = -92.189。跟论文附录表 4 的高精度值对到小数点后四位，分毫不差。
顺手还能回答一个疑问：bf16 和 fp32 指数位一样多，凭什么 bf16 先瞎？差在尾数。少 16 位精度，能表示的最小数就大了一万六千倍，e^x 归零提前了 11 个 nat。视力掉得快，是镜片磨薄了，眼睛本身没坏。
帖子主体忠实。机制、四种修复、按斜率依次失明，论文里都有对应原文。两处要修。
一处是它替论文编了句解释——"默认斜率恰好让下溢发生在不太关键的距离"。论文没这话。真实解释是：平斜率的头本来就是检索头，位置信号弱，远近都能看；陡斜率的头瞎了就退化成滑窗，靠多层接力把窗口拼长。是分工救了它。时机没这么巧。
另一处是建议的顺序。帖子首推对数距离，论文 §5.3 的默认推荐其实是 Clamping。对数距离在 passkey 上最灵，配上 clamping 把 AUC 从 0.08 拉到 0.79，接近十倍；但在大海捞针上反而不如原始 ALiBi。没有全能药，论文原话就这么说的。
最好玩的一个数：对数缩放把第一个头的失明距离从 124 个 token 推到 4.37×10^53。宇宙里原子也就 10^80 量级，这辈子的上下文窗口别想追上它了。
还有个考古彩蛋。论文考证 MPT 的实现早就把 bias 截断在 2000，但作者判断那是为了做软滑窗，跟浮点下溢无关。这 bug 有人顺手修过。修的人自己不知道在修 bug。
代码至今没放（论文脚注写着"Code will be released upon publication"），所以 2048 距离上 36.6% 条目下溢这种细节，我没法自己复现，只能信论文。下次谁跟我说"基准全正常"，我打算多问一句：passkey 测了吗。