4、内存指标：峰值内存、常驻内存、内存带宽、内存碎片化，以及如何通过工具监测

Edge AI 设备的推理任务通常在资源受限的 MCU、NPU 或嵌入式 Linux 系统上运行。与云端 GPU 服务器不同，边缘设备的内存容量有限（从几十 KB 到几 GB 不等），且往往没有 Swap 或虚拟内存机制兜底。内存指标直接决定了模型能否成功加载、推理能否实时完成、以及设备在长时间运行后是否会出现性能劣化或崩溃。本章将深入剖析四个核心内存指标——峰值内存、常驻内存、内存带宽、内存碎片化，并给出可落地的监测工具与分析方法。

4.1 核心原理：四个内存指标的定义与工程意义

峰值内存（Peak Memory）指程序在运行过程中某一瞬间达到的最大内存占用量。在 Edge AI 场景中，峰值内存通常出现在模型加载阶段（权重从 Flash 拷贝到 RAM）、推理前期的张量分配阶段，或某些特殊算子（如动态形状的 Resize、Non-Maximum Suppression）执行期间。峰值内存决定了设备能否容纳该模型——如果峰值超过物理 RAM 总量，系统将直接 OOM（Out of Memory）或被内核 Kill。需要特别注意的是，峰值内存并不等于模型文件大小，因为推理框架（如 TensorFlow Lite Micro、ONNX Runtime）在运行时会额外分配中间张量、算子工作缓冲区、激活值存储等。

常驻内存（Resident Set Size, RSS）指进程当前实际占用的物理内存页数，包括代码段、数据段、堆、栈以及共享库中被映射的部分。RSS 是衡量 Edge AI 设备内存压力的最直接指标。与峰值内存不同，RSS 是一个动态变化的值，它反映了进程在某一时刻对物理内存的真实占用。在嵌入式 Linux 系统中，RSS 可以通过 /proc/[pid]/status 中的 VmRSS 字段读取。对于裸机 MCU 环境，常驻内存通常等同于整个程序映像（包括 .text、.data、.bss 段）加上堆栈使用量。

内存带宽（Memory Bandwidth）指单位时间内 CPU/NPU 与内存之间传输的数据量，单位通常为 MB/s 或 GB/s。Edge AI 推理是典型的内存密集型任务——卷积运算需要反复读取输入特征图、权重和中间结果。当内存带宽不足时，即使 CPU/ NPU 计算能力再强，也会因为等待数据而空转，形成“内存墙”瓶颈。例如，在 Raspberry Pi 4 上运行 MobileNetV2 时，内存带宽利用率可能达到 60%-80%，此时进一步优化算子计算量对延迟的改善微乎其微，必须从数据复用、缓存优化或量化入手。

内存碎片化（Memory Fragmentation）指空闲内存被分割成许多不连续的小块，导致即使总空闲内存充足，也无法满足大块连续内存分配请求的现象。碎片化分为内部碎片（分配块大于请求量）和外部碎片（空闲块不连续）。Edge AI 设备长期运行后，频繁的 tensor 分配/释放会导致堆内存碎片化加剧。在极端情况下，一个 100KB 的分配请求可能因为找不到连续 100KB 空闲块而失败，尽管此时总空闲内存还有 500KB。碎片化对实时性要求高的推理任务尤其致命——它可能导致推理延迟出现毫秒级甚至百毫秒级的抖动。

4.2 判断方法与操作流程：如何精准测量四个指标

针对不同硬件平台（嵌入式 Linux、RTOS、裸机 MCU），监测工具和方法差异较大。以下按平台分类给出可操作的测量流程。

4.2.1 嵌入式 Linux 平台（基于 /proc 与 perf）

对于运行 Linux 的边缘设备（如 Jetson Nano、Raspberry Pi、RK3588 开发板），最直接的内存监测手段是读取 /proc 文件系统。以下脚本可周期性采集峰值内存和 RSS：

#!/bin/bash
# monitor_mem.sh - 采集推理进程的内存指标
PID=$(pgrep -f "your_inference_app")
if [ -z "$PID" ]; then
    echo "Process not found"
    exit 1
fi

echo "Timestamp, VmPeak, VmRSS, VmData, VmStk"
while true; do
    VMPEAK=$(grep VmPeak /proc/$PID/status | awk '{print $2}')
    VMRSS=$(grep VmRSS /proc/$PID/status | awk '{print $2}')
    VMDATA=$(grep VmData /proc/$PID/status | awk '{print $2}')
    VMSTK=$(grep VmStk /proc/$PID/status | awk '{print $2}')
    echo "$(date +%s.%N), $VMPEAK, $VMRSS, $VMDATA, $VMSTK"
    sleep 0.5
