从 CPPC 到 schedutil：Linux 内核能效管理子系统在 AI 推理负载中的深度优化工程实践

现代 AI 推理集群的功耗问题越来越成为 TCO 的核心变量。本文从硬件能效接口（CPPC/HWP）到内核调度器调频器（schedutil），系统性地剖析 Linux 能效管理子系统的架构与生产调优实践。

1. 为什么 AI 推理是"能效敏感型"负载

AI 推理服务器与传统批处理负载有本质区别：

• 稳态高利用率：24/7 以 60-85% 利用率运行，不像 Web 服务有明显的峰谷
• 延迟敏感：P99 延迟直接绑定 SLA，无法像离线训练那样任意降频
• 功耗密度爆炸：单机 8×H100 配置峰值功耗超过 10kW，电费和散热成本巨大
• 频率-性能非线性：GPU-bound 场景下 CPU 频率对吞吐影响小，但 NVMe 预处理流水线是有 CPU 频率瓶颈

在这样的场景下，理解并调优 Linux 内核的能效管理栈，往往能在不损失延迟的前提下节省 15-30% 的整机功耗。

2. 能效管理的全景架构

┌─────────────────────────────────────────────────────────────────────┐
│                        用户空间调优接口                               │
│   cpupower / sysfs / turbostat / perf                              │
├─────────────────────────────────────────────────────────────────────┤
│  ┌──────────┐  ┌───────────┐  ┌──────────────┐  ┌──────────────┐  │
│  │  schedutil│  │  ondemand │  │ conservative │  │ performance  │  │
│  │  governor │  │  governor │  │   governor   │  │   governor   │  │
│  └─────┬─────┘  └─────┬─────┘  └──────┬───────┘  └──────┬───────┘  │
│        └───────────────┴───────────────┴──────────────────┘          │
├─────────────────────────────────────────────────────────────────────┤
│                     cpufreq 核心框架                                  │
├───────────┬─────────────────┬───────────────────┬────────────────────┤
│ Intel P-  │    AMD CPPC     │   ARM SCMI/CPPC   │  acpi-cpufreq     │
│ State     │   (v1/v2/v3)    │                   │  (通用fallback)    │
│ (HWP/     │                 │                   │                   │
│  legacy)  │                 │                   │                   │
├───────────┴─────────────────┴───────────────────┴────────────────────┤
│                    ACPI firmware 接口层                               │
│   _CPC / _PSS / _PPC / _PCT                                           │
├─────────────────────────────────────────────────────────────────────┤
│            硬件寄存器 (MSR / AMBA SCMI / MPAM)                        │
└─────────────────────────────────────────────────────────────────────┘

关键洞察：schedutil 直接利用调度器的 CPU 利用率统计（PELT 信号），绕过了传统采样周期带来的延迟，这是它在 AI 负载下调频响应更快的根本原因。

3. CPPC：协作处理器性能控制

CPPC（Collaborative Processor Performance Control）是 ACPI 5.0+ 引入的能效接口核心，让 OS 通过"建议"而非"直接控制"来引导硬件调频决策。

3.1 CPPC 的三个性能等级

┌───────────────────────────────────────────────────────┐
│  Performance Level      │ 含义                       │
├───────────────────────────────────────────────────────┤
│  Nominal Performance    │ 芯片标称最高性能点          │
│  (Highest Perf)         │ 即"睿频"上限                │
├───────────────────────────────────────────────────────┤
│  Lowest Performance     │ 能效最优的低频率瓦点       │
│  (Lowest Non-linear)    │ 通常 ~60% of max            │
├───────────────────────────────────────────────────────┤
│  Minimum Performance    │ 最低可运行频率             │
│  (Lowest Performance)   │ 保证基本响应性              │
└───────────────────────────────────────────────────────┘

3.2 读取 CPPC capability

# 查看 ACPI CPC 寄存器信息
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/lowest_freq
1200000   # kHz

$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_freq
3500000   # 3.5 GHz

$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf
255       # 相对性能等级 (max)

$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/nominal_perf
180       # 标称性能相对值

