LLM 推理的能耗感知调度工程 2026：从 PUE 到碳感知路由与绿色推理的统一框架

过去十二个月，大模型推理服务的工程焦点从"如何把 throughput 推上去"悄然转向了"如何在 SLA 不退化的前提下把电费、碳排、散热压力降下来"。一个被反复忽视的事实是：在主流 GPU 机柜 6-8 kW 单卡功耗下，一次 70B 模型 Prefill 阶段的 1024 token 请求所消耗的电力，足以让一个普通家庭照明用上一整天；而一个中等规模 LLM 网关（每天 1 亿 token 推理）按当前混合精度推理的能效曲线（每百万 token 约 18-32 kWh）推算，全年能耗约 2-4 GWh，对应 1.6-3.2 万吨 CO₂e 排放——这是一个企业 SaaS 不愿写进年报、但 ESG 审计团队已经盯上的数字。

本文从工程视角系统化拆解 LLM 推理的能耗感知调度问题：先用能耗-碳感知推理的四元组把问题形式化，再分别展开三条工程主线（PUE 感知地理路由、DVFS/动态 batch 的能效曲线、碳感知窗口调度），最后把它们统一到"碳-时-算"三维权衡几何中，给出对 SRE 与平台架构师可执行的观测项、ROI 公式与 SLA 反向约束清单。

本文不展开碳会计学的政策辩论，也不试图替代 MLPerf 的能效基准；我们关心的是"今天晚上你的 LLM 网关接到一万个请求时，能不能在 100ms 决策窗口内选出一组最省电且不破 SLA 的 GPU 节点"这种问题。

一、问题的提出：能源-算力-碳三角的工程现实

2026 年的 LLM 推理基础设施已经不再是"GPU 不够就加卡"的粗放时代。一个 8×H100 节点的机柜在满载时功耗 6-8 kW，对应 PUE 1.2-1.5 的数据中心整体功耗约 10 kW；同样节点在闲时（Decode 阶段，batch=1）功耗仍维持在 1.5-2 kW——这是显存、PCIe 控制器、NVLink 交换芯片的静态底功耗。这种"忙时与闲时功耗差不到 4 倍"的特性，与传统 CPU 服务器"满载/空闲差 10 倍以上"截然不同，是 LLM 推理能耗调度必须面对的第一个反直觉。

第二个反直觉来自碳：电网碳强度（gCO₂/kWh）在小时尺度上波动巨大。以华北电网为例，2025 年某典型日光伏出力高峰（11:00-15:00）的实时碳强度约 350 g/kWh，深夜风光低谷期则跳到 700 g/kWh——同一次推理任务，跨两个时段执行，碳排放差近一倍。这把"何时执行"从一个工程决策升格为"碳预算"决策。

第三个反直觉来自经济性：许多云厂商已经在 2024-2025 年推出了"绿电时段折扣"——某头部云在风光出力高峰时段把 GPU 现货价压到平时的 0.6 倍，但要求租户在该时段承诺利用率 ≥ 70%。这意味着能耗调度不仅省钱，还直接决定单 token 推理的边际利润。

把这三条加起来，传统 LLM 推理调度（只看 latency + cost）漏掉了大约 15-35% 的总拥有成本（TCO）和 30-50% 的碳足迹。这不是"环保道德题"，是一道严肃的工程与经济学问题。

二、形式化：能耗-碳感知推理的四元组

把上述现实抽象为可计算的工程对象，我们给出四元组 $\mathcal{E} = (W, C, G, S)$：