done

内存带宽的测量需要使用 perf 工具或 ARM 的 Performance Monitoring Unit (PMU)。以 ARMv8 平台为例，可以使用 perf stat 统计 LLC（Last Level Cache）命中率和内存访问指令数：

# 统计推理程序的内存带宽相关事件
perf stat -e cache-misses, cache-references, dTLB-load-misses, dTLB-store-misses \
          -p $(pgrep -f "your_inference_app") sleep 10

更精确的带宽测量需要读取 PMU 中的 BUS_ACCESS 或 MEMORY_READ 事件，这通常需要平台特定的 perf 事件名称（如 armv8_pmuv3_0/inst_retired/）。对于大多数开发者，一个实用的替代方案是：在推理前后分别读取 /proc/[pid]/io 中的 read_bytes 和 write_bytes，计算差值除以时间得到近似带宽。

4.2.2 裸机 MCU 平台（基于链接脚本与运行时统计）

对于 STM32、ESP32 等裸机 MCU，没有操作系统提供 /proc 接口。此时需要借助编译工具链和运行时钩子函数。峰值内存可以通过检查链接脚本中的堆顶地址与程序实际到达的最大堆指针来估算。常用的方法是覆盖 malloc 和 free：

// 自定义 malloc 钩子，记录峰值堆使用量
static size_t heap_used = 0;
static size_t heap_peak = 0;

void *__real_malloc(size_t size);
void __real_free(void *ptr);

void *__wrap_malloc(size_t size) {
    void *ptr = __real_malloc(size);
    if (ptr) {
        heap_used += size;
        if (heap_used > heap_peak) heap_peak = heap_used;
    }
    return ptr;
}

void __wrap_free(void *ptr) {
    // 需要额外记录块大小，此处简化
    __real_free(ptr);
}

// 在推理完成后打印
printf("Peak heap usage: %u bytes\n", heap_peak);

内存碎片化在 MCU 上可以通过 mallinfo() 函数（Newlib 提供）获取空闲块数量和最大空闲块大小：

struct mallinfo mi = mallinfo();
printf("Total free space: %d bytes\n", mi.fordblks);
printf("Largest free block: %d bytes\n", mi.maxfree);
printf("Number of free blocks: %d\n", mi.ordblks);
// 碎片率 = 1 - (最大空闲块 / 总空闲空间)
float fragmentation = 1.0f - ((float)mi.maxfree / mi.fordblks);

4.3 案例拆解：智能摄像头推理进程的内存优化实战

背景与约束：某智能家居摄像头产品采用 RK3566 平台（2GB LPDDR4），运行 Linux 5.10 + TensorFlow Lite 2.12。设备需要同时运行人脸检测模型（MobileNetV2-SSD，INT8 量化）和系统服务（Wi-Fi 驱动、RTSP 推流、MQTT 通信）。产品规格要求：内存余量不低于 300MB，推理延迟小于 80ms，且设备需 7×24 小时连续运行。

初始现象：在实验室测试中，设备运行 48 小时后出现推理延迟从 65ms 逐渐恶化到 120ms，且偶发“Failed to allocate tensor memory”错误。通过 dmesg 查看内核日志，发现存在多次 oom_kill 事件，但被杀进程是 Wi-Fi 驱动辅助进程，而非推理主进程。

关键数据采集：使用 4.2.1 节的脚本采集推理进程 24 小时的内存数据，得到以下关键指标：

• 峰值内存 (VmPeak): 412MB，出现在模型加载阶段（权重 180MB + 中间张量 232MB）
• 常驻内存 (VmRSS): 稳定在 356MB，但每 30 分钟出现一次 30-50MB 的周期性波动
• 内存带宽: 通过 perf 统计，推理期间平均带宽 1.2GB/s，峰值 2.8GB/s，接近 LPDDR4 单通道理论带宽的 70%
• 碎片化指标: 通过 mallinfo() 获取，运行 48 小时后最大连续空闲块从初始的 128MB 降至 22MB，碎片率从 0.12 升至 0.83

分析判断过程：周期性 RSS 波动与 MQTT 心跳和 Wi-Fi 扫描时间吻合，判断为系统服务内存抖动。碎片化严重是导致“Failed to allocate”的直接原因——虽然总空闲内存仍有 180MB，但最大连续块仅 22MB，无法满足某些算子需要 32MB 连续内存的需求。内存带宽接近 70% 意味着进一步优化算子计算量对延迟改善有限，应优先考虑数据布局和缓存友好性。

