想象你是一栋 24 小时不熄灯写字楼的物业经理。楼里住着几十位“电老虎”——AI 训练用的 GPU 显卡，它们彻夜加班跑模型，电表转得飞快，机房的空调轰鸣不止。你被老板要求“省电费”，可你连电都浪费在哪都不知道：是哪个房间的机器在空转？哪台空调该关？半夜有没有“偷电”的设备在悄悄耗能？这时，你需要一套“大楼水电计量与巡检系统”：每层楼装智能电表、温度探头和客流传感器，信号汇集到中控室大屏，值班员盯着曲线抓异常，你根据月度账单做节能改造——这就是 AI 能效监测的完整故事。监测不是目的，省电才是，而省电的第一步是“看得清”。

岗位关联

能效监测是 AI 基础设施的“水电表”：掌握它，你才能在训练集群的能耗账本上做精细化管理，成为既懂模型又懂成本的双栖工程师。

目录
  1. 可视化演示
  2. 监测架构
  3. 核心指标
  4. 采集频率
  5. 异常检测
  6. 闭环调优
  7. 方案选型
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

监测架构

物业经理给大楼装监测系统，第一步不是买电表，而是想清楚“线怎么走”：传感器装哪些位置、信号怎么传回中控室、数据存在哪个柜子里、值班员盯哪块屏。少一个环节，数据就断一截，之后所有省电决策就成了盲人摸象。AI 能效监测的架构设计，本质就是这趟巡线工程。

技术世界里的“传感器”是数据采集代理（agent），它通过 NVIDIA 的 NVML 等接口，以固定频率读取 GPU 的功耗、利用率和结温。采集到的数据通过消息队列（Kafka 等）传输，像楼里的弱电井一样把信号汇总到中控层；随后写入时序数据库（InfluxDB、Prometheus 等），把每一秒的曲线归档成“电费台账”；最上层是 Grafana 看板和告警规则，让值班员一眼看到哪台机器在“偷电”。链路里每一个环节都可能丢数据，因此团队最关心一个指标——数据采集完整率：

架构这趟线路，就是给每层楼布好“电表、网线、账本和监控屏”。线路完整，数据才完整，中控室的大屏才能真正反映大楼的呼吸——这是能效监测的地基，也是后面所有公式能成立的先决条件。

采集完整率=成功到达存储的样本数应采集样本数×100%\displaystyle 采集完整率 = \frac{成功到达存储的样本数}{应采集样本数 \times 100\%}
完整率越高，监测数据越可信，异常检测的漏报率就越低。
  1. 成功到达存储的样本数从 GPU 读取后，经过传输、写入存储都未丢失的数据点。就像电表读数真的被抄进了台账，而不是记在电工的小纸条上弄丢了。
    成功样本=总样本−丢失样本\displaystyle 成功样本 = 总样本 - 丢失样本
  2. 应采集样本数理论上按“采集频率 × 监测时长”算出的目标总点数。
    应采集样本=f×T\displaystyle 应采集样本 = f \times T
  3. 完整率的意义完整率低于 90% 时，缺失区间的异常可能被完全掩盖，后续统计检测都会失真。
    完整率≥90%视为健康\displaystyle 完整率 \geq 90\% \quad \text{视为健康}

核心指标

中控室大屏上，物业经理最常盯四块“表”：电表（GPU 功耗）看这台机器到底吃多少电；温度计（结温）看它是不是快“发烧”降频了；客流器（利用率）看它有几分钟在真正干活；还有一块“额定红线表”（功耗墙），提醒工程师别把设备逼到保护性关机的悬崖边。四块表各有脾气，少盯一块都会出乱子。

