ESP32-CAM是市面上最便宜的AI摄像头开发板之一，几十块钱就能拿到一颗带Wi-Fi的芯片加一枚OV2640摄像头。很多人买回来第一件事就是想跑人脸识别，结果发现官方例程跑起来帧率很低，或者直接内存溢出重启。问题的根源在于ESP32这颗芯片的资源实在有限：520KB的SRAM、240MHz的双核处理器、没有专门的NPU。要在这样的硬件上跑神经网络，靠的不是蛮力，而是对框架和模型做精细的裁剪。这篇文章就来拆解ESP-WHO框架的结构，看看人脸检测模型是如何被压缩到能塞进ESP32里的。
先分清两个概念：人脸检测和人脸识别
很多初学者把这两个词混着用，但在ESP-WHO的工程结构里它们是完全不同的两个任务。人脸检测解决的是"画面里有没有脸、脸在哪"的问题，输出的是边界框坐标；人脸识别解决的是"这张脸是谁"的问题，需要先把检测到的脸抠出来，再提取特征向量做比对。
两者对算力的要求差距巨大。ESP-WHO自带的MTMN检测模型是一个轻量化的多任务级联网络，参考了MTCNN的思路，用P-Net、R-Net、O-Net三级结构逐步精化候选框。这个模型量化到8位之后只需要几百KB的内存就能运行，在ESP32上帧率可以接受。而识别阶段用的MFN模型虽然也算轻量，但特征提取的计算量明显更大，且需要额外维护一个人脸特征库做余弦相似度比对，整体内存压力会上升一个档次。
如果你的应用只是"有人靠近就亮屏"或者"检测到人脸就拍照上传"，那么只跑检测就够了，识别可以放到服务器端完成。这是最常见的裁剪思路：端侧做检测，云端做识别，ESP32-CAM只承担采集和筛选的角色。
ESP-WHO框架结构解读
ESP-WHO是乐鑫官方的图像处理和AI应用框架，早期版本自带一套叫dl_lib的轻量推理库，后来逐渐迁移到ESP-DL这个独立的深度学习组件上。理解这个演进很重要，因为网上大量教程基于老版本dl_lib写的，直接照抄到新版本idf环境会编译失败。
框架的整体分层大致是这样的：最底层是esp32-cam驱动的摄像头接口，负责从OV2640或OV3660拿到原始图像数据；中间层是图像处理工具库image_util，提供格式转换、缩放、直方图均衡这些操作；最上层是各类应用示例，比如face_detection、face_recognition、motion_detection等。
#include "esp_camera.h"
#include "fb_gfx.h"
#include "human_face_detect_msr01.hpp"
// 摄像头引脚配置（AI-Thinker版ESP32-CAM）
camera_config_t config = {};
config.pin_d0 = 5;
config.pin_d1 = 18;
config.pin_d2 = 19;
config.pin_d3 = 21;
config.pin_d4 = 36;
config.pin_d5 = 39;
config.pin_d6 = 34;
config.pin_d7 = 35;
config.xclk_pin = 0;
config.pwdn_pin = 32;
config.reset_pin = -1;
config.sccb_sda = 25;
config.sccb_scl = 23;
config.pixel_format = PIXFORMAT_JPEG;
// 有PSRAM时可以开大分辨率
config.frame_size = FRAMESIZE_QVGA;
config.fb_count = 2;
config.grab_mode = CAMERA_GRAB_LATEST;
esp_camera_init(&config);
这段配置里有个容易被忽略的细节：grab_mode设置为CAMERA_GRAB_LATEST可以让驱动始终返回最新帧，避免人脸移动时处理的是延迟的旧画面。fb_count设为2是为双缓冲，处理当前帧的同时采集下一帧，能明显提升流畅度。
另外要注意PSRAM的开启。ESP32-CAM板载4MB的PSRAM，必须在menuconfig里启用SPIRAM支持，否则QVGA以上的分辨率会直接分配失败。人脸检测前需要把JPEG解码成RGB888或灰度图，这个解码缓冲区就是放在PSRAM里的。
模型裁剪与量化的具体手段
ESP-WHO新版本中的人脸检测换成了MSRMNI模型，它把传统多级联结构合并成单阶段网络，用深度可分离卷积替代标准卷积，参数量进一步下降。官方已经提供了量化好的模型文件，直接include对应的头文件就能用：
#include "human_face_detect_msr01.hpp"
extern const uint8_t human_face_detect_msr01_ov_tflite[] asm(
"_binary_human_face_detect_msr01_ov_tflite_start");
HumanFaceDetectMSR01 detector(0.3F, 0.3F, 10, 0.2F);
camera_fb_t *fb = esp_camera_fb_get();
// 检测结果包含边界框和关键点
std::list<dl::detect::result_t> results = detector.infer((uint16_t *)fb->buf);
if (!results.empty()) {
printf("检测到人脸，共 %d 张\n", results.size());
}
esp_camera_fb_return(fb);
量化是所有裁剪手段里收益最大的一项。原始的浮点模型权重是32位，量化到8位整型后体积直接缩到四分之一，而且ESP32的整数运算远快于软浮点模拟，速度提升往往比体积缩小更可观。代价是精度损失，通常在1%到3%之间，对门禁场景来说基本可以接受。
除了量化，还有几个方向可以继续压。第一是降低输入分辨率，模型默认输入是96x96，如果你把它改成80x80重新训练，计算量大约下降三成，但小脸的检出率会受影响，需要根据实际摄像头画幅里人脸的平均大小来权衡。第二是裁剪通道数，把某些卷积层的输出通道减半，这在迁移学习微调时很容易操作。第三是减少级联阶段，如果应用场景人脸占比普遍较大，可以砍掉小尺度金字塔那一层，代价是远距离人脸漏检。
帧率优化与实战踩坑
模型裁剪完只是第一步，实际跑起来还有不少工程问题。第一个坑是WDT超时复位。ESP32默认的看门狗在FreeRTOS空闲任务里喂狗，如果检测循环占满CPU不释放，会触发中断看门狗。解决办法是给推理任务绑定到单独的核心，比如用xTaskCreatePinnedToCore把检测放在核心0，Wi-Fi协议栈放核心1，两边互不干扰。
第二个坑是分辨率与帧率的平衡。QVGA是320x240，配合96x96的模型输入需要缩放，缩放本身也消耗CPU。如果只是做检测触发，直接把frame_size设成更低档位，让传感器端就输出小图，比采集大图再软件缩小要快得多。实测AI-Thinker的ESP32-CAM跑MSRMNI量化模型，QVGA输入下大约能做到每秒5到8帧的检测速度，降分辨率后还能再提一截。
第三个坑是光照。OV2640在低照度下噪点很多，直接影响检测召回率。可以在image_util里先做直方图均衡，或者直接选带红外补光的摄像头模组。做门禁项目时强烈建议加个补光灯，这比在算法层面硬扛性价比高得多。
最后给一个选型建议：如果项目允许换板子，ESP32-S3是更好的选择，它有向量指令扩展，跑ESP-DL的量化模型速度比普通ESP32快数倍，而且S3的N16R8版本带16MB Flash和8MB PSRAM，可以跑更大的人脸识别模型而不必裁剪得那么激进。ESP32-CAM适合验证原型和控制成本，量产或对响应速度有要求的项目，升级到S3平台会更省心。