AI芯片算力之外可靠性同样关键

谈到AI芯片，许多人第一时间想到的往往是TOPS算力、L4/L5自动驾驶、图像识别算法等炫酷的技术概念。然而，在初创公司与芯片巨头争相追逐“AI热潮”的当下，一个被广泛忽略的问题正日益凸显——芯片的可靠性。这个问题看似可大可小，但一旦严峻起来，将直接决定终端产品的成败。

自动驾驶事故频发，芯片责任不容忽视

经常浏览汽车新闻的读者或许已经注意到，近年来因自动/辅助驾驶引发的事故屡见不鲜。原因多种多样，但很少有人会将矛头指向芯片。部分车企为抢占上市窗口，其AI芯片可能仅通过了AEC-Q100认证门槛，而对ISO 26262这类功能安全标准置若罔闻——在他们看来，这些标准过于“陈旧”，甚至成为所谓“创新流程”的绊脚石。

消费者同样存在认知偏差。人们对功能变化的感知最为直接，而对故障的容忍度只要维持在“可接受”范围内，便容易麻痹大意。这促使某些车企采用类似“手机APP式”的开发模式：快速迭代、快速上线。然而，这绝不意味着功能安全可以沦为儿戏。毕竟，一旦事故发生，任何责任方都无法逃脱追责。

在实现功能安全的过程中，从需求提出、架构设计、编码实现到最终测试，每个环节都需经过确认与验证。但完成验证是一回事，能否实现全过程追溯则是另一回事。举例来说，设计上的一个小改动，可能违背芯片的原始需求，导致实际性能缩水。因此，在功能安全开发认证过程中，可追溯性是不可妥协的硬性指标。

Harmony Trace芯片设计追溯 / Arteris

IP厂商Arteris推出了一套名为Harmony Trace的追溯方案，专门协助芯片厂商落地功能安全。其思路颇为直接：在分散的流程系统之间构建一个整合层，用于追踪半导体产品全生命周期中的所有失误。一旦出现违反芯片要求的错误，系统会立刻通知工程师——该改动需要检查，从而自动完成车规认证的审查流程。当然，各家芯片开发商的工具流差异较大，Harmony Trace也贴心地提供了对主流EDA工具和认证流程的兼容支持。

随着自动驾驶安全标准的不断演进，ISO 21448与UL4600等新标准提出了更高要求。在AI芯片设计中确保可追溯性，或许正是缩短产品开发认证周期的一条捷径。

可靠性至上：云端同样不可忽视

事实证明，可靠性这一关不仅自动驾驶领域需要跨越，云端场景同样绕不开。放眼当下的云端计算集群，多个节点为云服务提供了强大的算力支撑，但问题也随之而来——架构越复杂，每个节点都可能成为整个系统的阿喀琉斯之踵。

这类案例我们已经屡见不鲜，甚至开始影响日常生活。热搜上时不时出现“某某应用崩溃”的消息，互联网公司被服务器故障折腾得焦头烂额，而最令人头疼的莫过于定位故障源。这背后，芯片难辞其咎。

导致这些问题的芯片可靠性故障主要分为三类：早期失效（ELF）、正常运行下的随机失效，以及不可避免的设备老化。芯片都有其工作寿命，最后一项在设计层面基本无解，只能尽可能延长使用寿命。前两者才是云端需要重点防范的对象。

常见的早期失效包括闸极氧化层失效、老化效果不佳、软击穿等；随机失效则多与运行环境相关，例如温度过高、辐射过大等。

为帮助AI芯片摆脱这些可靠性隐患，初创公司Ceremophic推出了一款QS1芯片。这颗基于5nm工艺的分层学习芯片，集成了2GHz自定义机器学习处理器、2GHz自定义FPU用于机器学习计算，以及基于ThreadArch的RISC-V处理器和ARM Cortex-M55应用处理器。Ceremophic表示，后者主要用于元宇宙相关应用的视频处理。接口方面，它支持x16 PCIe 6.0 / CXL 3.0。

那么，这颗芯片在可靠性上有何独特之处？Ceremophic给出的答案很直接：针对早期失效，他们选择了高效的ASIC实现方式，采用抗ELF的逻辑库，通过正确的逻辑单元组合，以最小的设计开销实现低ELF。

面对随机失效，Ceremophic则亮出了自家多线程技术。具体做法是：用两个多线程处理器运行同一份程序，一旦检测到错误，便利用多个结果进行表决修正。修正后，程序执行会从发现错误的位置直接恢复运行，而不是回到一个未知的安全起始点，从而避免额外的功耗浪费。

在传统的高可靠性设计中，往往需要采用高成本方案，比如冗余。说白了，就是在两个地方做同一件事，计算资源和功耗都要翻倍。而且，解决问题的过程本身也需要消耗更多运行周期——这也是为什么云端服务器出现故障后，往往不能快速恢复的原因。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：AI芯片算力之外可靠性同样关键要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题