功耗（Power）是 GPU 整卡瞬间消耗的电功率，单位瓦特（W），它的曲线像心跳，高高低低跟随计算负载；利用率（Utilization）是流处理器（SM）忙碌时间的百分比，它说明“忙不忙”，却不直接等于“耗不耗电”——显存常驻或驱动残留都会让功耗保持高位；温度（Temperature）是 GPU 核心的结温，温度过高时显卡会主动降频来保护自己，出现“越跑越慢”的恶性循环；功耗墙（Power Cap/TDP）是制造商或管理员设定的功率上限，瞬时功耗可以短时间超出，但持续越线就会触发保护。把四块表合成一个“健康分数”，最常用的是 GPU 能效比：

四块表各有口径，但组合起来就是大楼的“健康档案”。物业经理从不在某一块表的单点读数上做决定，而是看四块表联动出来的整体画像——这正是能效监测从“记账”走向“诊断”的第一步。

能效比=有效算力输出（FLOPs）GPU实时功耗（W）\displaystyle 能效比 = \frac{有效算力输出（FLOPs）}{GPU 实时功耗（W）}
能效比衡量“每瓦电换来多少计算量”，是绿色 AI 的核心效率标尺。
  1. 有效算力输出训练过程中实际完成的浮点运算量（如 TerafLOPS）。注意“有效”二字剔除了空转和等待的泡沫。
    有效算力=∑t=1T算力(t)×忙闲因子(t)\displaystyle 有效算力 = \sum_{t=1}^{T} 算力(t) \times 忙闲因子(t)
  2. GPU 实时功耗同一时间窗内 GPU 整卡的瞬时功率，单位瓦特。
    功耗(t)=动态功耗+静态功耗\displaystyle 功耗(t) = 动态功耗 + 静态功耗
  3. 能效比读法数值越大，说明花的每度电都砸在了刀刃上。训练同一个模型，能效比高的机器能更快回本。
    能效比=完成步数千瓦时\displaystyle 能效比 = \frac{完成步数}{千瓦时}

采集频率

抄表频率是门手艺。物业经理如果让电工每分钟跑一层楼抄一次表，电费没省下，人工先翻倍；如果每季度才抄一次，楼里半夜偷电三月后才发现，账单已炸。监测系统面临同样的权衡：采样频率（Sampling Rate）决定数据的时间分辨率，也决定带宽和存储成本。

秒级采样（如 1 秒 1 次）已经能看清训练任务的宏观功耗趋势，适合做日报和周报；毫秒级采样（如 100 毫秒 1 次）专门用来捕获瞬时尖峰——比如梯度同步瞬间的功率爆发，这种峰值若只看秒级数据会被平均掉，就像拿月账单算不出一号楼某台空调半夜偷偷启动。但频率越高，传输带宽、存储空间、数据库写入压力都线性上涨，大量高频毛刺其实是噪声而非信号。所以成熟的监测系统会做动态调整：平常 5 秒采一次，检测到异常区间自动加密到 100 毫秒。用公式估算采样开销：

抄表频率的取舍，本质是“看得清”和“付得起”的博弈。聪明的物业经理不会全楼一个频率，而是给重点机房装高速电表、给普通楼层装慢速电表——按需采样，才能既抓得住偷电贼，又不让仓库堆满废纸。

采样数据量=采样频率×位宽×通道数×时长\displaystyle 采样数据量 = 采样频率 \times 位宽 \times 通道数 \times 时长
数据量决定存储和带宽成本，频率翻倍，成本翻倍；所以频率不是越高越好，而是“够用就好”。
  1. 采样频率每秒采集多少次读数，单位 Hz。1 Hz 即每秒 1 个点，10 Hz 即每秒 10 个点。
    f=1Δt\displaystyle f = \frac{1}{\Delta t}
  2. 位宽每个采样点占用的字节数。一个浮点数通常占 4 字节，再加上时间戳和标签，通常按 16 字节估算。
    单点大小=时间戳+指标值+标签\displaystyle 单点大小 = 时间戳 + 指标值 + 标签
  3. 通道数同时采集的设备数量。一个 64 卡集群就是 64 个通道，乘在一起数据量立刻膨胀。
    总通道=GPU数量×每卡指标数\displaystyle 总通道 = GPU数量 \times 每卡指标数
  4. 时长持续采集的总时间。三者相乘即为存储成本的最小估算。
    数据量(GB)=f×B×C×T\displaystyle 数据量(GB) = f \times B \times C \times T

