碳感知计算：从 RAPL 功耗调度到数据中心绿色工程实践

当 AI 大模型吞噬越来越多的算力，数据中心的碳排放已占全球总排放的 2% 以上。从芯片级 RAPL 功耗管控到集群级绿电调度，本文深入剖析碳感知计算的完整技术栈。

1. 为什么关注碳感知计算

2025-2026 年，全球 AI 算力需求持续爆炸式增长。NVIDIA 数据中心业务季度营收突破 300 亿美元，单颗 B200 GPU 功耗高达 1000W，一个万卡集群峰值功耗轻松突破 10MW——相当于一个小型城镇的用电量。

在这种背景下，"绿色计算"已从企业 ESG 口号演变为工程刚需。原因有三：

• 碳排放合规压力：欧盟 CSRD（企业可持续发展报告指令）要求大型企业披露范围三排放，即供应链和用电产生的碳排放。北美 SEC 气候披露规则也在推进中。
• 能源成本飙升：欧美数据中心电价持续上涨，部分时段每度电超过 0.15 美元。Google 和 Microsoft 纷纷签署核电协议锁定长期能源。
• 资源利用效率：研究表明，数据中心平均服务器利用率仅 12%-18%，大量能源被闲置设备白白消耗。

碳感知计算（Carbon-Aware Computing）的核心思想：根据电网实时碳强度信号，在时间和空间维度上调度计算任务，以最小化碳排放或能源成本。

2. 碳强度信号：碳排放的"天气预报"

碳感知计算的基础是碳强度信号——即每度电所产生的 CO₂ 克数（gCO₂eq/kWh）。不同地区、不同时段的碳强度差异巨大。

2.1 主要碳强度数据源

服务	覆盖区域	时间分辨率	API 类型
ElectricityMaps	全球 50+ 国家	1小时	商业/免费
WattTime	北美/欧洲/亚太	5分钟	免费（非商业）
UK National Grid ESO	英国	30分钟	免费
California ISO (CAISO)	美国加州	5分钟	免费
国家可再生能源信息中心	中国	1小时	免费

2.2 WattTime API 实战示例

WattTime 提供免费的 REST API，返回当前区域的边际碳强度：

#!/usr/bin/env python3
"""碳强度数据获取器 — WattTime API"""

import requests
import time
from dataclasses import dataclass

@dataclass(frozen=True)
class CarbonIntensity:
    """碳强度数据点"""
    timestamp: str
    value: float          # gCO2eq/kWh
    unit: str
    region: str
    forecast: bool = False

class WattTimeClient:
    """WattTime API 客户端"""

    BASE_URL = "https://api.watttime.org/v3"

    def __init__(self, username: str, password: str):
        self._token = self._login(username, password)

    def _login(self, username: str, password: str) -> str:
        resp = requests.post(
            f"{self.BASE_URL}/login",
            headers={"Authorization": f"Basic {self._b64auth(username, password)}"}
        )
        resp.raise_for_status()
        return resp.json()["token"]

    @staticmethod
    def _b64auth(u: str, p: str) -> str:
        import base64
        return base64.b64encode(f"{u}:{p}".encode()).decode()

    def get_current_intensity(self, latitude: float, longitude: float) -> CarbonIntensity:
        """获取指定坐标当前碳强度"""
        resp = requests.get(
            f"{self.BASE_URL}/forecast",
            headers={"Authorization": f"Bearer {self._token}"},
            params={"latitude": latitude, "longitude": longitude}
        )
        resp.raise_for_status()
        data = resp.json()["data"][0]
        return CarbonIntensity(
            timestamp=data["point_time"],
            value=data["value"],
            unit=data.get("units", "gCO2eq/kWh"),
            region=data.get("region", "unknown"),
        )

    def get_forecast(self, latitude: float, longitude: float, hours: int = 24) -> list[CarbonIntensity]:
        """获取未来 N 小时碳强度预测"""
        resp = requests.get(
            f"{self.BASE_URL}/forecast",
            headers={"Authorization": f"Bearer {self._token}"},
            params={
                "latitude": latitude,
                "longitude": longitude,
                "horizon_hours": hours,
            }
        )
        resp.raise_for_status()
        return [
            CarbonIntensity(
                timestamp=d["point_time"],
                value=d["value"],
                unit=d.get("units", "gCO2eq/kWh"),
                region=d.get("region", "unknown"),
                forecast=True,
            )
            for d in resp.json()["data"]
        ]

