当每个系统都在自保：3.8 GW 负载退出之后

2026 年 7 月 22 日早上 7 点 56 分，北弗吉尼亚一条 230 kV 输电线路发生机械故障。保护系统切除了故障，没有继电器误动作，也没有断路器拒动。按设备层面的检查结果看，这一段处理没有出错。

麻烦发生在随后。电压扰动让一批数据中心切换到备用电源；公共电网的取电需求骤降，电压升高，又触发了第二批机房切换。不到两分钟，约 3,800 MW，也就是 3.8 GW 的负载离开公共电网。PJM 与 Dominion 的初步调查把它记录为 PJM 经历过的最大一次此类负载转移。

这不是 3.8 GW 的服务器停机。负载转到了备用供电，变的是电力来源。PJM 后来的事件说明也明确说，电网没有受到显著的可靠性损害。频率一度达到 60.092 Hz，调度人员降低发电出力、调整无功资源；区域控制误差限值的越限在九分钟内恢复，Dominion 报告客户在三十分钟内重新接回电网。

我在意的是中间那段相互作用：机房为了保住业务切换电源，这个动作却改变了其他机房接下来要面对的供电条件。不能只问 UPS 是否保护好了服务器，还得问它离开电网以后，外面发生了什么。

一分钟三次扰动，机房决定不再回来

理解这种反应，得先把“切备用电源”拆开。UPS 可以在电压暂降时用电池维持关键负载，随后恢复从电网取电；采用飞轮和柴油机的旋转式 UPS，则可能更长时间依靠备用系统。即使硬件相同，运营方加在上面的控制规则也可能改变恢复行为。它们对服务器都叫不间断供电，对电网却不一定是同一种负载。

2024 年 7 月 10 日的另一场事件，把这种差别暴露得很具体。一条 230 kV 线路的避雷器故障后，自动重合闸在 82 秒内形成六次故障及清除过程。每次持续 42 至 66 毫秒，都被保护系统正常清除，但约 1,500 MW 的数据中心负载退出了电网。NERC 的调查报告记录了机房侧一种典型规则：一分钟内数到三次电压扰动，就转备用供电，直到人工接回。

线路侧反复重合闸，是在尝试恢复供电；机房侧连续数到异常，则是在判断外部电网不值得继续信任。第三次电压暂降附近，约 1,260 MW 负载退出，数小时没有返回。NERC 把大部分持续性负载下降归因于重合闸序列与扰动计数控制的交互。

不需要假设某台 UPS 坏了，才能解释这段过程。短暂的电气扰动经过控制规则，变成了持续的取电变化。但也不能拿 2024 年查到的“一分钟三次”直接解释 2026 年所有机房的动作：后者公开材料仍是初步调查，不同设施的设备参数和配置需要分别确认。

这一区别会影响整改方向。如果是设备扛不住，可能要改硬件；如果是额外控制逻辑过早转入长时间备用状态，就要检查触发条件和恢复规则。把两者混成“机房太敏感”，很难知道到底该改哪一层。

少用电，为什么也会给电网添麻烦

谈数据中心与 AI，我们常问电够不够、GPU 会吃掉多少新增容量。7 月的事件却从反方向提出问题：一大片负载突然不取电了，电网能不能及时跟上？

发电与用电需要持续平衡。负载瞬间下降、发电出力尚未同步降低，会暂时留下有功功率过剩，推动频率升高。电压还受无功平衡、线路阻抗与控制装置影响，不能把电压上升简单当成频率上升的另一种说法。它们可以被同一次负载变化触发，但分析和调节手段不同。

这次更棘手的地方是，第一批负载退出之后出现的高电压，又成了第二批机房保护动作的输入。后续扰动不全来自最初那根故障线路，也有一部分来自系统对故障的反应。PJM 的事件说明记录了这两波转移，不能把整个过程写成一次同时发生的“集体关机”。

所以，只提供峰值功率和一年预计用电量，不足以说明大型机房对电网的影响。同样规模的两个园区，一个在扰动清除后迅速恢复取电，另一个转备用后半小时不回来，对调度的要求会很不同。平均耗电相同，并不意味着动态响应相同。

这也让我对“冗余越多越可靠”多加了一个条件。不同机房可以各有一套 UPS、发电机和控制器，仍然共同暴露在同一场电压扰动下。它们未必坏了，也不需要互相通信，就可能作出高度相关的动作。冗余设备的数量，没有自动消除共同触发条件。

“局部最优”在这里是个比喻，不是计算结果

从运营方的目标看，尽快摆脱异常外部电源不难理解：服务器和制冷不断电，业务继续运行。电网要维持的却是整个区域的有功、无功与频率平衡。一个保护业务的选择，可以同时增加公共系统的调节工作。

