简介：这是一份由腾讯联合中国电信、英特尔发布的数据中心算力—电力灵活性协同研究白皮书，面向数据中心运维、能源管理与需求响应从业者，聚焦高比例新能源接入和需求响应常态化下如何挖掘算力侧调节能力。文件仅含1份PDF，压缩包约2.22MB，便于查阅归档，已有250人学习下载。白皮书围绕业务—算力—电力协同，梳理空载服务器功耗状态切换、服务器子部件资源消耗不均衡、平移和伸缩实时性不敏感任务、跨数据中心转移任务等策略，并结合硬盘密集型、内存密集型、CPU密集型任务测试，说明秒级功率控制的可行性。读者可从中了解灵活性策略设计、测试结果、后续研究启示与未来展望，包括自动化系统联动、标准测试方法标定机型电力特性及开源共享等方向，为数据中心参与需求侧响应、电力现货市场和辅助服务市场提供参考。

1. 算力也是“负瓦”：为什么数据中心能从刚性负荷变成秒级可调资源

一个反直觉的结论是：数据中心并不天然是“电力跟随算力”的刚性负荷。服务器里跑什么任务、任务压在哪个子部件上、空载机是否休眠、并行规模开多大，都会直接改变功率曲线。这份关于数据中心算力-电力灵活性协同的白皮书，把需求响应从“加储能、调空调”推到服务器内部：不改硬件，只靠算力侧的任务特征识别和功率钳制，就能让服务器集群在秒级做出 2%～27% 的负荷下调，空载机软关机甚至能降 100%。PUE 衡量的是总能耗与 IT 能耗之比，而真正的大头在服务器；把“算力跟随电力”做成可验证的控制回路，才是这份材料最值得拆的底层机制。

2. 从电力跟随算力到算力跟随电力：服务器功率的可压缩空间从哪里来

2.1 PUE 遮住的真相：服务器才是耗电大户

数据中心能效讨论里，PUE 太容易被当成唯一指标。PUE 的定义很清楚：数据中心总能耗除以 IT 设备能耗，越接近 1 说明制冷、配电等非 IT 部分占比越小。问题在于，PUE 只回答“非 IT 设备省不省”，不回答“IT 设备本身能不能少用电、能不能按电网需要调整用电”。白皮书给了一个很直白的结构：以 PUE 为 1.3 的数据中心为例，服务器耗电占比约 77%。也就是说，盯着空调和供配电优化，边际空间会越来越小；而服务器侧的功率如果可调，调节深度和响应速度都完全不同。

过去数据中心为什么一直“电力跟随算力”？因为服务器供电配置和计算任务信息分属不同管理系统：供电侧按铭牌功率配容量，业务侧按任务排队和 SLA 调度，两边没有实时映射。供电侧看到的是“这台机器额定多少瓦”，业务侧看到的是“这个任务还要跑多久”，中间缺一层“当前任务把哪个子部件压成了瓶颈、哪些部件还有冗余”的特征数据。没有这层数据，服务器负荷就被当成不可调的刚性负荷，只能靠储能、柴发、空调做文章。

更关键的是，算力消耗的电力由算力程序驱动电子元件产生，天然具备可观、可测、可即时调节的特性。CPU、内存、硬盘、网络各子部件的功率可以通过带外管理平台或操作系统工具读出来，功率上限也可以通过 PowerCap 一类机制在毫秒级到秒级限制。这意味着不需要额外加任何硬件，就能把“算力调节”变成“电力调节”。常见的实现思路是：业务侧给出任务类型和可中断性，算力侧给出子部件压力特征，电力侧给出响应目标，三者在一个控制回路里对齐。难点不在“能不能降功率”，而在“降了之后业务性能是否可接受、恢复是否可控”。

2.2 长板与短板：任务在子部件上的电力特征模型

理解子部件不均衡性，先把服务器看成一个木桶：CPU、内存带宽、硬盘 I/O、网络、GPU 各是一块板。任何一个业务负载跑起来，总有一个或几个子部件先成为“短板”，其余部件的能力相对冗余，也就是“长板”。白皮书的策略二就是利用这个冗余：在不影响业务负载运行效率的前提下，降低非瓶颈子部件的性能，从而降低整机电力负荷。