def find_best_window(forecast: list[CarbonIntensity], window_hours: int = 2) -> tuple[float, str]:
    """在预测中找到碳排放最低的时间窗口"""
    best_avg = float("inf")
    best_time = ""
    for i in range(len(forecast) - window_hours + 1):
        window = forecast[i:i + window_hours]
        avg = sum(c.value for c in window) / len(window)
        if avg < best_avg:
            best_avg = avg
            best_time = window[0].timestamp
    return best_avg, best_time

if __name__ == "__main__":
    # 示例：加州硅谷区域 (Electric Grid: CAISO_NORTH)
    client = WattTimeClient("your_username", "your_password")
    intensity = client.get_current_intensity(37.3875, -122.0575)
    print(f"当前碳强度: {intensity.value} gCO₂eq/kWh")

    forecast = client.get_forecast(37.3875, -122.0575, hours=48)
    best_avg, best_time = find_best_window(forecast, window_hours=4)
    print(f"未来 48 小时最优 4h 窗口: {best_time}")
    print(f"  平均碳强度: {best_avg:.1f} gCO₂eq/kWh")

3. 芯片级功耗管控：RAPL 深度实战

碳感知计算的起点是精确测量和管控单台服务器的功耗。Intel 自 Sandy Bridge 架构起引入的 Running Average Power Limit (RAPL) 是目前最广泛使用的芯片级功耗接口。

3.1 RAPL 架构与域

RAPL 通过 MSR（Model Specific Register）暴露多个功耗域的实时数据和限制能力：

• Package (PKG)：整个 CPU 插座的总功耗，包含核心 + 核显 + 内存控制器 + PCIe 控制器等
• Power Plane 0 (PP0)：CPU 核心的功耗
• Power Plane 1 (PP1)：核显（Uncore）功耗
• DRAM：内存控制器和 DRAM 条功耗
• Platform (PLAT)：整个服务器平台总功耗（部分 Xeon 支持）

3.2 通过 msr-safe 安全读取 RAPL

Linux 内核的 msr 驱动允许直接读取 MSR 寄存器。生产环境中推荐使用 Google 开源的 msr-safe 白名单机制，限制容器或特定用户仅能访问安全的 MSR：

/* rapl_reader.c — RAPL 功耗实时读取器 */
/* 编译: gcc -O2 -o rapl_reader rapl_reader.c */
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>

#define MSR_RAPL_POWER_UNIT     0x606
#define MSR_PKG_ENERGY_STATUS   0x611
#define MSR_DRAM_ENERGY_STATUS  0x619
#define MSR_PP0_ENERGY_STATUS   0x639

/* RAPL 封装的能耗单位信息 */
struct rapl_units {
    double energy;   /* 焦耳单位 */
    double power;    /* 瓦特单位 */
    double time;     /* 秒单位 */
};

static int read_msr(int cpu, uint32_t reg, uint64_t *val) {
    char path[64];
    snprintf(path, sizeof(path), "/dev/cpu/%d/msr_safe", cpu);
    int fd = open(path, O_RDONLY);
    if (fd < 0) {
        /* 回退到 msr */
        snprintf(path, sizeof(path), "/dev/cpu/%d/msr", cpu);
        fd = open(path, O_RDONLY);
    }
    if (fd < 0) return -1;
    int ret = pread(fd, val, sizeof(*val), reg);
    close(fd);
    return (ret == sizeof(*val)) ? 0 : -1;
}

static struct rapl_units get_rapl_units(int cpu) {
    uint64_t raw;
    if (read_msr(cpu, MSR_RAPL_POWER_UNIT, &raw) < 0) {
        fprintf(stderr, "Cannot read RAPL units (are you root?)\n");
        exit(1);
    }
    struct rapl_units u;
    /* 位定义: [3:0]能量, [12:8]时间, [19:16]功率 */
    u.energy = 1.0 / (1 << (raw & 0xF));
    u.time   = 1.0 / (1 << ((raw >> 8) & 0x1F));
    u.power  = 1.0 / (1 << ((raw >> 16) & 0xF));
    return u;
}