异常检测

半夜两点，写字楼没人，但 3 号机房的电表在疯狂走字。物业经理知道：一定有设备在偷跑。能效监测的核心任务，就是从功耗曲线里抓出这种“不合理的跳变”。异常检测的挑战在于，GPU 功耗天然有波动——训练步进、数据加载、同步通信都会引起起伏，就像楼里偶尔有人在加夜班会开灯。怎么区分“正常加班”和“深夜偷电”？统计工具登场。

最常用的方法是滑动窗口（Sliding Window）：取当前时间点前后各 30 秒的数据，算出一个局部均值，代表“此刻的合理功耗基线”，再用 Z-score（标准分数）衡量当前值偏离基线多少个标准差。如果偏离超过 3 个标准差，就亮起红灯——这相当于物业经理看到整层楼只有一间房亮灯，但电表读数却等于整层满员时的功耗，显然有鬼。公式如下：

抓出异常只是第一步，物业经理还会把“功耗异常”和“温度异常”联动判断：如果功耗高但温度正常，可能是软件 bug 导致算力空转；如果功耗高且温度飙升，多半是散热失效或任务过载。两条线索交叉，才能分清是“小贼偷电”还是“设备生病”。

Z=x−μσ\displaystyle Z = \frac{x - \mu}{\sigma}
Z-score 把“偏高多少”标准化成“偏离了几个标准差”，让不同功耗水平的 GPU 之间有统一的异常判据。
  1. x（当前样本）此刻读到的 GPU 功耗实测值。
    x=功耗now\displaystyle x = 功耗_{now}
  2. μ（窗口均值）滑动窗口内所有样本的平均值，代表近期的正常基线。
    μ=1n∑i=1npi\displaystyle \mu = \frac{1}{n}\sum_{i=1}^{n} p_i
  3. σ（窗口标准差）窗口内功耗的波动幅度。σ 小说明楼里很安静，一点风吹草动就是异常；σ 大说明本来就很吵，容忍度要高一些。
    σ=1n∑i=1n(pi−μ)2\displaystyle \sigma = \sqrt{\frac{1}{n}\sum_{i=1}^{n}(p_i - \mu)^2}
  4. 判定规则|Z| > 3 视为异常，通常还需连续多次命中才触发告警，避免单点毛刺误报。
    ∣Z∣>3⇒异常\displaystyle |Z| > 3 \Rightarrow 异常

闭环调优

抓完贼，省电的战役才刚打完前半场。物业经理拿到月度电费账单，开始做节能改造：把加班楼层集中到同一侧以便关闭另一侧电梯；给机房加装隔热层减少空调负载；下个月再对比账单，看省了多少。这就是闭环——监测数据不能躺在数据库里吃灰，要喂给优化动作，再验证效果。

AI 训练集群的闭环调优路径清晰：首先是能耗报告，按任务、按 GPU 卡、按时段汇总能耗，生成“电费账单”，让每个算法工程师看到自己训练一次模型花了多少度电；然后是任务调度，把非紧急任务从用电高峰挪到低谷，或者给功耗超限的任务设置功率上限（限频），牺牲一点速度换整体稳定；接着是参数调优，比如发现 batch size 设置不当导致 GPU 利用率只有三成，功耗却不低，调整后既省电又快；最后是效果复测，用统一指标对比优化前后的能耗，确认省下来的电是真金白银：

闭环调优把“监测”从成本中心变成了利润中心。物业经理最骄傲的瞬间，不是大屏上曲线多漂亮，而是下季度电费单上那个下降的箭头——监测的最终价值，永远落在省下来的每一度电上。