# CPPC v3 特有：参考性能计数器
$ cat /sys/devices/system/cpu/cpu0/acpi_cppc/reference_perf
200       # 参考性能 = 标称最低有效性能

3.3 在生产节点上分析 EPP (Energy Performance Preference)

# Intel HWP + EPP 调优
# EPP 梯度：0=performance, 128=balance, 255=power

# 查看当前 EPP 值
$ rdmsr -p 0 0x774
# 或
$ cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference
balance-performance

# 查看可用档位
$ cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_available_preferences
performance balance-performance balance-power power

# AI 推理场景：设置平衡偏性能
for cpu in /sys/devices/system/cpu/cpu*/cpufreq; do
    echo "balance-performance" > "$cpu/energy_performance_preference"
done

4. schedutil：调度器驱动的调频革命

schedutil 是 Linux 4.9 后引入的最重要调频器，它的核心创新是直接读取调度器的 PELT (Per-Entity Load Tracking) 利用率。

4.1 PELT 信号本质

// kernel/sched/pelt.c
/*
 * PELT 的衰减模型：每 1ms 衰减一半
 * util = util_prev + (1 - y/32) * delta
 * y = PELT_HALF_LIFE = 32 (≈ 32ms 半衰期)
 *
 * 这对 AI 推理的意义：
 * - 延迟敏感任务 (~10-50ms 推理周期) 的 PELT 信号
 *   能在 1-2 个 tick 内被捕获并响应
 */

4.2 schedutil 的选频公式

// kernel/sched/cpufreq_schedutil.c
/*
_util_raw = max(cpu_util, 1024)  // 1024 = 100% 利用率
freq = (util_raw / max_cap) * max_freq

关键行为：
1. 即时：不需要 sampling idle 的不确定性
2. 单调：利用率升高 -> 频率立刻升高
3. 无死区：小幅度超出即响应，适合延迟敏感负载
*/

4.3 MHz 与推理吞吐量的实际关系测量

在一台双路 AMD EPYC 9554 (64C/128T) 上的实测数据：运行 LLaMA-3-70B FP16 推理，预处理流水线瓶颈在 CPU：

┌──────────────┬───────────────┬───────────────┬──────────────┐
│ CPU 频率     │ 预处理延迟    │ P99 端到端    │ 整机功耗     │
│              │ (tokenize+BSS)│ 延迟          │ (W)          │
├──────────────┼───────────────┼───────────────┼──────────────┤
│ 3.7 GHz      │ 12ms          │ 892ms         │ 487          │
│ 2.8 GHz      │ 15ms          │ 901ms         │ 398          │
│ 2.2 GHz      │ 21ms          │ 919ms         │ 341          │
│ 1.7 GHz      │ 34ms          │ 947ms         │ 298          │
│ 1.2 GHz      │ 67ms          │ 1021ms        │ 264          │
└──────────────┴───────────────┴───────────────┴──────────────┘

结论：2.8 GHz 是 PARETO 最优点 (仅 1.1% 延迟增长，18% 功耗节省)

5. 生产级调频器配置策略

5.1 AI 推理节点的推荐 governor 配置

#!/bin/bash
# setup-cpufreq-inference.sh
# 适用于稳态推理负载的调频器配置

set -euo pipefail

GOVERNOR="schedutil"
EPP_MODE="balance-performance"  # Intel HWP 专用

for cpu_dir in /sys/devices/system/cpu/cpu*/cpufreq; do
    cpu_id=$(basename "$cpu_dir")
    governor_path="$cpu_dir/scaling_governor"
    
    # 1. 设置 governor
    if [ -w "$governor_path" ]; then
        echo "$GOVERNOR" > "$governor_path"
    fi
    
    # 2. 调整 schedutil 专有参数 (如果可用)
    if [ -f "$cpu_dir/schedutil/up_rate_limit_us" ]; then
        # 升频速率 (ns)。越小越快。
        # 默认 500us。AI 推理建议 200us 保证低延迟
        echo "200" > "$cpu_dir/schedutil/up_rate_limit_us"
        echo "50" > "$cpu_dir/schedutil/down_rate_limit_us"
    fi
    
    # 3. 设置 EPP (如果硬件支持)
    epp="$cpu_dir/energy_performance_preference"
    if [ -w "$epp" ]; then
        echo "$EPP_MODE" > "$epp"
    fi
    
    # 4. 对隔离 CPU 可设 performance
    systemd-cgls -u inference.slice 2>/dev/null | grep -q "$cpu_id" && \
        echo "performance" > "$governor_path"