这个模型要落地，需要三类特征数据。第一类是业务负载对各子部件的压力特性：这个任务是 CPU 密集、内存带宽密集，还是硬盘 I/O 密集。第二类是总体业务性能与子部件性能的关联：把 CPU 功率压下去 10%，任务耗时会不会涨、涨多少。第三类是子部件性能变化时的能耗特性：压这个部件到底能省多少瓦。执行响应时还要实时监测业务负载对各子部件的实时压力，否则任务阶段一变，原来的“长板”可能已经变成“短板”，继续压就会翻车。

这里有一个容易被忽略的细节：对单一部件施加压力的负载，并不代表不会对其他子部件造成压力。比如内存读写不可避免地带来 CPU 运算，硬盘写入也会经过文件系统和 CPU。白皮书在实验里尽量选取对单一部件压力最大、关联部件压力尽可能小的模拟负载，目的是“窥斑见豹”：真实业务可以近似看作这些单一负载的组合，先测出每种组合的电力弹性边界，再在实际调度时按当前任务画像查表。这个思路很像性能调优里的“先找瓶颈再动手”，只不过这里的优化目标从耗时换成了功率。

2.3 三类可调度资源与四种策略的边界

白皮书把数据中心服务器负荷的灵活性拆成四种策略：空载服务器功耗状态切换、利用子部件资源消耗不均衡性、平移和伸缩实时性不敏感任务、跨数据中心转移任务。前三种是实际测试重点，第四种需要庞大的业务群和分布式计算存储架构支撑，更像空间维度的延伸。把它们放在一个框架里看，本质是三类可调度资源：空载态的时间资源、子部件冗余的深度资源、任务时间弹性的平移资源。

空载态切换解决“没事干的机器还要吃多少电”。服务器空载并不等于零功耗，实验中单台空载功耗 215W，CPU 占 53%，内存占 21%。把空载机 Freeze、用 PowerCap 压 CPU 上限、或者软关机，分别对应不同的响应深度和恢复代价。子部件不均衡性解决“有事干的机器能不能少用非瓶颈部件”。硬盘密集型任务可以把 CPU 功率从 215W 压到 160W，降幅 26%，硬盘写入速度不受影响；内存密集型任务在内存带宽占用 74% 时，CPU 功率可压缩空间达到 18%；CPU 密集型任务则没有免费午餐，功率从 363W 降到 232W，计算耗时从 1377 秒涨到 2303 秒。任务平移伸缩解决“能不能把用电时间挪一挪”。断点续算让任务随时中断、续算，并行规模可变让功率曲线可以缩容、扩容。

这四类策略的边界也很清楚：前三类要求业务-算力-电力三者有精准关联关系，但适用于各种规模的数据中心、机房、集群和服务器；跨数据中心转移要求业务架构支持冷迁移或热迁移，收益在空间分布上，不在单机功率上。白皮书把前三种作为研究重点，是因为它们不依赖额外硬件，也不要求所有业务都做成分布式，落地门槛更低。用一句口语化的总结：这是把“服务器能不能少喝点电”拆成了“空转的少喝、干活的挑着喝、不急的换个时间喝”。

3. 空载态与子部件冗余：两类“无感降功率”策略的实测边界

3.1 空载功耗结构：215W 的构成与三种切换路径

空载服务器不是零功耗，这个事实本身就是节能和需求响应的入口。实验单台服务器在未运行任何计算任务时消耗 215W，其中 CPU 占 53%，内存占 21%，其余是主板、风扇、电源等。这个结构说明：空载态下 CPU 仍然是最大单一耗电部件，压 CPU 功率或让系统进入更低功耗状态，收益最直接；内存占两成，说明只压 CPU 不能把空载功耗打到零，剩余部分需要靠系统级状态切换或关机。

白皮书测试了三类切换方式。第一类是把 Linux 功耗状态设置为 freeze，再通过管理接口唤醒。第二类是通过数据中心管理平台的 PowerCap 把 CPU 功率上限调到最低，再解除设定恢复。第三类是输入系统命令 shutdown 做软关机，再通过电源按键启动。三种方式对应三种控制粒度：Freeze 是系统级暂停，PowerCap 是部件级功率钳制，关机是整机断电。它们不是互相替代关系，而是分别适合不同的响应深度和恢复时间要求。

