微型推理框架实验失败后的排查

在 RAM 只有 8GB 的树莓派 5 或者 Rockchip RK3588 边缘嵌入式板卡上跑 Qwen-1.5B 或 Llama-3-8B-INT4 时，最头疼的莫过于长文本推理过程中内存渐进式泄漏。系统刚启动时一切正常，连续运行 48 小时处理数万条上下文后，板卡突然失联。登跳板机查看内核日志，发现系统被内核 oom-killer 强制屠杀。

在受限芯片上运行 LLM，纯靠理想化的内存管理不靠谱。必须建立一套常驻的巡检与熔断止损机制，在内存触顶前主动清理 KV Cache，或者优雅降级回退到小模型，避免整机锁死或服务直接崩溃。

1. 凌晨 3 点板卡静默挂掉：oom-killer 直接抹掉了 llama-cpp 进程

设备运行两天后突然无法响应 HTTP 请求。通过串口连接或者 syslog 翻看 Linux 内核打印，能看到典型的 OOM 堆栈信息：

# 微型推理框架实验失败后的排查
dmesg -T | grep -E -C 5 "Out of memory|Killed process"

# 微型推理框架实验失败后的排查
ps -eo pid,comm,pmem,oom_score | sort -k4 -nr | head -n 10

日志记录非常直接：

[Sun Aug 16 03:14:22 2026] llama_main invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[Sun Aug 16 03:14:22 2026] CPU: 2 PID: 4892 Comm: llama_main Not tainted 6.1.0-rpi5 #1
[Sun Aug 16 03:14:22 2026] Hardware name: Raspberry Pi 5 Model B Rev 1.0
[Sun Aug 16 03:14:22 2026] Mem-Info:
[Sun Aug 16 03:14:22 2026] active_anon:1834201kB inactive_anon:5820492kB isolated_anon:0kB
[Sun Aug 16 03:14:22 2026] Tasks state (memory values in pages):
[Sun Aug 16 03:14:22 2026] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
[Sun Aug 16 03:14:22 2026] [   4892]  1000  4892  2104500  1892040     15425792        0             0 llama_main
[Sun Aug 16 03:14:22 2026] Out of memory: Killed process 4892 (llama_main) total-vm:8418000kB, anon-rss:7568160kB, file-rss:0kB, shmem-rss:0kB

从 total-vm 和 anon-rss 可以看到，llama_main 占用了 7.5GB 的匿名物理页。小芯片没有独立的显存，C++ 推理库（如 llama.cpp 或 NCNN）的 Context Window 在多次多轮对话后，未被及时释放的 Slot Tensor 与临时 Token 分配逐步把内存塞满。Linux 内核找不到可回收的 Buffer 页，直接选择得分最高（oom_score 接近 1000）的推理进程予以击杀。

2. 自动化巡检与双阈值熔断架构

靠死扛等待 OS 的 OOM 是最糟糕的处理方式。防御方案必须设计双阈值保护策略：警戒阈值（Warning Threshold，如 RAM 占用 85%）与熔断阈值（Critical Threshold，如 RAM 占用 93%）。

关键策略在于：

• 警告线：放弃早期历史 Token 的 Attention Cache，强制回退 Context Length（如从 4096 截断到 1024）。
• 熔断线：拒绝对高消耗长文本请求的响应，向前端返回降级提示，同时向后台推理 Worker 发送信号，进行内存重置与垃圾回收。

3. 零外置依赖的 Shell/Python 健康检查与优雅降级脚本

以下 Python 脚本作为一个后台守护进程（Daemon）运行，无需额外依赖第三方库，直接解析 /proc 文件系统获取真实 RSS 物理内存，并向 LLM 服务发送管控指令。

#!/usr/bin/env python3
import os
import sys
import time
import signal
import urllib.request
import json

PROCESS_NAME = "llama_main"
WARN_MEM_RATIO = 0.82   # 82% 内存触发 Context 裁剪
CRIT_MEM_RATIO = 0.91   # 91% 内存触发拒绝服务与重启熔断
CHECK_INTERVAL = 3.0    # 巡检周期 (秒)
LLM_API_BASE = "http://127.0.0.1:8080"