“局部最优陷阱”能概括这个冲突的一面，但这个说法需要留点余地。没有各家机房的目标函数、耐受能力、成本和配置数据，我们无法证明当时的策略真是数学上的最优解，更不能把一次扰动叫作已经证实的纳什均衡。

比较稳妥的判断是：这些策略服务于局部可靠性目标，其外部影响没有在系统层面被充分约束。电网为突然消失的负载调整发电和电压，这些成本不一定全部落在作出切换决定的那家机房身上。这里有外部性，也有控制系统之间缺少协调的问题。

但不能据此说所有独立保护都会伤害整体。如果动作规模很小、响应足够分散，或者电网本就为这样的转移做好了准备，各自保护自己可能完全合理。需要研究的是共同触发条件、动作相关性、规模和响应速度的组合，而不是把“自主决策”本身当成故障原因。

我在这条故障链里看到了重试风暴

软件工程里有个熟悉的场景：后端变慢，客户端超时，于是重试。对一个调用方，多试一次可能换来成功；对已经过载的后端，成千上万个客户端一起多试一次，可能让队列更长，下一轮超时更多。

这与机房切换电源不是同一种物理过程，但反馈结构相似。参与者观察共同环境，为自己的任务采取补救；补救改变环境，又让更多参与者继续补救。Google 的 SRE Book讨论了重试预算、带随机扰动的退避、限制尝试次数和过载时降低工作量等做法。

其中“预算”很重要。假设一次请求在上、中、下三层各允许三次总尝试，最坏情况下，最下游可能收到 27 次调用，而不是三次。这是按调用层数构造的示例，不是本次电网事件的数据。每层单独看都像是很克制，组合起来却可能超出共享服务容量。

不过，不能顺手把“随机退避”搬到电气保护上。HTTP 调用可以等待，真正危险的电气故障往往要求保护在毫秒尺度动作。延迟必要保护，可能损坏设备。可以借鉴的是约束额外动作、协调恢复、验证集体响应的方法，不是照抄软件里的时间参数。

扩缩容也有相近的问题。几个上游服务各自因为 CPU 偏高增加实例，如果瓶颈在共享数据库，增加的只是更多并发连接。测试只看上游单服务吞吐量，很容易把压力转移当成改进。要判断有没有帮助，得同时看下游排队、总成功量和恢复时间。

测试不能停在 UPS 的出口

机房测试 UPS 切换、发电机启动、服务器是否断电；电网测试故障清除、断路器动作、重合闸时序。这些测试都不能省，但两边各自通过，仍然没有回答它们组合后的行为。

Nancy Leveson 的 STAMP 系统安全方法提供了一种补充视角：事故也可能来自正常运行组件之间的不安全交互，分析要涉及控制结构和约束，而不只寻找损坏的零件。我并不是说这次事件已经完成了 STAMP 分析，只是它提醒我们，测试边界不能刚好止于组织或设备的交接处。

如果我要审阅这种接入研究，会要求把负载响应说清楚：什么电压或频率条件触发切换，条件持续多久才生效，短暂异常是否被累计，退出后是否锁定，恢复由谁决定。正常功率曲线解释不了这些状态转换。

然后要把大量设施放在同一个扰动场景里看，而不是把单个模型简单复制几百份、默认动作彼此独立。相近阈值遇到同一电压曲线，可能一起跨过边界；第一波动作改变的电网状态，还应回到后续仿真输入里。

模型本身也要有证据。NERC 在 2026 年 3 月的大负载差距评估指出，负载模型验证和测量存在缺口，不能直接照搬发电机的现场试验方式。比较现实的路径，是在明确的安全边界内结合仿真、设备测试和真实扰动记录校准；必要时再考虑硬件在环。不能为了证明韧性，随意在生产电网上制造故障。

我还会单独看恢复。退出期间，调度已经降低发电出力；一大批负载突然接回，可能造成反方向的失衡。什么时候回来、恢复多快、是否需要外部协调，和什么时候离开同样值得测试。NERC 的 2024 年事件报告也特别提醒了受控重接和爬坡速率的风险。

留下多久，回来多快，需要提前约定

“为了电网稳定，不许机房切备用”是个过于省事的答案。超出设备耐受范围时，继续取电可能把风险留给服务器、制冷和业务。协调不是取消保护，而是划清哪些扰动应当穿越、哪些情况允许退出，以及保护之后怎样恢复。