实际操作步骤：

1. 针对碎片化：在推理框架中启用内存池（arena allocator），将 TFLite 的 arena_size 从默认 256MB 调整为 300MB，并设置 arena_align 为 64 字节。同时将频繁创建/销毁的中间张量改为复用模式。
2. 针对 RSS 波动：将 MQTT 心跳间隔从 30 秒调整为 60 秒，并关闭 Wi-Fi 的省电扫描模式（改为仅在空闲时扫描）。
3. 针对带宽瓶颈：将输入图像从 640×480 降为 512×384（人脸检测精度损失 <1%），减少内存读取量约 36%。同时将 TFLite 的线程数从 4 降为 2，避免多线程竞争内存带宽。
4. 增加监控告警：在应用层增加内存水位线检查，当最大连续空闲块小于 32MB 时主动重启推理引擎。

结果对比：优化后，推理延迟稳定在 58-62ms（降低约 10%），RSS 波动幅度从 50MB 降至 12MB，最大连续空闲块在 72 小时运行后仍保持在 85MB 以上，碎片率稳定在 0.35 以下。设备连续运行 7 天未再出现分配失败或 OOM 事件。

风险与代价：内存池增大 44MB 导致系统可用内存从 380MB 降至 336MB，仍在 300MB 规格线以上。输入分辨率降低导致人脸检测的最小可识别像素从 24×24 变为 30×30，对 2 米外的人脸识别率下降约 2%。线程数减少使 CPU 占用率从 45% 升至 52%，但仍在散热设计范围内。

复盘经验：碎片化是嵌入式 Linux 上长期运行的 AI 推理进程最常见的隐性杀手，单纯看总内存余量会误判。内存池大小需要根据模型峰值张量需求 + 20% 余量来设定，而不是随意指定。带宽瓶颈需要结合具体硬件平台（DDR 通道数、频率）来评估，不能只看计算量。

4.4 常见误区与总结复盘

误区一：只关注峰值内存，忽略常驻内存。峰值内存决定了模型能否加载，但常驻内存决定了系统能否稳定运行。一个模型峰值 400MB、常驻 380MB 的设备，与峰值 400MB、常驻 250MB 的设备，在长时间运行时的稳定性差异巨大。前者几乎没有余量给系统服务，任何内存抖动都可能导致 OOM。

误区二：将内存带宽与网络带宽混淆。内存带宽是芯片内部的数据传输速率，网络带宽是设备间通信速率。在 Edge AI 中，内存带宽通常比网络带宽更先成为瓶颈。例如，一个 1080p 视频帧（约 6MB）从摄像头传感器到 NPU 的传输，如果内存带宽不足，即使网络带宽再高也无济于事。

误区三：忽视碎片化的累积效应。碎片化不是静态指标，而是随时间恶化的动态过程。很多开发者在测试初期（1-2 小时）未发现问题，就认为内存健康。实际上，碎片化可能需要数小时甚至数天才会暴露。建议在开发阶段进行至少 24 小时的压测，并周期性记录最大连续空闲块。

误区四：盲目使用内存池而不分析分配模式。内存池并非万能。如果推理过程中的张量大小变化剧烈（例如动态输入尺寸），固定大小的内存池会导致内部碎片增加。此时应使用分级内存池（不同大小类别）或采用伙伴系统算法。

误区五：在 MCU 上忽略栈溢出对内存指标的影响。裸机 MCU 的栈空间通常只有几 KB，递归调用或深层函数嵌套可能导致栈溢出，破坏堆内存数据，造成看似“内存泄漏”的假象。监测时除了关注堆，还应通过链接脚本中的 __stack_top 和 __stack_bottom 计算栈使用峰值。

总结复盘：内存指标是 Edge AI 系统稳定性的基石。峰值内存和常驻内存决定了“能不能跑”，内存带宽决定了“跑得快不快”，内存碎片化决定了“跑得久不久”。在实际项目中，建议建立一套标准化的内存监测流程：开发阶段使用 Valgrind Massif 分析峰值和分配热点；集成测试阶段使用 /proc 脚本 + perf 统计带宽；长期稳定性测试阶段使用 mallinfo 监控碎片化趋势。只有四个指标同时达标，才能保证 Edge AI 设备在真实场景中可靠运行。