面向硬件生命周期的超大规模数据中心功率规划（OSDI 2026）

原题：Hardware Lifecycle-Aware Power Planning in Commercial Hyperscale Datacenters (Operational Systems)

一句话总结：生产服务的整机功率只有设计峰值的 20%–90%，而且不同服务很少同时达峰；Meta 因此按硬件生命周期逐步收紧机架功率预算（RPB），并用 PowerSight 在可靠功率传感器尚未就绪时由性能计数器预测整机功率，十年部署的加权结果是在总供电不变时多放置约 20% 的机架，但全新架构上的 MLP 平均误差仍为 7.89%。

问题与动机

数据中心不能简单地把每台服务器的设计峰值相加。这样做很安全，却会把大量电力预留给几乎不会同时发生的峰值，形成闲置电力（stranded power）。反过来，如果机架功率预算（rack power budget，RPB）估得太低，同一供电设备下会摆放过多机架，极端流量或全局故障时就可能触发功率封顶，损害性能。这个决定还会影响机架位置、供电设备和是否新建数据中心，出错后很难低成本补救。

难点在于信息出现得太晚。一个服务器平台从 pre-EVT 到量产（MP）超过 18 个月；机型配置在 pre-EVT 已基本确定，可靠的 BMC 功率传感器通常到 DVT/PVT 才可用。规划者却要更早决定容量。只依赖 SPEC CPU2017 也不够：它主要压高 CPU core，不能代表生产服务的内存、SoC non-core、网卡、磁盘和风扇功耗。

论文其实包含两个相互衔接的贡献。第一部分总结 Meta 十年以上的生命周期感知 RPB 流程：硬件越成熟、遥测越完整，预算就从保守预测逐步变成基于生产分布的估计。第二部分提出 PowerSight，用早期 EVT 样机已经可收集的机器配置与性能计数器，填补可靠功率传感器出现前约 12–18 个月的信息缺口。PowerSight 不是 pre-silicon 模拟器，也不取代量产后的真实功率遥测。

关键观察 / 隐含假设

观察 1：标准 benchmark 会系统性低估生产整机功率。图 4 中，生产工作负载平均达到设计功率的 85.60%，SPEC CPU2017 只有 75.51%，相对低估 11.8%；二者 core power 接近，差距主要来自 non-core、内存和其他部件。
- 依赖假设：Meta 数千个在线服务足以代表其未来服务组合。
- 可能失效场景：若新平台主要运行与历史服务完全不同的持续满载任务，历史差值不能直接外推。
观察 2：服务异质性同时带来风险和可利用的余量。图 5 中服务功率横跨设计功率的 20%–90%，超过 15% 的服务器低于 50%；图 9 又显示不同服务的周内峰值并不重合。
- 依赖假设：空间分布与峰值错开关系在规划周期内相对稳定，并且最坏故障场景已纳入计算。
- 可能失效场景：GPU 训练长期维持高利用率，论文也指出这会降低峰值错开程度，使可超配空间变小。
观察 3：不同部件的能效进步不同，单看 CPU 利用率会漏掉主要功耗。图 6 中 CPU-E 相比 CPU-B 的单位吞吐 socket power 改善接近 2 倍，DDR5 相比 DDR4 同带宽只改善约 1.2 倍；最新一代内存已占整机功率的 20% 以上。
- 依赖假设：现有性能计数器能稳定反映 CPU、内存、存储、网络和 GPU 的活动。
- 可能失效场景：新加速器的关键活动没有低开销 counter，或固件改变 counter 语义时，模型必须补特征并重训。
假设 1：历史大规模样本能为新平台提供足够先验。PowerSight 用数百万生产数据点学习跨架构关系，并在估算 RPB 时沿用上一代服务占比 f_w。
- 证据强度：中。现有架构上的新工作负载 MLP 误差为 3.81%，但架构和工作负载都未见过时升到 7.89%，说明迁移不是无成本的。
假设 2：平均预测误差足以指导带安全余量的规划。
- 证据强度：弱到中。论文给出 MAPE 和三个用例，却没有给最危险的低估尾部、预测区间或供电越界次数。

核心方法

生命周期流程先区分三个预算阶段。pre-EVT/EVT/DVT 的 forecast RPB 没有生产功率数据，只能用电气规格和历史降额经验做保守预测。PVT/MP 的 initial RPB 开始使用服务负责人测得的目标利用率：对每种工作负载 w，取得其服务器占比 f_w 和目标负载下功率 p_w，再结合每机架服务器数 n 与 ToR 交换机功率求和。这一步利用的是不同服务器运行不同服务所带来的空间余量。