这里要区分“功率降低”和“响应速度”两个指标。Freeze 降低 9W，降比 4%，响应小于 1 秒；PowerCap 降低 57W，降比 27%，响应小于 1 秒；软关机降低 215W，降比 100%，但开关机切换需要约 2.5 分钟，额外消耗电量 0.0083kWh。如果只看降幅，关机最漂亮；如果看秒级需求响应，关机反而不适合频繁调用。这个取舍在后面避坑章还会展开，因为很多方案在纸面上把“可降 100%”写成卖点，却忽略了恢复过程和额外能耗。

3.2 响应深度与恢复代价：为什么软关机不是默认答案

把三种方式放进同一个时序里看，差异更明显。Freeze 和 PowerCap 都是“下发指令—功率下降—恢复指令—功率回升”的短回路，适合秒级、分钟级的负荷调节；软关机是“下发关机—系统退出—电源断开—按键启动—系统恢复—业务恢复”的长回路，适合长时间空载备用机的节能，不适合作为秒级响应的主力。白皮书的测试曲线也显示，Freeze 和 PowerCap 在指令下发后很快进入低功率平台，恢复也快；关机则有一个明显的过渡过程。

这张表最重要的不是数字，而是“响应速度”这一列。需求响应按时间尺度分日前、小时、分钟、秒级，不同尺度给的钱和考核方式不一样。秒级响应要求功率快速跟随，Freeze 和 PowerCap 有优势；关机虽然深度大，但切换过程本身要耗电，频繁开关还会带来业务恢复风险和硬件磨损。常见的实现思路是分层：秒级用 PowerCap 做连续可调，分钟级用 Freeze 做状态切换，小时级以上才考虑软关机或休眠。这样既拿到深度，又不把恢复代价压到业务侧。

还有一个容易踩的坑：空载功耗基线会漂移。同一台机器在不同室温、不同风扇转速、不同后台进程下，空载功率可能差出几瓦到十几瓦。如果基线取一次就固定，后面算降幅就会虚高。白皮书在实验里给出 215W 这个基线，是为了做策略对比，不是让生产环境直接套这个数。实际落地要定期重采基线，按机型、按固件版本、按环境温度分组，否则“降了 27%”可能只是基线取低了。

3.3 硬盘密集型任务：CPU 压到 160W 为何写入速度不变

子部件不均衡性最直观的验证是硬盘密集型任务。实验用 Linux 上的 dd 工具持续向硬盘写入和删除文件，模拟硬盘 I/O 压力；然后用 PowerCap 对 CPU 做不同功率水平的限制，记录写入同样大小文件所用的平均时间和平均写入速度。测试流程是运行 dd 向硬盘写入 1 个 512MB 文件，重复三次，再复制 1024 个 5MB 文件并删除，记录任务所用时间，同时逐步降低 CPU 功率。

结果很关键：在执行硬盘密集型任务时，CPU 功率可以从 215W 压缩到 160W，降比 26%，而硬盘写入速度没有受到影响。这说明在这个任务画像里，CPU 不是瓶颈，硬盘 I/O 才是短板；CPU 的性能冗余被压掉一部分，业务侧无感。这个结论的价值在于“无感降功率”不是口号，而是可以用写入速度、任务耗时这些业务指标验证的。只要瓶颈不在被压的部件上，压缩非瓶颈部件就不会直接转化为业务性能损失。

但要注意，这个结论有严格前提：任务确实是硬盘密集型，且文件系统缓存、写入模式、RAID 配置没有把 CPU 重新变成瓶颈。如果 dd 的块大小、同步方式、压缩/加密选项变了，CPU 可能重新进入关键路径，压 CPU 就会掉写入速度。白皮书用 dd 是为了构造一个相对纯粹的硬盘压力场景，真实业务里数据库、日志、对象存储的 I/O 模式更复杂，不能直接拿 26% 这个数去套。我一般会这么理解：26% 是这类任务在实验条件下的电力弹性上限，不是生产环境的默认值。

3.4 内存与 CPU 密集型任务：可压缩空间的两种极端

