激光雷达的算力税：为什么你的几百TOPS算力，还是带不动它？

在如今的电动车发布会上，如果不甩出128/256/512线激光雷达这张王牌，似乎都不好意思说自己懂智驾。

很多人以为加了激光雷达，车辆就有了上帝视角，计算压力会变小。大错特错。今天我们就从底层数据的角度，扒一扒激光雷达到底占用了多少算力，以及它为何让智驾芯片有苦说不出。

算力消耗

如果只看 NPU 的账面数字，处理激光雷达的数据似乎并不贵。

以主流的 NVIDIA Orin-X 平台为例，运行一个经典的 PointPillars 点云检测网络，大概只需要消耗 10-15 TOPS 的算力。即使是更先进、更复杂的 TransFusion架构，算力消耗通常也在 30-50 TOPS 之间。

听起来很划算对吧？200 TOPS 的芯片，切出 50 TOPS 给激光雷达，洒洒水啦？

并没有那么简单。

在嵌入式系统中，TOPS 只是衡量矩阵运算能力的指标，它就像是健身房里的卧推重量。但处理激光雷达数据，每次卧推，还要提前准备好工具。

第一步：预处理

摄像头吐出的是 RGB 图像，是稠密矩阵，天生就适合喂给 NPU 吃。

但激光雷达吐出的是什么？是点云。每秒 150 万个点，散落在三维空间里，无序、稀疏、且伴随噪点。在把这些数据喂给神经网络之前，必须进行预处理。最典型的步骤叫体素化：把无序的点变成规则的占用网格。

这是一个典型的逻辑密集型任务，而不是计算密集型任务。它包含大量的条件判断、循环和内存寻址。这种活NPU 干不了，只能扔给 CPU 去干。光是处理一颗激光雷达的体素化，就能吃掉 1-2 个宝贵的 CPU 核心。要知道，Orin-X一共也就 12 个核，还得跑操作系统、跑规划控制、跑通信协议。

第二：访存带宽

做过嵌入式的朋友都知道，很多时候系统卡顿不是算力不够，而是数据搬不过来了。

激光雷达的数据量虽然不如 800万像素的摄像头大，但它的数据结构非常松散。为了处理这些稀疏数据，系统需要在 CPU 和 GPU/NPU 之间频繁地搬运数据。这就导致了DRAM 带宽的巨大消耗。

这就好比你去超市买东西，摄像头是一箱整整齐齐的牛奶，一把就能搬走；激光雷达是一地散落的黄豆，你得一颗颗捡起来装袋，这过程中消耗的时间和精力远超想象。

第三：融合的代价

这也是为什么 Tesla 和小鹏坚决要把雷达砍掉的原因之一。

当你同时拥有摄像头和激光雷达时，你面临一个终极哲学问题：当它们“吵架”了听谁的？

摄像头说前方有一个箱式货车（因为有纹理）。
激光雷达说前方是一堵白墙（因为它也是平的）。

为了解决这个问题，传统的后融合或现在的“BEV 特征级融合”，需要消耗大量的算力去做时空对齐。哪怕两者的标定误差只有 0.1 度，在 100 米外都会产生巨大的偏差。

为了把激光雷达的特征塞进 BEV 空间里和视觉特征融合，算法工程师需要设计极其复杂的网络结构。这部分的算力开销，往往比单独跑一个视觉网络还要大。

反面教材：200 TOPS 硬上三激光

我们来看一个业界真实存在的怪胎配置：

某款车型搭载的智驾芯片总算力仅在 200 TOPS 上下，但在营销上为了显得遥遥领先，硬是塞进去了 3 颗激光雷达。

这在系统工程上简直是灾难： 3 颗雷达全开，每秒产生的原始点云数据量高达 450万~500万个点。这颗 200 TOPS 芯片配套的 CPU 光是处理这 3 颗雷达的去畸变、时间同步和体素化，可能就要占去 60%-70% 的 CPU 算力。

结果就是强大的 NPU 空有一身肌肉，但因为 CPU 忙不过来，数据喂不进去，NPU 只能干瞪眼。

工程师为了让系统不崩，只能在软件上做手脚——虽然装了 3 颗雷达，但实际算法只跑中间那颗，两边的雷达只用来做最简单的障碍物触发（不进深度学习网络）；或者干脆大幅降低雷达的采样频率，虽然会导致并线的时候看不到后方来车，但是系统好歹跑起来了。

这就好比买了一辆东风小康，非要给它装上三个波音 747 的引擎。除了发布会上好听，实际跑起来，车架子都要散架。

文章转载自公众号：期望氢气球

原文链接：https://mp.weixin.qq.com/s/UZBTOR8CjBsduJGbxZmxhQ