MP 约一年后，refined RPB 再利用时间余量。作者定义服务间最大相关系数 CR：分子把各服务各自的最坏峰值相加，分母取同一时刻的总功率峰值。不同服务越不同时达峰，CR 越大，可安全收紧的 RPB 越多。预算还会随着服务比例和硬件配置继续更新，而不是量产时算一次后固定不变。这里的“安全”仍以作者纳入的最坏 fleet failure 和上游 panel/switchboard/main switch 限额为边界。

PowerSight 面向 DVT/PVT 可靠传感器出现之前的早期 EVT。推理输入不含目标机器的功率传感器读数，而是机器配置，以及 CPU、DRAM/HBM、磁盘、网络和 GPU 等性能计数器；为控制线上开销，作者特意排除了昂贵的 kernel-level GPU counter。训练标签仍来自历史机器的真实功率传感器，所以它只是把已有遥测迁移到新平台，不是无监督测功率。

模型先用基于 PCA 的聚类从强相关 counter 中选代表特征，相比全部特征准确率差少于 0.1%。作者比较 Lasso、Ridge、SVR、DT、GBDT 和 MLP：线性模型难以描述非线性关系，SVR 的训练复杂度随样本数平方增长，实验甚至只能抽取 1% 数据；DT、GBDT、MLP 更准确。最终选择 MLP，是因为它在“现有架构、新工作负载”和“全新架构、新工作负载”两种迁移测试中都最好。

训练数据来自数百万台生产机器、数千个服务、8 代 CPU、2 代 GPU 和 42 种机器配置。模型按配置聚合并去除异常值，用不同日期的数据测试，以减少同日泄漏。PowerSight 的输出可以代入机架密度 n = (D - P_TOR) / P_s 和 RPB 公式，也能先缩小 DVFS 搜索区间；最终量产决策仍应在传感器就绪后重新校准。

设计取舍

逐阶段收紧预算，而不是一开始追求最精确：早期 forecast RPB 保守、可解释，代价是留下余量；生产遥测到齐后才利用服务比例和非同时峰值，降低了因错误预测而选错供电位置的风险。
用统一跨架构模型换取可部署性：一个 MLP 覆盖 compute、storage 与 AI 机型，维护比每种配置单独建模简单，但全新架构 MAPE 从 3.81% 上升到 7.89%，需要留出更大的安全边界。
只用低开销 counter：这使 PowerSight 能在生产基础设施上运行，却主动放弃了可能更有解释力的 kernel-level GPU 特征。
边界条件：该方案最适合有多年 fleet 遥测、配置标准化和大量样本的运营商；只有数万样本、服务组合快速漂移，或机架长期同步满载时，论文给出的准确率与超配收益都不能直接复用。

实验与结果

生产服务与 benchmark 的差距：对数百万机器、数千服务以及 compute/storage/AI 工作负载的统计显示，生产服务平均达到设计功率的 85.60%，SPEC CPU2017 为 75.51%，相对低估 11.8%（图 4）；服务功率还横跨设计值的 20%–90%，超过 15% 服务器低于 50%（图 5）。
代际变化说明不能只建 CPU 模型：CPU-E 相比 CPU-B 的单位吞吐 socket power 接近改善 2 倍，而 DDR5 相比 DDR4 同带宽只改善约 1.2 倍；最新一代内存已贡献超过 20% 的系统功率（图 6，§3.4）。
生命周期 RPB 带来的容量：forecast RPB 相比 design power 使 rack density 增加 13%，refined RPB 又相对 forecast 增加 11%（图 10）。这两个数不能直接相加；按不同 rack 的功率 footprint 加权，十年全球 fleet 的总体结果是同一总供电下约多部署 20% 机架（§4.1–§4.2）。
PowerSight 的模型准确率与泛化落差：联合现有 compute/storage/AI 架构时，MLP、DT、GBDT 的准确率分别为 96.19%、95.59%、95.53%（图 12）；表 4 更严格地区分出，MLP 对现有架构上的新工作负载 MAPE 为 3.81%，对未见 CPU-H + GPU-B 架构和新工作负载则为 7.89%。仅数万训练点时误差超过 10%，作者建议至少使用数百万点（图 13）。
三个规划用例：留出 CPU-E 训练时，PowerSight 的 rack design power MAPE 为 1.7%，但经除法换算后 server count/rack 误差放大到 8.7%；沿用上一代 f_w 时 RPB 误差为 2.5%；Video 服务实测最优频率为 2.6 GHz，模型把候选范围缩到 2.4–2.8 GHz（§5.3、图 14）。

