企业官网建设流程全解析

前言

学习 MIT 韩松教授讲授的 MIT 6.5940: Tiny ML and Efficient AI Computing 课程，本篇文章记录第十讲：MCUNet的学习内容，和大家一起分享交流😄

Website：https://hanlab.mit.edu/courses/2026-fall-65940

Video：https://www.youtube.com/playlist?list=PLH7PIPKvCm38

1. Lecture Plan

今天我们要讲第十讲：MCUNet 与 TinyML。我们会通过一个非常详细的例子，看看如何为微控制器上的极小规模模型做模型压缩与部署。我们会用到前面几讲讨论过的所有技术，比如量化、剪枝、神经架构搜索和蒸馏。

这是今天的安排：首先讨论什么是 TinyML，以及 TinyML 面临的挑战和困难，比如如何压缩模型、如何把它塞进微控制器。然后我们会讲神经网络设计，结合神经架构搜索技术。最后讲 TinyML 的一些应用，比如视觉应用、音频应用，还有异常检测。

2. What Is TinyML?

我们先从一个很简单的问题开始。什么是 TinyML？为什么我们要把深度学习网络放到那么小的微控制器上运行？

这张图我们在第一讲里讨论过：今天的 AI 系统可以非常庞大、非常昂贵。模型的参数越来越多、GPU 也在变大，但今天的前沿模型远比这还要大。即使在 2020 年发布的 GPT-3，也已经有 1750 亿参数，训练大约需要超过 300 个 GPU 年，估计成本 460 万美元。而 TinyML 的工作点完全不同：低能耗、低延迟、低成本，还有更好的隐私保护。

在传统的云端 AI 模式下，设备会把数据上传到远程服务器，服务器执行模型推理，比如做预测。这样我们能用到强大的云端算力，比如这里最新的 GPU；但它也带来了通信延迟、额外成本，而且你需要把个人数据上传到云服务器，这可能引发隐私问题。

移动 AI 把一部分计算从云端移到智能手机上，把大部分推理负载保留在本地设备、本地计算资源上，能更好地保护隐私。不过智能手机仍有数 GB 内存，计算资源也比微控制器多得多。那我们的问题是：能不能再进一步？能不能超越移动 AI？能不能在只有几百 KB 片上内存的微型设备上运行有实际意义的神经网络？

为什么要 Tiny AI？为什么要把 AI 模型跑在微控制器上，而不是手机或云端 GPU 上？一方面是我们讨论过的隐私问题；另一方面，用微控制器，我们可以做到更低的成本、更低的能耗，而且几乎可以部署在任何地方，比如个人健康监测器、个人检测设备，以及各种制造场景。微控制器遍布全世界，全球已有数十亿台 IoT 设备在使用微控制器。在这些平台上部署神经网络，可以把智能直接带到传感器、不同应用、不同机器和嵌入式系统上。

它还能大幅降低成本：GPU 可能要几十万到上百万美元，而微控制器非常便宜。这种低成本让 AI 能力可以用在那些没有智能手机、服务器或可靠网络、或者部署不实用的场景里。它还能帮我们省电，实现“绿色 AI”。微控制器通常功耗很低，工作在毫瓦级。这让始终在线的检测与感知成为可能，而不会很快耗尽设备电量，也支持由小电池或能量采集供电的应用。

这些特性打开了广泛的应用场景，比如智能家居、制造业的自动化检测、个性化医疗，还有精准农业等等。

在资源极其受限的场景中引入智能，挑战在哪里？关键挑战是：把有用的模型塞进极小的硬件预算里，也就是极低的算力、极低的内存带宽和极低的存储。

在这张表里可以看到，即使是很老的云端 GPU 比如 Tesla V100，也有 32 GB 的显存，而且部署在云集群里，会有 TB 级的磁盘存储。移动 AI 通常有 4 GB 到 32 GB 的内存，存储大约 250 GB 或稍大一些。而 TinyML 的典型微控制器要小得多：通常只有大约 300 KB 的片上 SRAM 用于计算、存放激活值；存储方面大约 1 MB 的 flash，用于存放模型权重和程序。

