谈谈嵌入式AI功能安全
作者：姜辛
大概是2009年的时候，我还是个刚工作不久的萌新，我的主管高博发来一打PDF，是一个编号26262的ISO标准，还没发布的Draft版本。高博说这个新出的汽车电控的安全标准，可以研究研究。上汽当时有平台优势，大概第二年就有IKV的老外来给我们做了整整三天的培训，那个时候一边是想推咨询业务的肯教，一边是刚开始工作积累的想学，互动热烈，就此认识功能安全。当时我们从事的是新能源的动力系统电控，所以当时探索这方向的几个人被称做扭矩监控组。后来的工作虽然不再专门去做功能安全方向，但一直也频繁有接触。
上周与朋友约饭，也是这个领域的资深专家，聊了这个话题，回家继续把一些零碎的思路整理。
站在今天从功能安全的视角比较传统汽车嵌入式电控与基于神经网络的方法，归纳三条基础不同：
传统嵌入式控制讲究确定性的计算，即由可解释的规则性算法逻辑代码组成；而基于NN模型的计算变得更高维和非线性，是基于概率原则的。
传统嵌入式控制系统中，即便建模一个复杂的逻辑，通常也只有较小的状态空间；而神经网络基于极为庞大的隐空间维度，其状态空间反映在Activation和Tokens上是成百上千甚至更高维度。
传统嵌入式控制系统的故障在原则上可分析，尽管可能很复杂。理论上从故障（Fault）到失效（Failure）到产生危害（Hazard）的链条可追溯。而NN模型失效更多的是“语义性”，而非“bit-exact”性质。
首先说“Bit-exact”。在神经网络中，大部分操作对传统的位错误（Bit Error）失效模式，例如位卡滞（bit stuck）, 位反转（bit flip）等等可能是不敏感的。神经网络结构中包含本身大量的卷积、池化、量化和数据格式转换等，这些操作对数据精度的影响已经堪称“大刀阔斧”了，与之相比，绝大多数在位级别上的错误很可能在一层层的计算中已经被严重“稀释”了，对结果几乎不造成什么影响。
但另一方面，也不能排除模型对一些错误可能极其敏感，即在一些“边界、非连续”的场景，比如量化过程的不连续边界，比如logits的分布稍微差一点，可能被层层放大，对最终计算结果的影响“失之毫厘，谬以千里”。更进一步，对于长程的推理模型，中间存在一些关键的“pilot token”，如果出现错误，有可能把推理轨迹导向完全不同的方向。
粗略考虑一些最常见的计算位错误的敏感性，比如：
卷积Conv/矩阵乘Matmul：线性混合的过程，一般来说Bit Error会被“稀释”掉
池化Pooling：大部分概率下有稀释效果
ReLU：会缓冲掉部分错误
量化：本身就是大多数bit位精度粗糙化的操作，只是如果错误在数据类型阈值边界上，可能对结果影响较大
Softmax/Attention：在指数位上可能改变分布结果；反之可能没有影响
Normalization：可能对大部分错误有缓冲作用
等等，对于各种算子，原则上都可以就其对位错误的敏感度做类似的分析
从算子层面再放大到模型结构，考虑其中哪些部分可能是对错误最敏感，
分类模型的分类边界logits
模型中关键的控制/结构，Token路由，例如Top-K和Argmax
门控机制，例如MoE的选择等
等等
这些位置相对来说可能会引起模型输出行为的重大变化，可以认为是安全的瓶颈点需要重点保护。把失效情况大致分分类：
失效转化成无害的噪声，在计算过程中被稀释和冲洗掉了
失效引起了局部的计算结果“飘移”，经过后续模型多层映射计算，结果受到影响但仍落在合理语义区域内
失效导致了局部计算结果变异，并且影响到后续整个推理输出的性质变化，灾难性的后果
听起来好像是逻辑上的废话，但有一点个人直觉，从比例上1和2是大部分，3是少数，理由是模型的隐空间流形的结构可能是大部分区域连续平滑，少部分区域不连续，多层映射后局部错误的“突起”会被抹平。希望有实验能证实。
嵌入式AI功能安全的窘境在于，对于MCU或者CPU为主要硬件载体的计算形式而言，当过渡到用GPU/NPU这种大规模并行计算单元进行大规模数据处理时，无论是计算、还是内存和通讯的footprint都大出不止一个量级，在此情形下一般的功能安全机制设计思路多少都会遇到些瓶颈。比如冗余，CPU核可以直接做锁步，但把GPU/NPU也这样加冗余从功耗和成本上都无法接受；再比如内存和通讯加校验，对于小存储区域校验的时间可行，而数据块大了之后，校验计算本身就引入了过大的负荷。同时，如前一部分所述，对于模型来说，要监控的更多是推理输出的“语义”变化，而非位错误本身。
所以我的核心观点是，在嵌入式AI领域，硬件要保证的目标可能不是“精确可重复的计算”，而是语义输出的鲁棒性（被Safety Goal分解到的语义）。功能安全需要结合模型架构和硬件部署特点，做针对性的设计，保护关键点而非大而泛之，方能有实效；不然只是停留在形式上的套皮，看似热闹然则是皇帝新衣，形式意义大于实际意义。
讨论一些可以想的招数：
理论分析+故障注入试验，用自动化的方式在目标模型里逐层在权重/激活值/中间token等注入错误，做敏感度扫描，尤其是理论上的不连续边界，试图对目标模型建一张“Criticality Map”，根据“Criticality Level”应用不同的安全机制。
判定网络逐层的先验特征，比如激活分布统计，然后做轻量级的层分布的统计特性检查。
蒸馏轻量化的冗余模型兜底，类似投机采样的方式，用较小的计算代价把底线包络住，这也是传统功能安全应用层算法常用的思路。
用规则化的兜底，比如检查特定值范围、输出连续性约束等，在CPU上跑，硬件上同时也冗余。
另外在模型架构方面，对于有功能安全要求的模型是否可以在架构设计上考虑给更多Activation加上边界bounding/clipping算子，或者限制层Lispchitz条件，减缓异常传播，付出一定性能代价使模型更鲁棒。
或者在训练时就是“FuSa Aware”的，训练过程中就引入一些故障注入和攻击，诱导模型的鲁棒性加强。
以上是个人过往零碎思考观点的输出，限于水平错误难免。因为现在实际也没有在做功能安全的具体工作，所以也缺少实践支撑。发出来抛砖引玉，希望引发些有价值的讨论。
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
链接：