能耗优化率=优化前能耗−优化后能耗优化前能耗\displaystyle 能耗优化率 = \frac{优化前能耗 - 优化后能耗}{优化前能耗}
优化率是闭环调优的“成绩单”：数值越高说明调度和调参越有效，但要同时监控训练时长，防止省了电却拖慢了上线。
  1. 优化前能耗同一训练任务在未调整配置时的总能耗，单位千瓦时（kWh）。
    Ebefore=∫0T1Pbefore(t) dt\displaystyle E_{before} = \int_{0}^{T_1} P_{before}(t)\,dt
  2. 优化后能耗调整调度或参数后，同任务跑完的总能耗。
    Eafter=∫0T2Pafter(t) dt\displaystyle E_{after} = \int_{0}^{T_2} P_{after}(t)\,dt
  3. 优化率计算分子是省下的电量，分母是原来的总电量。注意优化率受训练时长和功耗双重影响，单独看任何一个都可能被骗。
    优化率=Ebefore−EafterEbefore\displaystyle 优化率 = \frac{E_{before} - E_{after}}{E_{before}}

方案选型

写字楼要上监测系统，物业团队面临采购决策：是买现成的智能楼宇管理平台，还是让工程部自己写一套？开源方案灵活免费但需要专人维护；商业平台开箱即用但按点数收费，还要担心数据出网合规。AI 能效监测的选型也是在开源工具与商业平台之间走钢丝，同时要评估监测本身的开销。

开源阵营里，NVIDIA 官方提供的 NVML（管理库）和 DCGM（数据中心 GPU 管理器）负责底层指标读取，搭配 Prometheus 做时序采集、Grafana 做可视化，形成一套零授权的监测栈，适合有运维能力的团队深度定制；商业平台（如云厂商的能耗监控服务、第三方 FinOps 工具）提供开箱即用的报表、告警和优化建议，适合以业务为主的团队快速落地。选型的核心是算清“监测成本”：

选型的终点不是买完工具就完事，而是看向未来：新一代监测平台开始用机器学习预测负载、自适应调节采样频率、甚至自动执行降频策略，从“被动记账”进化到“主动管家”。物业经理的终极梦想，是一套能自己发现问题、自己解决一半问题的系统——这就是能效监测从工具走向基础设施的演进方向。

监测开销率=监测系统自身能耗训练集群总能耗\displaystyle 监测开销率 = \frac{监测系统自身能耗}{训练集群总能耗}
监测系统也要消耗 CPU、内存和网络带宽。经验上，监测开销率低于 3% 才划算，否则就陷入了“为了省电而更费电”的悖论。
  1. 监测系统自身能耗采集代理占用的 CPU、内存、网卡流量折算成的电耗。
    Emonitor=∑采集节点功耗×运行时长\displaystyle E_{monitor} = \sum 采集节点功耗 \times 运行时长
  2. 训练集群总能耗GPU 整机、CPU 主机、散热制冷和供电损耗的总和。
    Etotal=EGPU+Ehost+Ecooling\displaystyle E_{total} = E_{GPU} + E_{host} + E_{cooling}
  3. 开销率判断开源高频监控如果不加节制，可能自己吃掉几个点的算力；而商业平台如果按数据点计费，采样越频繁账单越贵，同样需要权衡。
    开销率=EmonitorEtotal<3%为健康\displaystyle 开销率 = \frac{E_{monitor}}{E_{total}} < 3\% \quad \text{为健康}

AI 应用场景

云厂商 GPU 集群能效报表与异常告警

阶段：训练基础设施运维与能效优化

解决的问题：云厂商运行着数千张 GPU 卡，传统做法靠人工巡检，功耗异常要等用户投诉才发现。引入能效监测后，秒级采集每卡功耗和温度，Z-score 检测在电压飙升的瞬间就能触发工单，自动定位到机柜和卡位，把平均故障发现时间从小时级压缩到分钟级。

