自动驾驶的安全底层,不是算力,是冗余架构

特斯拉 AI 简单分享了有关 AI4 芯片的安全结构，直接说明了特斯拉在自动驾驶和机器人上的安全冗余：

“Our AI4 chip is built with full fail-over redundancy. That means two computers run in parallel and keep checking each other...”

中文翻译特斯拉的方案就是：AI4 芯片是带完整故障转移冗余的。两台电脑平行运行互相校验，主系统如果异常，副系统可以无缝接管。而且这套逻辑，车里的 FSD 和擎天柱（Optimus）机器人都在用。

车辆和其他硬件确实不太一样。不像电脑、手机、智能家居，这些东西故障了虽然也会造成麻烦，但通常不会直接涉及人身安全。

不同设备故障的影响程度差异很大。

拿我家用的 HomeKit 智能家居来说，一年下来总会遇到几次某个硬件没响应，或者某个硬件自己“幽灵开关”的情况。从体感上来说也没什么特别大的影响，最多也就是费点电、重启一下。

但如果类似的“死机”发生在一台时速 120km/h 的汽车上呢？ 或者发生在一个正在厨房操作刀具的 Optimus 机器人身上？

那已经不是简单的 Bug，而是安全问题。

在物理世界里，系统稳定性的要求远高于消费电子产品，硬件级冗余不是锦上添花，而是底线设计。

HW3 车主的经历

为什么我对“冗余”这两个字这么敏感？

因为我是实打实吃过亏的 HW3 车主（尾期 HW3 最后一批车主，懂得都懂）。

有一次在高架上用 AP，路况很好，车也不多，系统突然提示接管。我接管后重新开启，刚连上又让我接管，再开就提示本次驾驶 AP 不可用。

我并没有忽略方向盘警告，也没有长时间脱手，当时确实不清楚为什么反复触发接管。后来回想，大概率是 HW3 平台叠加老版本 AP 偶发异常。

这类问题本质上不是“功能不好用”，而是底层稳定性不足。

我后来观察到，AI4（HW4.0）平台车辆在运行 FSD 时，类似底层崩溃的案例明显更少。

最近北美还有一个案例：一台 AI4 车辆被后车追尾后，FSD 并未立即退出，车辆仍保持稳定控制。当然，这是否属于系统设计逻辑的一部分，还有待更多信息确认。但至少说明在遭遇突发冲击时，底层系统并未直接崩溃。

从安全工程角度看，这种稳定性比单纯算力参数更重要。

关于 TOPS 的一点看法

现在很多车企发布会谈到智能驾驶，核心指标往往是“多少 TOPS”、“几颗芯片”、“算力碾压谁”。

但算力只是能力上限，不等于系统稳定性。

软件可用性、安全边界、底层冗余机制是否完善，这些往往在 PPT 上看不出来。

买车时，参数当然重要，但真正能验证系统成熟度的，还是长期实际使用体验，以及真实车主在复杂场景下的表现。

算力高不一定等于更安全，安全冗余也不是单一指标能决定的，它是一整套系统工程。