这里有数个数量级的差距：激活内存（也就是用于深度学习网络激活值的片上内存）大约只有云端 AI 的 1/13,000；存储大约只有 1/100,000。所以为 GPU 或手机设计的模型，不能轻易适配到微控制器这样的 TinyML 设备上。

因此我们需要同时减小内存占用：减少激活值，这样模型才能逐层运行而不撑爆片上内存；同时减少模型权重，因为 flash 只有 1 MB 存储。如果模型太大，比如有 2 MB，就没法存到微控制器上。

总结一下：TinyML 通常受延迟和能耗约束，也有内存约束。在这种场景下，我们需要同时减小模型的激活值和权重大小，才能把它塞进 SRAM 和 flash。面对这种不同的设定，我们需要同时改变模型架构设计和系统优化。

3. Understanding the TinyML Challenges

下面我们先看看卷积神经网络在微控制器上运行时，权重内存和激活内存分别用在哪里。

考虑一个卷积层：它先读入激活值，把卷积核作用在上面，得到输出激活值。要理解网络的权重在做什么，我们需要知道推理过程中激活值和权重分别存在哪里。通常，推理运行时我们把输入和输出激活值存放在 SRAM 里；而卷积核在推理期间是固定的，所以可以存在非易失的 flash 中，在需要时读取。

如果你还记得，像 Arduino Nano 33 BLE Sense 这样的微控制器有 256 KB SRAM 和 1 MB flash。另一个例子是STM32 F746ZG—过去几年非常流行的一款商用微控制器，有 320 KB SRAM 和 1 MB flash。我们的任务是设计一个能跑在这些微控制器上的模型：输入和输出激活值要小于 SRAM，模型权重也要能存进 flash。

粗略估算时，flash 通常用来存模型，所以在评估模型能否存进微控制器时，我们要计算静态模型大小；而 SRAM 使用量通常按输入激活加输出激活来考虑。它是动态的，因为不同层的特征图大小不同，我们只关心整个推理过程中的峰值 SRAM。比如在卷积网络的早期层，激活图可能非常大，所以早期层的 SRAM 消耗更高，而后面层的 SRAM 压力会小得多。

这是不同网络激活峰值 SRAM 的分析结果。我们有 ResNet-50，也有 MobileNet V2。即使 MobileNet V2 是为移动设备部署优化的，它的峰值 SRAM、最大激活仍然非常大，可能是片上预算的 22 倍。即使做量化，最大激活、最大 SRAM 使用量仍然远大于设备 320 KB 的约束。

如果我们把 MobileNet V2 和 ResNet-18 比较，MobileNet V2 的参数量已经比 ResNet-18 小得多，但激活值其实略大，峰值激活甚至比 ResNet-18 还高。也就是说，它是为移动部署优化的，却不是为 TinyML 部署优化的，尤其是在微控制器上。

这会导致一个很严重的问题：SRAM 与 flash 都会成为推理的整体瓶颈。在 MCUNet 中，我们会同时处理这两个约束：既减小模型大小，也设计峰值激活内存更低的网络。TinyML 模型必须同时适配 flash 和 SRAM，因为超过任何一个预算，模型都无法在微控制器上运行。

4. Tiny Neural Network Design

带着硬件约束，我们来研究如何专门为端侧部署设计网络。MCUNet 是我们研究组之前的工作，采用算法-系统协同设计。

4.1 MCUNet: Co-Designing Architecture and Inference Engine

传统上，人们通常只优化神经网络架构，或者只优化推理引擎。但在 MCUNet 中，模型架构和推理引擎是一起设计的，这样能同时利用两边的优势，用协同设计的方式演进，比只优化一边高效得多。

这是对我们讨论过的神经架构搜索的简要回顾。这是一种常见的做法，用来优化可部署在资源受限场景中的模型：保持软件，或者说推理库不变，优化模型架构。这里的例子有 ProxylessNAS 和 MnasNet，展示了神经架构搜索的有效性。