内存密集型任务用 memtester 模拟，通过运行多个 memtester 进程把内存带宽利用率维持在 74%、47%、28% 三个压力水平，再用 PowerCap 逐步降低 CPU 功率，监测内存带宽利用率变化。数据显示，当内存带宽占用率约为 74%、47%、28% 时，初始服务器功率分别为 313W、278W、255W，可压缩功率分别为 18%、8%、2%。也就是说，内存 I/O 越密集，CPU 功率可压缩空间越大；内存占用越低，CPU 越可能参与更多非内存工作，压缩空间反而变小。

CPU 密集型任务则是另一个极端。实验用 Linpack 类浮点基准模拟单节点 CPU 密集型任务，用 PowerCap 限制 CPU 功率，记录任务完成时间和 GFlops。数据显示，降低服务器功率时不存在“任务完成时间不变”的平台区域：服务器功率从 363W 降到 232W，计算耗时从 1377 秒增加到 2303 秒。换句话说，CPU 密集型任务里 CPU 就是短板，压 CPU 功率会直接降低执行速度，没有免费的性能冗余可拿。

这张表把“长板/短板”模型讲透了：同样是压 CPU，硬盘密集和内存密集任务能拿到无感或低感收益，CPU 密集任务则要拿性能换功率。白皮书也指出，后续应探索 CPU 之外子部件的功率控制，比如内存、网络的功率控制，挖掘 CPU 密集型任务压缩其余子部件冗余的潜力。这个方向很重要，因为真实数据中心里 CPU 密集型任务占比不低，只靠压 CPU 功率做需求响应，业务侧不可能长期接受。

4. 任务平移与伸缩：断点续算如何把电力负荷切成时间片

4.1 checkpoint/restart 的机制：中断不是重启

实时性不敏感任务是第三类灵活性资源。影视渲染、效果图渲染、基因测序、风机工况模拟、AI 训练等任务，往往计算成本敏感、实时性不敏感、计算规模可变动。它们不需要在某个时刻必须跑完，但需要“断了还能接着算”。断点续算就是这里的核心机制：任务随时可以被中断，重启后从检查点继续，而不是从头开始。有些应用本身支持断点续算，有些可以通过 MPI 里的 checkpoint/restart 技术实现。

从电力视角看，断点续算把一条连续的功率曲线切成了多个时间片。任务运行时功率高，中断后功率降下来，等待一段时间再续算，功率又上去。这个“等待”可以对齐电网的响应邀约时段，也可以对齐电价低谷。如果应用还支持并行节点数可变，就能进一步做伸缩：需要降负荷时缩容，减少并发节点；需要赶进度时扩容，增加节点。平移改变时间分布，伸缩改变功率大小，两者组合起来就是“削峰填谷”的算力版。

一个抽象的调度状态机可以写成下面这样，注意这不是白皮书原文代码，而是把 checkpoint/restart 的控制逻辑用伪代码表达出来：

# 抽象状态机：断点续算 + 并行规模调整 task_state = "running" checkpoint = None def on_power_signal(signal): global task_state, checkpoint if signal == "shed" and task_state == "running": checkpoint = save_checkpoint() # 保存当前迭代/时间步 pause_task() # 暂停计算，功率下降 task_state = "paused" elif signal == "restore" and task_state == "paused": resize_nodes(target_nodes) # 缩容或扩容到目标节点数 resume_from(checkpoint) # 从检查点续算，不是重跑 task_state = "running"

这段伪代码的关键在save_checkpoint()和resume_from(checkpoint)：中断不是杀进程重来，而是把任务进度持久化，恢复时从检查点继续。resize_nodes(target_nodes)决定伸缩后的并行规模。真实系统里还要考虑检查点写盘开销、检查点频率、节点故障后的重建、MPI 进程组的重新拉起。白皮书的实验表明，对于可分配至计算节点独立计算的并行任务，缩容、扩容、平移不会显著影响总耗电量和总时长；对于子任务耦合的并行任务，也能调整功率，但算力和电力的扩缩容关系是非线性的。

4.2 子任务独立型并行：2→1 缩容、2→3 扩容的账