具体案例：某云厂商的 AI 训练集群发现夜间“功耗幽灵”，监测系统在凌晨三点捕捉到 12 张卡功耗异常升高 40%，联动分析发现是某用户的推理任务占用了 GPU 显存持续空转。系统自动给该任务打上“可回收”标签并通知用户释放，当季度节省电费超 8 万元。

企业 AI 训练成本核算与 FinOps

阶段：成本治理与资源优化

解决的问题：传统成本核算按 GPU 卡时粗略分摊，算法团队不知道自己的实验到底耗了多少电。通过能效监测的能耗报告，每个训练任务都能出具“电费账单”，让团队直观看到模型训练对环境的影响，倒逼优化模型结构和参数配置。

具体案例：某互联网公司用监测数据发现，同一个推荐模型在两张不同型号 GPU 上训练，能效比相差 2.3 倍。团队将推理任务迁移到低功耗卡，训练任务集中在高能效卡，整体电费下降 17%，并将“单位模型能耗”写入新模型上线的评审清单。

绿色 AI 碳排放核算与 ESG 报告

阶段：企业可持续发展战略

解决的问题：ESG 报告需要披露 AI 算力的碳排放数据，传统方法只能按机房总电费估算，误差极大。能效监测按 GPU 型号、任务类型拆分能耗，结合当地电网碳排放因子，输出可审计的碳足迹报表。

具体案例：某金融机构为满足监管要求，用能效监测系统按季度输出训练与推理的能耗明细，并通过“能效比排行榜”推动各业务线优化，一年内单位训练任务的碳排放强度下降 24%，相关成果被写入社会责任报告。

Python 演示

python51 行
import mathimport random  class EnergyMonitor:    """模拟 GPU 集群能效监测: 滑动窗口 Z-score 异常检测."""     def __init__(self, window: int = 30, threshold: float = 3.0):        self.window = window        self.threshold = threshold     def detect(self, series: list) -> list:        """返回异常点的索引列表."""        anomalies = []        n = len(series)        for i in range(n):            left = max(0, i - self.window)            right = min(n, i + self.window + 1)            window_data = series[left:right]            mu = sum(window_data) / len(window_data)            variance = sum((v - mu) ** 2 for v in window_data) / len(window_data)            sigma = math.sqrt(variance + 1e-9)            z = abs(series[i] - mu) / sigma            if z > self.threshold:                anomalies.append(i)        return anomalies  def simulate_gpu_power(num_steps: int = 600, seed: int = 42) -> list:    """生成随训练步数波动的模拟 GPU 功耗序列, 包含异常尖峰."""    random.seed(seed)    series = []    base = 280.0    for i in range(num_steps):        v = base + math.sin(i / 20.0) * 30.0 + random.uniform(-10.0, 10.0)        if i % 80 > 71:            v += 140.0        series.append(v)    return series  if __name__ == "__main__":    power = simulate_gpu_power()    monitor = EnergyMonitor(window=30, threshold=3.0)    abnormal = monitor.detect(power)    total_power = sum(power)    abnormal_power = sum(power[i] for i in abnormal)    print("总能耗(模拟瓦秒):", round(total_power, 1))    print("异常点数:", len(abnormal))    print("异常位置(前10个):", abnormal[:10])    print("异常能耗占比:", round(abnormal_power / total_power * 100, 2), "%")
目的：用滑动窗口 Z-score 检测模拟 GPU 功耗曲线中的异常尖峰，并统计异常能耗占比——这是能效监测系统最核心的检测算法原型。
  1. class EnergyMonitor定义一个能效监测器，window 是滑动窗口半径，threshold 是 Z-score 判定阈值，模仿物业经理的“警觉程度”。
  2. def detect(self, series: list) -> list遍历每个时间点，取前后各 30 个样本组成局部窗口，计算局部均值和标准差。
  3. variance = sum((v - mu) ** 2 for v in window_data) / len(window_data)计算窗口内功耗的方差，再开平方得到标准差，衡量“楼里安静程度”。
  4. z = abs(series[i] - mu) / sigma当前功耗偏离基线多少个标准差，偏离越多越可疑。
  5. if z > self.threshold超过 3 个标准差就记录为异常点，相当于深夜走廊里突然亮起的灯。
  6. simulate_gpu_power模拟 600 个时间步的 GPU 功耗，包含正常波动和每 80 步出现一次的尖峰，用于演示算法的判别能力。

