ENAS 真能在没有 GPU 的微控制器上搜到好网络吗

ENAS 致力于将可部署性、搜索耗时和激活 RAM 整合进筛选流程。基于两组基准的现有证据尚不足以证明其能通吃微控制器场景，但这套兼顾资源限制的搜索框架已展现出明确的技术思路。

arXiv:2609.30272v1 提出的 ENAS，全称是面向资源受限微控制器的硬件感知神经网络架构搜索框架。它没有把重点放在扩大搜索空间上，而是试图将“模型能不能部署”“搜索要花多久”“运行时占多少内存”放进同一条筛选链。两组基准的结果值得关注，但还不足以证明它能通吃微控制器场景。

ENAS 实际搜索了什么

ENAS 采用基于 cell 的搜索空间，其中包含标准块、深度可分离块和 bottleneck block，并允许为网络加入可选的 skip connection。

搜索过程分为三个阶段：

1. 先执行随机搜索。
2. 再从候选结果中保留 top-$K$。
3. 最后围绕这些候选进行 mutation。

这里还有一项容易被忽略的设计：persistent cross-run caching，也就是把跨运行缓存保留下来。它可能减少重复搜索，但摘要没有交代缓存命中条件、失效规则，以及搜索耗时是否把缓存收益单独算出来。

在部署约束上，ENAS 会先做静态可行性检查。论文强调它可以在不依赖 GPU 的情况下运行，目标不是用大量并行计算换取搜索规模，而是适应开发资源同样有限的 TinyML 环境。

论文给出的数字

ENAS 在 Visual Wake Words 和 Melanoma Cancer 两个 TinyML 基准上进行了评估。实验环境在微控制器与模型配置的覆盖范围、运行效率及内存优化效果上均提供了对比数据。

• 硬件覆盖范围：共测试 8 款微控制器，SRAM 容量从 20 KB 到 1 MB。
• 输入配置：覆盖 9 种输入图像分辨率。
• 搜索效率：Visual Wake Words 的平均搜索耗时加速为 $2.41×$，Melanoma Cancer 为 $1.70×$。
• 准确率表现：与近期的 NanoNAS 框架相比，ENAS 保持了有竞争力的测试准确率。
• 内存表现：在准确率相同的情况下，ENAS 选出的模型使用了明显更低的峰值激活 RAM。论文把激活 RAM 称为微控制器部署时的主要约束。
• STM32H743 结果：测试准确率达到 $79.4\%$，比 greedy CPU-only baseline 高 2.6 个百分点。

其中，20 KB 到 1 MB 的 SRAM 范围比单一开发板上的平均加速更有意义。微控制器不是模型越小就一定能跑，峰值激活 RAM 往往才是决定部署是否可行的硬门槛。ENAS 把这个指标放进搜索结果，而不是等模型选定后再单独压缩，确实更贴近实际部署。

不过，摘要只说峰值激活 RAM“substantially lower”，没有给出绝对数值或降幅。仅有这个定性描述，还无法判断不同设备上的收益是否稳定。

复现时最该盯住的四个问题

摘要没有公开若干会影响判断的实验细节。首先是搜索预算，需要确认随机搜索、top-$K$ 和 mutation 各自运行多少次，以及不同方法是否使用相同预算。其次是缓存收益，跨运行缓存到底节省了多少时间，加速比是否包含缓存命中带来的收益，仍需进一步明确。此外，基线设置要求交代 NanoNAS 和 greedy CPU-only baseline 的具体配置，以及测试准确率的统计波动。最后是 RAM 数据，应当记录相同准确率下各模型的峰值激活 RAM，而不只是给出“更低”的结论。

这些信息并不是额外要求，而是判断 $2.41×$、$1.70×$ 和 2.6 个百分点能否复现时必须核对的部分。没有搜索预算、缓存口径和多次运行结果，单次最快结果很容易被高估。

公开代码能验证框架的核心假设

论文已经开放 ENAS 源码，仓库地址为：

https://github.com/EdgeIntelligenceLab/ENAS

代码公布后，ENAS 的硬件感知能力就有机会接受更细的检验。值得优先检查的是静态可行性检查覆盖了哪些约束、三阶段搜索如何衔接、跨运行缓存保存了什么，以及 NanoNAS 对比是否公平。

在没有实际运行这些代码前，不能替论文下“已经证明优于所有 NAS 框架”的结论。现阶段更准确的定位是，ENAS 提出了一条面向资源受限微控制器的完整搜索路径，并用 8 款微控制器、两种 TinyML 基准和 9 种分辨率给出了初步证据；$2.41×$ 搜索加速与更低峰值激活 RAM 是否足够稳定，仍要由公开实现和复现实验来决定。