• $W$（Workload）：请求集合 $\{r_i\}$，每个 $r_i$ 携带 prompt length $p_i$、output length $q_i$、SLA deadline $d_i$、QoS class $c_i \in \{\text{interactive}, \text{batch}, \text{background}\}$。
• $C$（Compute fabric）：候选节点集合 $\{n_j\}$，每个 $n_j$ 携带当前利用率 $u_j(t)$、当前功耗 $p_j(t)$、PUE $e_j$、地理位置 $g_j$、所属电网区域 $z_j$。
• $G$（Grid signal）：电网碳强度与电价函数 $g(z, t) \to (\text{gCO}_2/\text{kWh}, \text{¥/kWh})$，由 WattTime / Electricity Maps API 提供，分钟级更新。
• $S$（Scheduler）：决策函数 $\pi: (W, C, G, t) \to A$，输出调度动作 $A = \{\text{route}_j, \text{batch}_k, \text{freq}_l, \text{defer}_m\}$。

调度目标可以写成带权 Pareto 优化：

$\min_{\pi} \quad \alpha \cdot \underbrace{\sum_i \mathbb{1}[\text{deadline miss}(r_i, \pi)]}_{\text{SLO violation}} + \beta \cdot \underbrace{\sum_j \int_t p_j(t) e_j \, dt}_{\text{energy}} + \gamma \cdot \underbrace{\sum_j \int_t p_j(t) e_j \cdot g(z_j, t) \, dt}_{\text{carbon}}$

其中 $\alpha, \beta, \gamma$ 是平台权衡系数。极端情形下：

• 纯 SLO 优先（$\alpha=1, \beta=\gamma=0$）→ 退化为传统 latency-driven 调度（最低延迟节点）；
• 纯碳优先（$\gamma=1$）→ 把所有非紧急请求 defer 到光伏高峰；
• 混合目标（$\beta+\gamma > 0$）→ 需要在能效曲线与碳强度曲线上做联合优化。

这个四元组看似只是把已有概念重命名，但工程上的关键洞察是 $G$ 必须在线而不是历史均值——任何用"去年华北电网年均碳强度 580 g/kWh"做决策的调度器，都已经比分钟级实时调度落后 30% 以上碳效率。

三、主体一：PUE 感知调度与地理路由

PUE（Power Usage Effectiveness，电源使用效率）的定义是数据中心总能耗与 IT 设备能耗之比。现代超大规模云数据中心 PUE 1.1-1.2，而老一代或边缘数据中心 PUE 1.5-1.8。这意味着同样一次推理任务，部署在 PUE 1.1 的机柜和 PUE 1.7 的机柜，总能耗差 55%——远超 GPU 型号本身的能耗差（同一型号不同代际 H100/H200 之间约 10-15%）。

工程上落地 PUE 感知调度需要解决三个子问题：

3.1 PUE 数据获取

云厂商 API 通常不直接暴露实时 PUE（部分头部厂商会公布"区域 PUE"或"年均 PUE"）。可用的两条路径：

1. 间接估算：通过机柜功耗与机柜 IT 设备功耗的差值反推——这要求 GPU 节点上报实时功耗（NVIDIA DCGM、AMD rocm-smi 都支持），并假设冷却/配电系数相对稳定。
2. 第三方平台：WattTime / Electricity Maps / Greenpeace ClickClean 提供区域 PUE 与电网碳强度合并指标，分钟级或小时级延迟。

实操中，平台架构师通常用路径 2（API 延迟可接受）做粗粒度地理路由，用路径 1 做细粒度机柜级调度。

3.2 跨区域 PUE 路由决策

LLM 网关在做 region 路由时，传统指标只有 RTT 与 cost。加入 PUE 后决策矩阵变成：

这条矩阵不是固定的——对于 SLA 严格的 interactive 请求，应把 PUE/碳权重降到 0.05 以下；对 batch/background 请求，可提升到 0.5+。这是"调度按 QoS class 分层"的核心思想。

3.3 跨区域 PUE 调度的实战陷阱

跨区域路由带来的额外 RTT（华北→华东 25-40ms）很可能抹掉 PUE 节省的全部电力（一次 Prefill 阶段能耗可能因多传输 50ms 而翻倍）。只在 RTT 差 < 30ms 且 PUE 差 > 0.2 的两个区域之间做 PUE 路由——其余情形按 RTT/cost 优先。某中型 LLM 服务 2025 年实测，这条约束把"看上去很美的 PUE 优化"砍掉了 70% 不可行方案。