PJM 在2026 年 9 月 8 日的方案里，给出了按电压幅度与持续时间划分的运行区间。在相应区间，允许负载暂时降低有功功率；电压回到大于 0.9、低于 1.1 p.u. 的范围后，要求两秒内恢复到扰动前 90% 以上。这里的 p.u. 是相对额定值的标幺量，不能把这个要求读成任何故障都必须撑住两秒。

截至本文写作时，本文引用的是提案，不是已经全面生效的统一标准。PJM 9 月 10 日的说明还提到与既有设施协商过渡安排。具体配置仍要依据适用要求、现场能力和系统研究，不宜从文章里抄一个阈值就上线。

还有成本归属。如果改进故障穿越、增加监测和动态建模主要帮公共电网降低风险，机房却独自承担投入，技术上可行也未必会主动发生。接入要求、责任划分与补偿机制会影响这个选择，不能都留给 UPS 控制器解决。

9 月 17 日，事情出现了一个有意思的对照。PJM 在供电紧张时启动需求响应，并获应急授权，必要时可以要求数据中心等大型客户切到备用发电。授权不等于所有客户已经执行；但它说明，切备用电源本身既不是好事，也不是坏事。缺电时的协调减载，与扰动中未经预期的集体退出，需要放在各自状态里判断。

编译器也能改写功率曲线

还有一条不直接涉及 UPS 的路径：在计算侧减少功率波动。传统集群里许多任务不同步，负载起伏有机会相互抵消；大型同步训练则可能让大量加速器一起计算、一起进入通信或等待阶段。GPU 数量与总峰值功率之外，时间上的相关性也会影响供配电设施。

Google 在 2025 年 2 月的技术文章里报告了集群层面数十 MW 的波动，并从 TPU 编译器入手：识别与功率变化有关的同步标记，在这些标记附近调整主要计算单元的活动，把利用率在时间上铺得更平滑。在披露的测试案例中，波动幅度降低近 50%，性能影响低于 1%。

这组结果不等于电费减半。文章同时提到平均功率小幅增加；被减小的是波动幅度，也不是证明所有训练任务都能达到相同效果。它更没有直接解决北弗吉尼亚的保护退出问题。这是计算负载整形，不是电压保护参数整改。

我觉得值得借鉴的，是把调度目标从“设备尽量忙”扩展到设施约束。任务启动顺序、可移动的批处理窗口、园区功率爬坡，都可能成为优化变量，但同步训练有依赖，错开计算也可能增加等待。是否划算，要测有效吞吐量、训练时间、能耗与功率曲线，不能只盯着 GPU 利用率，也不能不看业务代价就要求所有任务错峰。

Agent 变强以后，共享服务未必更轻松

换到 Agent 平台，问题会以熟悉的软件形式出现。下面是一个假想场景，不是已经观察到的同类事故：外部 API 变慢，每个 Agent 为了完成任务增加重试、搜索和交叉验证；这些额外调用继续拉长响应时间，于是下一轮规划又决定“再多查一点”。

更高的单任务成功率，可能是靠占用更多共享资源换来的。一个 Agent 从 95% 提升到 98%，若同时让其他任务等待数倍时间，单项成绩不足以判断平台有没有改进。这些百分比只是说明评估口径的假设数字。

实现上，我会把 API 总预算、并发上限和重试额度放在工具执行层，而不是只在提示词里要求节制。预算应覆盖整个任务和实际调用链，不能每生成一个子 Agent 就重新发一份额度；超出时明确返回限额或退避状态，避免规划器把它当成普通失败继续尝试。

恢复策略同样需要外部约束。服务刚恢复时，先限制放行量，再根据错误率和排队情况提高并发，比让所有任务同时补齐积压更容易观察和控制。验收也应看总完成量、尾延迟、其他任务是否被挤占，以及故障后的恢复时间。这是从软件场景推导出的设计建议，不是把电网的保护规则复制过来。

读完这次调查，我会在架构评审里加一个场景：假设所有组件都正确执行了自己的保护策略，系统接下来会怎样？如果测试只证明了每个机房不断电、每个客户端愿意重试、每个 Agent 更努力，仍然可能漏掉它们共同作用时的代价。

至于北弗吉尼亚，需要继续等待更完整的调查与模型验证，才能判断不同配置各承担了多大影响。现有记录已经足够说明，可靠性评审应把切换后的电网变化和负载恢复纳入边界；还不足以凭一个宏大的“局部最优”解释，替代这些具体工作。

本文依据截至 2026 年 10 月 8 日查阅的公开材料编辑。2026 年事件机制来自 PJM / Dominion 初步调查；2024 年的扰动计数配置来自 NERC 另一次事件报告，两者不混用。重试、扩缩容与 Agent 的讨论是软件工程类比和作者推导，不是此次事件的现场调查结论。