另一条研究路线是：给定输入模型，如何相应地优化推理引擎？一个非常重要的例子是TVM，它可以在给定神经网络的情况下调优深度学习库，在不改变模型架构的前提下优化推理效率。而MCUNet 把两个方向的优化结合起来：它协同设计高效的神经网络架构和高效的编译器、运行时。这样就把设计空间扩展到比以往单纯的模型搜索或推理库、编译器优化更大。

MCUNet 框架有两个主要组件：第一是 TinyNAS，搜索能适配目标硬件的神经架构，比如我们今天反复提到的微控制器；第二是 TinyEngine，它编译搜索得到的模型，并在目标设备上高效执行。两个组件互相反馈，可以迭代得越来越好。TinyNAS 在评估候选架构时通常使用真实的系统约束；TinyEngine 则围绕最终网络用到的算子和内存访问模式做优化。

4.2 TinyNAS: Search Space Design

本讲我们主要关注 TinyNAS 和神经网络的自动化设计，推理引擎会在后面的讲座里讨论。TinyNAS 建立在我们已经很熟悉的神经架构搜索之上。人工设计架构严重依赖人类专业知识，而 NAS 会用机器学习和计算，以更高效的方式探索不同候选。一个重要的问题是：搜索应该在哪里进行，或者说，TinyML 的搜索空间是什么？

这张图说明，搜索空间的质量在很大程度上决定了最终网络的质量。比如你的搜索空间不好，即使有很强的神经架构搜索算法，也找不到足够好、令人满意的结果。那如果我们有好的搜索空间，也有好的搜索算法，就能为精度和效率找到非常好的最终网络。

简单地复用移动网络的搜索空间，对 TinyML 是行不通的，因为资源约束差别非常大：手机上几 GB 和微控制器上几百 KB 之间的鸿沟，会让整个情形完全不同。甚至最小的移动网络也无法在微控制器上运行，因为它的参数太多、激活值太大，塞不进微控制器的设备内存。

所以我们需要选择不同的搜索空间，专门为微控制器、为 IoT 设备设计。挑战在于如何缩放架构，让空间里包含足够有能力的模型，能够满足 SRAM 和 flash 约束。

对于 MobileNet 这类模型家族，两个有用的缩放维度是输入分辨率和宽度乘子，这里用 R 和 W 表示。R 表示分辨率：比如输入是 224×224，R 就是 224。W 是施加在模型通道数上的乘子：W 越大，可以想象模型的宽度、通道数就越大。

对于智能手机，典型的起点是 R = 224、W = 1.0。同一个架构家族可以放大到更强的硬件比如云端 GPU，那里分辨率更大、宽度乘子也更大。而对于微控制器，我们要往相反方向缩放，因为希望模型更小、更容易塞进设备内存。不同设备提供的 SRAM 和 flash 约束不同，所以微控制器的神经架构设计没有简单的“最优解”。TinyNAS 会针对每个硬件预算独立选择这些取值。

这引出了两阶段流程：首先，在目标内存和存储约束下优化、设计搜索空间；然后在特定的搜索空间里搜索出最好的单个网络。第一阶段通常选择较粗的缩放变量，比如前面讨论的分辨率和宽度乘子；搜索空间缩小之后，第二阶段搜索细节架构，比如不同的卷积核大小、不同的扩展比，以及每个阶段的 block 数量。这就是在给定分辨率和宽度乘子下进行模型架构设计。

这里有一个有意思的观察：在相同内存约束下，我们希望模型有更多的 FLOPs—FLOPs 越大，模型容量越大，也更有可能取得更高精度。图中这些曲线分别对应不同的搜索空间，但都处在相同的内存约束下：如果搜索空间好，我们就能有更大的 FLOPs，也能有更高的精度；而搜索空间不好时，平均 FLOPs 会低得多，精度也会比好的设计低得多。