static double read_energy_joules(int cpu, uint32_t msr, const struct rapl_units *u) {
    uint64_t raw;
    if (read_msr(cpu, msr, &raw) < 0) return -1.0;
    /* 低 32 位为能耗计数器，溢出后回绕 */
    return (raw & 0xFFFFFFFF) * u->energy;
}

int main(int argc, char **argv) {
    int cpu = 0;
    if (argc > 1) cpu = atoi(argv[1]);

    struct rapl_units u = get_rapl_units(cpu);
    printf("RAPL 能耗单位: %.6f J, 功率单位: %.4f W, %.9f s\n",
           u.energy, u.power, u.time);

    /* 连续采样，计算实时功率 */
    double pkg_e1 = read_energy_joules(cpu, MSR_PKG_ENERGY_STATUS, &u);
    double dram_e1 = read_energy_joules(cpu, MSR_DRAM_ENERGY_STATUS, &u);

    for (int i = 0; ; i++) {
        usleep(1000000);  /* 1 秒采样间隔 */
        double pkg_e2 = read_energy_joules(cpu, MSR_PKG_ENERGY_STATUS, &u);
        double dram_e2 = read_energy_joules(cpu, MSR_DRAM_ENERGY_STATUS, &u);

        /* 处理计数器回绕 (32-bit overflow ≈ 65536 * energy_unit 秒) */
        double pkg_delta = (pkg_e2 >= pkg_e1) ? (pkg_e2 - pkg_e1) : (pkg_e2 + (1ULL<<32) * u.energy - pkg_e1);
        double dram_delta = (dram_e2 >= dram_e1) ? (dram_e2 - dram_e1) : (dram_e2 + (1ULL<<32) * u.energy - dram_e1);

        printf("[CPU%d] PKG: %8.2f W | DRAM: %7.2f W | Total: %8.2f W\n",
               cpu, pkg_delta, dram_delta, pkg_delta + dram_delta);
        pkg_e1 = pkg_e2;
        dram_e1 = dram_e2;
    }
    return 0;
}

生产注意事项：RAPL 能耗计数器为 32 位，在典型能耗单位 (15.3μJ) 下约 65535 × 15.3μJ ≈ 1kJ 就会溢出。长时间采样必须处理回绕。

3.3 通过 powercap 子系统设置功耗上限

Linux 内核 4.10+ 引入了统一的 powercap 子系统，允许通过 sysfs 为 RAPL 域设置功耗上限：

#!/bin/bash
# 查看系统中所有 RAPL 域
for zone in /sys/class/powercap/intel-rapl\:*/; do
    name=$(cat "$zone/name" 2>/dev/null)
    max_power=$(cat "$zone/constraint_0_max_power_uw" 2>/dev/null || echo "N/A")
    echo "Zone: $name  Max: ${max_power} μW"
done

# 为 CPU Package 限制到 95W (单位: 微瓦)
echo 95000000 > /sys/class/powercap/intel-rapl\:0/constraint_0_power_limit_uw

# 设置时间窗口 (tau) 为 1 秒
echo 1000000 > /sys/class/powercap/intel-rapl\:0/constraint_0_time_window_uw

# DRAM 功耗限制到 25W
echo 25000000 > /sys/class/powercap/intel-rapl\:0/intel-rapl\:0\:1/constraint_0_power_limit_uw

# 启用 PL1 和 PL2 限制
echo 1 > /sys/class/powercap/intel-rapl\:0/enabled
echo 1 > /sys/class/powercap/intel-rapl\:0/intel-rapl\:0\:1/enabled

echo "RAPL power limits applied successfully."

4. 内核级 Energy-Aware Scheduling

Linux CFS 调度器传统上只关注公平性和吞吐量，但从 5.x 内核开始引入了 Energy-Aware Scheduling (EAS)，专门针对异构 big.LITTLE 架构优化能耗。

4.1 EAS 核心机制

EAS 的关键组件：

• Energy Model (EM)：描述每个 CPU freq level 的功耗和性能映射。由 SoC 厂商提供设备树表或使用 libenergy 动态计算。
• Schedutil governor：基于 CPU 利用率直接选择调频策略，反馈延迟极短。
• 跑跳迁移 (Task Packing)：在满足负载前提下将任务集中到尽量少的核上，让空核进入深度空闲状态。

4.2 能效比分析实践

