端侧推理首版该做到什么程度

在端侧设备(如边缘计算盒、智能终端或工业 PC)上部署大模型推理服务时,架构设计容易面临两类典型偏差:一是直接以 root 权限运行裸露的 HTTP 推理服务,一旦模型解析非安全 Prompt 或遭受注入攻击,整个操作系统的权限隔离将失效;二是在第一版(MVP)阶段过度设计,试图直接引入 TPM 硬件安全芯片、机密计算 Enclave 及复杂的虚拟化隔离,导致开发周期拉长,且多层封装带来不可忽略的算力开销。

端侧 AI 推理的第一版,应先明确要保护的进程、数据和设备资源,并用可维护的隔离措施降低推理服务对系统其他部分的影响。


1. 第一版部署的关键取舍:安全与复杂度的平衡

在端侧操作系统上,AI 推理引擎(如基于 C++ 的 llama.cppONNX Runtime)本质上是一个高 CPU/GPU 占用、高内存吞吐的计算密集型进程。

下表梳理了第一版端侧 AI 部署在安全隔离上的控制范围:

安全/架构维度 第一版必须做到(MVP 必备) 第一版暂缓实现(避免过度工程)
进程权限控制 独立非 root 用户运行,利用 cgroups 限制内存与 CPU 自定义 LSM 内核模块或 TPM 硬件远程 Attestation 校验
系统调用隔离 根据推理引擎实际调用集配置 Seccomp,并在目标设备验证 全量微内核沙盒隔离或 Secure Enclave 加密
内存与安全保护 配合 cgroup memory controller 设置限额,并观察 OOM 行为 物理内存全程实时同态加密
IPC 数据交互 基于 Unix Domain Socket + 共享内存只读映射 复杂的异构 RPC 加密通信网关

第一版的重点是限制推理进程的资源和权限。Prompt 本身不会让模型直接执行系统命令;真正要控制的是服务是否把模型输出连接到了工具调用、文件访问或命令执行。


2. 基于 POSIX 与 cgroups 的资源控制实践

端侧 AI 推理服务容易引发的系统隐患在于内存占用过高。当上下文 Token 长度突增或加载参数量过大的模型时,Linux 内核的 OOM Killer 可能会终止系统的其他核心守护进程。

因此,在第一版中,需在系统层显式地对推理进程进行资源限额。下面展示在 Linux 系统上启动推理子进程时,通过 POSIX setrlimitseccomp 进行安全防护的 C 语言实现:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/resource.h>
#include <seccomp.h>
#include <err.h>

// 示例值:实际限额应按模型、设备和并发压测结果配置
#define MAX_MEM_BYTES (4ULL * 1024 * 1024 * 1024)

void apply_resource_limits() {
    struct rlimit rl;
    
    // 1. 设置最大虚拟内存限制;它应与 cgroup 限制配合评估
    rl.rlim_cur = MAX_MEM_BYTES;
    rl.rlim_max = MAX_MEM_BYTES;
    if (setrlimit(RLIMIT_AS, &rl) != 0) {
        perror("setrlimit RLIMIT_AS 失败");
        exit(EXIT_FAILURE);
    }
    
    // 2. 禁用 core dump 防止内存敏感 Token 泄漏到磁盘
    rl.rlim_cur = 0;
    rl.rlim_max = 0;
    setrlimit(RLIMIT_CORE, &rl);
}

void apply_seccomp_sandbox() {
    scmp_filter_ctx ctx;

    // 默认允许常规系统调用,显式禁用危险的系统级调用
    ctx = seccomp_init(SCMP_ACT_ALLOW);
    if (!ctx) {
        errx(1, "seccomp 初始化失败");
    }

    // 禁止衍生新进程 (禁止 execve 和 execveat)
    seccomp_rule_add(ctx, SCMP_ACT_KILL, SCMP_SYS(execve), 0);
    seccomp_rule_add(ctx, SCMP_ACT_KILL, SCMP_SYS(execveat), 0);
    
    // 禁止进程调试与内存跟踪 (禁止 ptrace)
    seccomp_rule_add(ctx, SCMP_ACT_KILL, SCMP_SYS(ptrace), 0);

    // 加载 Seccomp 过滤规则到内核
    if (seccomp_load(ctx) != 0) {
        perror("seccomp 规则加载失败");
        seccomp_release(ctx);
        exit(EXIT_FAILURE);
    }
    
    seccomp_release(ctx);
}

int main() {
    printf("[系统安全] 正在为端侧 AI 推理进程建立隔离环境...\n");
    
    apply_resource_limits();
    apply_seccomp_sandbox();

    printf("[系统安全] 隔离环境初始化完成,准备启动推理引擎内核。\n");
    
    // 此处启动推理子逻辑
    // 若推理引擎试图调用 execve 启动 shell,内核将发送 SIGSYS 终止该进程
    
    return 0;
}

3. 共享内存与 IPC 通信的零拷贝安全设计

在端侧部署中,频繁的 Prompt 输入与 Token 向量输出如果经过传统 TCP/HTTP 协议栈转发,在低功耗 CPU 上会产生编解码开销与上下文切换损耗。第一版推荐采用 Unix Domain Socket 传递控制信令 + POSIX 共享内存(mmap)传递数据载荷 的架构。

在使用共享内存时,需明确以下边界:

  1. 权限隔离:共享内存文件(如 /dev/shm/ai_infer_shm)的权限严格设为 0600,仅允许推理进程与安全网关进程访问。
  2. 只读映射(PROT_READ):推理进程读取输入 Buffer 时,映射权限设为只读,防止推理引擎内的指针错误破坏网关进程放在共享内存中的元数据。
  3. 环形缓冲区(Ring Buffer)同步机制:使用进程共享 mutex 或无锁协议处理并发读写;前者还需考虑持锁进程退出后的恢复策略。

4. MVP 版本的验收与演进路线

完成进程降权、资源限额、经过测试的 Seccomp 规则和本地通信后,第一版已有基础隔离能力;是否达到上线要求仍取决于设备、数据敏感度和威胁模型。

工程团队可以通过以下标准对 MVP 版本进行验收:

  1. 极限内存占用压测:并发发送长上下文 Prompt,验证推理进程是否能在受控状态下抛出 OOM 拒绝服务,且系统内核及其他业务进程保持稳定运行。
  2. 命令注入测试:在 Prompt 中构造包含系统命令注入的攻击载荷,验证 Seccomp 是否触发 execve 拦截并终止进程。
  3. 长周期运行测试:按实际负载和发布节奏运行足够长时间,监控 CPU/GPU 内存、句柄和重启次数;发现趋势异常后再定位。

基础防护应在第一版完成并通过演练。机密计算、TPM 证明等能力是否引入,应由设备控制权、数据等级和合规要求决定。

Logo

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