这张网格图展示了不同设计选择之间的另一个关系。可以看到，如果 SRAM 大小相同、flash 更大，我们就能有更多参数，因为模型可以更大；如果 flash 大小相同、增大 SRAM，就意味着可以有更宽的激活通道，模型容量更大。

总结一下，如图中所示：如果 SRAM 固定，分辨率可能需要降低，以补偿更宽的激活值；SRAM 更大则允许更大的激活图，所以分辨率可以提高，而宽度仍然大致受不变的 flash 容量约束。

如果搜索空间已经确定，TinyNAS 会使用带权重共享的 once-for-all NAS：训练一个超网络，采样不同的子网再一起微调。较小的子网络嵌套在较大的子网络中，所以一次训练过程就能得到许多硬件专用的网络。比如设备内存较小，就选较小的子网部署；片上内存更多，就可以用更大、参数更多的网络。所有这些网络都能在同一个超网络中一次性训练完成。

这是不同子网嵌套在超网络中的演示。与 MobileNetV2 的对比很能说明问题：MobileNetV2 的峰值激活内存可能达到平均值的两倍，而 TinyNAS 里这个差距小得多，各层的峰值内存更均匀—因为搜索出的网络通常会在不同 block 之间更均匀地使用内存。这正是我们想要的，因为如果峰值内存远大于平均值，就意味着大多数层没有充分利用设备内存。而如果分布更均匀，每一层都能最大化利用设备内存，模型容量更大、精度更好。

结果，TinyNAS 取得了更好的精度-效率权衡。在VWW—视觉唤醒词—数据集上，任务就是检测给定图像里有没有人，MCUNet 相比人工设计和早期 NAS 模型，在精度高得多的同时，峰值 SRAM 显著更少、实测延迟更低。

4.3 Patch-based Inference

现在我们更仔细地回顾激活内存：SRAM 使用量逐层变化，所以正如之前所说，决定网络能否跑起来的是峰值而不是平均值。比如这张图里，峰值内存大约有 1300 KB，塞不进只有 250 KB 或 320 KB 的微控制器。这个峰值对本地部署来说太大了。而到了后面的层，SRAM 占用就远低于某些微控制器 256 KB 的约束了。

那问题是：能不能降低前几层的峰值内存，从而把更强的模型塞进微控制器？解决方案就是我们针对早期层超大内存消耗所做的这两项优化。

在传统卷积中，我们用逐层推理，即基于给定输入计算完整的输出。比如给定很大的输入特征图，你需要在每个位置应用卷积核，得到一个很大的输出特征图。不过，根据卷积的特性，我们可以一块一块地（patch by patch）做卷积计算。

基于 patch 的推理改变了调度方式：把大的激活值切分成更小的部分，让一个 patch 先穿过前几层，再处理下一个 patch。结果就是，每次卷积推理时—尤其是早期层—我们只处理原特征图的一部分，所以峰值激活小得多。比如这张图里，我们把峰值激活降到了原来的约 1/4。

再回头看之前的柱状图，用了 patch 推理后，峰值内存大幅下降，可以塞进 256 KB 的约束。我们还可以选择不同的 patch 大小，也就是把原始输入特征图切成多少块，并优化这个参数，让模型能塞进目标内存约束。

同样的思路也适用于不同网络架构。这些是在 STM32F746 微控制器上测得的一些峰值 SRAM 使用量。

Q & A

Q：把输入特征图切成不同的 patch 或块，会增加整体推理延迟吗？

A：对于如今的大规模云端 GPU，这种操作肯定会引入大量开销：原来每层卷积只做一次前向，现在要按 patch 数做很多次，还可能有额外的冗余计算。但对微控制器来说，设备受峰值内存和算力的严格约束，这类额外的控制开销相对原始推理时间不算什么；最大的问题反而是它引入的额外计算，我们后面会讨论如何解决。这一页最重要的信息是：原本无法在本地微控制器上运行的模型，现在因为峰值内存降到了设备约束以下，就能运行了。

