006、轻量化改进（四）：神经架构搜索（NAS）与自动设计

一、从一次调试说起上周在 Jetson Nano 上部署 YOLO 时遇到一个典型问题模型推理时间达标了但功耗始终压不下去。客户要求边缘设备连续工作 8 小时以上现有的轻量化模型在功耗上还是“奢侈”了点。手动调整了通道数、改了两次激活函数效果都不明显。这时候想起之前看过的一篇论文里面用 NAS 搜出来的结构在同等精度下功耗低了 23%。行今晚就聊聊神经架构搜索这件事——它不只是学术玩具在真实部署中能救场。二、NAS 不是魔法是更聪明的暴力搜索很多人一听 NAS 就觉得是“自动炼丹”黑箱操作不敢用在项目里。其实它的核心思想很直接我们手动设计网络时无非是在调整层类型、通道数、连接方式这些参数NAS 不过是把这个过程自动化用算法代替人眼去评估成千上万个候选结构。早期的 NAS 方法确实奢侈比如用强化学习在几百块 GPU 上搜几周那是大厂玩的。但现在进化出不少平民化的方案权重共享Weight Sharing典型如 DARTS把所有可能的结构拼成一张超网训练一次就能评估所有子网。好处是快缺点是容易过拟合到搜索空间里。我在项目里试过搜出来的结构在训练集上漂亮一上真实数据就拉胯——这里踩过坑建议搜完后用少量真实数据再微调一下结构。单路径随机采样Single Path One-Shot每次只训练一条路径内存占用小适合在单卡上跑。但收敛慢容易陷入局部最优。适合对搜索时间不敏感但设备受限的场景。硬件感知搜索Hardware-Aware NAS这才是部署工程师该重点看的。不光看精度还把延迟、功耗、内存占用当目标函数。比如在搜索时直接调用 TensorRT 测速度或者用芯片的功耗模型做评估。我们上次在 ARM Cortex-A53 上搜出来的卷积核配置就比 MobileNetV3 快了 1.3 倍。三、在 YOLO 里引入 NAS 的实操片段直接改主干网络太激进我一般从 Neck 或 Head 开始试水。下面是一段基于 ProxylessNAS 思路的代码片段用来搜索 Neck 中的通道数配置classSearchableNeck(nn.Module):def__init__(self,search_channels[64,128,256]):super().__init__()# 候选通道数搜索时会从中选一个self.candidate_channelssearch_channels# 用可学习参数表示每个候选的“得分”self.alphann.Parameter(torch.randn(len(search_channels)))# 准备不同通道数的卷积模块self.conv_layersnn.ModuleList()forchinsearch_channels:self.conv_layers.append(nn.Sequential(nn.Conv2d(256,ch,3,padding1),nn.BatchNorm2d(ch),nn.ReLU(inplaceTrue)# 别用 LeakyReLU这里实测效果差不多但延迟高))defforward(self,x):# 用 softmax 把 alpha 转换成概率分布weightsF.softmax(self.alpha,dim0)# 加权求和各个分支的输出out0fori,convinenumerate(self.conv_layers):outweights[i]*conv(x)returnout训练时正常反向传播更新 alpha 和卷积权重搜索结束后取权重最大的分支作为最终结构。这个方法比 DARTS 简单好调试适合第一次尝试 NAS 的团队。四、避开 NAS 的常见坑搜索空间设计比算法更重要别一上来就搞花哨的搜索算法。先把搜索空间约束在合理范围内比如卷积核只考虑 3x3 和 5x5通道数按 8 的倍数设置很多芯片对 8 对齐有优化。空间太大搜不动太小没意义。验证集和测试集一定要隔离搜索时用验证集评估结构测试集留到最后。见过有人用测试集反馈调搜索空间那是作弊上线必崩。硬件指标要实测别信公式论文里的 FLOPs 和实际延迟经常是两码事。我在 RK3399 上遇到过 depthwise 卷积比标准卷积还慢的情况驱动没优化好。所以硬件感知搜索一定要在目标板上实测模拟器都不完全可靠。一次搜索定终身不现实芯片换代、数据分布变了结构可能都得重新搜。建议把 NAS 流程自动化定期用新数据跑一下特别是业务场景变化快的项目。五、个人经验什么时候该用 NAS项目中期优化瓶颈时手动调参没进展了用 NAS 撞撞运气。硬件平台特殊时比如新的 NPU 指令集手动设计经验少让搜索算法去探索。长期维护的产品一次搜索成本摊薄到多次迭代中划算。但如果是赶工期的项目或者硬件非常成熟比如 Cortex-A77 GPU直接抄现成的 MobileNet 或 EfficientNet 更稳妥。NAS 是利器但不是瑞士军刀别指望它解决所有问题。六、写在最后轻量化不是一味地砍参数而是找到精度和效率的平衡点。NAS 把这个平衡点的搜索过程自动化了但它依然需要工程师先定义好“平衡”是什么——是 1ms 的延迟优先还是 1MB 的内存优先这些目标函数的设计才是体现经验的地方。下次遇到模型在边缘设备上跑不动时别急着剪枝量化先想想这个结构真的是为我的场景设计的吗如果不是或许该让算法帮你找一条新路。