子任务独立型并行计算的特点是并行效率接近 100%，计算效率几乎不受并行节点数量和网络影响。实验用一个白车身轻量化的多学科设计优化任务做测试：把前地板、外挡板等 20 个位置的料厚作为设计变量，在满足刚度性能前提下求结构轻量化和一阶模态性能的最优解，用某多学科设计优化软件做分布并行计算。测试了三种策略：基线是在 2 个节点上一直算完；缩容是在 2 个节点上跑一段时间后中断，把剩余计算量放到 1 个节点续算；平移+扩容是在 2 个节点上跑一段时间后中断，把剩余计算量放到 3 个节点续算。

结果是：2 节点基线耗时 10 分 27 秒，总功耗 118Wh；2 节点转 1 节点缩容，耗时 13 分 49 秒，总功耗 123Wh；2 节点转 3 节点扩容，耗时 9 分 54 秒，总功耗 125Wh。缩容后总时长变长、总功耗略增，扩容后总时长变短、总功耗也略增。这个账看起来不“节能”，但它换的是功率曲线形状：缩容期间节点数减少，瞬时功率下降；扩容期间节点数增加，瞬时功率上升。对于电网侧，重要的是在指定时段把负荷压下去或抬上来，而不是全天总电量最小。

这张表说明一个设计取舍：需求响应的收益不完全等于总电量下降。如果电网按容量（kW）补偿，削峰时段的功率下降本身就有价值；如果按能量（kWh）补偿，才更看总电量。白皮书提到部分地区对需求响应电能量补偿费用远高于工商业电价，数据中心参与响应可以带来额外收入。但技术方案不能只算钱，还要算业务排队时间、检查点开销、节点利用率。子任务独立型任务适合做平移和伸缩，因为它对网络不敏感，缩容扩容的边界比较干净。

4.3 子任务耦合型并行：VASP 的通信开销与非线性

子任务耦合型并行计算更接近真实 HPC 场景。子任务之间需要通过网络通信和同步，除了计算本身，还有通信计算和等待过程。实验用某材料计算模拟程序做一个典型的子任务耦合型任务，测试了四种策略：2 节点基线、4 节点基线、4 节点平移（跑一段时间后中断，等待一段时间再续算）、4 节点平移后缩容到 2 节点续算。

数据是：2 节点并行耗时 52 分 41 秒，总功耗 511Wh；4 节点并行耗时 41 分 42 秒，总功耗 753Wh；4 节点平移，总耗时 37 分 7 秒，总功耗 623Wh；4 节点跑一段时间后中断，等待一段时间，缩容到 2 节点续算，总耗时 45 分 35 秒，总功耗 661Wh。这里最值得注意的是 4 节点平移的总功耗 623Wh 反而低于 4 节点基线的 753Wh，耗时也更短，但这不意味着“中断等待一定省电”，而是实验里任务规模、检查点位置、等待时长、节点利用率共同作用的结果。换成另一个检查点频率或等待时长，账可能就变了。

这组数据说明子任务耦合型任务也能通过缩容、平移调整功率，但算力和电力的扩缩容关系是非线性的。原因在通信：节点数增加，单节点计算量减少，但通信和同步开销增加，功率不一定线性下降，耗时也不一定线性缩短。工程上做需求响应，不能拿“节点数减半、功率减半”去拍脑袋，必须按任务类型实测功率-性能曲线。白皮书把子任务独立型和耦合型分开测，就是为了把这个非线性暴露出来。

4.4 功率形状的价值：总电量相近为何仍能削峰填谷

把子任务独立型和耦合型放在一起看，会发现一个共同点：平移和伸缩不一定让总电量大幅下降，甚至可能略增，但它改变了功率在时间上的分布。电网要的是在指定时段把负荷压下去，在新能源大发时段把负荷抬上来。数据中心的任务弹性正好可以提供这种“功率形状”。白皮书说三种策略均可根据外部指令实现秒级对服务器功率的快速控制，为数据中心参与分钟级、秒级响应或电力现货市场和辅助服务市场提供可行性依据。这里的“秒级”主要指空载切换和 PowerCap，任务平移伸缩更多是分钟级到小时级的块状调节。