我们回来继续讲。之前介绍的那款商用微控制器有 320 KB 片上 SRAM。原来的逐层推理会产生大约 315 KB 的峰值，已经非常接近硬性上限。即使是缩小后的 MobileNetV2—我们同时降低了分辨率和宽度—把输入按 2×2 切 patch 来做推理，也能大幅降低最大 SRAM 使用量，为推理留出更多空间。

Q & A

Q：patch 推理时，输出激活是怎么处理的？多个 patch 的结果在哪里合并？

A：这是个很好的问题。做 patch 推理时，我们不仅把输入激活切成不同的 patch，也同时切分输出激活，因为在做卷积时，如果只对左上角那块做卷积，输出特征图也只有原来的四分之一。但在几层之后，因为 CNN 中有下采样，特征图的尺寸会远小于原始尺寸。一旦特征图足够小，我们就可以保留这个 patch 的输出，开始下一个 patch 的推理。聚合只发生在几层之后的输出层，因为那时特征图已经足够小，这样输入和输出尺寸都能减小。对不同模型，在卷积中应用逐 patch 推理都能带来一致的内存节省，尤其是在输入激活图非常大的前几层。

4.4 The Halo Problem and Receptive-Field Redistribution

这里还有一个 patch 推理的问题，我们称之为 halo（光环）问题。

如果按 2×2 切 patch，只输入左上角那四分之一，就会漏掉边界上的一些元素：原始卷积层—比如对于这个输出元素，假设有 3×3 卷积核—实际上会用上一些当前 patch 中不存在的元素，这就引入了 halo 问题。

而且随着传播到更多层，卷积的感受野会大得多，所需的 halo 更宽，重复的卷积计算量也会逐层增加。比如假设卷积核是 3×3，要迭代三层，每层 halo 会在每条边上向外扩一个元素，三层之后特征图的宽和高都会比原始尺寸大 6。这类问题会引入大量冗余计算，因为引入 patch 推理时我们不想改变最终输出，不想牺牲正确性或精度，所以必须考虑第一层输入激活中所有这些感受野。

因此把原始特征图切成不同块时，不同 patch 之间会有重叠。如果层数太多，感受野可能非常大，甚至与原始特征图相当，这不是我们想要的，因为会引入大量冗余计算。halo 区域里的元素会在覆盖它的所有 patch 中被计算多次。所以我们在 MCUNetV2 中引入了另一种优化，用来重新分配感受野。

标准 MobileNet V2 架构里有很多 3×3 卷积块—这是 MobileNet 的卷积块，可以把它理解为一个卷积子网络。核大小为 3×3 时，可以想象随着推理层数增加，感受野会变得很大。而在 MCUNetV2 中，我们重新分配了这种感受野：早期层多用 1×1 逐点卷积、少用 3×3 空间卷积（包括深度卷积），这样模型早期层的感受野不会增长太快；而在后面的层，我们做更多的空间卷积来增大感受野。

因为那里图像大小、激活大小已经很小，可以引入更大的卷积核，并且可以用逐层推理代替 patch 推理，就不会有冗余计算问题，同时也补偿了前几层减少的感受野。这种在前几层减小感受野、在后面层补偿的设计，能在保持精度的同时，让 patch 推理的额外开销小到可以忽略。

最后，这两个方法—神经架构和推理调度—是联合搜索的。架构搜索的选项包括深度、宽度、卷积核大小等很多设计空间；调度则包括 patch 的数量以及前多少层使用 patch 推理。TinyEngine 会贡献额外的系统级选择，让推理更高效，并且无需太多人工工程开销就能适配微控制器。

4.5 MCUNetV2 Results and Insights

刚才我们讲了 MCUNetV2 中的优化技术，比如 patch 推理，也简单提到了推理优化和推理引擎，用于把模型部署到微控制器上。现在来看 MCUNetV2 的一些实际应用。

首先这张图展示了 MCUNetV2 把内存需求降低了大约 30 KB，同时保持 90% 的精度。在固定精度下，由于前面讲的优化，它的 SRAM 用量大约只有第一代 MCUNet 的 1/4。