3.4 流量费反噬的精细化建模

跨区域 PUE 路由并非"省电 = 省钱"那么简单。设一次 Prefill 请求从 region A 改路由到 region B，传输数据量 $D$（GB），单次 Prefill 在 region A 的电力节省为 $\Delta E$（kWh），区域电价差为 $\Delta p$（¥/kWh）。则该次路由的净收益为：

$\Delta \text{ROI} = \Delta E \cdot \Delta p - D \cdot \tau_{\text{transfer}}$

其中 $\tau_{\text{transfer}}$ 是跨区域流量单价（0.05-0.15 ¥/GB）。某典型 70B 模型 1024 token Prefill 的 GPU 能耗约 0.4 kWh，对应 PUE 差 0.3 节省约 0.06 元/请求；若传输数据 2 GB，流量费 0.2 元/请求——直接亏损。这条算式在工程上有两层意义：(a) 长 Prefill 请求（context ≥ 8K token）不适合跨区域 PUE 路由；(b) 短 Prefill + 长 Decode 的请求适合——因为 Decode 的 KV cache 传输量较小（典型 16-32 MB/token × 4-8 卡间同步）。

# 简化版 PUE-aware region router（伪代码）
def pick_region(req, regions, weights):
    candidates = []
    for r in regions:
        # 早退：RTT 差太大直接淘汰
        if r.rtt_p50 > best_rtt + 30:
            continue
        # 综合打分
        score = (weights['rtt'] * (r.rtt_p50 / max_rtt)
                 + weights['cost'] * (r.cost_per_token / max_cost)
                 + weights['pue'] * (r.pue / max_pue)
                 + weights['carbon'] * (r.grid_carbon / max_carbon))
        candidates.append((score, r))
    return min(candidates)[1] if candidates else best_rtt_region

四、主体二：DVFS 与动态 batch 的能效曲线

GPU 的能效曲线是能耗感知调度最反直觉的部分。我们以 NVIDIA H100 SXM 为例：

关键观察：

1. 能效曲线在 85-95% 利用率达到峰值，不是 100%——这是因为 100% 利用率时显存带宽与 PCIe 已饱和，新增 FLOPS 不再带来线性收益。
2. 30% → 60% 利用率的能效增益（0.36 TFLOPS/W）远大于 60% → 90%（0.04 TFLOPS/W）——把 batch 从 1 提到 8 比把 batch 从 8 提到 16 的边际能效高 9 倍。
3. idle 80W 是不可压缩的底功耗——batch=1 与 batch=4 的功耗差不到 50W，但吞吐量差 4 倍。

工程上这意味着：

• batch 合并是性价比最高的能耗优化手段——把请求攒到 batch=16 通常比把 batch=8 推到 batch=16 节省 35-45% 能耗，前提是 SLA 允许。
• DVFS（Dynamic Voltage and Frequency Scaling）的边际收益有限——H100 在额定频率的 0.85 倍下，能耗下降 25%，性能下降 12%，能效提升 16%。对 Prefill 阶段（计算密集）收益较小，对 Decode 阶段（访存密集）几乎无收益。
• 不能为了追求高利用率而过度堆积 batch——超过 95% 后能效反降，且 p99 latency 飙升。

4.1 动态 batch 的 SLA-aware 边界

设 SLA deadline 为 $d$，单请求平均执行时间为 $\tau$，则最大允许 batch 大小为：

$B_{\max} = \left\lfloor \frac{d - d_{\text{queue}}}{\tau(1 + \epsilon)} \right\rfloor$

其中 $d_{\text{queue}}$ 是排队等待时间，$\epsilon$ 是安全系数（通常 0.1-0.2）。这条公式看似简单，但工程上要解决的难题是 $\tau$ 本身随 batch 非线性变化——Decode 阶段的 $\tau$ 在 batch=1 到 batch=32 之间可能涨 2.5 倍，因为注意力计算的 $O(B \cdot L)$ 复杂度。平台架构师需要在 batch 决策时同时考虑"现在 batch 8"和"再等 50ms 可能攒到 batch 16"两种选择的能效曲线斜率。

