在你的推理集群中的某个地方，可能有一块芯片正在计算错误答案。不是崩溃 —— 而是错误答案。它通过了制造测试，通过了健康检查，但在指令序列、数据值、电压和温度的特定组合下，它会返回一个完全错误的数字。超大规模云服务商已经在大规模范围内记录了这一现象：大约每千台设备中就有一台会发生静默数据损坏（Silent Data Corruption），这一比率比我们过去担心的宇宙射线导致的比特翻转（bit flip）要高出几个数量级。
五十年来，软件拥有一种针对此情况的免疫系统：确定性（Determinism）。相同的输入，相同的输出 —— 因此你可以进行校验和（checksum）、回放，并与基准结果（golden results）进行对比，撒谎的硬件最终会被抓获。LLM 推理是第一个失去这种免疫系统的主要工作负载。当模型给出一个略差的答案时，是因为采样器的随机性，还是因为退化的 GPU 在你的 KV 缓存中翻转了比特？没人能通过检查来判断。一个不稳定的加速器可以在所有仪表盘显示正常的情况下，静默地拉低你的质量指标数周之久。
每千块芯片中就有一个在撒谎
证据自 2021 年以来一直在堆积。Google 的工程师将其描述为“反复无常的核心（mercurial cores）” —— 由于逃过了所有测试的制造缺陷，单个 CPU 核心会间歇性地计算出错误结果。一个反复无常的核心可能在 99.99% 的时间里都是正确的，仅当特定的指令在特定的温度下遇到特定的操作数时才会失败。Google 将实际损害追溯到了它们：损坏的加密密钥、崩溃的数据库索引、删除活动数据的垃圾回收。
Meta 对超过 100 万个生产环境中的 CPU 进行了系统性研究，并确认了问题的严重程度：静默数据损坏不是黑天鹅事件，而是大型集群的一种稳态属性，大约每千台设备就会发生一次故障。将其与历史上大约百万分之一的软错误基准相比，你就能理解为什么超大规模云服务商现在要进行持续的生产环境筛选。
有三种力量加剧了这一问题，且都在加速：
- 硅片密度（Silicon density）。 更小的晶体管意味着更多边缘化的晶体管，以及更多逃过测试覆盖的缺陷。
- 电压和频率缩放（Voltage and frequency scaling）。 为了达到效率目标，芯片运行在更接近其电力极限的状态，因此一个有轻微缺陷的电路在发生误操作前的余量更小。
- 加速器（Accelerators）。 GPU 封装了海量的算术单元，其单单元验证比 CPU 核心要少，而 AI 工作负载恰恰在持续的高温下全天候地锤炼这些单元。
对 AI 团队来说，结论是：你所运行的硬件正以低但非零的比率在撒谎，而你恰好购买了大量的此类硬件。
确定性曾是免疫系统
回顾一下旧有的防御机制是很有意义的，因为它们的丧失正是故事的核心。
经典的分布式系统假设即使硬件不可信，软件也是确定的。这一单一假设支撑着每一层损坏防御：校验和验证字节在传输中幸存；写后读取（write-then-read-back）验证存储；在两台机器上运行相同的计算并比较输出，能以近乎绝对的把握抓获撒谎的核心；将可疑任务针对基准输出进行回放，能将“数字看起来很奇怪”转变为二进制的判定。Meta 的集群工具链就建立在此之上 —— 带有已知正确答案的有针对性的微基准测试，要么在维护窗口运行，要么切入生产任务之间毫秒级的间隙中运行。Google 在生产环境中持续对 CPU 进行模糊测试，将实际硅片的计算结果与架构定义的规范结果进行对比。
所有这些技术都归结为同一个原语：计算两次，精确比较。 精确比较是将静默损坏转化为显性损坏的关键。
现在看看 LLM 推理。采样是有意随机的。浮点数归约（Floating-point reductions）不满足结合律，因此结果会随执行顺序而产生合理的波动。而近年来最尖锐的发现是：即使在 Temperature 为 0 时，生产环境的推理也不是确定的，因为归约内核（reduction kernels）会根据批次大小（batch size）产生不同的数值结果，而批次的构成取决于那一毫秒内恰好到达的其他请求。一个团队在 Temperature 为 0 的情况下，通过一个流行的开源模型运行了 1,000 次相同的提示词，结果得到了 80 种不同的补全结果 —— 而这还是在健康的硬件上。比特级比较，这一作为五十年损坏防御基础的原语，在完全正常的集群上也会整天返回“不匹配”。
因此，曾经用于警示硬件撒谎的警报，现在会因为各种良性原因不断响起，这等同于警报从未响过。
撒谎的 GPU 在 LLM 中是什么样的
大多数工程师的直觉 —— “比特翻转会产生 NaN 或乱码，我们会注意到的” —— 被证明大错特错。对 LLM 工作负载中永久性 GPU 缺陷的故障注入研究发现，NaN 和无穷大值仅占静默损坏结果的 1% 左右。绝大多数损坏的值在数值上仍然是合理的：一个偏移了几个百分点的激活值，一个略微偏高的 logit，或者一个将概率权重转移到错误标记上的注意力分数。只有不到 40% 的比特翻转事件是单比特的；真实的缺陷会以更混乱、更有规律的方式损坏数值。
追踪一个有缺陷的乘加单元（multiply-accumulate unit）出现在你的推理服务器路径上会发生什么：
- 早期层的损坏值会传播到随后的每一层 —— Transformer 没有内部纠错机制，而归一化层会“贴心地”将损坏扩散到整个隐藏状态。
- KV 缓存中的比特翻转更糟糕：损坏的键或值在随后的每个解码步骤中都会被重复读取，因此一次翻转就会污染生成的整个剩余部分。
- 可见的症状不是胡言乱语。而是一个略微错误的答案，一个幻觉细节，一个在第四步脱轨的推理链 —— 这些输出与模型的普通失败模式难以区分。
这就是为什么故障表现为“模型在某些请求上似乎变笨了”。用户报告不一致；你的评测（evals）在噪声带内波动；值班工程师重新运行可疑提示词，得到了一个不错的答案（不同的批次，不同的 GPU），然后关闭了工单。与此同时，每个路由到那个坏加速器的请求都在玩一场灌铅骰子的质量抽奖。
训练让代价变得具体。Meta 的 Llama 3 团队报告称，在 16,384 块 H100 上进行 54 天的运行期间，他们遭遇了 466 次任务中断 —— 更具代表性的是，还检测到了 6 起静默数据损坏事件。而这些仅仅是他们抓获的。训练中检测到的静默数据损坏（SDC）至少最终会通过损失激增（loss spikes）或检查点（checkpoints）的校验和不匹配来宣告自己的存在；一个以数值合理的方式损坏的梯度，只会在数十亿次参数更新中不断复合。推理则没有训练那样的补救机会 —— 它没有损失曲线，没有检查点回放。错误的答案被发送给用户一次，然后就烟消云散了。
在随机性集群中检测“说谎者”
你无法免费获得精确的对比结果，但你可以重建旧防御机制的统计版本。那些行之有效的技术都有一个共同点：在狭窄、受控的路径中重新引入确定性，或者按主机汇总质量信号，直到硬件效应从采样噪声中分离出来。
使用固定种子的金丝雀提示词。 维护一组具有已知良好输出的固定提示词，并按计划在每台主机上运行——这相当于大语言模型（LLM）版本的 Meta 微基准测试（带有标准答案）。为了使对比具有意义，请固定所有能固定的变量：贪婪解码（greedy decoding）、固定种子，以及理想情况下的批次无关算子（batch-invariant kernels，现在主流推理引擎已支持，且吞吐量成本较低）或单批次金丝雀路径。在这些条件下，单台主机上的输出差异就是证据，而不是噪声。在 token 级别进行精确匹配评分；如果一台主机在之前能通过的金丝雀测试中开始出现差异，那么它理应被隔离并进行硬件诊断。
贪婪解码校验路径。 金丝雀测试的泛化版：将一小部分真实的生产流量路由到确定性配置中，在两台主机上重复执行，并对比 token 流。不一致性可以在单次观察中将故障定位到两台机器中的一台。这是“双重计算”（compute-the-thing-twice）的复兴——你只需要在进行对比的路径中买回确定性。成本仅为集群容量的几个百分点，对于一个每 1,000 台设备中就有 1 台会说谎的集群来说，这是廉价的保险。
逐主机的质量回归统计。 采样噪声会相互抵消，但硬件问题不会。为每个响应打上产生它的主机（最好还有 GPU）的标签，然后跟踪每台主机的质量代理指标：采样流量的评估分数、拒绝率、生成 token 的平均对数概率（mean logprob）、输出长度分布、用户反馈率。任何单次请求都说明不了问题。但每台主机每天一万次请求就能为你提供分布情况，而如果某台主机的分布偏离了集群的整体水平，那么它要么是配置错误，要么是在说谎。前提条件——推理遥测数据中的主机级归因——是大多数团队缺失的一环；如果没有它，坏掉的 GPU 所造成的破坏会被无形地抹平在汇总指标中。
引擎中的数值合理性守卫。 推理引擎可以廉价地监控故障注入研究所识别出的特征：超出历史区间（envelopes）的激活幅值、跨内存地址的周期性损坏模式、输出范数在某台设备上激增但在同类设备中却没有的层。这些措施能及早且廉价地捕捉到粗糙的损坏，从而让统计机制去捕捉那些细微的异常。
这一切并不罕见。这就是超大规模架构下的 SDC（静默数据损坏）应对策略——金丝雀测试、重复对比、全集群异常检测——从精确对比转化为统计学方法，并在对比发生的路径中有意地重新购回确定性。
当你看不到硬件时该提出什么要求
大多数团队并不运行自己的加速器，而是从 API 购买 token。但这并不会让问题消失——它只是变成了合同问题。你的供应商的集群同样拥有和其他人一样的千分之一设备故障率，而你的可见性甚至比他们还要低。值得询问的问题（按答案的信息量排序）：
- 你是否在准入和运行过程中持续筛查加速器的静默数据损坏？ “我们的供应商测试过它们”是一个危险信号；测试遗漏缺陷和老化诱发的故障恰恰是供应商测试会错过的，这也是为什么 Google 和 Meta 会在生产环境中进行筛查。
- 你能否在事后将特定的请求归因到特定的设备？ 如果他们不能，那么你提出的任何质量投诉都无法追溯到硬件，“模型偶尔会那样”就变成了一个无法证伪的借口。
- 你是否在每台主机上运行固定提示词的金丝雀测试？如果测试失败会发生什么？ 诚实的回答应包括隔离工作流和检测所需时长。
- 当你发现损坏的设备时，是否会通知受影响的客户？ 询问他们上一次发生此类事件是什么时候。如果在一个拥有数万个加速器的集群中“从未发现过一个”，那就意味着他们从未寻找过。
对于你这一侧，请保留证据以使降级变得可检测：记录完整的请求参数和响应，定期针对供应商运行你自己的固定评估库，并绘制随时间变化的结果图表。如果你的金丝雀评分连续一周下降，并在供应商下一次维护窗口后恢复，你就学到了一些状态页（status page）永远不会告诉你的东西。
现在的信任建立在统计学之上
更深层的转变是观念上的。几十年来，我们构建的系统，其正确性是一个可以检查的属性——重新计算、对比、得出结论。随机性软件终结了这一点，而且时机很糟糕：它终结的那一刻，正值硬件进入几十年来最不可信的时代，其故障率比旧基准高出千倍，而集群规模也扩大了千倍。
替代方案并非绝望，而是统计学。在不可靠硬件上运行的随机系统的正确性是一种分布属性——这台主机的输出是否与其同行来自同一分布——而验证这一点需要深思熟虑的工程设计：确定性对比路径、逐设备归因、以及在硬件所在的粒度级别上汇总质量指标。构建了这一机制的团队能在几天内抓获说谎的芯片。而不构建这些机制的团队将花费数个季度去追踪“模型变差了”的反馈，而任何提示词优化都无法解决这些问题，因为模型从来都不是问题所在。
硬件会以已知的概率说谎。唯一的问题是，你的可观测性构建是否足以察觉到这一点。
会员专享
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- —完整文章，包含未公开存档的部分
- —可落地的工作框架，附带权衡与决策依据
- —新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部