这种改进不仅限于 VWW 这样的行人检测数据集，也提升了在 SRAM 非常有限的设备（比如前面说的 256 KB 片上内存）上的 ImageNet 分类；在同样约束下，还在 Pascal VOC 目标检测上带来更大收益。

我们可以检视搜索出来的 MCUNetV2 架构，理解自动神经架构搜索做出的设计决策。早期层使用基于 patch 的推理，因为输入图很大；后面的层回到普通的逐层执行，因为特征图已经足够小，不需要再切成 patch。在早期的 patch 阶段，搜索选择了不同的、更小的核，尤其是 1×1 卷积和深度卷积核，来减小感受野增长，从而减少前面提到的 halo 问题带来的重复计算。

这也证明了推理与模型架构协同设计的有效性：我们知道推理瓶颈是 SRAM 的峰值内存，所以引入 patch 推理；而 patch 推理有冗余计算、感受野增大的挑战，所以我们在早期层引入更小的卷积核，让整个优化循环不断演进，为特定应用产出更好的模型架构和推理引擎。

在中间阶段，扩展比保持得很小，空间分辨率仍然可观，所以在这里激进的扩展通道会重新造成巨大的内存峰值。层名里的 MB4 就表示扩展比很小。在后面的阶段，分辨率已经通过大量下采样大幅降低，所以网络可以使用更大的扩展比，有更多通道来提升模型容量，从而带来更多计算量和更好的精度，而不会超出 SRAM 预算。

由于引入了 patch 推理，我们还能使用更大的输入分辨率而不撞上内存墙。这对分辨率敏感的任务很重要，比如前面提到的 VWW：在低分辨率下，如果远处有人，人可能非常小，低分辨率图像会损害模型检测远处行人的性能。MCUNetV2 使用 160×160 的输入而不是 128×128—后者是之前 MobileNet 版本的配置。所以 patch 推理让我们能用更高的输入分辨率，带来更好的模型性能。

5. Applications

现在我们已经讲完了 MCUNetV2 的主要设计和主要技术。接下来看看不同的应用。我们先讲一些视觉应用，然后讲 TinyML 中非常重要的音频场景，最后讲时间序列，尤其是异常检测。

5.1 Tiny Vision

在早期的微控制器演示中，我们通常分类简单的物体，比如苹果、香蕉、橙子等等。而物体的颜色能提供很多信息，是分类的强信号。比如看到红色的东西，它更可能是苹果而不是香蕉或橙子。有了 MCUNet，我们可以超越这些玩具例子，在商用微控制器上跑真正 ImageNet 级别的分类。

想象一下，我们现在能在极小的微控制器上做 ImageNet 级分类—再次强调，这个设备的片上内存只有几百 KB、总存储只有 1 MB。

在这项对比中，MCUNet 是第一个在商用微控制器上实现超过 70% ImageNet top-1 精度的系统。不同设备的 SRAM 和 flash 限制不同，所以我们在 MCUNet 中使用的 once-for-all 训练策略，可以一次训练、特化出不同的子网络，部署到不同目标约束、不同类型的商用微控制器上。

这里是针对 VWW 基准的实际微型视觉任务，检测是否有人在场。它相当于语音唤醒词的视觉版本。一个小的始终在线模型可以持续监测画面里是否有人进入检测区域，而不用昂贵的、始终运行的人脸识别模型，这样就能让模型一直在微控制器上运行，而不会过快耗光设备电量，同时节省能耗、降低设备成本，也有助于保护隐私。

这是微控制器上的演示：画面里是 MIT 36 号楼或 38 号楼的电梯—有人时亮红灯，人走了就亮绿灯。

目标检测是另一类应用，相比分类任务它对输入分辨率更敏感，因为需要做稠密的空间预测。降低分辨率会严重损害检测精度，正如图中所示：分辨率越低，精度越低。我们的 patch 推理技术打破了激活内存瓶颈，让微控制器能处理大得多的输入，从而在目标检测任务上获得更好的精度。

