端侧推理的内存隔离与服务管理

在 Edge Linux 设备（如嵌入式工控机、车联网终端、智能网关）上部署端侧 AI 推理引擎（如 ONNX Runtime、llama.cpp、TensorRT-LLM）时，资源瓶颈与内核调度机制常常产生冲突。若未在操作系统层面配置确定性的资源隔离规则，推理进程在处理长上下文或突发高并发请求时，容易引发内存无节制上涨。

内存回收无法满足分配请求时，内核可能触发 OOM Killer 选择受害进程。选择结果受内存使用、oom_score_adj、cgroup 边界和系统状态影响，不能预先假定一定会杀掉某个网络服务。端侧设备仍应为推理进程设置资源边界，并为关键服务制定可验证的恢复策略。

1. 内核 OOM 触发机理与现场日志分析

当端侧 AI 推理引擎在申请连续内存空间失败且页回收（Page Reclaim）无效时，Linux 内核将调用 out_of_memory() 函数。内核根据进程占用的物理内存比例以及 oom_score_adj 的调整值计算出各进程的得分（oom_score），并选择得分最高的进程执行 SIGKILL 信号清理。

在缺乏隔离配置的机器上，dmesg -T 可能出现类似日志：

[Thu Aug 20 22:15:03 2026] Out of memory: Kill process 842 (systemd-networkd) score 155 or sacrifice child
[Thu Aug 20 22:15:03 2026] Killed process 842 (systemd-networkd) total-vm:18452kB, anon-rss:4120kB, file-rss:1024kB

上述日志表明，由于推理引擎在短时间内动态申请数百兆 Buffer 冲破物理上限，操作系统在计算分数时，网络守护进程因为得分较高而遭误杀。要彻底解决该问题，不能寄希望于推理代码自身的主动内存管理，而必须依赖操作系统级别的硬性隔离。

2. 基于 Systemd 与 Cgroup v2 的分层隔离架构

保障端侧操作系统稳定运行的核心在于两项基础约束：

1. 硬性约束资源上界：利用 Cgroup v2 限制 AI 推理进程的物理内存与 Swap 开销；
2. 保护关键系统服务：将网络与远程运维进程的 oom_score_adj 显式设为负值，确保其在内核 OOM 触发时处于保护区。

3. Systemd 配置与规则示例

将资源隔离逻辑写入 Systemd 服务定义文件中，可以在系统启动时自动完成 Cgroup v2 挂载与权限剥夺。

以下为服务配置示例。MemoryHigh、MemoryMax、Swap 配额和 OOMScoreAdjust 必须根据设备内存、其他服务和压测结果确定：

[Unit]
Description=End-Device AI Inference Engine Service
After=network.target
Wants=network-online.target

[Service]
Type=simple
User=ai-runner
Group=ai-runner
WorkingDirectory=/opt/ai-engine

# 执行启动命令
ExecStart=/opt/ai-engine/bin/onnx_runner --config /etc/ai-engine/config.json

# 1. Cgroup v2 资源隔离限制
MemoryAccounting=true
MemoryHigh=1.6G
MemoryMax=2.0G
MemorySwapMax=256M
CPUAccounting=true
CPUQuota=200%

# 2. OOM 调度优先级调整：赋予推理进程较高的被清除调度分值
OOMScoreAdjust=900

# 3. 进程异常退出退避与自动重启
Restart=on-failure
RestartSec=10s

# 4. 安全沙箱隔离（只读限制与权限剥夺）
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/opt/ai-engine/logs /tmp
NoNewPrivileges=true
CapabilityBoundingSet=

[Install]
WantedBy=multi-user.target

为了确保研发团队提交的部署服务符合 ADR 规范，可在 CI/CD 流水线中引入自动化规则检查脚本。以下为基于 Python 构建的校验程序：

import os
import sys
import re

def verify_service_security(service_path: str) -> bool:
    """自动化检查 Systemd 配置文件是否符合端侧安全部署 ADR 规范"""
    if not os.path.exists(service_path):
        print(f"[ERROR] 找不到配置文件: {service_path}")
        return False

    with open(service_path, "r", encoding="utf-8") as f:
        content = f.read()

    # 必要的硬性规则清单
    required_checks = {
        "MemoryMax 硬限制": r"MemoryMax=\d+(\.\d+)?[MG]",
        "OOM 优先级调整": r"OOMScoreAdjust=900",
        "权限剥夺防范": r"NoNewPrivileges=true",
        "只读保护系统目录": r"ProtectSystem=strict"
    }

    all_passed = True
    for item_name, pattern in required_checks.items():
        if re.search(pattern, content):
            print(f"[PASS] 规则校验通过: {item_name}")
        else:
            print(f"[FAIL] 缺少必要的安全规则: {item_name}")
            all_passed = False

    return all_passed

if __name__ == "__main__":
    target = "/etc/systemd/system/ai-inference.service"
    if os.path.exists(target):
        if not verify_service_security(target):
            sys.exit(1)
    else:
        print("[INFO] 本地测试环境未找到目标配置文件，跳过文件检查")

4. 架构决策记录 (ADR) 规范与复盘沉淀

工程经验的沉淀应当以版本化的架构决策记录（Architecture Decision Record, ADR）存放在代码仓库的 docs/adr/ 路径下，保持工程规范的持续演进。

标准化 ADR 模板示例如下：

# ADR-008: 端侧 AI 推理进程的 Cgroup v2 隔离与 OOM 保护机制

## 状态
已通过 (Accepted) - 2026-08-21

## 背景与问题陈述
嵌入式终端部署端侧 AI 推理模块时，突发高并发长上下文请求导致物理内存超载。在未限制资源边界的情况下，内核 OOM Killer 误杀 systemd-networkd，导致设备网络通信中断。

## 决策选项评估
1. 方案 A：在 C/C++ 推理引擎代码层增加自定义分配器控制内存（改造成本高，第三方库申请无法全面拦截）。
2. 方案 B：基于操作系统 Cgroup v2 与 Systemd 沙箱配置硬隔离与 OOMScoreAdjust 规则（推荐，确定性高且无侵入性）。

## 确立的工程规则
- 推理服务配置 `MemoryMax`，上限由设备可用内存和共存服务的压测结果决定。
- 为推理服务显式设置合适的 `OOMScoreAdjust`，并在故障演练中验证 OOM 行为。
- 对网络、远程运维等关键服务评估 `OOMScoreAdjust`、重启策略和带外恢复手段，避免将单一参数视为绝对保护。

## 验证与后置后果
- 经压测验证，当推理进程触发物理超限时，Systemd 自动捕获该清理动作并在退避 10 秒后重启服务，期间操作系统网络连通性不受影响。

5. 端侧部署避坑指南

结合操作系统与端侧 AI 结合的实践，归纳以下三条部署原则：

1. 避免单靠语言层面的内存管理：三方 C++ 动态库在端侧推理时容易出现内存碎片化或泄露，仅靠上层代码难以保证资源归还，必须依赖操作系统 Cgroup 进行兜底。
2. 将安全复盘转化为自动化校验脚本：任何文字层面的经验总结，都应当转化为可被 CI 流水线或系统启动工具执行的结构化校验逻辑。
3. 分层设置 MemoryHigh 与 MemoryMax：利用 MemoryHigh 提前向进程发出垃圾回收或缓存清理信号，通过 MemoryMax 设置最终的硬性隔离阀门，降低死机风险。