常见误区

误区看到利用率 100% 就断定这台 GPU 在疯狂耗电，利用率低就以为它在省电。

正解利用率反映的是流处理器“忙不忙”，功耗反映的是“吃多少电”，两者不成正比。GPU 显存常驻数据、驱动后台任务、甚至散热风扇全速运转时，功耗都可能维持在高位，即便利用率只有 20%。判断能耗必须直接读功耗指标，而不是拿利用率“猜”，就像看办公室能耗不能只数人头，还要看空调是不是全开着。

为何常见：人们习惯用“忙碌程度”推断“消耗程度”，但在芯片世界，静态功耗（漏电、显存刷新）占比不小，导致二者经常脱节。

误区为了“不留死角”，把采集频率调到 10 毫秒一次，觉得数据越密越安全。

正解频率翻倍意味着带宽、存储、数据库写入成本全部翻倍，高频样本里充斥着热噪声和瞬时毛刺，反而干扰异常检测。更合理的做法是按需分层：稳态用秒级采样，检测到可疑区间再自动加密到毫秒级，像物业只在深夜疑似异常时才调取高帧率监控录像，而不是全年无休录 4K 视频。

为何常见：技术新人直觉认为“更多数据 = 更准结论”，忽略了数据采集本身是有资源代价的。

误区看到某秒功耗超过了 GPU 的 TDP（热设计功耗）就立刻告警，认为设备要烧了。

正解GPU 的动态加速（Boost）机制允许功耗短时间超过 TDP，这是硬件设计的正常操作，就像电梯允许短时间超载 10% 完成救援。真正需要告警的是“持续超限”或“超限幅度离谱”。成熟监测系统会要求连续多个窗口的 Z-score 都超阈值才触发告警，把瞬时毛刺过滤掉。

为何常见：把厂商标注的“建议上限”误解为“物理红线”，忽略了现代硬件都带有短时超频容错设计。

误区把 NVML 读到的 GPU 功耗乘以运行时长，就当作整个训练任务的能耗成本。

正解数据中心里 GPU 只是“电老虎”之一，CPU 主机、内存、网卡、存储阵列，以及占比常达 30% 以上的散热制冷，都在烧电。完整的能效核算应该覆盖整机柜甚至整个数据中心的 PUE（电源使用效率），否则你优化了半天 GPU，可能只动了总能耗的三分之一。

为何常见：GPU 是训练中最显眼的硬件，初学者容易把注意力全放在它身上，忽略基础设施的电费账单里还有一大块“隐形开销”。

面试题

Q1. 能效监测的首要目标是什么？

单选题 · easy

  • A.降低 GPU 采购成本
  • B.量化能耗并支撑优化← 正确答案
  • C.提升模型推理精度
  • D.加速训练数据准备

答案：B。能效监测的核心是“先看清再优化”，为能耗优化提供数据驱动依据。B 准确概括了这一目标。A 是采购决策，C 和 D 是模型效果问题，都与能耗计量无直接关系。

Q2. GPU 功耗墙（TDP）指的是什么？

单选题 · easy

  • A.GPU 的最长使用年限
  • B.风扇支持的最高转速
  • C.制造商设定的功率上限← 正确答案
  • D.显存的最大存储容量