这是口罩检测的演示：戴口罩的人画绿框，不戴口罩的画红框。这是疫情期间一个很有意思的演示。右边还有行人检测演示，会用框把摄像头中的人框出来。

定量结果说明了分辨率为什么重要：与基线相比，基于 patch 的推理找回了漏检的人，并减少了若干误检。可以看到两个例子里，MCUNet 在高分辨率下检测得更好，模型在同样的 SRAM 预算内看到了更多细节。看左边，这个人因为分辨率低没有被模型检测到；而这个检测就好得多。

此外，我们甚至可以在同样的内存预算下做训练或微调，而不只是在微控制器上做推理。想象一下，现在我们用 256 KB 内存训练一个模型。这个例子里，我们有一个微控制器和一个图像分类模型：用微控制器拍摄不同物体的几张照片，训练之后模型就能区分两种不同物体—橙子和香蕉。

采集过程中，红色代表香蕉、绿色代表橙子。经过若干训练样本、若干微调样本后，把摄像头对着香蕉，屏幕会显示这是香蕉并亮红灯；如果是橙子，就显示绿色。微型视觉的例子就讲到这里。我们讲了分类、目标检测，甚至端侧训练等不同应用。

5.2 Tiny Audio

接下来讲 TinyML 音频和关键词识别应用。音频是 TinyML 另一个非常重要的工作负载，应用包括关键词识别、语音识别和噪声消除。

这些任务受益于始终在线、低功耗的处理，不需要持续把麦克风数据发到云端，你还能获得更好的隐私。

关键词识别流水线会把波形切成重叠的帧，再把每一帧变换成频域特征。这里有语音波形，切成不同帧后转成频谱图。这个频谱图会输入到某个模型中，神经网络就可以预测不同关键词的概率，比如 yes、no、on、off 等等。

全连接 DNN 会忽略这种时频表示中的局部结构，而卷积神经网络能利用相邻时间帧、相邻频率之间的相关性，还能处理不同说话风格带来的小幅偏移。所以在相近的计算预算下，CNN 在这类关键词识别任务上比传统 DNN 效果好得多。

MCUNet 进一步把同样的硬件感知约束和协同设计理念推广到语音命令领域：在搜索中引入真实的硬件刻画，从而在关键词识别任务中，在精度、效率和模型大小之间找到更好的权衡。相比 MobileNetV2 等现有网络，我们精度更好、延迟更小。

5.3 Tiny Time Series and Anomaly Detection

最后，我们来看 TinyML 在时间序列分析和异常检测中的应用。异常检测在很多应用中非常重要，尤其是制造业质检；我们也把它用于健康监测、欺诈或攻击检测。

目标是学习正常数据的模式，把偏离已学习模式的输入标记出来，这样当模型收到异常的输入时就能发出警告。

这里简要介绍自编码器：它包含编码器和解码器。编码器把高维输入压缩成低维的潜在表示，解码器再从这个潜在表示重建出输出，输出应该与原始输入非常相似—这就是自编码器的目标。借助这个信息瓶颈，我们可以训练出一个非常有用的编码器来压缩、编码原始输入。

训练时，我们最小化正常样本上的重建误差。推理时，正常输入能很好地重建，而异常输入会产生很大的误差，我们就可以用这个误差做异常检测。自编码器如今也被广泛用于不同的领域，比如图像生成、视觉语言模型，我们会在后面的讲座中讨论。这里我们主要讨论它在异常检测中的应用。

它对这个任务有两个有用的性质。首先，训练可以是无监督的，因为我们不需要引入任何异常样本、异常标签—有时异常样本的标签比正常样本难获得得多。这个例子里，我们主要在正常样本上训练自编码器，学到一个特定于正常训练分布的表征。最后，我们用它在评估任务上做重建：如果有不正常的样本，最终输出会有很大差异，于是我们就能报告异常。

这里是运转风扇异常检测的演示。这是微控制器，风扇正在运转。如果用螺丝刀去干扰风扇，这里就会亮起黄色的警告灯；把螺丝刀拿走，黄灯就熄灭。摇晃风扇时，警告灯也会亮起。现在警告灯是亮的，因为风扇在晃。它会熄灭—现在灭了，因为它恢复正常状态了。