#!/bin/bash
# 检查当前系统 EAS 状态
echo "=== Energy-Aware Scheduling Status ==="
for domain in /sys/devices/system/cpu/cpufreq/policy*/; do
    policy=$(basename "$domain")
    gov=$(cat "${domain}scaling_governor" 2>/dev/null)
    epp=$(cat "${domain}energy_performance_preference" 2>/dev/null || echo "N/A")
    echo "$policy: governor=$gov, epp=$epp"
done

# 查看 Schedutil 调频器状态 (感知 CFS 利用率的核心)
cat /sys/devices/system/cpu/cpufreq/policy0/schedutil/rate_limit_us 2>/dev/null

# 查看 CPU idle 状态分布 (功耗优化的关键指标)
for cpu in /sys/devices/system/cpu/cpu*/cpuidle/state*/; do
    name=$(cat "${cpu}name" 2>/dev/null)
    latency=$(cat "${cpu}latency" 2>/dev/null)
    residency=$(cat "${cpu}residency" 2>/dev/null)
    echo "  $name: latency=${latency}μs target_residency=${residency}μs"
done | head -20

关键调优参数：

• energy_performance_preference：performance/balance_performance/balance_power/power，直接影响 EPP MSR (0x774)
• schedutil/rate_limit_us：限制调频频率，值越大越节能但响应越慢
• sysfs /sys/cpu/cpuidle/governors/menu：menu governor 的预测器调优

5. Kubernetes 集群级碳感知调度

将碳感知从单机扩展到集群，需要在 Kubernetes 调度框架中集成碳强度信号和功耗感知。

5.1 架构设计

一个完整的 K8s 碳感知调度框架包含以下组件：

# -carbon-aware-scheduler 部署架构 --
apiVersion: v1
kind: ConfigMap
metadata:
  name: carbon-scheduler-config
data:
  config.yaml: |
    carbon_api:
      provider: watttime
      update_interval: 300  # 5 分钟刷新碳预测
      default_region: "CAISO_NORTH"
    scheduling:
      weight: 50           # 碳评分在总评分中的权重 (0-100)
      defer_threshold: 100 # 碳强度阈值 gCO2eq/kWh，超过时批处理任务延后
    power_model:
      cpu_tdp_watts: 250   # 单 CPU TDP
      gpu_tdp_watts: 400   # 单 GPU TDP
      idle_ratio: 0.35     # 空闲功耗占 TDP 比例
    metrics:
      enabled: true
      backend: prometheus
      pushgateway: "http://prometheus-pushgateway.monitoring:9091"

5.2 调度器 Filter & Score 插件实战

// carbon_score.go — K8s 调度器碳感知评分插件
package carbon

import (
    "context"
    "math"
    "time"

    v1 "k8s.io/api/core/v1"
    "k8s.io/apimachinery/pkg/runtime"
    framework "k8s.io/kubernetes/pkg/scheduler/framework"
)

// CarbonScoring 实现 framework.ScorePlugin 接口
type CarbonScoring struct {
    carbonClient CarbonIntensityProvider
    powerModel   ServerPowerModel
}

type CarbonIntensityProvider interface {
    GetCurrent(region string) (gCO2PerKWh float64, error)
}

type ServerPowerModel struct {
    CPUIdleWatts  float64
    CPUMaxWatts   float64
    GPUIdleWatts  float64
    GPUMaxWatts   float64
}

func (cs *CarbonScoring) Name() string { return "CarbonScoring" }

// Score: 根据节点实时功耗和碳强度打分 (0-100)
func (cs *CarbonScoring) Score(ctx context.Context, state *framework.CycleState,
    pod *v1.Pod, nodeName string) (int64, *framework.Status) {

    // 获取节点注解: "carbon-region" 和 "rapl-power-watts"
    annotations := cs.getNodeAnnotations(nodeName)

    // 碳强度归一化 (0-1, 越低越好)
    carbonIntensity := annotations.carbonIntensity // gCO2eq/kWh
    carbonNorm := math.Min(carbonIntensity/900.0, 1.0)

    // 功耗评分: 节点剩余容量越多评分越高（鼓励打包）
    powerUsed := annotations.raplPower // 当前实时功耗 W
    powerMax  := annotations.powerMax  // 节点功耗上限 W
    powerNorm := 1.0 - (powerUsed / powerMax)

    // 综合得分
    carbonWeight := cs.config.Weight / 100.0
    score := (carbonWeight*powerNorm + (1-carbonWeight)*(1-carbonNorm)) * 100

    return int64(math.Round(score)), framework.NewStatus(framework.Success)
}