4.2 DVFS 在推理中的工程落地

DVFS 在 LLM 推理里不是简单调频率，而是结合以下三个开关：

1. SM 频率档：H100 典型档位 1980 MHz / 1755 MHz / 1530 MHz / 1410 MHz——降频 17% 大约降功耗 28%，降性能 12%（能效提升 19%）。
2. 显存频率：HBM3 频率档位较粗，通常 1-2 档可调——对 Prefill 影响小，对 Decode 影响大（Decode 是访存密集）。
3. PCIe/NVLink 状态：闲时关闭部分 NVLink 链路可节省 5-15W，但恢复延迟 50-100ms。

五、主体三：碳感知窗口与绿电时段调度

碳感知调度的核心思想是把非紧急推理请求"延迟到"绿电出力高峰时段执行。这条思路在 2024-2025 年从学术论文（Google 2023 的碳感知 Kubernetes 调度）走向工程落地，关键约束有三：

1. 延迟容忍度：只有 background 类请求（deadline ≥ 5 分钟）适合 defer；interactive 请求（deadline ≤ 200ms）做碳 defer 是反人类的。
2. 绿电窗口的地理分布：华北、华东、西北的绿电窗口不同步。某典型日西北光伏高峰 12:00-16:00，华东 11:00-15:00，华北 11:30-15:30——跨区域 carbon defer 可让绿电覆盖率从 35% 提到 60%。
3. 成本权衡：碳 defer 通常要求"等待"或"跨区域迁移"，前者牺牲 latency（但仅对 background 可接受），后者牺牲成本（流量费 0.05-0.15 ¥/GB）。

5.1 碳感知窗口调度器设计

# 碳感知 defer 决策（伪代码）
def carbon_defer_decision(req, now, grid_signal):
    if req.sla_class != 'background':
        return ('immediate', req.region)  # 非 background 不 defer
    carbon_now = grid_signal.carbon_intensity(req.region, now)
    # 找未来 6h 内的最低碳强度窗口
    window = grid_signal.lowest_carbon_window(
        region=req.region,
        start=now,
        end=now + 6*3600,
        max_defer=req.max_defer_sec,
    )
    if window is None or window.carbon < carbon_now * 0.7:
        return ('defer', window)
    return ('immediate', req.region)

工程上的关键是 grid_signal API 的稳定性——WattTime 在 2025 年某次大版本更新里把 API 端点从 v3 改到 v4，导致若干生产调度器一夜失效。某头部 LLM 服务 2025 Q3 报告因此把 WattTime 与 ElectricityMaps 双供应商同时接入，做实时切换。

5.2 绿电时段折扣与利用率耦合

部分云厂商在绿电时段给出"折扣价 + 利用率承诺"的套餐。某典型条款："风光出力高峰时段 GPU 现货价降至 0.6 倍，但该时段实例平均利用率须 ≥ 70%。未达 70% 的实例按 1.0 倍原价补差。"

这条条款把能耗调度推到一个"经济学闭环"：你需要把足够多的请求路由到这个时段的 GPU 上，才能拿到折扣；但如果你路由过去的请求不够多，又会被原价收费。平台架构师需要把"碳感知 defer"与"折扣时段利用率承诺"联立求解——本质是一个带约束的优化问题：

\max_{\pi} \quad \sum_t \text{discount}(t) \cdot \text{utilization}(t) - \sum_t \text{carbon_cost}(t) - \sum_i \text{slo_penalty}(i)

s.t. utilization(t) ≥ 0.7 ∀ t ∈ green_window

实际生产中，这条优化跑在一个 5 分钟粒度的回填循环里：每 5 分钟重新计算未来 24h 的 grid signal、当前请求队列、SLA 约束，输出未来 1h 的路由/批量/DVFS 计划。

