最近在 STM32N6 上做一个人脸关键点 pipeline遇到一个特别典型的改造需求现有流程里 BlazeFace 只负责检测人脸框和做关键点定位但业务方又提了新玩法——要能区分“戴了口罩的人脸”和“没戴口罩的人脸”甚至后面可能还要加“戴眼镜”“戴帽子”这类属性类别。这实际上就是要把 BlazeFace 从单类别检测器扩展成多类别检测器同时保住原有的 Face Landmark 回归分支最终还得跑进 STM32N6 的板子里在整个 pipeline 里不拖帧率。这篇文章不聊虚的就围绕这条改造路线把我在数据准备、网络修改、量化部署、板端集成时实际踩过的坑和验证过的做法整理出来。适合正在做嵌入式人脸识别、MCUNPU 端侧视觉的工程师看也适合想把手头单类别检测模型扩成多类别但不确定从哪下手的同学。文章里的思路不绑定特定框架PyTorch、Keras 都能用。1. 先想清楚这个改造的本质是把“检测器”变成“检测分类器”1.1 先复盘一下现有 pipeline 的组成我手里这套 STM32N6 Face Landmark Pipeline 的核心链路很标准图像从摄像头进来做预处理缩放、归一化、通道调整。送入 BlazeFace 检测人脸框同时回归一组人脸关键点。根据人脸框做裁剪或对齐再进后续关键点精修或识别模块。BlazeFace 本质上是一个 SSD 思路的单阶段检测器骨干网络用 Depthwise Separable Convolution 和 BlazeBlock 做轻量化设计输出头同时出三样东西anchor 对应的目标类别得分、bounding box 回归量、关键点坐标回归量。在默认实现里类别得分那一路基本上只有一个目标类别“face”所以分类头的输出维度是 1或者背景人脸2。而扩展类别的本质就是把分类头的输出维度从 1 改成 N然后告诉网络“你现在要认出的不只是人脸而是戴了口罩的人脸、没戴口罩的人脸、戴眼镜的人脸……”这些类别之间可以有交集但在当前项目里我们按互斥类别来处理。这里有个容易搞混的点所谓“扩展额外类别”不是让 BlazeFace 去识别“人脸框之外的其他物体”而是在已有的 人脸框 基础上细化“这到底是一张什么状态的人脸”。所以 anchor 生成方式、box 回归分支、landmark 分支完全不用动真正动的是 class head。1.2 为什么这一类改造放在 STM32N6 上做有意义STM32N6 和传统跑 Linux 的边缘盒子不同它是一颗 MCUM55 内核自带 NPU 加速器。好处是启动快、成本低、功耗低、没有操作系统调度开销适合做闸机、门禁、低功耗视觉传感器之类产品。但坏处也明显内存和 Flash 有限NPU 对算子的支持有限模型转换过程中稍不注意某个算子不支持就会被拉到 CPU 上跑帧率立刻崩。所以模型扩展类别后能不能在 NPU 上高效推理是比“精度涨一点”更优先要考虑的问题。也正是因为 STM32N6 的 NPU 算力相对有限BlazeFace 这种参数只有几十万到一两百万的轻量网络才有机会跑实时。如果你拿 ResNet50 之类去做多人脸检测数据量还没吃进去内存就先报警了。1.3 改造前先评估的三件事动手改网络之前建议先回答三个问题否则后面会陷入反复返工类别之间是互斥还是可有交集比如“戴口罩”和“戴眼镜”完全可以同时存在但 SSD 的 softmax 分类头默认是互斥的如果你要支持多属性并存得改成 multi-label 训练或者为每个属性单独接一组 sigmoid 输出。新增类别是否需要对应的关键点语义比如戴口罩的人脸下巴区域的关键点其实是不准确的那么 landmark 分支对这部分样本需要特殊处理要么在训练时降低这部分关键点的 loss 权重要么标注时就把不可见点忽略掉。板端是否需要实时切换类别白名单如果只是做固定场景下的口罩检测类别固定就行如果需要动态加载不同任务的模型就要考虑 Flash 布局和 NPU 上下文切换。我这次的项目里业务方一开始只说要区分“face”和“masked face”我按互斥类别做后来又要加“sunglasses face”好在分类头维度是一次性扩好的改起来不费劲。这就是为什么我建议你哪怕现在只扩一个类别也直接按未来 3~5 类的容量来设计 head省得后面反复重新训练。2. 数据准备类别扩展最花时间的往往不是代码而是标注2.1 类别标签怎么定直接决定数据采集成本别急着找训练脚本先把类别规范定清楚。以口罩为例我最终定为三类类别ID类别名语义0background背景非目标1face无遮挡常规人脸关键点完整可见2masked_face面部下半部分被口罩遮挡关键点最多只能看到眼部区域这里没有加“全家福”“半遮挡”之类模糊类别因为模糊类别会让数据标注人员崩溃也让模型学得稀里糊涂。遮挡程度如果不一致宁可归为 face 然后靠关键点分支自己处理也不要单独学一个不伦不类的类。另外如果你确实要做多属性共存比如“戴眼镜的口罩脸”个人建议别急着加联合标签第一版先把“口罩”和“眼镜”拆成两条任务或者直接让分类头走多个二分类分支否则数据量和标注成本会成倍增长。2.2 数据来源与标注规范数据来源我的优先级排序是自有业务场景拍摄。最贴合最终部署环境尤其是摄像头安装角度、人员动线、光照特点。公开人脸数据集做迁移。比如一些带口罩标注的人脸检测数据集或者通用人脸识别数据集里筛一份出来。爬虫或众包补充。适合做长尾场景但要注意隐私合规人脸数据不是闹着玩的。标注格式我建议直接用 Pascal VOC 或者 COCO 的格式存下来因为你后面转 TFRecord 或 YOLO 格式都方便网上工具也多。每个目标框需要标class_id、xmin、ymin、xmax、ymax。如果你还想顺带训练 landmark那就得把 6 个关键点坐标也标出来左眼、右眼、鼻子、嘴左角、嘴右角、下颌或者你自己的业务点位。这块工作量很大我实际经验是一个新类别最少要准备 5000 到 10000 张带目标样本其中“正样本目标框”数量最好不低于 2 万否则后面类别不均衡问题会很麻烦。2.3 数据增强别让小样本类别的增强策略太粗暴BlazeFace 是轻量模型数据增强很重要尤其是新增类别样本少的时候。我这里用过并且有效的增强组合几何增强随机旋转 ±20°、随机缩放 0.8~1.2、随机平移、水平翻转。注意翻转后如果有文字类属性要处理人脸场景基本不受影响。光照和颜色增强亮度随机抖动、对比度调整、HSV 扰动、高斯噪声。因为很多嵌入式摄像头画质一般光照增强必须给足。遮挡模拟对 face 类样本随机画一些黑色块来模拟局部遮挡可以帮助模型减少对局部特征的过度依赖。Mosaic 增强把多张图拼接成一张对提升小目标检测效果很明显。不过 BlazeFace 输入分辨率只有 128x128 或 256x256拼接后目标更小要小心别把目标拼得看不清。一个特别容易踩的坑新增类别的样本往往拍摄场景单一比如只在室内光源下模型一拿到户外逆光的画面就露馅。所以我建议对新增类别做半离线增强比如把一部分样本背景换掉、加了随机色块、做了强光照变换相当于用离线方式模拟场景多样性。2.4 类别不均衡怎么处理新增类别刚起步时样本量肯定远少于已有的 face 类。我试过两种有效做法第一在线采样时按类别做 loss 加权或者 hard negative mining。具体来说背景框数量极大如果全部参与反向传播模型会被“全是背景”带偏。BlazeFace 本身有 anchor matching 策略默认会生成很多负样本所以我在训练时专门做了 hard negative mining只取分类 loss 最高的那部分负样本参与训练负正比控制在 3:1 左右。第二对小众类别用 Focal Loss。如果你把分类头改成多类别输出直接用 softmax cross-entropy小样本类别容易学不动。Focal Loss 的 gamma 我一般取 1.5~2.0alpha 按类别样本比例的倒数来配实测对小类别召回率提升比较明显。3. 网络结构修改与训练策略不是所有层都需要重训3.1 BlazeFace 的结构回顾以及到底改哪里BlazeFace 的网络结构大致可以分成三段输入层接受 128x128x3 或 256x256x3 的输入。Backbone由多个 BlazeBlock 堆叠提取特征。检测头在多个尺度的特征图上做预测每个 anchor 输出几类信息。在标准实现里检测头通常长这样box_heads每个 anchor 输出 4 个 box 坐标偏移值。class_heads每个 anchor 输出类别得分。landmark_heads每个 anchor 输出 6~16 个关键点坐标具体看你用的版本。所以扩展类别的核心动作是把 class_heads 的输出维度从 [num_anchors, 1] 改成 [num_anchors, num_classes]。其他 head 不动。有一种更省事的做法是直接在 class_head 旁边加一个很小的属性分类分支比如把原来的检测头先不碰额外加一个“face_attributes”分支专门输出是否戴口罩、是否戴眼镜。这种设计的好处是不影响原始 BlazeFace 的检测能力坏处是推理多了一次额外计算而且 attribute 分支的特征可能没有和检测框对齐。我最终选择的是直接扩展 class_head理由很简单部署在 STM32N6 上模型输入输出越简单越好多一个输出头就多一次后处理逻辑板端代码也更复杂。3.2 训练策略全量微调还是冻结 backbone改完网络结构后第一个问题就是到底要不要冻结 backbone 只训练新 head我的经验分阶段第一阶段冻结 backbone只训练新初始化的 class head跑 20~30 个 epoch。目的是让新分类头先学会用 backbone 提的特征做判断避免 backbone 刚初始化时梯度抖动影响全局。第二阶段解冻全部网络用较低学习率微调全模型跑 50~100 个 epoch。这个阶段模型会重新适配新增类别同时微调检测框和关键点回归。学习率方面第一阶段用 1e-3 量级第二阶段降为 1e-4 到 5e-5。优化器选择上AdamW 比较稳不要一上来就用很高学习率的 SGD否则新增类别几乎学不动。输入尺寸我用的 128x128x3和原版 BlazeFace 保持一致。如果你希望小目标检测更好可以上 256x256但推理时间会明显增加STM32N6 帧率大概率吃不住先想清楚指标再决定。3.3 关键点分支在新类别样本上的处理人脸关键点检测和新增类别之间的关系应该是“互不拖累”。我处理的方式对 masked_face 样本把下半脸那几个关键点的 loss 权重直接置为 0也就是让模型不关注这些不可见点。对无遮挡 face 样本正常计算全部关键点 loss。具体实现时可以给每个关键点配置一个 visibility mask。标注数据里每个关键点除了坐标外再标一个 0/1 可见性标签。loss 计算时只对可见点计算距离损失不可见点跳过。这样处理之后模型在训练阶段不需要强行“猜”口罩下面的嘴在哪关键点分支的精度不会再被新类别拖累。3.4 量化感知训练从第一天就要考虑STM32N6 的 NPU 对高精度浮点支持的效率不如 INT8 量化所以模型最终上板基本都要走 INT8 量化。很多人是先训练 FP32 模型再一口气转量化结果精度掉得惨不忍睹。我的建议是训练一开始就考虑量化问题。做法是导入量化感知训练QAT。具体操作是在训练流程中模拟 8-bit 量化带来的精度损失比如在 activation 和 weight 后插入 fake quantize 节点这样模型在训练时就学会适应量化噪声转换后精度损失能控制在 1%~3% 以内。如果训练框架不支持 QAT退而求其次的做法是先正常训练一个高精度 FP32 模型转换时准备一个覆盖新增类别各种光照、角度、遮挡场景的校准数据集大概几百到一千张图统计每层激活值范围再用 PTQ 做 INT8 量化。我实际跑了多个模型结论是QAT 模型转 INT8 之后分类 mAP 平均损失大概在 1% 左右PTQ 模型平均损失可能在 3%~5%而且小类别更容易翻车。如果你要上产线强烈建议上 QAT。4. STM32N6 部署与 pipeline 集成细节模型导入只是刚开始4.1 模型导出格式与转换链从我常用的路线给你一个可复现的转换链PyTorch 或 Keras 训练好模型后先导出 ONNX。用 ONNX 转 TFLite或者直接用 ST Edge AI Core 导入 ONNX。做 INT8 量化生成量化模型。在 STM32CubeMX 里集成 ST Edge AI Core也就是以前的 X-CUBE-AI生成为 STM32N6 优化的 C 代码工程。这里有个很容易踩的坑ONNX 里有很多算子默认不支持 NPU 加速比如某些自定义的 Resize 模式、动态 shape、一些高级激活函数。如果 NPU 不支持的算子太多ST Edge AI Core 会自动把这些层放到 CPU 上执行结果就是模型占用内存不高但帧率根本提不上来。我的做法是导出 ONNX 之前先手动检查网络里有没有这些“高危算子”Resize / Upsample能不用就不用或者改成 nearest 模式。复杂的激活函数比如 SiLU / GELUSTM32N6 的 NPU 不一定支持最好换成 ReLU / ReLU6。Split / Concat 如果 tensor 维度变化太多可能被拆到 CPU能合并的层尽量合并。动态 shape 必须全部去掉模型输入输出必须是静态尺寸。你可以在 PC 端先用 ST Edge AI Core 的基准测试工具跑一遍看看每层被分配到 NPU 还是 CPU。哪层落到 CPU 了优先把那层优化掉这会比整天调训练参数更影响最终效果。4.2 板端 pipeline 的内存与预处理设计STM32N6 这类 MCU内存管理不是“够用就行”而是“要显式规划”。我的经验是分四块输入图像缓冲区建议放在 AXI SRAM方便 NPU 和摄像头 DMA 直接访问。模型权重区通常放在外部 Flash加载时按需换入内部 RAM或者直接内存映射。中间激活值区NPU 推理时需要一块很大的临时 buffer这块要预留充足否则编译时可能会因为内存不足直接报错。后处理结果区存放检测框、关键点、类别得分。预处理也要格外注意。BlazeFace 在训练时一般做了归一化比如值域缩放到 [-1, 1] 或 [0, 1]。到了板端摄像头输出的通常是 RGB888 或者 YUV422你需要先做格式转换再缩放同时把像素值缩放到和训练一致的范围内。我之前犯过一个低级错误PC 端用 ImageNet 的 mean/std 做了归一化板端却忘了做同样的归一化导致模型在板端准确率崩掉。后来我把归一化操作融合到输入图像的量化参数里也就是在转换时把 scale/zero_point 调整好让板端只要做简单的像素格式转换和缩放归一化由 NPU 的输入算子自己搞定避免在 MCU 上做浮点除法。4.3 输出后处理NMS、类别过滤、关键点坐标换算模型跑完板端拿到的是一堆 anchor 的原始输出需要做后处理。我在板端实现的后处理流程是读取分类得分按 score_threshold一般取 0.5~0.6过滤低分 anchor。对保留下来的 box 做解码转换为图像坐标。做类别维度的 NMS。注意 NMS 要按类别分别做否则不同类别之间可能互相误抑制。输出最终的人脸框、类别 ID、类别得分、关键点坐标。之后才进入你原有的 Face Landmark 精修流程。也就是说pipeline 的“前一半”是目标检测和分类“后一半”才是针对检测框的 landmark 定位。如果帧率有压力我建议把 NMS 的 IoU 阈值适当调大一点默认 0.5 可以调到 0.6减少候选框数量能省一点 CPU 时间。另外NMS 在 MCU 上建议用平方距离代替开方 IoU 计算能降低不少浮点开销。4.4 实际部署性能数据参考这里说一个我在板上的实测感受以 128x128 输入、单类别扩展成 3 类背景、人脸、口罩人脸STM32N6 上用 NPU 跑一次推理耗时大约在十几到几十毫秒量级具体数值和模型算子优化程度强相关。如果后处理没有做额外的手写优化整条 pipeline 大致能跑 10~30 FPS。如果你把输入提升到 256x256推理耗时可能会翻倍这个账要提前算好。项目上一般建议先把“检测分类”跑通一个闭环再考虑上关键点精修因为关键点精修往往还包含一个小的 CNN它同样要吃 NPU/CPU 时间。5. 实操中最容易翻车的五个问题5.1 新增类别总是被误判为原有类别这个几乎必然出现尤其是新增类别样本不够的时候。解决办法除了加数据我建议把类别阈值单独调。做法是训练完成后在验证集上统计每个类别的 PR 曲线给“容易混”的类别单独设一个更高的置信度阈值。比如 face 类用 0.5masked_face 类用 0.65这样可以减少误报。5.2 量化后某一类精度断崖下降这是 PTQ 的经典问题。我的排查路径是先确认是不是校准数据集没有覆盖这一类。校准集里要有大量该类别的样本否则量化统计的激活范围就不对。检查网络里有没有对数值敏感的层比如大通道数的 depthwise conv这类层量化误差容易被放大可以考虑在转换工具中对该层做“per-channel 量化”或“保持浮点”。如果无法通过调校准集解决就得回炉用 QAT 重训。5.3 板端推理时间突然拉长先用 ST Edge AI Core 的 profiling 工具看各层耗时。如果某些算子落到了 CPU推理时间一定会暴涨。常见触发点是 Resize 和 Concat 结构堆得太多。另一个隐藏坑是内存带宽限制如果中间 buffer 放在内存带宽不够的区域NPU 会频繁等待数据搬移。我最后把 buffer 尽量放在 AXISRAM同时注意对齐带宽改善比较明显。5.4 关键点在口罩人脸样本上飘前面说过靠 visibility mask 解决。但如果你的模型是从公开预训练权重迁移过来的而预训练模型从来没见过口罩样本那么即便设了 maskbackbone 的特征也未必能适应遮挡区域。建议在数据增强阶段给 face 样本的嘴巴区域叠加一个黑块模拟口罩然后这部分的 landmark loss 同样做 mask效果很好。5.5 模型在 STM32N6 上能跑但一接摄像头就花屏或者掉帧这种情况多半是 DMA 中断和 NPU 推理的并行处理没做好。建议摄像头采集用双 buffer 切换当前帧在 NPU 推理时下一帧通过 DMA 持续写入另一块 buffer这样帧率才能上去。不要等整帧推理完再开始采集下一帧。6. 部署后性能调优的一点心得最后给准备动手的同学一个建议扩类别的训练工作不要想着“一次训完直接上板”。我通常先训练一个小模型只验证分类头能不能在 NPU 上跑到低延迟再回来扩数据、调参。这种“板端验证先行”的策略能帮你节省大量时间。另外在板端调试阶段建议打印每一帧的检测结果包括类别、得分、box 坐标、关键点坐标并和上位机跑同一张图的结果做对比。如果两边数值差异较大优先排查预处理归一化是否一致其次是量化精度损失。这个项目后续还可以继续扩展的方向一是给不同类别定制不同的关键点返回策略比如口罩人脸只返回眼睛区域关键点直接减少无效计算二是在 STM32N6 上叠加一个轻量分类器对检测框区域做二次确认来进一步提升属性类别的准确率。总之BlazeFace 这套网络结构本身很适合做嵌入式多类别人脸检测关键是每个环节的数据和部署细节都要抠到位。
最近在 STM32N6 上做一个人脸关键点 pipeline遇到一个特别典型的改造需求现有流程里 BlazeFace 只负责检测人脸框和做关键点定位但业务方又提了新玩法——要能区分“戴了口罩的人脸”和“没戴口罩的人脸”甚至后面可能还要加“戴眼镜”“戴帽子”这类属性类别。这实际上就是要把 BlazeFace 从单类别检测器扩展成多类别检测器同时保住原有的 Face Landmark 回归分支最终还得跑进 STM32N6 的板子里在整个 pipeline 里不拖帧率。这篇文章不聊虚的就围绕这条改造路线把我在数据准备、网络修改、量化部署、板端集成时实际踩过的坑和验证过的做法整理出来。适合正在做嵌入式人脸识别、MCUNPU 端侧视觉的工程师看也适合想把手头单类别检测模型扩成多类别但不确定从哪下手的同学。文章里的思路不绑定特定框架PyTorch、Keras 都能用。1. 先想清楚这个改造的本质是把“检测器”变成“检测分类器”1.1 先复盘一下现有 pipeline 的组成我手里这套 STM32N6 Face Landmark Pipeline 的核心链路很标准图像从摄像头进来做预处理缩放、归一化、通道调整。送入 BlazeFace 检测人脸框同时回归一组人脸关键点。根据人脸框做裁剪或对齐再进后续关键点精修或识别模块。BlazeFace 本质上是一个 SSD 思路的单阶段检测器骨干网络用 Depthwise Separable Convolution 和 BlazeBlock 做轻量化设计输出头同时出三样东西anchor 对应的目标类别得分、bounding box 回归量、关键点坐标回归量。在默认实现里类别得分那一路基本上只有一个目标类别“face”所以分类头的输出维度是 1或者背景人脸2。而扩展类别的本质就是把分类头的输出维度从 1 改成 N然后告诉网络“你现在要认出的不只是人脸而是戴了口罩的人脸、没戴口罩的人脸、戴眼镜的人脸……”这些类别之间可以有交集但在当前项目里我们按互斥类别来处理。这里有个容易搞混的点所谓“扩展额外类别”不是让 BlazeFace 去识别“人脸框之外的其他物体”而是在已有的 人脸框 基础上细化“这到底是一张什么状态的人脸”。所以 anchor 生成方式、box 回归分支、landmark 分支完全不用动真正动的是 class head。1.2 为什么这一类改造放在 STM32N6 上做有意义STM32N6 和传统跑 Linux 的边缘盒子不同它是一颗 MCUM55 内核自带 NPU 加速器。好处是启动快、成本低、功耗低、没有操作系统调度开销适合做闸机、门禁、低功耗视觉传感器之类产品。但坏处也明显内存和 Flash 有限NPU 对算子的支持有限模型转换过程中稍不注意某个算子不支持就会被拉到 CPU 上跑帧率立刻崩。所以模型扩展类别后能不能在 NPU 上高效推理是比“精度涨一点”更优先要考虑的问题。也正是因为 STM32N6 的 NPU 算力相对有限BlazeFace 这种参数只有几十万到一两百万的轻量网络才有机会跑实时。如果你拿 ResNet50 之类去做多人脸检测数据量还没吃进去内存就先报警了。1.3 改造前先评估的三件事动手改网络之前建议先回答三个问题否则后面会陷入反复返工类别之间是互斥还是可有交集比如“戴口罩”和“戴眼镜”完全可以同时存在但 SSD 的 softmax 分类头默认是互斥的如果你要支持多属性并存得改成 multi-label 训练或者为每个属性单独接一组 sigmoid 输出。新增类别是否需要对应的关键点语义比如戴口罩的人脸下巴区域的关键点其实是不准确的那么 landmark 分支对这部分样本需要特殊处理要么在训练时降低这部分关键点的 loss 权重要么标注时就把不可见点忽略掉。板端是否需要实时切换类别白名单如果只是做固定场景下的口罩检测类别固定就行如果需要动态加载不同任务的模型就要考虑 Flash 布局和 NPU 上下文切换。我这次的项目里业务方一开始只说要区分“face”和“masked face”我按互斥类别做后来又要加“sunglasses face”好在分类头维度是一次性扩好的改起来不费劲。这就是为什么我建议你哪怕现在只扩一个类别也直接按未来 3~5 类的容量来设计 head省得后面反复重新训练。2. 数据准备类别扩展最花时间的往往不是代码而是标注2.1 类别标签怎么定直接决定数据采集成本别急着找训练脚本先把类别规范定清楚。以口罩为例我最终定为三类类别ID类别名语义0background背景非目标1face无遮挡常规人脸关键点完整可见2masked_face面部下半部分被口罩遮挡关键点最多只能看到眼部区域这里没有加“全家福”“半遮挡”之类模糊类别因为模糊类别会让数据标注人员崩溃也让模型学得稀里糊涂。遮挡程度如果不一致宁可归为 face 然后靠关键点分支自己处理也不要单独学一个不伦不类的类。另外如果你确实要做多属性共存比如“戴眼镜的口罩脸”个人建议别急着加联合标签第一版先把“口罩”和“眼镜”拆成两条任务或者直接让分类头走多个二分类分支否则数据量和标注成本会成倍增长。2.2 数据来源与标注规范数据来源我的优先级排序是自有业务场景拍摄。最贴合最终部署环境尤其是摄像头安装角度、人员动线、光照特点。公开人脸数据集做迁移。比如一些带口罩标注的人脸检测数据集或者通用人脸识别数据集里筛一份出来。爬虫或众包补充。适合做长尾场景但要注意隐私合规人脸数据不是闹着玩的。标注格式我建议直接用 Pascal VOC 或者 COCO 的格式存下来因为你后面转 TFRecord 或 YOLO 格式都方便网上工具也多。每个目标框需要标class_id、xmin、ymin、xmax、ymax。如果你还想顺带训练 landmark那就得把 6 个关键点坐标也标出来左眼、右眼、鼻子、嘴左角、嘴右角、下颌或者你自己的业务点位。这块工作量很大我实际经验是一个新类别最少要准备 5000 到 10000 张带目标样本其中“正样本目标框”数量最好不低于 2 万否则后面类别不均衡问题会很麻烦。2.3 数据增强别让小样本类别的增强策略太粗暴BlazeFace 是轻量模型数据增强很重要尤其是新增类别样本少的时候。我这里用过并且有效的增强组合几何增强随机旋转 ±20°、随机缩放 0.8~1.2、随机平移、水平翻转。注意翻转后如果有文字类属性要处理人脸场景基本不受影响。光照和颜色增强亮度随机抖动、对比度调整、HSV 扰动、高斯噪声。因为很多嵌入式摄像头画质一般光照增强必须给足。遮挡模拟对 face 类样本随机画一些黑色块来模拟局部遮挡可以帮助模型减少对局部特征的过度依赖。Mosaic 增强把多张图拼接成一张对提升小目标检测效果很明显。不过 BlazeFace 输入分辨率只有 128x128 或 256x256拼接后目标更小要小心别把目标拼得看不清。一个特别容易踩的坑新增类别的样本往往拍摄场景单一比如只在室内光源下模型一拿到户外逆光的画面就露馅。所以我建议对新增类别做半离线增强比如把一部分样本背景换掉、加了随机色块、做了强光照变换相当于用离线方式模拟场景多样性。2.4 类别不均衡怎么处理新增类别刚起步时样本量肯定远少于已有的 face 类。我试过两种有效做法第一在线采样时按类别做 loss 加权或者 hard negative mining。具体来说背景框数量极大如果全部参与反向传播模型会被“全是背景”带偏。BlazeFace 本身有 anchor matching 策略默认会生成很多负样本所以我在训练时专门做了 hard negative mining只取分类 loss 最高的那部分负样本参与训练负正比控制在 3:1 左右。第二对小众类别用 Focal Loss。如果你把分类头改成多类别输出直接用 softmax cross-entropy小样本类别容易学不动。Focal Loss 的 gamma 我一般取 1.5~2.0alpha 按类别样本比例的倒数来配实测对小类别召回率提升比较明显。3. 网络结构修改与训练策略不是所有层都需要重训3.1 BlazeFace 的结构回顾以及到底改哪里BlazeFace 的网络结构大致可以分成三段输入层接受 128x128x3 或 256x256x3 的输入。Backbone由多个 BlazeBlock 堆叠提取特征。检测头在多个尺度的特征图上做预测每个 anchor 输出几类信息。在标准实现里检测头通常长这样box_heads每个 anchor 输出 4 个 box 坐标偏移值。class_heads每个 anchor 输出类别得分。landmark_heads每个 anchor 输出 6~16 个关键点坐标具体看你用的版本。所以扩展类别的核心动作是把 class_heads 的输出维度从 [num_anchors, 1] 改成 [num_anchors, num_classes]。其他 head 不动。有一种更省事的做法是直接在 class_head 旁边加一个很小的属性分类分支比如把原来的检测头先不碰额外加一个“face_attributes”分支专门输出是否戴口罩、是否戴眼镜。这种设计的好处是不影响原始 BlazeFace 的检测能力坏处是推理多了一次额外计算而且 attribute 分支的特征可能没有和检测框对齐。我最终选择的是直接扩展 class_head理由很简单部署在 STM32N6 上模型输入输出越简单越好多一个输出头就多一次后处理逻辑板端代码也更复杂。3.2 训练策略全量微调还是冻结 backbone改完网络结构后第一个问题就是到底要不要冻结 backbone 只训练新 head我的经验分阶段第一阶段冻结 backbone只训练新初始化的 class head跑 20~30 个 epoch。目的是让新分类头先学会用 backbone 提的特征做判断避免 backbone 刚初始化时梯度抖动影响全局。第二阶段解冻全部网络用较低学习率微调全模型跑 50~100 个 epoch。这个阶段模型会重新适配新增类别同时微调检测框和关键点回归。学习率方面第一阶段用 1e-3 量级第二阶段降为 1e-4 到 5e-5。优化器选择上AdamW 比较稳不要一上来就用很高学习率的 SGD否则新增类别几乎学不动。输入尺寸我用的 128x128x3和原版 BlazeFace 保持一致。如果你希望小目标检测更好可以上 256x256但推理时间会明显增加STM32N6 帧率大概率吃不住先想清楚指标再决定。3.3 关键点分支在新类别样本上的处理人脸关键点检测和新增类别之间的关系应该是“互不拖累”。我处理的方式对 masked_face 样本把下半脸那几个关键点的 loss 权重直接置为 0也就是让模型不关注这些不可见点。对无遮挡 face 样本正常计算全部关键点 loss。具体实现时可以给每个关键点配置一个 visibility mask。标注数据里每个关键点除了坐标外再标一个 0/1 可见性标签。loss 计算时只对可见点计算距离损失不可见点跳过。这样处理之后模型在训练阶段不需要强行“猜”口罩下面的嘴在哪关键点分支的精度不会再被新类别拖累。3.4 量化感知训练从第一天就要考虑STM32N6 的 NPU 对高精度浮点支持的效率不如 INT8 量化所以模型最终上板基本都要走 INT8 量化。很多人是先训练 FP32 模型再一口气转量化结果精度掉得惨不忍睹。我的建议是训练一开始就考虑量化问题。做法是导入量化感知训练QAT。具体操作是在训练流程中模拟 8-bit 量化带来的精度损失比如在 activation 和 weight 后插入 fake quantize 节点这样模型在训练时就学会适应量化噪声转换后精度损失能控制在 1%~3% 以内。如果训练框架不支持 QAT退而求其次的做法是先正常训练一个高精度 FP32 模型转换时准备一个覆盖新增类别各种光照、角度、遮挡场景的校准数据集大概几百到一千张图统计每层激活值范围再用 PTQ 做 INT8 量化。我实际跑了多个模型结论是QAT 模型转 INT8 之后分类 mAP 平均损失大概在 1% 左右PTQ 模型平均损失可能在 3%~5%而且小类别更容易翻车。如果你要上产线强烈建议上 QAT。4. STM32N6 部署与 pipeline 集成细节模型导入只是刚开始4.1 模型导出格式与转换链从我常用的路线给你一个可复现的转换链PyTorch 或 Keras 训练好模型后先导出 ONNX。用 ONNX 转 TFLite或者直接用 ST Edge AI Core 导入 ONNX。做 INT8 量化生成量化模型。在 STM32CubeMX 里集成 ST Edge AI Core也就是以前的 X-CUBE-AI生成为 STM32N6 优化的 C 代码工程。这里有个很容易踩的坑ONNX 里有很多算子默认不支持 NPU 加速比如某些自定义的 Resize 模式、动态 shape、一些高级激活函数。如果 NPU 不支持的算子太多ST Edge AI Core 会自动把这些层放到 CPU 上执行结果就是模型占用内存不高但帧率根本提不上来。我的做法是导出 ONNX 之前先手动检查网络里有没有这些“高危算子”Resize / Upsample能不用就不用或者改成 nearest 模式。复杂的激活函数比如 SiLU / GELUSTM32N6 的 NPU 不一定支持最好换成 ReLU / ReLU6。Split / Concat 如果 tensor 维度变化太多可能被拆到 CPU能合并的层尽量合并。动态 shape 必须全部去掉模型输入输出必须是静态尺寸。你可以在 PC 端先用 ST Edge AI Core 的基准测试工具跑一遍看看每层被分配到 NPU 还是 CPU。哪层落到 CPU 了优先把那层优化掉这会比整天调训练参数更影响最终效果。4.2 板端 pipeline 的内存与预处理设计STM32N6 这类 MCU内存管理不是“够用就行”而是“要显式规划”。我的经验是分四块输入图像缓冲区建议放在 AXI SRAM方便 NPU 和摄像头 DMA 直接访问。模型权重区通常放在外部 Flash加载时按需换入内部 RAM或者直接内存映射。中间激活值区NPU 推理时需要一块很大的临时 buffer这块要预留充足否则编译时可能会因为内存不足直接报错。后处理结果区存放检测框、关键点、类别得分。预处理也要格外注意。BlazeFace 在训练时一般做了归一化比如值域缩放到 [-1, 1] 或 [0, 1]。到了板端摄像头输出的通常是 RGB888 或者 YUV422你需要先做格式转换再缩放同时把像素值缩放到和训练一致的范围内。我之前犯过一个低级错误PC 端用 ImageNet 的 mean/std 做了归一化板端却忘了做同样的归一化导致模型在板端准确率崩掉。后来我把归一化操作融合到输入图像的量化参数里也就是在转换时把 scale/zero_point 调整好让板端只要做简单的像素格式转换和缩放归一化由 NPU 的输入算子自己搞定避免在 MCU 上做浮点除法。4.3 输出后处理NMS、类别过滤、关键点坐标换算模型跑完板端拿到的是一堆 anchor 的原始输出需要做后处理。我在板端实现的后处理流程是读取分类得分按 score_threshold一般取 0.5~0.6过滤低分 anchor。对保留下来的 box 做解码转换为图像坐标。做类别维度的 NMS。注意 NMS 要按类别分别做否则不同类别之间可能互相误抑制。输出最终的人脸框、类别 ID、类别得分、关键点坐标。之后才进入你原有的 Face Landmark 精修流程。也就是说pipeline 的“前一半”是目标检测和分类“后一半”才是针对检测框的 landmark 定位。如果帧率有压力我建议把 NMS 的 IoU 阈值适当调大一点默认 0.5 可以调到 0.6减少候选框数量能省一点 CPU 时间。另外NMS 在 MCU 上建议用平方距离代替开方 IoU 计算能降低不少浮点开销。4.4 实际部署性能数据参考这里说一个我在板上的实测感受以 128x128 输入、单类别扩展成 3 类背景、人脸、口罩人脸STM32N6 上用 NPU 跑一次推理耗时大约在十几到几十毫秒量级具体数值和模型算子优化程度强相关。如果后处理没有做额外的手写优化整条 pipeline 大致能跑 10~30 FPS。如果你把输入提升到 256x256推理耗时可能会翻倍这个账要提前算好。项目上一般建议先把“检测分类”跑通一个闭环再考虑上关键点精修因为关键点精修往往还包含一个小的 CNN它同样要吃 NPU/CPU 时间。5. 实操中最容易翻车的五个问题5.1 新增类别总是被误判为原有类别这个几乎必然出现尤其是新增类别样本不够的时候。解决办法除了加数据我建议把类别阈值单独调。做法是训练完成后在验证集上统计每个类别的 PR 曲线给“容易混”的类别单独设一个更高的置信度阈值。比如 face 类用 0.5masked_face 类用 0.65这样可以减少误报。5.2 量化后某一类精度断崖下降这是 PTQ 的经典问题。我的排查路径是先确认是不是校准数据集没有覆盖这一类。校准集里要有大量该类别的样本否则量化统计的激活范围就不对。检查网络里有没有对数值敏感的层比如大通道数的 depthwise conv这类层量化误差容易被放大可以考虑在转换工具中对该层做“per-channel 量化”或“保持浮点”。如果无法通过调校准集解决就得回炉用 QAT 重训。5.3 板端推理时间突然拉长先用 ST Edge AI Core 的 profiling 工具看各层耗时。如果某些算子落到了 CPU推理时间一定会暴涨。常见触发点是 Resize 和 Concat 结构堆得太多。另一个隐藏坑是内存带宽限制如果中间 buffer 放在内存带宽不够的区域NPU 会频繁等待数据搬移。我最后把 buffer 尽量放在 AXISRAM同时注意对齐带宽改善比较明显。5.4 关键点在口罩人脸样本上飘前面说过靠 visibility mask 解决。但如果你的模型是从公开预训练权重迁移过来的而预训练模型从来没见过口罩样本那么即便设了 maskbackbone 的特征也未必能适应遮挡区域。建议在数据增强阶段给 face 样本的嘴巴区域叠加一个黑块模拟口罩然后这部分的 landmark loss 同样做 mask效果很好。5.5 模型在 STM32N6 上能跑但一接摄像头就花屏或者掉帧这种情况多半是 DMA 中断和 NPU 推理的并行处理没做好。建议摄像头采集用双 buffer 切换当前帧在 NPU 推理时下一帧通过 DMA 持续写入另一块 buffer这样帧率才能上去。不要等整帧推理完再开始采集下一帧。6. 部署后性能调优的一点心得最后给准备动手的同学一个建议扩类别的训练工作不要想着“一次训完直接上板”。我通常先训练一个小模型只验证分类头能不能在 NPU 上跑到低延迟再回来扩数据、调参。这种“板端验证先行”的策略能帮你节省大量时间。另外在板端调试阶段建议打印每一帧的检测结果包括类别、得分、box 坐标、关键点坐标并和上位机跑同一张图的结果做对比。如果两边数值差异较大优先排查预处理归一化是否一致其次是量化精度损失。这个项目后续还可以继续扩展的方向一是给不同类别定制不同的关键点返回策略比如口罩人脸只返回眼睛区域关键点直接减少无效计算二是在 STM32N6 上叠加一个轻量分类器对检测框区域做二次确认来进一步提升属性类别的准确率。总之BlazeFace 这套网络结构本身很适合做嵌入式多类别人脸检测关键是每个环节的数据和部署细节都要抠到位。