done

echo "[OK] CPU frequency governor configured for inference workload"

5.2 调频器参数验证脚本

#!/bin/bash
# verify-cpufreq.sh - 验证调频配置是否生效

echo "=== CPU Frequency Configuration Audit ==="
echo ""
for cpu_dir in /sys/devices/system/cpu/cpu*/cpufreq; do
    cpu=$(basename "$cpu_dir")
    gov=$(cat "$cpu_dir/scaling_governor" 2>/dev/null)
    cur=$(( $(cat "$cpu_dir/scaling_cur_freq" 2>/dev/null) / 1000 ))
    min=$(( $(cat "$cpu_dir/scaling_min_freq" 2>/dev/null) / 1000 ))
    max=$(( $(cat "$cpu_dir/scaling_max_freq" 2>/dev/null) / 1000 ))
    epp=$(cat "$cpu_dir/energy_performance_preference" 2>/dev/null || echo "N/A")
    
    printf "%-5s  gov=%-12s  cur=%4dMHz  min=%d  max=%d  epp=%s\n" \
           "$cpu" "$gov" "$cur" "$min" "$max" "$epp"
done | head -8  # 只显示前 8 个核心
echo "... ($(nproc) CPUs total)"

6. PELT 调优：让调度器知道"真正的负载"

AI 推理工作流的特殊性在于短时突发负载 ——每批 tokenize 持续 5-50ms 后进入 GPU 等待。标准 PELT 的半衰期 ~32ms 对这个场景几乎完美匹配，但仍需针对特定流水线微调。

6.1 调整 PELT 的时钟周期

# PELT 半衰期（默认 32 个 1ms window）
# 对 AI 推理，32ms 意味着约 30 个 decode step 的贡献叠加

# 对于更短的推理流水线（如 10ms/step），可以降低半衰期让响应更敏捷
echo 8 > /proc/sys/kernel/sched_pelt_half_life_shift
# 这会降低等效半衰期到 ~8ms

# 但要警惕：过短的半衰期会让 governor 过度敏感
# 导致在偶发空闲时降频过快

6.2 CPU 带宽与 cgroup 的协同

/*
 * AI 推理场景的 cgroup 配置
 * cgroup v2 cpu.max 同时限制"带宽"和"PELT 统计"
 *
 * 注意：cpu.max 的最大值为 100ms/100ms（100%）
 * 设置 cpu.max 时，schedutil 看到的 util 会被 clamp 到这个上限
 */

// 示例：限制 CPU-intensive 预处理到 50% 核
// echo "50000 100000" > /sys/fs/cgroup/inference/cpu.max

// 这将使 schedutil 看到的最高 util = 50%
// governor 会据此选择 ~50% 频率点

7. 实战：在 AI 推理集群中部署的完整方案

7.1 节点部署脚本

#!/bin/bash
# deploy-power-tuning.sh - 在推理集群节点上执行
# 前提：无正在进行的推理负载（建议在节点维护窗口执行）

set -euo pipefail

LOG="/var/log/cpufreq-tuning.log"
exec 2>&1

log() { echo "[$(date '+%H:%M:%S')] $*" | tee -a "$LOG"; }

log "Starting CPU frequency tuning for AI inference..."

# 0. 记录初始状态（便于 rollout 验证）
log "=== Pre-tuning snapshot ==="
cpupower frequency-info | grep -E "hardware|governor|boost" >> "$LOG"