6. Summary

今天的课差不多就到这里。总结一下：我们把深度学习带到了资源极其受限的设备上，这里有很多约束，比如计算约束和内存约束。

今天的课我们主要讨论如何压缩和部署模型到非常有限的片上内存中，比如微控制器的 250 KB SRAM。我们还讲了 MCUNet 的系统-算法协同设计，以及 MCUNetV2 的基于 patch 的推理。这些技术让实用的视觉、音频和异常检测应用可以直接跑在微控制器上。你可以让始终在线的微控制器在日常生活中承担各种监测任务。

结语

第十讲把前面所有的武器—量化、剪枝、NAS、蒸馏—收拢成一个完整的案例：MCUNet。它先回答了"为什么要 TinyML"：云端 AI 有通信延迟、成本和隐私问题，手机虽然能本地推理但仍有数 GB 内存，而微控制器只有约 300 KB SRAM 和 1 MB flash—激活内存只有前者的约 1/13,000、存储约 1/100,000。更麻烦的是这两个预算要同时满足：激活值放在 SRAM、权重放在 flash，任何一边溢出，模型就根本跑不起来。这一讲还用数据戳破了一个幻觉：MobileNet V2 虽然是为移动端优化的，参数量比 ResNet-18 小得多，峰值激活却反而略大，其峰值 SRAM 甚至可能是片上预算的 22 倍。于是问题被定义得很清楚：既要更小的权重，又要更低的峰值激活。

MCUNet 的答案是算法-系统协同设计：TinyNAS 负责搜架构、TinyEngine 负责编译与执行，两者互相反馈。TinyNAS 先解决"在哪搜"—直接把移动端的搜索空间搬过来是不行的，得为微控制器重新设计；它用分辨率 R 和宽度乘子 W 做粗缩放，两阶段地从粗到细搜索，而判断空间好坏的标准很漂亮：相同内存约束下 FLOPs 越大，模型容量和精度越可能高。再配上 once-for-all 的权重共享，一次训练就能给不同 SRAM/flash 预算切出嵌套子网，而且搜出来的网络在各 block 间的峰值内存更均匀，把设备内存用满。MCUNetV2 则盯住了新的瓶颈—前几层的峰值激活：patch 推理把大特征图切块、逐块穿过早期层，峰值激活降到约 1/4，256 KB 的内存终于放得下；代价是 halo 问题—patch 之间要重叠、感受野逐层增长会带来重复计算，于是又反过来调整架构，早期层改用更小的 1×1 与深度卷积，把感受野的补偿留到分辨率已经降下来的后层。架构与调度联合搜索之后，同等精度下 SRAM 用量只有原来的约 1/4，还能把输入分辨率提到 160×160。

这些技术让微控制器真正有了实用价值：第一个在商用 MCU 上把 ImageNet top-1 做到 70% 以上的系统；VWW 可以一直在线地检测有没有人（电梯里有人亮红灯、无人亮绿灯的演示都安排上了）；目标检测对分辨率敏感，patch 推理恰好找回了低分辨率下漏检的行人；甚至还能在 256 KB 内存上做端侧训练，拍几张照片就能分清橙子和香蕉。音频侧的关键词识别把波形切帧、转成频谱图再喂给 CNN，MCUNet 把硬件刻画带进搜索，精度更好、延迟更小；时间序列侧则用自编码器做无监督异常检测—正常样本重建误差小、异常样本误差大，风扇被螺丝刀一干扰就亮起黄灯。回过头看，这一讲像一次收网：剪枝、量化、NAS、蒸馏各自解决一个维度，而只有把它们放进同一个协同设计的循环，几百 KB 的芯片才真正装得下智能。

下一讲，我们将讲解 TinyEngine 和并行处理 🤗。

参考

• https://hanlab.mit.edu/courses/2026-fall-65940
• https://www.youtube.com/playlist?list=PLH7PIPKvCm38