Linux systemd 在 AI 推理集群中的服务管理、资源精细化控制与 cgroup v2 集成工程实战

引言

在 AI 推理集群的生产部署中，工程师们往往把大量精力投入到 GPU 调优、内核参数、io_uring 异步 I/O 等底层优化上，却忽略了一个基础设施层面的问题：谁来管理这些推理进程的生命周期、资源隔离和运行时保证？

systemd 作为现代 Linux 系统的 init 和服务管理器，在 AI 推理集群的运维工程中扮演着比大多数人想象中更关键的角色。它不仅是启动服务的工具，更是一个完整的进程沙箱、资源控制器和运行时编排引擎。

本文将从 AI 推理场景的工程需求出发，深入剖析 systemd 如何通过 cgroup v2 控制器、套接字激活、看门狗机制和实时调度策略，为推理服务提供生产级的可靠性保证。

一、AI 推理服务的工程诉求

现代企业级 AI 推理部署的核心诉求可以归纳为以下五个维度：

诉求	具体指标	典型挑战
快速冷启动	P99 启动时间 < 3s	模型加载阻塞进程
健康检测	死锁/卡死检测 < 5s	GPU hang 无法被普通 probe 捕获
资源隔离	QPS 波动率 < 10%	Noisy Neighbor 干扰
优雅退出	当前请求完成率 > 99.9%	模型更新不丢请求
自愈能力	宕机恢复 < 8s	OOM 后需自动拉起

这些诉求中有相当一部分可以通过 systemd 的内置能力实现，而无需引入额外的编排层。

二、cgroup v2 控制器集成

systemd 通过 Slice 和 Scope 单元与 cgroup v2 深度集成。在 AI 推理场景中，核心控制点包括 CPU、内存和 I/O 三个维度。

2.1 多级 Slice 层级设计

# /etc/systemd/system/ai-inference.slice
[Slice]
# 整个推理集群的资源天花板
CPUQuota=800%
MemoryMax=200G
MemoryHigh=180G
IOWeight=800

通过 Slice 层级嵌套，可以实现从集群级到实例级的多级资源隔离：

ai-inference.slice          (200G RAM, 800% CPU)
├── triton.slice            (80G RAM,  4× A100 节点)
│   ├── triton.service      (主推理服务)
│   └── triton-health.service  (健康检查辅助)
├── vllm.slice              (80G RAM,  4× A100 节点)
│   └── vllm.service
└── preprocessing.slice     (40G RAM,  CPU 预处理池)
    └── preprocessor.service

2.2 CPU 精细化控制

除了基础的 CPUQuota 和 CPUWeight，systemd 还支持 CPU 集合绑定和控制组实时优先级：

[Service]
# 绑定到 NUMA node 0 的物理核心，避免跨 NUMA 延迟
CPUAffinity=0-31 64-95

# 限制该服务只能使用特定 CPU 集合
AllowedCPUs=0-31 64-95

# 实时调度策略：适用于 DPDK 预处理流水线
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=50

# 禁止内存迁移到远端 NUMA 节点
MemoryDenyWriteExecute=false

对 AI 推理服务而言，CPUAffinity 的配置尤为关键。以一个 2× AMD EPYC 9654 的双路服务器为例，两个 CPU 插槽各有 96 核。跨 NUMA 访问内存的延迟比本地访问高出约 40-60%，这对推理吞吐和尾延迟有直接影响。

2.3 内存水位线策略

[Service]
# 硬限制：超过即 OOM Kill
MemoryMax=75G

# 软限制：内核会积极回收但不会杀进程
MemoryHigh=68G

# swap 限制：训练场景下建议关闭 swap
MemorySwapMax=0

# 通过 cgroup v2 memory.events 监控
ExecStartPre=/usr/local/bin/oom-guard.sh

MemoryHigh 的精妙之处在于它不是硬限制，而是触发内核积极回收的阈值。在 LLM 推理服务中，KV-Cache 的占用会随批处理量动态变化。将 MemoryHigh 设置为模型权重 + 预留 buffer 的大小，可以让内核在保证服务稳定的前提下最大化内存利用率。

2.4 I/O 权重与带宽控制

在推理节点上，模型加载、checkpoint 保存、日志写入和 profiling 数据共享同一个 NVMe 带宽。通过 systemd 的 IO 控制器可以量化隔离：

[Service]
# 默认权重为 100，范围 1-10000
IOWeight=800

# NVMe 设备的读写带宽限制 (需内核 >= 5.7)
IOReadBandwidthMax=/dev/nvme0n1 5G
IOWriteBandwidthMax=/dev/nvme0n1 2G

三、推理服务的生命周期管理

3.1 套接字激活（Socket Activation）

systemd 的套接字激活机制允许在网络连接到达时才启动服务进程，这为冷启动优化提供了基础：

# triton.socket
[Socket]
ListenStream=8000
ListenStream=8001
ListenStream=8002

# 每个连接的服务实例数
MaxConnections=4

# 空闲超时自动关闭，节省 GPU 内存
KeepAlive=no

[Install]
WantedBy=sockets.target