论断—证据表

论断	证据	评测边界	置信度
只用 SPEC 会低估 hyperscale 整机功率	图 4：生产服务为设计功率的 85.60%，SPEC 为 75.51%，相对差 11.8%	Meta 生产服务与 SPEC CPU2017；未比较其他整机 benchmark	强
异质服务的空间与时间错峰能转化为机架容量	图 5、图 9、图 10；forecast 增加 13%，refined 再增加 11%	依赖持续 fleet 遥测、最坏故障建模和上游功率保护	强
生命周期方法在生产中有长期价值	§1、§4.2：部署超过十年，加权后约多放置 20% 机架	运营观察，不是受控反事实；多项流程与硬件共同演化	强
PowerSight 能跨现有架构准确预测功率，但新架构更难	图 12、表 4：现有架构联合准确率 96.19%；未见架构 MAPE 7.89%	数百万 Meta 样本；未公开绝对功率和完整数据	强
平均功率误差会被机架整数容量放大	§5.3.1：rack design power MAPE 1.7%，server count/rack 误差 8.7%	单个留出 CPU-E 的规划案例	中

批判性分析

论证链条

论文从“设计峰值过保守、生产峰值不重合”的测量，推到分阶段 RPB，再用十年生产结果证明这不是纸面机会；这条主链条是闭合的。PowerSight 也有清楚定位：早期缺传感器，所以从已有 counter 和历史标签迁移。需要谨慎的是，约 20% 是十年运营后的加权整体结果，不是只打开某个算法开关得到的受控收益；硬件代际、服务组合、调度策略和人工流程也同时变化，论文没有分离各自贡献。

假设压力测试

上一代服务占比 f_w 在稳定业务中合理，但 AI 训练/推理快速增长时会漂移；持续高利用率的 GPU rack 也比 CPU rack 更少错峰，作者已明确说其 CR 可能更低。PowerSight 对未见架构的 7.89% MAPE 明显高于现有架构新负载的 3.81%，因此“跨架构”不应理解为任意新芯片都能无校准复用。若新 accelerator 缺乏低开销 counter，或散热、电源转换等未观测因素改变，模型还可能系统性偏差。

实验可信度

数百万机器、数千服务、42 种配置和十年生产使用，是这篇 operational paper 最强的证据；跨日期测试与真实留出架构也优于随机切分。但论文匿名化了绝对功率，完整数据、模型和代码只承诺未来发布，外部无法复现。更关键的是，主要指标为 MAPE：它把高估和低估平均起来，却没有报告低估的 p99、预测区间、触发 power capping 的次数或安全余量。对于容量规划，这些尾部指标比平均误差更直接。

系统性缺陷

PowerSight 推理不需要目标机器的功率传感器，但训练仍依赖历史传感器、BMC 校准和大规模遥测；论文自己的样本量实验显示，数万点时误差仍超过 10%，小型运营商很难复制。系统还缺少公开的漂移检测、重训练触发条件和失败保护策略。1.7% 功率误差变成 8.7% 的机架服务器数误差，也说明非线性容量决策会放大看似很小的平均误差；若直接四舍五入到机架整数，必须单独审计低估风险。

局限与后续工作

局限 1：论文没有公开绝对功率、训练数据、模型或生产保护逻辑，当前 artifact 只说计划未来发布。
局限 2：评测以平均误差为主，没有给危险低估尾部、置信区间、实际供电越界或 power-capping 事件率。
局限 3：约 20% 是长期综合运营结果，没有能分离生命周期预算、调度、人工作业和硬件变化的反事实。
局限 4：全新架构 + 新工作负载的 MLP MAPE 为 7.89%，上一代 f_w 与峰值相关性在 AI 比例快速变化时也可能失效。
后续工作 1：在至少三代新平台上报告低估 p95/p99、prediction interval、功率越界次数，并按风险约束而非纯 MAPE 选择 RPB。
后续工作 2：用时间漂移实验测量 f_w、CR 和 counter-power 关系多久需要更新，并给出自动重训与回退到保守 forecast 的触发规则。
后续工作 3：发布去敏的特征、标签和模型，在百万、十万、万级样本下比较迁移学习、校准和安全余量，使中小规模运营商也能验证方法。

Awesome System Papers Wiki

探索

PowerSight-OSDI26