# 1. 启用所有 CPPC 核心（AMD EPPC 默认启用，这里确保）
if [ -d /sys/devices/system/cpu/cpufreq ]; then
    for pstate in /sys/devices/system/cpu/intel_pstate/*; do
        # Intel 强制启用 HWP
        if grep -q "hwp" "$pstate/name" 2>/dev/null; then
            echo "1" > "$pstate/hwp_dynamic_boost" 2>/dev/null || true
        fi
    done
fi

# 2. 配置 governor
GOVERNOR="${INFERENCE_GOVERNOR:-schedutil}"
for gov in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
    echo "$GOVERNOR" > "$gov" 2>/dev/null || true
done
log "Governor set to: $GOVERNOR"

# 3. 配置 EPP/EPB
if [ -d /sys/devices/system/cpu/cpu0/cpufreq ]; then
    for epp in /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference; do
        echo "${INFERENCE_EPP:-balance-power}" > "$epp" 2>/dev/null || true
    done
    log "EPP set to: ${INFERENCE_EPP:-balance-power}"
fi

# 4. 验证
log "=== Post-tuning verification ==="
for cpu in cpu0 cpu1 cpu2 cpu3; do
    f=$(cat /sys/devices/system/cpu/$cpu/cpufreq/scaling_cur_freq 2>/dev/null || echo 0)
    g=$(cat /sys/devices/system/cpu/$cpu/cpufreq/scaling_governor 2>/dev/null || echo "N/A")
    log "$cpu: $((f/1000))MHz  governor=$g"
done

log "CPU frequency tuning complete."

7.2 Systemd 集成

# /etc/systemd/system/cpufreq-inference.service
[Unit]
Description=CPU Frequency Tuning for AI Inference
After=multi-user.target
Before=inference-server.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/deploy-power-tuning.sh
RemainAfterExit=yes
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

8. 监控与持续调优

8.1 监控指标采集脚本

#!/bin/bash
# metrics-cpufreq.sh - 采集 CPU 频率相关指标输出到 stdout (JSON-like)
# 适配 Prometheus textfile collector

OUTPUT="/var/lib/node_exporter/cpufreq.prom"

{
    echo "# HELP node_cpu_freq_mhz Current CPU frequency in MHz"
    echo "# TYPE node_cpu_freq_mhz gauge"
    for cpu_dir in /sys/devices/system/cpu/cpu*/cpufreq; do
        cpu=$(basename "$cpu_dir")
        freq=$(( $(cat "$cpu_dir/scaling_cur_freq" 2>/dev/null || echo 0) / 1000 ))
        echo "node_cpu_freq_mhz{cpu=\"$cpu\"} $freq"
    done
    
    echo ""
    echo "# HELP node_cpu_governor Current scaling governor (1=active)"
    echo "# TYPE node_cpu_governor gauge"
    for cpu_dir in /sys/devices/system/cpu/cpu*/cpufreq; do
        cpu=$(basename "$cpu_dir")
        gov=$(cat "$cpu_dir/scaling_governor" 2>/dev/null || echo "unknown")
        for g in performance schedutil ondemand conservative powersave; do
            [ "$gov" = "$g" ] && val=1 || val=0
            echo "node_cpu_governor{cpu=\"$cpu\",governor=\"$g\"} $val"
        done
    done
} > "$OUTPUT"

8.2 验证是否命中目标频率

# turbostat 实时查看频率、C-state 和功耗
$ turbostat --show Core,CPU,Avg_MHz,Busy%,Bzy_MHz,TSC_MHz,CoreTmp,PkgWatt \
    --interval 1 --num_iterations 10

# 输出示例：
# Core    CPU     Avg_MHz  Busy%   Bzy_MHz  TSC_MHz  PkgWatt
# -       -       2783     82.5    3372     3700     87.4
# 0       0       2812     83.1    3384     3700     87.4
# 0       1       2799     82.7    3381     3700     87.4
# 1       2       2756     81.9    3364     3700     87.4
# ↑ Bzy_MHz ≈ 3.37GHz → 当前 schedutil 选择的高频工作点
#   预期：平衡负载下保持高频，与 GPU-bound 流水线协同良好

9. 常见陷阱与排错

9.1 Governor 看似生效但频率不变化

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
schedutil

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1200000  # 1.2 GHz —— 太慢了？