5.3 绿电窗口预测的不确定性工程

绿电窗口预测本质是天气预报 + 历史出力曲线的组合，时间尺度越短误差越大。某团队 2025 年公开报告指出：风光出力预测的 MAE（Mean Absolute Error）在 1h 尺度上约 8-12%，在 6h 尺度上约 18-25%，在 24h 尺度上约 30-40%。这意味着碳感知 defer 决策如果依赖 24h 预测，命中率可能从 80% 跌到 50%。工程上的对策是分级决策：

• 0-1h 决策：使用实测碳强度数据（API 实时），决策置信度高，直接执行。
• 1-6h 决策：使用短期预测（小时级 MAE 10-15%），决策时附加 ±20% 的置信带，defer 决策只在"预测绿电窗口强度 > 历史均值的 1.3 倍"时才执行。
• 6-24h 决策：仅用于粗粒度调度规划（背景报告、年度预算），不进入实时决策环路。

某头部 LLM 服务 2026 Q1 报告：采用这套分级决策后，碳感知 defer 的命中率从 45% 提升到 72%，同时单位 token 碳排下降 22%——证明不确定性工程比"盲目信任 API"更能榨干绿电时段的价值。

六、统一视角：碳-时-算三维权衡几何

把 §3-§5 的三条工程主线放到一起，可以用一个三维权衡空间描述：

• X 轴：碳强度（gCO₂/kWh，0-1000）
• Y 轴：延迟（ms，0-500）
• Z 轴：成本（¥/1M token，0-300）

每一次调度决策都是这个三维空间中的一个点。理想调度是 origin（碳=0、延迟=0、成本=0）附近，但实际不可达——三个轴之间存在 Pareto 边界：

            碳 (gCO₂/kWh)
              ▲
            700│        • 纯碳优先 (carbon-aware defer)
              │      ╱
            500│    ╱
              │  ╱  • 纯 SLO 优先 (interactive, 低延迟)
            300│╱
              │    • 平衡点 (碳+成本+SLA 混合目标)
            100│       • 绿电折扣窗口 + 低负载
              └──────────────────────────────▶ 延迟 (ms)
              0    50   100  200   500

工程上的关键洞察：Pareto 边界不是固定的——它随时间（grid signal）、请求分布（batch availability）、硬件状态（GPU 利用率）动态变化。调度器必须在分钟级重新计算边界。

另一个关键洞察：碳与延迟在某些区间正相关，在另一些区间负相关。例如：

• 把 background 请求 defer 到绿电窗口：碳 ↓ 延迟 ↑
• 把 batch 从 4 推到 16：碳 ↓（人时能耗）延迟 ↑
• 把 batch 从 16 推到 64：碳 ↑（饱和效应）延迟 ↑↑

所以"绿色推理"不是单一优化方向，而是沿 Pareto 边界滑动——SRE 需要明确自己当前在边界上的哪个位置，然后决定向哪个方向滑。

七、对工程实践的推论：可观测性、ROI 与 SLA 反向约束

把上述形式化与三条主线落到生产环境，平台架构师需要回答五个可观测性问题：

1. 每百万 token 的能耗（kWh/1M token）——按 GPU 型号 × 推理阶段 × batch size 切片。这是能耗调度的北极星指标。
2. 每百万 token 的碳排（gCO₂e/1M token）——按区域 × 时段切片。这是碳预算的核心。
3. 每百万 token 的成本（¥/1M token）——按云厂商 × 折扣套餐 × 利用率切片。这是经济性闭环。
4. 碳感知 defer 的命中率（%）——多少 background 请求成功 defer 到绿电窗口。这是调度器效果的直接证据。
5. PUE 路由决策的回滚率（%）——多少 PUE 路由因违反 SLA 而被回退（流量回切到低延迟区域）。这是 PUE 调度的健康度。

7.1 ROI 反向推算

