L4自动驾驶:无需万亿大模型,但需每秒做一亿亿道数学题

读者朋友，儿童节快乐！

这里是Brad Liu的博客微信公众号。本文聊聊实现L4自动驾驶的硬件基石。本文主要由小米MiMo大模型辅助。

我没多打字，就是“一亿亿”，不是“一亿”。那么，一秒钟做一亿亿道数学题，究竟是怎样的体验？

开车时，司机遇到的最常见的情况，不仅仅是快速辨别与前车的距离，还要注意后方车辆和其他车道上的情况，可能时不时还要应付一下跟车上乘客的沟通。

未来的L4自动驾驶汽车，其实就是这样一个“住在车里”的司机师傅。它不仅仅要做人类司机同样的事情，还要满足当下和未来人们对“智能座舱”的需求。

但在这种对未来的畅想中，我们很有可能会这么思考：人类在应对路面交通和车内沟通的时候，几乎就用到了司机的全部精力，这是不是意味着，能够达成L4自动驾驶的汽车，也需要非常强大的“大脑”？

在自动驾驶产业的竞赛中，一个违反直觉的现象正在引发业内关注：要实现L4级别的全自动驾驶，车载人工智能模型的参数量大约只需100亿到140亿，这个数字放在今天的大模型版图中完全不起眼——这点参数量，甚至不到某些通用大语言模型的十分之一。

然而，承载这个“小模型”的车载芯片，未来所需的本地算力却要达到8000甚至10000TOPS，也就是每秒需要完成8000万亿次甚至一亿亿次整数运算。一个并不庞大的模型，凭什么需要一座几乎等同于小型数据中心的计算能力来驱动？

这个问题的答案，揭示了更高级自动驾驶从技术理想走向商业落地过程中最核心的工程挑战。

模型参数量并非越大越好

首先需要澄清一个认知误区：自动驾驶当然需要“大模型”。

某新势力厂商研发的云端大模型参数量已高达720亿，国内某款VLA（视觉-语言-动作）基座模型也达到了400亿参数。这些庞大的模型聚集在云端，通过海量驾驶数据——汽车厂商用了约10亿Gb的视频数据——进行训练，从无数个“长尾场景”中汲取应对经验。

有一点很容易理解：模型的参数量决定了它能在多大范围内完成精准的识别和决策。但真正部署在车端的模型，又被压缩到了一个相对紧凑的规模。

某厂商智驾负责人曾公开表示，基于当前主流的车端芯片，车端模型的尺寸通常在1亿到5亿之间，即使是备受关注的VLA大模型，参数规模也一般在20亿左右。英伟达最新发布的专为L4级自动驾驶设计的推理模型Alpamayo-R1，参数规模才刚达到100亿左右。

至于为什么不能在车上直接部署更大参数的模型，原因则非常直接：车载芯片的存储空间和功耗承受不起。因此，这些抛弃了冗余知识和参数的，经过压缩和蒸馏的，针对驾驶任务的小参数模型，就成为了车端部署的更优解。

参数量不等于算力

这里需要区分两个不同的概念。模型的参数量衡量的是“知识容量”，它决定了模型能够存储多少从数据中学习到的规律和模式，好比一座图书馆的藏书规模。而芯片算力衡量的是“计算吞吐”，它决定了系统每秒钟能处理多少任务，好比图书馆里同时工作的图书管理员数量。

一座图书馆可能只有几千册藏书，但如果每天有上万名读者同时涌入借还书籍，管理员团队就必须非常庞大。L4自动驾驶面临的正是这种局面：模型本身的知识量经过精心优化已经足够精炼，但实际运行时的计算强度却远远超出常规AI应用。

在真实世界中，驱动一个130亿参数的Transformer模型仍是一件比较消耗算力的事情。根据业界的测算，处理单个词元（Token，模型处理文本或图像的基本单位）就需要约0.026TFLOPS的算力，约等于0.052TOPS或0.104TOPS。那么当数据以洪水般的速度输入和输出时，再小的模型也会被压榨出恐怖的算力和能源需求。

同时，在面对智能座舱和行驶本身的电能需求，实现L4自动驾驶所需要的能源也需要限制在合理的范围内。

速度就是生命

自动驾驶与普通人工智能应用之间最本质的区别，在于它对实时性的要求近乎苛刻。

我们平时在屏幕前问豆包时，完全不认为它三五秒的推理时间有什么大不了，甚至不觉得带来了什么不便。但一辆百公里时速行驶的汽车，每延迟一百毫秒就意味着在完全没有感知的情况下盲驶约2.8米。这在高速公路上完全能决定一个人的生死，甚至会决定是否触发一场连环追尾。

因此，自动驾驶系统的完整决策链条——从摄像头和雷达捕获环境信息，到人工智能理解场景含义，再到规划行驶路径并发出控制指令——必须在极低的延迟下全部完成，而且要以每秒二十到三十帧的频率持续运行，一次都不能中断，一帧都不能延迟。

