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

2026 年 7 月 22 日早上 7 点 56 分，北弗吉尼亚一条 230 kV 输电线路发生机械故障。保护系统正常切除故障，继电器和断路器都完成了自己的工作。麻烦恰恰发生在这些设备各自尽责之后。

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

机房转到了备用供电，业务继续运行，公共电网却突然少了这笔用电需求。频率一度升至 60.092 Hz，调度人员降低发电出力、调整无功资源；区域控制误差限值的越限在九分钟内恢复，Dominion 报告客户在三十分钟内重新接回电网。PJM 后来的事件说明记录，这次调节最终维持住了电网可靠性。

这件事最值得追的，就是“机房保护成功”后面的那段账。一个园区切走负载，改变了其他园区面对的供电条件；几座园区接连动作，又把调节压力送回电网。只把服务器不断电当成验收终点，可靠性就少算了半张图。

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

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

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

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

短暂扰动被控制规则放大成了持续的取电变化。2024 年的报告查明了扰动计数与重合闸的交互；2026 年的初步调查则记录了两波负载转移。沿着各自事件的设备参数和恢复规则往下查，才能找到真正可改的配置。

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

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

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

发电与用电需要持续平衡。负载瞬间下降、发电出力还没跟着减，有功功率暂时过剩，频率就会上升。电压则还受无功平衡、线路阻抗和控制装置影响。同一次负载变化，会同时把两套调节问题推给调度。

第一批负载退出后出现的高电压，又触发了第二批机房切换。PJM 记录的两波转移，把反馈过程展示得很清楚：系统对故障的应对，本身也成了下一轮扰动的来源。最初那条故障线路被切掉之后，事情还在继续。

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

冗余在这里遇到了共同触发条件。每座机房可以有自己的 UPS、发电机和控制器，却一起承受同一条电压曲线。阈值相近，动作就会相关，设备再多也可能同一时间切走。接入研究该验证的，是这种集体响应。

机房保住业务，电网接下波动

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

机房按自己的业务风险设阈值，电网却要按整个区域的响应安排备用、发电和调压。决策权在园区，部分调节代价落在园区之外。单个设施看起来合理的配置，叠在一起就可能把公共系统推向更难处理的状态。

问题就在这层外部性：切换决定替本地业务降了风险，电网则接下突然消失的负载。接入要求、动态模型和恢复协议，应该把这笔账提前摆出来。事后再问某台 UPS 是否按规格工作，已经晚了一步。

动作规模小、响应分散、调度准备充足时，备用切换可以很平稳。真正危险的组合是：同一场扰动、相近的触发条件、大规模负载、短时间动作。这几个量该进入模型，而不是让组织边界替测试划线。

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

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

把它放到软件里看，反馈结构很熟悉：参与者观察共同环境，为自己的任务补救；补救改变环境，又让更多参与者继续补救。Google 的 SRE Book因此把重试预算、带随机扰动的退避、尝试次数和过载降载放在一起讨论。

设想一条上、中、下三层的调用链，每层最多尝试三次，最下游最多会收到 27 次调用。每层的局部配置都很克制，乘起来却可能压垮共享服务。预算要覆盖整条链路，分散到各层的“再试一次”才有总量约束。

电气保护需要在毫秒尺度切除危险故障，HTTP 调用的退避时间当然得留在软件里。跨领域值得借鉴的是控制方法：额外动作设预算，恢复过程有协调，验收覆盖集体响应。必要保护照常快速动作，保护之后的连锁反应也要有人管。

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

测试不能停在 UPS 的出口

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

Nancy Leveson 的 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%。

这里削掉的是功率波动幅度，平均功率反而小幅增加。编译器把计算活动铺得更平，设施侧看到的负载就更平滑。它打开的是计算调度这一层的控制空间，与 UPS 的电压保护形成了两条不同的改进路径。

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

越努力的 Agent，越拥堵的服务？

设想一个 Agent 平台：外部 API 变慢，每个 Agent 为完成任务增加重试、搜索和交叉验证；额外调用继续拉长响应，下一轮规划又决定“再多查一点”。单任务看起来更努力，平台却越来越堵。

如果一个 Agent 把任务成功率从 95% 提高到 98%，代价却是其他任务多等数倍时间，这个优化该算给谁？平台验收得把被挤占的资源和用户一起算进来。只展示那三个百分点，几乎看不到整个系统付出的代价。

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

恢复策略也应由执行层管住。服务刚恢复时，先限制放行量，再根据错误率和排队情况提高并发，把积压逐步消化。验收看总完成量、尾延迟、其他任务的等待，以及故障后的恢复时间。让系统回到稳态，本身就是一项要完成的任务。

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

我更愿意把可靠性评审的最后一问改成：所有组件都按自己的规则自保之后，谁来收拾它们共同改变的环境？北弗吉尼亚的两波负载转移，已经把这个问题推到了调度台上。软件架构里，最好在事故前就把它问出来。