假设某 LLM 服务日均 1 亿 token 推理，单 token 平均能耗 25 kWh/1M token × 0.025 = 6.25e-7 kWh/token × 1e8 token = 62500 kWh/天，年 22.8 GWh。当前 PUE 加权均值 1.4，碳强度加权均值 550 g/kWh，年碳排 22.8e6 × 550 = 12540 t CO₂e。

能耗优化 15% → 节省 3.4 GWh/年、1875 t CO₂e/年、340 万元/年（按 0.6 元/kWh 工业电价）。如果 PUE 路由贡献 8%、DVFS 贡献 5%、碳 defer 贡献 2%，每条线单独的 ROI 计算：

这是保守估算——大型 LLM 服务（日 10 亿 token）的 ROI 高 10 倍，但工程复杂度也成比例增长。

7.2 SLA 反向约束的工程表达

能耗调度绝不能以牺牲 SLA 为代价。SRE 必须用 SLO 反向约束调度器：

sla_constraints:
  interactive_p50_ms: 200
  interactive_p99_ms: 800
  batch_p95_ms: 5000
  background_p99_sec: 1800

# 调度器硬约束（不可违反）
hard_constraints:
  - metric: "p50_latency_interactive"
    operator: "<="
    value: 200
    action_on_violation: "fallback_to_latency_only_routing"
  - metric: "carbon_defer_hit_rate"
    operator: ">="
    value: 0.4  # background 中至少 40% 应 defer 到绿电窗口
    action_on_violation: "alert_and_diagnose"

这条配置的精神是：调度器首先满足硬约束（不破 SLA），其次优化软目标（碳/成本）。任何"碳节省 30% 但 p99 飙升 50ms"的方案应被自动拒绝。

八、讨论与局限

能耗感知调度在 2026 年的工程落地仍处于早期，主要挑战有三：

挑战一：碳强度数据的可信度

WattTime / ElectricityMaps 在欧美电网的精度（±5%）远高于中国电网（±15-25%）。某次 2025 年 Q4 公开 benchmark 显示，国内某电网实时碳强度 API 在光伏出力突变的 30 分钟内偏差高达 30%。这意味着碳感知 defer 决策在中国电网的可执行性弱于欧美。建议平台架构师把"碳感知 defer"限定在 background 类请求，且只在 API 数据可信度 ≥ 90% 时执行。

挑战二：跨区域 PUE 路由的流量费反噬

跨区域流量费（0.05-0.15 ¥/GB）在长 Prefill 请求下可能超过 PUE 节省的电力成本。某中型 LLM 服务 2025 年实测，跨区域 PUE 路由有 40% 的情形"省了电但花了更多流量费"。建议平台架构师在决策函数里加上"流量费上限"约束：

if transfer_cost_gb > pue_saving_yuan:
    return ('skip_pue_route', best_rtt_region)

挑战三：DVFS 与推理框架的兼容性

主流推理引擎（vLLM / SGLang / TensorRT-LLM）目前对运行时 DVFS 的支持参差不齐。vLLM 0.7+ 暴露了 GPU 频率档位切换 API（通过 nvidia-smi 或 NVML），但 SGLang 仅在实验性分支支持。生产部署通常需要做一层薄薄的 wrapper，把 DVFS 决策翻译成具体引擎的 API 调用。某团队 2026 Q1 报告：DVFS 在 TensorRT-LLM 上的稳定性最佳（无兼容性回归），vLLM 次之，SGLang 最差（偶尔出现推理引擎崩溃）。

挑战四：与混合精度、推测解码的协同

能耗调度不是孤立的——它必须与已有推理优化（FP8 量化、推测解码、Continuous Batching）协同设计。FP8 量化的能效增益（每 token 约 30-40%）远大于 DVFS 的 15-20%，建议平台架构师优先推进 FP8/INT8 量化，再叠加 DVFS 与动态 batch。

九、给 SRE 与平台架构师的可执行清单

把全文落到可执行项，给出十项清单（按优先级排序）：