所以，车载芯片不是完成一次计算就可以休息，而是在整个行驶过程中必须不间断地进行高强度运算。

十二双眼睛同时看路

如果说实时性是时间维度上的压力，那么传感器数量则构成了空间维度上的数据爆炸。

从目前设想的未来来看，一辆L4级别的自动驾驶车辆通常会搭载六到十二个高分辨率摄像头、多个激光雷达、若干毫米波雷达以及超声波传感器。这些传感器就好比给汽车装上了十二双不同功能的眼睛，它们各自从不同角度、以不同方式捕捉周围环境的全部细节。

仅以摄像头为例，每一路画面经过图像编码处理后都会被拆解为数百个信息单元，十二路摄像头以每秒三十帧的速度运行，系统每秒钟就需要处理大约二十万个视觉信息单元。激光雷达产生的三维点云数据，其计算密集程度比图像处理还要高出一个量级。

这些不同来源的数据还需要进一步融合——就像人的大脑需要把双眼看到的画面合成为一个立体图像一样，系统必须把十二双“眼睛”的信息统一在一个空间坐标系下，才能形成对环境的完整理解。这个过程的计算量极为可观。

流水线背后的乘数效应

外界容易产生的一个误解是，芯片只需要运行一个模型。但事实上，芯片算力要驱动的是一条完整的推理流水线，由多个模型和算法模块串联或并联组成。

从传感器数据输入开始，系统首先要运行图像编码器提取特征，然后将多路信息融合为鸟瞰图式的全局表征，接着进行三维目标检测以识别周围的车辆、行人和障碍物，随后要对每一个运动目标进行持续跟踪和轨迹预测，再据此规划自身的行驶路径，最后还要经过一道安全校验模块对规划结果进行可靠性审核。

这条流水线中，有些环节必须等待前序结果才能启动，有些环节可以同步并行执行，但无论哪种方式，所有环节的计算总量叠加在一起，远远超过其中任何一个单独模型的开销。

一个130亿参数的模型处理一帧多摄像头画面，单次推理就可能消耗数百TFLOPS的算力；而若以每秒20帧的帧率运行，那么这一个模型就需要数千TFLOPS的持续计算能力，换算下来很可能就已经来到了万级的TOPS需求。当流水线中其他模型同步运行时，算力需求自然会攀升至上万TOPS的量级。

标称算力与实际算力之间的隐性鸿沟

上文中反复多次出现过“TFLOPS”和“TOPS”这两个单位。这里需要说明的是，业界习惯以INT8精度来标注芯片的算力数值，这个指标通常用TOPS来表示。但实际部署中的神经网络推理往往需要更高的数值精度来保证决策的准确性，这意味着标称一万TOPS的芯片，换算到常用的FP16精度后大约只有五千TFLOPS。

再加上内存带宽的物理瓶颈、数据在不同存储层级之间搬运所产生的时间开销，以及操作系统层面的调度损耗，芯片的实际有效利用率通常只有百分之六十到百分之八十——即便如此，这也只是乐观估计。也就是说，一辆L4自动驾驶车辆真正需要的，是标称上万TOPS、实际有效算力六七千TFLOPS的计算平台，才能在各种极端工况下留有足够余量。

车辆自动驾驶能力对硬件要求的不断提升也预示着：汽车厂商对于特制的AI芯片和存储颗粒的需求，预计到2028年都处于居高不下的状态。这同时也对当前全球芯片产能不足的困境制造了更大的麻烦。

小结：精炼模型面对极端场景的更优解

回到最初的问题，100亿到140亿参数量模型之所以足够，是因为就目前的行业判断，自动驾驶是一个领域明确、任务边界清晰的垂直场景，经过专业的精调和蒸馏优化后，模型不需要冗余的通用知识，只需要高效地完成感知、理解和决策。

但上万TOPS的算力是绝对刚需，则是因为这个任务被执行的方式极为极端——多传感器同步输入的数据洪流、每秒数十帧的硬实时约束、多模型串联的长流水线，以及为安全冗余预留的计算余量，这四重因素相乘，共同将算力需求推升到了一个惊人的高度。

这一现象给科技商业领域带来的启示是深远的。在人工智能产业化的进程中，模型能力与部署成本之间的关系远比外界想象的复杂。一个模型在实验室中表现优秀，并不意味着它能以合理的成本跑在真实的硬件上。真正决定自动驾驶商业可行性的，不仅是算法的先进程度，更是从芯片、传感器、系统工程到安全冗余的全链路协同能力。

模型可以做到越做越精炼，但只要场景的实时性和安全性要求不变，底层算力平台就必须足够强大。这不是资源浪费，而是生命安全场景下不可妥协的工程底线。

（图片来源：网络）

觉得文章不错的话就点一下屏幕右下角的“❤️”吧~