# triton.service
[Service]
Type=notify
ExecStart=/opt/triton/bin/tritonserver --model-repository=/models

# 当 socket 激活时，systemd 监听端口
# 服务仅在第一个请求真实到达时启动

3.2 Watchdog 看门机制

[Service]
# 启用 systemd watchdog，每 10s 需发送一次心跳
WatchdogSec=10s

# 若连续 3 次未发送心跳，systemd 自动重启服务
Restart=on-failure
RestartSec=2s
StartLimitBurst=5
StartLimitIntervalSec=60s

这段配置的核心价值在于解决了 GPU 推理服务中最棘手的问题：GPU 挂起检测。当 CUDA 内核因为内存越界或驱动 bug 导致 GPU hang 时，传统的进程级健康检查（如 HTTP 心跳）可能仍然正常返回。

一个高效的 watchdog 实现应将 GPU 活性检测集成到心跳信号中：

# health_daemon.py — GPU 看门狗心跳实现
import ctypes
import sdnotify  # python-systemd 库
from pynvml import *

nvmlInit()
n = sdnotify.SystemdNotifier()

def gpu_health_check():
    """返回 True 表示 GPU 健康，否则触发 watchdog 超时"""
    try:
        for i in range(nvmlDeviceGetCount()):
            handle = nvmlDeviceGetHandleByIndex(i)
            util = nvmlDeviceGetUtilizationRates(handle)
            temp = nvmlDeviceGetTemperature(handle, NVML_TEMPERATURE_GPU)

            # GPU 过热保护
            if temp > 95:
                return False

            # 检查 ECC 错误计数
            ecc = nvmlDeviceGetTotalEccErrors(handle, NVML_MEMORY_ERROR_TYPE_UNCORRECTED,
                                               NVML_VOLATILE_ECC)
            if ecc > 100:
                return False
    except NVMLError:
        return False
    return True

while True:
    n.notify(f"WATCHDOG=1\nGPU_HEALTH={'OK' if gpu_health_check() else 'FAIL'}")
    time.sleep(5)

3.3 优雅退出与请求排空

AI 推理服务在升级或配置热加载时需要保证在途请求不丢失。systemd 的优雅退出机制配合 Python PreStop hook 可以实现：

[Service]
# 发送 SIGTERM 后等待 30s，超时发送 SIGKILL
TimeoutStopSec=30s

# 退出后始终重启（除非 systemctl stop）
Restart=on-success
RestartSec=1s

# 确保 cgroup 内子进程也收到信号
KillMode=mixed
FinalKillSignal=SIGKILL

#!/usr/bin/env bash
# PreStop 脚本：请求 Kubernetes / 负载均衡器摘流
curl -sf -X POST http://localhost:8001/health/unregister
# 等待在途请求完成 (最大 20s)
timeout 20 bash -c 'until [ $(curl -sf http://localhost:8001/metrics/requests_pending) -eq 0 ]; do sleep 1; done'

四、高级安全沙箱

systemd 的 ProtectSystem、PrivateTmp、NoNewPrivileges 等安全指令为 AI 推理服务提供了操作系统级别的纵深防御：

[Service]
# 文件系统沙箱
ProtectSystem=strict       # 只读挂载 /usr /boot /etc
ProtectHome=true           # 不可访问 /home /root /run/user
PrivateTmp=true            # 独立 tmp 命名空间
ReadWritePaths=/models /var/log/triton  # 仅允许写入模型&日志目录

# 能力性限制
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SYS_NICE
NoNewPrivileges=true

# 系统调用过滤
SystemCallFilter=@system-service
SystemCallFilter=~@mount @reboot @swap @clock @cpu-emulation @debug @obsolete @privileged @resources
SystemCallArchitectures=native

# 内核参数锁定
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectKernelLogs=true

# 用户命名空间
PrivateUsers=true
RestrictNamespaces=true

# 地址空间保护
MemoryDenyWriteExecute=true

在 AI Agent 场景下，模型可能通过 prompt injection 尝试执行逃逸代码。MemoryDenyWriteExecute=true 阻止了代码注入后的 shellcode 执行，PrivateTmp 和 ProtectSystem 限制了文件系统攻击面。

五、监控与可观测性集成

systemd 提供了丰富的状态接口，可以与 Prometheus/监控栈无缝集成。

5.1 服务状态指标体系

通过 systemctl show --property=All triton.service 可以导出服务状态的完整快照：

# 关键监控指标
systemctl show triton.service --property=\
ActiveState,\
SubState,\
MainPID,\
MemoryCurrent,\
MemoryPeak,\
CPUUsageNSec,\
IOReadBytes,\
IOWriteBytes,\
TasksCurrent,\
NRestarts,\
InvocationID

5.2 cgroup 指标采集脚本

#!/bin/bash
# 导出推理 slice 的 cgroup v2 指标
SLICE="ai-inference.slice"
CGROUP_PATH="/sys/fs/cgroup/${SLICE}"

# CPU 使用量 (纳秒)
cat ${CGROUP_PATH}/cpu.stat

# 内存分布
cat ${CGROUP_PATH}/memory.stat