// ScoreExtensions — NormalizeScore 确保所有节点分数归一化到 0-100
func (cs *CarbonScoring) ScoreExtensions() framework.ScoreExtensions {
    return cs
}

func (cs *CarbonScoring) NormalizeScore(ctx context.Context, state *framework.CycleState,
    pod *v1.Pod, scores framework.NodeScoreList) *framework.Status {
    var maxScore int64
    for _, s := range scores {
        if s.Score > maxScore {
            maxScore = s.Score
        }
    }
    if maxScore == 0 {
        return framework.NewStatus(framework.Success)
    }
    for i := range scores {
        scores[i].Score = scores[i].Score * 100 / maxScore
    }
    return framework.NewStatus(framework.Success)
}

// DeferDispatch: 批处理任务在碳强度高峰时延后执行
func ShouldDefer(pod *v1.Pod, currentCI float64, threshold float64) (bool, time.Duration) {
    batchLabel := pod.Labels["workload-type"]
    if batchLabel != "batch" {
        return false, 0 // 在线服务不延迟
    }
    if currentCI < threshold {
        return false, 0 // 碳强度未超限
    }
    // 延迟到碳强度预测窗口中最低谷 (最大 2 小时)
    return true, 1 * time.Hour
}

5.3 节点 RAPL 指标采集 DaemonSet

# rapl-exporter DaemonSet — 每节点采集 RAPL 并暴露 Prometheus 指标
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: rapl-exporter
spec:
  selector:
    matchLabels:
      app: rapl-exporter
  template:
    metadata:
      labels:
        app: rapl-exporter
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9494"
    spec:
      hostNetwork: true
      containers:
        - name: exporter
          image: quay.io/yebinbing/rapl-exporter:latest
          securityContext:
            privileged: true   # 需要访问 /dev/cpu/*/msr
          ports:
            - containerPort: 9494
          env:
            - name: SCRAPE_INTERVAL
              value: "15s"
            - name: NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName

6. 生产实践：碳感知调度的量化收益

以下是基于真实生产环境模拟测试的数据参考：

策略	碳排放降低	延迟影响	适用场景
RAPL PL1 限制 (TDP→80%)	12-18%	吞吐量降 3-5%	离线批处理推理
碳强度时间窗口调度	15-30%	分钟级延迟	可延迟批任务 (ETL/训练)
碳感知空间迁移 (跨区)	20-45%	秒级 (冷启动)	跨地域弹性训练
EAS + Schedutil 调频	5-10%	<1%	ARM big.LITTLE 边缘节点
组合策略全套应用	35-55%	依策略	混合负载数据中心

6.1 关键设计原则

• 分级延迟策略：在线服务 (SLA 严格) 仅使用 RAPL 调频；延迟批处理任务可使用时间窗口调度；跨区迁移适用于容错训练任务。
• 碳预测 + 缓冲：碳强度信号有噪声和预测误差，调度器应使用滚动窗口的平均值，避免频繁决策抖动。
• 功耗测量闭环：不要仅依赖 TDP 标称值。使用 RAPL 实时测量 + Prometheus 长期监控，建立每个服务的功耗画像模型。
• 功耗与性能的 Pareto 前沿：为工作负载找到碳排放和延迟的最佳权衡点。通常 10% 的延迟损失可换来 25-30% 的碳排放降低。

7. 总结

碳感知计算正从"锦上添花"演变为"工程刚需"。其技术栈覆盖从芯片级 RAPL 功耗管控、内核级 Energy-Aware Scheduling、到集群级 Kubernetes 调度的完整链路。

在当前 AI 算力需求持续爆发和全球碳排放监管的双重压力下，构建碳感知的数据中心基础设施，既是技术挑战，也是商业机遇。对工程师而言，掌握 RAPL、EAS、powercap 这些底层机制，以及如何在 K8s 框架中集成碳感知能力，将是未来几年区分优秀和普通基础设施团队的关键。

绿色计算的终极目标不是牺牲性能换取碳中和，而是在精确测量、智能调度和弹性调度的三重加持下，实现性能与可持续性的双赢。