答案：C。TDP（热设计功耗）是厂商给出的功率参考上限，超过会触发降频保护。A 是寿命概念，B 是散热概念，D 是容量概念，都不涉及功率约束。

Q3. 采样频率设置过高会带来什么问题？

单选题 · mid

  • A.带宽和存储成本上升← 正确答案
  • B.训练速度自动变快
  • C.显卡散热效果更好
  • D.模型精度显著提升

答案：A。采样频率与数据量成正比，频率翻倍则带宽、存储和数据库开销翻倍。B、C、D 都与采样频率无关——训练速度和模型精度由计算任务决定，散热由物理环境决定。

Q4. 能效比公式中的分母是什么？

单选题 · mid

  • A.GPU 实时功耗← 正确答案
  • B.GPU 显存容量
  • C.训练样本总数
  • D.服务器 CPU 核数

答案：A。能效比 = 有效算力输出 ÷ GPU 实时功耗，衡量每瓦电换来多少计算量。显存、样本数、CPU 核数都不是直接耗电功率，因此不具备“每瓦效率”的含义。

Q5. 下列哪些属于能效监测的核心指标？

多选题 · hard

  • A.GPU 实时功耗← 正确答案
  • B.GPU 利用率← 正确答案
  • C.GPU 结温温度← 正确答案
  • D.模型参数量

答案：ABC。核心指标是功耗、利用率、温度以及由此推出的功耗墙状态，它们直接反映能耗与健康状态。模型参数量是算法设计属性，不随运行状态变化，也不是能耗指标。

Q6. 滑动窗口 Z-score 检测需要哪些统计量？

多选题 · hard

  • A.窗口内功耗均值← 正确答案
  • B.窗口内功耗标准差← 正确答案
  • C.集群总 GPU 数量
  • D.训练集样本规模

答案：AB。Z-score = （当前值 − 均值） ÷ 标准差，只依赖局部窗口的均值和标准差。GPU 数量和训练集规模属于集群配置与任务数据，与单点离群判定无关。

Q7. 监测到 GPU 功耗持续异常超限的首选动作是什么？

单选题 · mid

  • A.立即强制关机
  • B.定位异常并调整调度← 正确答案
  • C.中断所有训练任务
  • D.忽略等待自动恢复

答案：B。正确流程是先定位异常来源（任务缺陷、散热故障或资源竞争），再通过调度策略调整，如限频、迁移任务。直接关机或中断所有任务会伤及无辜工作负载，忽略则可能扩大故障。

Q8. 闭环调优通常包含哪些环节？

多选题 · hard

  • A.生成能耗报告← 正确答案
  • B.调整任务调度策略← 正确答案
  • C.验证优化前后的差异← 正确答案
  • D.追加采购 GPU 数量

答案：ABC。闭环是“报告 → 调度/调参 → 复测”的循环，强调用数据驱动优化并验证效果。追加采购 GPU 属于扩容决策，不在能耗调优的闭环动作之列。

Q9. 数据采集完整率过低会导致什么后果？

单选题 · mid

  • A.监测结果更有参考价值
  • B.异常检测漏报率升高← 正确答案
  • C.训练任务加速完成
  • D.GPU 显存容量变大

答案：B。完整率低意味着大量功耗数据在传输或存储中丢失，缺失区间的异常会被掩盖，统计基线（均值、标准差）也会失真，导致漏报。完整率不影响训练本身的性能或显存。

Q10. 以下哪项属于开源能效监测的技术组合？

单选题 · easy

  • A.NVML 与 Prometheus← 正确答案
  • B.手工抄表记录
  • C.纸质值班日志
  • D.Excel 离线统计

答案：A。NVML 负责读取 GPU 功耗等指标，Prometheus 负责时序采集与告警，是典型的开源监测栈。手工抄表、纸质日志和 Excel 都属于离线人工方式，无法支撑实时监测与异常检测。