def get_system_memory_usage():
    mem_total = 0
    mem_available = 0
    with open('/proc/meminfo', 'r') as f:
        for line in f:
            parts = line.split()
            if parts[0] == 'MemTotal:':
                mem_total = int(parts[1])
            elif parts[0] == 'MemAvailable:':
                mem_available = int(parts[1])
    if mem_total == 0:
        return 0.0
    used_ratio = (mem_total - mem_available) / float(mem_total)
    return used_ratio

def find_pid_by_name(name):
    for pid_str in os.listdir('/proc'):
        if pid_str.isdigit():
            try:
                with open(f'/proc/{pid_str}/comm', 'r') as f:
                    comm = f.read().strip()
                    if comm == name:
                        return int(pid_str)
            except (FileNotFoundError, PermissionError):
                continue
    return None

def trigger_kv_cache_truncate():
    """通过 HTTP API 通知 LLM 服务清空过期上下文"""
    url = f"{LLM_API_BASE}/slots/action"
    req_data = json.dumps({"action": "clear_oldest_context", "keep_tokens": 512}).encode('utf-8')
    req = urllib.request.Request(url, data=req_data, headers={'Content-Type': 'application/json'}, method='POST')
    try:
        with urllib.request.urlopen(req, timeout=2.0) as resp:
            print(f"[PATROL WARN] 已发送上下文截断指令，响应状态: {resp.status}")
    except Exception as e:
        print(f"[PATROL ERROR] 无法连接 LLM API 截断上下文: {e}")

def trigger_graceful_restart(pid):
    """发送 SIGTERM 优雅终止，由 systemd 负责拉起重启"""
    print(f"[PATROL CRITICAL] 内存触及硬熔断线，准备终止 PID {pid} 以防整机死锁...")
    try:
        os.kill(pid, signal.SIGTERM)
        time.sleep(2.0)
        if os.path.exists(f"/proc/{pid}"):
            os.kill(pid, signal.SIGKILL)
    except ProcessLookupError:
        pass

def main():
    print("[PATROL START] 小芯片大模型内存巡检与止损守护进程已启动...")
    while True:
        mem_ratio = get_system_memory_usage()
        pid = find_pid_by_name(PROCESS_NAME)

        if pid is not None:
            if mem_ratio >= CRIT_MEM_RATIO:
                print(f"[ALERT] 当前内存使用率: {mem_ratio*100:.2f}% (CRITICAL >= {CRIT_MEM_RATIO*100}%)")
                trigger_graceful_restart(pid)
            elif mem_ratio >= WARN_MEM_RATIO:
                print(f"[WARNING] 当前内存使用率: {mem_ratio*100:.2f}% (WARN >= {WARN_MEM_RATIO*100}%)")
                trigger_kv_cache_truncate()

        time.sleep(CHECK_INTERVAL)

if __name__ == "__main__":
    main()

除了守护进程，系统底层必须配置 Linux 内核参数 vm.panic_on_oom 与 sysrq 机制，防止整机因为 Memory Starvation 陷入永久性的内核锁死（Kernel Lockup）。

# 微型推理框架实验失败后的排查
sudo sysctl -w vm.overcommit_memory=2
sudo sysctl -w vm.overcommit_ratio=80
sudo sysctl -w vm.panic_on_oom=0

# 微型推理框架实验失败后的排查
sudo sysctl -w vm.swappiness=10

4. 止损机制的验证与复盘

为了验证这套运维巡检系统的效果，可以用并发请求压测脚本向嵌入式推理服务注入长文本 Task。

# 微型推理框架实验失败后的排查
for i in {1..20}; do
  curl -s -X POST http://127.0.0.1:8080/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "qwen", "messages": [{"role": "user", "content": "重复输出以下文本 2000 次..."}]}' > /dev/null &
done

在压测过程中监控系统物理内存变化：

# 微型推理框架实验失败后的排查
smem -P llama_main -k

观察日志输出，在内存使用率升至 83% 时，巡检守护进程精准捕获并触发上下文截断 API，内存增长趋势立刻平缓下来。在极限拉满并发导致内存突破 91% 的瞬时，守护进程在 oom-killer 介入前 1.2 秒主动发送 SIGTERM 关停进程，并由 systemd 在 3 秒内完成重新拉起，整体服务中断时间缩短到 4 秒内，且没有造成嵌入式板卡挂卡或掉线。

在算力受限的嵌入式小芯片上跑大模型，防线必须筑在系统前面。通过自动化指标巡检与分级熔断，彻底摆脱系统硬崩的阴影。