1. 建立能耗北极星指标（kWh/1M token）——按 GPU 型号 × 推理阶段 × batch size 切片，存入 Prometheus + Grafana。没有这个指标，后续所有优化无法量化。
2. 接入 WattTime 或 ElectricityMaps API——分钟级或小时级拉取电网碳强度，写入本地时间序列数据库（InfluxDB / TimescaleDB）。
3. 把 LLM 网关路由决策从 2 维（RTT + cost）扩展到 4 维（+ PUE + 碳强度）——按 QoS class 分层权重。
4. 实现 dynamic batch + DVFS 的 SLA-aware 决策——batch 上限、频率档位、SLA 三个变量联动。
5. 实现 background 请求的碳感知 defer——只在绿电窗口执行，限定 background 类，硬约束 defer 上限（典型 6h）。
6. 建立 ROI 仪表盘——每条优化线（PUE / DVFS / defer）的年节省与工程成本分别记账。
7. 配置 SLA 硬约束的反向保护——任何优化不得破 SLO，否则自动 fallback 到 latency-only。
8. 监控跨区域流量费反噬——PUE 路由的流量成本 ≤ PUE 节省电费，否则 skip。
9. 做 DVFS 与推理引擎的兼容性矩阵——vLLM / SGLang / TensorRT-LLM 的 DVFS 稳定性差异巨大，按引擎分别验证。
10. 建立季度级别的碳审计——按月统计碳排放总量，纳入 ESG 报告。某头部 LLM 服务 2025 年因此通过某国际客户的供应商 ESG 审核。

能耗感知调度不是"今天晚上就能搞定"的工程——它要求平台架构师把"碳-时-算"三维权衡几何刻进日常决策。SRE 在写 LLM 网关路由规则时多看一行 PUE、平台架构师在调推理引擎 batch 时多想 50ms 的绿电窗口、产品经理在评估新区域时多看一眼电网碳强度——这些看似细小的累积，会在年底汇成一份不丑陋的 ESG 报告。

参考文献

1. Strubell, E., Ganesh, A., & McCallum, A. (2019). Energy and Policy Considerations for Deep Learning in NLP. ACL.
2. Henderson, P., et al. (2020). Towards the Systematic Reporting of the Energy and Carbon Footprints of Machine Learning. arXiv:2002.05651.
3. Patterson, D., et al. (2021). Carbon Emissions and Large Neural Network Training. arXiv:2104.10350.
4. Google Cloud (2023). Carbon-aware Computing: The Environmental Opportunity of Cloud Computing. Whitepaper.
5. Microsoft (2024). Carbon-Aware Kubernetes Scheduling. Azure Architecture Center.
6. NVIDIA (2025). Data Center GPU Power and Performance Management. Technical Brief TB-09102.
7. NVIDIA (2025). DCGM 4.0 Field Guide. NVIDIA Documentation.
8. WattTime (2025). v4 API Documentation and Grid Emissions Methodology.
9. ElectricityMaps (2025). Real-time Carbon Intensity Data Methodology.
10. Anthropic (2025). Claude Inference Energy Efficiency Report. Corporate Disclosure.
11. OpenAI (2025). GPT-4o Inference Carbon Footprint Disclosure.
12. Linux Foundation (2025). Kepler: Kubernetes Efficient Power Level Exporter.
13. MLCommons (2025). MLPerf Inference v4.0 Power Efficiency Benchmark Suite.
14. Uptime Institute (2025). Global Data Center Survey: PUE Trends.
15. International Energy Agency (2025). Electricity 2025: Data Centers and AI Demand.

一句话摘要

LLM 推理的能耗感知调度不是"环保道德题"，而是一道把 PUE 感知地理路由、DVFS/动态 batch 的能效曲线、碳感知 defer 窗口三条工程主线沿碳-时-算三维 Pareto 边界滑动的严肃工程与经济学问题——按 1 亿 token/日规模估算年节省 250+ 万元、减碳 1800+ 吨、投资回收期 < 9 月。