从控制角度看，这是一个多层时间尺度的问题：秒级用 PowerCap 压 CPU 和内存功率，分钟级用 Freeze 切空载机，小时级用任务平移和缩容把负荷挪到电价低或新能源富余的时段。每一层的响应速度、可调深度、业务影响都不一样。白皮书的实验价值在于把每一层的边界测出来了：空载 PowerCap 能降 27%，硬盘密集型能降 26%，内存密集型在 74% 带宽时能降 18%，CPU 密集型没有免费平台区，子任务独立型可以干净地缩容扩容，子任务耦合型有通信非线性。这些数字不是让你直接抄，而是让你知道“哪一层能拿多少、代价是什么”。

5. 避坑与排查：算力-电力协同实验里最容易翻车的五个点

5.1 把空载功耗当成固定值：基线漂移导致降幅虚高

现象：同一台服务器，今天测空载 215W，明天测 225W，按第一次基线算出来的降幅看起来很大，但业务侧并没有感觉到更多节能。原因：空载功耗受环境温度、风扇转速、固件版本、后台管理进程、电源效率曲线影响，不是固定常数。实验环境可以控制变量，生产环境变量更多。解决：按机型、固件版本、进风口温度分组采基线，每次响应前重新读一次当前空载功率，用“响应前功率减响应后功率”算实际降幅，而不是拿历史基线套。基线采样要覆盖不同负载阶段，避免把任务刚结束的瞬时低功率当成空载。

这个坑在纸面方案里很常见：有人拿实验室 215W 去乘机器数，算出整个集群能降多少兆瓦，忽略了生产环境空载率、机型混布、风扇策略差异。更稳妥的做法是把基线做成一条曲线，按 CPU 利用率、内存利用率、环境温度分桶，响应时按当前桶取参考值。如果桶太粗，降幅误差会很大；如果桶太细，采样成本又上去。工程上一般先粗后细，先用 5% 以内的误差目标定桶宽，再根据实际响应考核结果调整。

5.2 只看总功率不看子部件：压错瓶颈导致性能雪崩

现象：看到服务器总功率 300W，直接压 CPU 功率，结果某个内存密集型任务耗时翻倍，业务告警。原因：总功率下降不等于业务无感，压错了瓶颈部件，性能损失会直接传导到任务耗时。硬盘密集型任务压 CPU 可能没事，CPU 密集型任务压 CPU 就是拿性能换功率。解决：响应前先读任务画像，确认当前瓶颈子部件；响应中实时监测 CPU、内存带宽、硬盘 I/O、网络利用率；响应后对比任务耗时、吞吐、错误率。对未知任务先小范围灰度，不要一上来全集群压。

排查时重点看三个信号：被压部件的利用率是否已经接近饱和、非瓶颈部件的冗余是否真实存在、业务指标是否出现拐点。白皮书的硬盘密集型实验里，CPU 从 215W 压到 160W，写入速度不变，是因为瓶颈在硬盘；CPU 密集型实验里，功率从 363W 降到 232W，耗时从 1377 秒涨到 2303 秒，说明 CPU 就是瓶颈。同样是压 CPU，结论完全相反。做需求响应的人必须习惯“先分类、再压”，不能拿一个全局功率阈值一刀切。

5.3 忽略切换代价：关机降 100% 却吃掉响应收益

现象：方案里写“空载机可降 100% 功率”，实际调度时发现关机再开机要几分钟，响应时段已经过去，还额外消耗了电量。原因：只看了功率降低深度，没看响应速度和恢复代价。软关机涉及系统退出、电源断开、按键启动、系统恢复、业务拉起，链路长；Freeze 和 PowerCap 是秒级回路。解决：按响应时间尺度选策略。秒级用 PowerCap 或 Freeze，分钟级用 Freeze 或休眠，小时级以上才考虑软关机。关机策略要算额外耗电和业务恢复时间，不能只看降幅。

白皮书的数据很直接：Freeze 降 9W、4%、小于 1 秒；PowerCap 降 57W、27%、小于 1 秒；软关机降 215W、100%、约 2.5 分钟，额外消耗 0.0083kWh。如果响应邀约是秒级，关机根本来不及；如果是长时间空载备用机节能，关机才有意义。工程上可以把三种方式做成优先级队列：先 PowerCap，再 Freeze，最后关机，按响应深度和恢复时间动态选。不要把所有空载机都关机，否则业务高峰一来，恢复不过来。