# I/O 统计
cat ${CGROUP_PATH}/io.stat

# PSI (Pressure Stall Information) — 资源争抢信号
cat ${CGROUP_PATH}/cpu.pressure
cat ${CGROUP_PATH}/memory.pressure
cat ${CGROUP_PATH}/io.pressure

PSI（Pressure Stall Information）是评估 AI 推理集群资源健康度的关键指标。当 memory.pressure 的 some avg10（过去 10s 平均阻塞比例）持续高于 20% 时，说明节点的内存带宽或容量已接近瓶颈，应当触发弹性扩容告警。

六、生产故障案例分析

案例 1：Noisy Neighbor 导致的尾延迟飙升

现象：同一台 4× A100 服务器上运行的 LLM 推理服务，P99 延迟从 120ms 飙升至 800ms。

根因：训练任务（运行在另一个 slice 但未设置 MemoryHigh）吃掉了所有可用内存带宽，导致推理服务的 KV-Cache 页面回收频繁。

修复方案：

# 为训练任务设置 MemoryHigh，为推理预留带宽
[Slice]
# 推理 slice — 更高权重，保证响应性
[Slice]
CPUWeight=1000
IOWeight=900
MemoryHigh=70G
MemoryZSwapAcceptModifier=5

# 训练 slice — 更低权重，允许被压缩
[Slice]
CPUWeight=300
IOWeight=200
MemoryHigh=90G
MemorySwapMax=16G  # 允许训练 swap

引入 MemoryZSwapAcceptModifier（Linux 6.8+）后，可以对特定 slice 启用 zswap 压缩缓存，在内存压力与 CPU 开销之间取得平衡。

案例 2：GPU Hang 引发的服务死锁

现象：推理服务的 HTTP 健康检查持续返回 200，但请求延迟无限延长。

根因：CUDA 内核执行了越界内存访问，导致 GPU SM（流式多处理器）死锁。由于 Python GIL 存在，HTTP 监控线程仍然正常响应。

修复方案： 1. 引入 GPU watchdog 心跳（见上文 Python 示例） 2. 设置 WatchdogSec=5s，超时即重启 3. 配合 systemd 的 coredump 收集保留崩溃现场

[Service]
# 允许 systemd 收集 core dump
LimitCORE=infinity
ExecStopPost=/usr/local/bin/collect-gpu-backtrace.sh

案例 3：OOM 循环重启

现象：推理服务被 OOM 拉起后反复失败，形成重启循环。

根因：模型权重占满内存，重启后再次加载即 OOM，未给 garbage collector 留时间。

修复方案：

[Service]
# 配置启动速率限制，防止重启风暴
StartLimitIntervalSec=300s
StartLimitBurst=3

# 渐退式重启间隔
RestartSec=10s

# 启动前执行环境检查
ExecStartPre=/usr/local/bin/check-memory.sh

#!/usr/bin/env bash
# check-memory.sh — OOM 防护
FREE_G=$(free -g | awk '/Mem:/{print $7}')
if [ "$FREE_G" -lt 15 ]; then
    echo "Insufficient memory for AI model loading (${FREE_G}G free, need 15G+)"
    exit 1
fi

七、最佳实践清单

基于以上分析，总结出 AI 推理集群 systemd 配置的"五个必须"：

1. 必须设置 MemoryHigh：防止 Noisy Neighbor 推高 tail latency
2. 必须启用 WatchdogSec + GPU 健康检测：防止 GPU Hang 服务僵死
3. 必须配置 CPUAffinity：避免跨 NUMA 内存访问
4. 必须开启 StartLimitBurst：防止重启风暴
5. 必须使用 SystemCallFilter：最小化攻击面

# AI 推理服务 systemd 配置的黄金模板
[Unit]
Description=AI Inference Server
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
ExecStart=/opt/inference/bin/server --config /etc/inference/config.toml
ExecStartPre=/usr/local/bin/check-memory.sh
ExecStopPost=/usr/local/bin/drain-connections.sh

# 资源控制
MemoryMax=72G
MemoryHigh=64G
MemorySwapMax=0
CPUQuota=400%
CPUWeight=800
IOWeight=700
CPUAffinity=0-31 128-159

# 故障恢复
WatchdogSec=8s
Restart=on-failure
StartLimitBurst=3
StartLimitIntervalSec=300s
RestartSec=10s
TimeoutStopSec=30s

# 安全沙箱
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true
SystemCallFilter=@system-service
ReadWritePaths=/models /var/log/inference

# 监控
LimitNOFILE=65536
LimitMEMLOCK=infinity

[Install]
WantedBy=multi-user.target

结语

很多人认为 systemd 只是一个 init 进程，但它在 AI 推理集群的工程化部署中远不止如此。从资源隔离到进程生命周期，从安全加固到故障自愈，systemd 提供了一整套操作系统原生的生产级保障能力。

在下一篇文章中，我们将探讨如何将这些 systemd 配置与 Kubernetes 的 QoS 策略、Device Plugin 框架进一步集成，构建面向大规模 AI 推理集群的统一资源管控平面。