# 排查步骤
# 1. 检查调度器 tick
$ dmesg | grep -i "sched_clock"
# 2. 确认 schedutil 被注册
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
# 如果 schedutil 不在列表中 → 检查 CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y

# 3. 检查是否有进程独占 CPU (taskset 到 isolated cores)
#    隔离核心的 governor 不受 schedutil 管理
$ cat /sys/devices/system/cpu/isolated
# 4. 检查 thermal pressure
$ cat /proc/pressure/cpu
some avg10=0.00 avg60=0.00 avg300=0.00 total=0

9.2 AMD EPYC 系统在 HWP 缺失时降级到 acpi-cpufreq

# 如果系统启动日志显示：
#     "HWP not enabled by BIOS"
# 或
#     "acpi-cpufreq: overriding BIOS-provided _PSS"
# 说明 fallback 到 ACPIs 接口，性能模式选择受限
#
# 解决：进 BIOS 启用 "Collaborative Power Performance Control"
#      或设置 Global C-state Control 为 Auto

9.3 频率抖动问题

# 症状：频率在 2-3 GHz 间快速振荡
# 原因：PELT 信号不稳定（短任务频密切换）
#
# 解法：增大 schedutil 的 rate_limit_us
$ echo 1000 > /sys/devices/system/cpu/cpu0/cpufreq/schedutil/up_rate_limit_us
# 或者切换 conservative governor，但会牺牲响应性

# 终极方案：使用 cpuset 隔离预处理线程到特定核心
# 让其他核心保持稳定高频
$ echo "0-15" > /sys/fs/cgroup/inference/cpuset.cpus
$ echo "16-31" > /sys/fs/cgroup/post-process/cpuset.cpus

10. 进阶：与 uncore frequency 协同调优

除了 CPU 核心频率，现代服务器还有非核心（uncore）频率——L3 缓存、内存控制器和互联总线的时钟。这对 AI 推理中涉及大量 KV-cache 数据传输的场景影响显著。

# Intel Uncore Frequency 控制
# 启用 uncore 调频
$ echo 1 > /sys/devices/system/cpu/intel_uncore_frequency/package_00_die_00/enable

# 设置最小和最大 uncore 频率
# L3 频率直接影响 core-memory 带宽
$ echo 2000000 > /sys/devices/system/cpu/intel_uncore_frequency/package_00_die_00/min_freq_khz
$ echo 2400000 > /sys/devices/system/cpu/intel_uncore_frequency/package_00_die_00/max_freq_khz

# 验证：对 LLaMA-70B gguf 加载时间# 纯核心高频但 uncore 低速时：KV cache 传输慢 → 首 token 延迟大
# 最优：核心 2.8 GHz + uncore 2.2 GHz → 最佳吞吐功耗比

11. 总结与检查清单

AI 推理场景 CPU 能效管理检查清单：

□ BIOS 设置
  ├─ HWP Mode = Enabled
  ├─ CPPC = Autonomous 或 OS Controlled
  ├─ C-States = C1E minimum（不要关闭）
  └─ Global C-State = Enabled

□ OS 配置
  ├─ Governor = schedutil (首选) 或 performance (延迟极端敏感)
  ├─ EPP = balance-power (推理) 或 balance-performance (延迟敏感)
  ├─ schedutil rate_limit_us = 200-500 (推理场景)
  └─ Uncore freq enabled (高速 KV-cache 传输)

□ 监控验证
  ├─ turbostat Bzy_MHz ≈ 目标频率 (±10%)
  ├─ P99 延迟符合 SLA
  └─ PkgWatt 下降 ≥ 10% vs performance governor

□ 关键参数速查
  ├─ PELT half-life: 32ms (默认，适合 AI 推理)
  ├─ Up rate: 200us (schedutil)
  ├─ Down rate: 50us
  └─ Force boost: 关闭（推理不需要瞬时睿频）

最后的忠告：能效调优不是设置一次就完事。随着模型架构、批大小、GPU 配比的变化，最优频率点也会迁移。建议将调频策略版本化（IaC），并结合 Prometheus 指标做持续回归。在大型集群中，即使每节点节省 10W，万台节点规模下每年也可节省 数十万美元 的电费。