5.4 把并行扩容当线性缩放：耦合任务越扩越慢

现象：任务从 2 节点扩到 4 节点，预期耗时减半、功率线性增加，实际耗时只缩短一点，通信开销把收益吃掉了。原因：子任务耦合型并行计算需要网络通信和同步，节点数增加会带来额外的通信计算和等待，算力与电力不是线性关系。解决：按任务类型实测并行效率曲线，找到“性价比拐点”；扩容前评估网络带宽、同步频率、检查点大小；对耦合型任务优先做平移和缩容，不要盲目扩节点。子任务独立型任务可以更激进地伸缩，耦合型任务要保守。

白皮书的耦合型实验里，2 节点 511Wh、4 节点 753Wh、4 节点平移 623Wh、4 节点缩容到 2 节点 661Wh，说明不同策略的账差别很大。排查时先看并行效率：如果 4 节点相对 2 节点的加速比远低于 2，说明通信或同步已经成为瓶颈，继续扩容只会增加功率，不会等比例缩短时间。再看检查点开销：检查点写盘本身要时间和电量，频率太高会抵消平移收益。最后看等待时长：中断等待太久，业务排队成本可能超过电力收益。

5.5 没有业务-算力-电力映射：数据对不上账

现象：电力侧说负荷降了 20%，业务侧说任务耗时没变，算力侧说节点数没动，三份报表对不上。原因：业务、算力、电力三套系统各记各的账，缺少统一的标识和时间戳。电力侧按机房总表读，算力侧按任务队列读，业务侧按 SLA 读，颗粒度和采样周期都不同。解决：建立任务-服务器-子部件-功率的映射关系，统一时间戳和采样周期；响应前后打标记，把电力事件和业务事件关联起来；至少做到“哪个任务、在哪台机器、压了哪个部件、降了多少瓦、业务指标变了多少”可追溯。

这个坑是落地自动化的最大障碍。白皮书也提到，未来需要形成自动化系统，联动业务-算力-电力三者的对应信息，还需要产业伙伴采用一套标准的测试方法标定业务负载在机型上的电力特性数据，开源共享。没有这套映射，实验数据只能写报告，不能进生产控制回路。排查时可以先做小闭环：选一类任务、一个机型、一个机房，把三侧数据打通，跑通一次完整的“响应邀约—任务识别—功率调整—业务验证—恢复”流程，再逐步扩规模。不要一开始就追求全集群大而全，数据对不上账，规模越大越危险。

6. 设计取舍：为什么“标准化测试方法 + 自动化联动”比单点节能更重要

单点节能的账很好算：一台机器降多少瓦，乘机器数，乘时间。但算力-电力协同的账要复杂得多，因为它同时牵涉业务性能、算力调度、电力响应三个目标。白皮书的实验给出的不是一套可直接复制的参数，而是一组边界：空载 PowerCap 能秒级降 27%，硬盘密集型能无感降 26%，内存密集型在 74% 带宽时能降 18%，CPU 密集型没有免费平台区，子任务独立型可以干净伸缩，子任务耦合型有通信非线性。真正落地时，最该先做的不是买设备，而是把业务负载在机型上的电力特性数据标准化测出来，形成可查询的特征库。

这张表没有标准答案，因为需求响应的补偿方式、业务 SLA、机型混布程度都不一样。如果电网按容量补偿，削峰时段的功率下降比总电量更重要；如果按能量补偿，总电量账要算细。如果业务是实时在线，空载切换要保守；如果是离线批处理，任务平移空间更大。我一般会这么理解：先确定响应时间尺度和补偿方式，再倒推该用哪层策略，而不是反过来拿策略去找场景。

验证方法上，建议至少跑三组对照：基线组不调整，策略组按目标调功率，恢复组验证业务回到正常水平。每组记录功率曲线、任务耗时、业务指标、额外能耗。白皮书的附录给了软硬件配置和测试流程，这类材料最大的价值就在可复现的测试条件，而不是几个漂亮的百分比。从那以后我每次做类似评估，都强制走一遍“基线—策略—恢复”的闭环，哪怕时间紧也不省略恢复验证。希望帮到你。

本文还有配套的精品资源，点击获取