我一直觉得，2021年夏天那场AI Day，是近几年自动驾驶行业信息密度最高的一场发布会。当时不少同行看完的第一反应是“这家车企把技术方案全都摊开讲了”，随后一年里，BEV、占用网络、数据引擎、仿真生成这些词，几乎成了各家技术团队的标配。我写下这篇略记，不是为了完整复盘那天的流程，而是想把自己当时记录、事后反复验证过的一些技术逻辑整理出来，聊聊哪些才是真正决定一个自动驾驶系统上限的关键选择。
那天的内容排得很密：从自研超级计算机，到多任务感知网络，再到自动标注与数据闭环，最后抛出一个机器人原型。表面看是不同产品线的展示，实际上整场都在围绕同一件事：怎么把“AI能力”当作一个系统工程来建设。下面我按自己的记忆和理解，把这些内容拆开讲，也顺带说说当时业内是怎么看、以及后来哪些判断被验证了。
1. 先看全局：这场AI Day到底想讲什么
1.1 发布会内容的整体节奏
那天的议程大致分三块：硬件算力、软件算法、数据与机器人。开场讲的是自研训练芯片和超级计算机，紧接着是自动驾驶神经网络的技术演示，再往下是自动标注和仿真，最后用一个机器人原型收场。
这个顺序不是随便排的。算力放在最前面，是在回答一个根本问题：你的算法和数据量，需要什么样的计算平台才能撑起来？很多做自动驾驶的公司习惯用现成的GPU集群训练模型，但这家公司选择从芯片开始自研，等于把算力也纳入了自己的技术栈。后面讲算法和数据时，很多设计的合理性都建立在“我有专门的训练硬件”这个前提之上。
给我的整体感觉是：它不是一场产品发布会，更像一次技术路线宣讲。每个环节都在解释“我们为什么这么做”，而不是单纯展示“我们做出来了什么”。所以散场后大家讨论最多的，不是哪个指标有多强，而是这套思路能不能被复制。
1.2 为什么它值得反复看
一个发布会值得反复看，通常不是因为场面好看，而是因为它留下了可以验证的线索。2021年AI Day上提到的几个概念，后来在行业内被反复引用：多相机融合成鸟瞰视角特征，成为不少视觉方案跟进的方向；占用网络后来被越来越多团队用来处理异形障碍物；数据引擎和自动标注，也逐渐成为高阶辅助驾驶团队的标配话题。
我建议后来入行的朋友也回去看看当时的公开资料，重点不是看热闹，而是看他们怎么把一个复杂问题拆成“算力—算法—数据”三个可迭代的模块。这种拆法，比单纯追某个模型结构要有用得多。
2. Dojo超级计算机：自研算力，不是为了炫技
2.1 从GPU困境说起
要理解Dojo，得先看清当时训练自动驾驶模型遇到的真实瓶颈。
那时候主流做法是用大规模GPU集群训练视觉模型，表面看算力不缺，但实际用起来处处受限。第一个问题是数据传输。视频训练数据量极大，动辄PB级，GPU集群要把数据从存储搬到显存，再从显存搬到计算单元，数据搬运的时间和能耗往往超过计算本身。第二个问题是扩展性。GPU互联有层级结构，跨节点通信走网络，节点一多通信开销就上来了，模型并行和数据并行的效率都会下降。第三个问题是成本与供应，高端GPU采购周期长、价格高，而且新架构的适配主动权不在自己手里。
有个生活化的类比：GPU集群像几十个人分头干活，每干一步都要开会同步一次，大量时间花在“沟通”上而不是“干活”上；如果能把这几十个人安排在同一个房间里，共享同一块黑板，沟通成本会大幅下降。Dojo的思路，本质上就是把这个“房间”做到极致。
2.2 D1芯片与训练块的工程细节
当时公开的D1芯片信息里，有几个数字我记得比较清楚：采用先进的7nm工艺，晶体管数量达到数百亿级别，在BF16/CFP8这类训练常用精度下，单芯片算力大约是数百TFLOPS。芯片本身集成了大规模片上存储和高速互连接口，目的就是让数据尽量在芯片内部流动，减少对外部存储和网络的依赖。
更关键的是一层结构：25颗D1芯片通过先进的封装技术集成在一起，组成一个训练块。这个训练块被当作一个整体来使用，算力可以达到千万亿次级别。也就是说，早期那台超级计算机并不是“一堆服务器插着加速卡”，而是把25颗芯片在物理上做成了类似一个超大芯片的东西。芯片之间的通信走的是片上互连，延迟和带宽远优于传统服务器网络。
再往上是把多个训练块再组合，形成一个更大的计算集群，目标算力直奔E级（每秒百亿亿次级别）。从工程角度看，这不是简单堆数量：芯片如何供电、如何散热、如何保证长时间高负载下的稳定，都是挑战。当时公布的设计里采用了不少液冷方案，功耗密度被推到很极端的水平。
2.3 编译器与“整晶圆”思路
硬件上把芯片做成一整块，只解决了一半问题。另一半问题在于，训练计算图要怎么映射到这样的硬件上。
普通深度学习框架对底层硬件做了良好抽象，使用者不用关心计算怎么被分配到不同芯片上。但Dojo这种紧密耦合结构，要求计算图的切分足够合理，才能发挥硬件优势。所以那天的技术演示里，花了不少篇幅讲编译器：如何把模型算子调度到相邻的芯片上，如何减少跨芯片通信，如何让“一个训练块”真正像一个芯片一样工作。
我当时记了一个感慨：真正难的不是造芯片，而是让芯片体系里跑的应用发挥出应有性能。现在回看，不少自研芯片项目都容易低估编译器与软件栈的工作量。特斯拉在AI Day上愿意讲编译器细节，说明他们确实把“软硬协同”当成核心竞争力在做了。对于做自动驾驶训练平台的人而言，这一部分的信息价值甚至比芯片本身更值得研究。
3. HydraNet：一个身体，多头输出
3.1 从单任务模型到多任务网络
自动驾驶感知的传统做法，是每个任务各训练一个模型：目标检测一个模型、车道线一个模型、可行驶区域一个模型。这样做的好处是简单、独立迭代快，但坏处也很明显：多个模型在车端同时运行，算力消耗成倍增长；维护和部署复杂；而且每个模型只看到自己的任务目标，缺少对场景的整体理解。
那场AI Day提出的HydraNet，思路很直接：所有任务共享同一个视觉特征提取网络，这个网络输出丰富的中间特征，然后让不同任务头各取所需。名字里的“Hydra”就是九头蛇的意思——一个身体长出多个头，每个头处理一个任务。
共享特征带来的好处很实际。首先是计算效率提升，特征提取部分只需要做一次，各任务头通常比较小，整体算力开销远低于多个独立模型之和。其次是训练上的互相促进，多任务共享backbone会让模型学习到更通用的视觉表示，检测任务学到的特征也能帮助车道线任务。第三是工程上非常友好，新增一个感知任务时只需加一个任务头，不必重新训练整个网络，产品迭代效率高很多。
3.2 多摄像头特征如何融成鸟瞰视角
HydraNet的输入是车身四周多枚摄像头拍摄的画面。每路摄像头的位置、朝向、视野不同，如果只是在图像层面简单拼接，视角割裂问题会很严重。当时演示的方案是：各路图像先经过共享网络提取特征，再在一个统一的空间坐标系里做融合，最终得到以自车为中心的鸟瞰视角特征，也就是常说的BEV（Bird‘s Eye View）。
当时这个细节让不少同行眼前一亮。此前行业里比较多的是在3D空间直接预测目标，或者把摄像头感知结果分别处理后再融合。而HydraNet是在特征层面做融合，相当于先把两张图都“理解”到一定程度，再在空间上对齐，这样融合的信息量远高于后融合。
BEV特征的好处是对下游任务特别友好。车辆、行道线、可行驶区域全部落在同一个俯视网格上，规划控制模块可以直接在这个表示上做路径搜索和碰撞检查。用生活经验类比：开车的人脑子里都有一个“俯视图”，知道自己前后左右各有什么，而不是分别记着左前摄像头看到什么、右后摄像头看到什么。HydraNet正是在给自动驾驶系统建立这样一个统一的“空间心智模型”。
3.3 时间维度：用视频而不是单帧
那次演示还有一个反复强调的点：模型不是用单张图片训练和推理，而是处理一段时间的连续视频流。
单帧图像的局限很明显：无法感知物体的运动速度，无法处理被遮挡物体的短期推理，也不容易判断一个目标下一秒可能出现的位置。引入时间维度后，模型在特征层面对齐帧与帧之间的对应关系，既能感知自身车辆的移动，也能提取出其他交通参与者的运动趋势。
这带来了一个工程上很重要的问题：如何给视频数据打标签。如果只在单帧上标注，时间信息等于浪费了。所以当时同时展示了“4D标签”的概念：在三维空间的基础上加时间轴，标注的目标不仅要有3D位置和尺寸，还要有连续轨迹。这套标签体系，是整个视频训练方案能够落地的地基。没有高质量轨迹真值，模型再怎么设计也很难学到真正稳健的运动预测能力。
4. 占用网络：模型开始“理解空间”
4.1 目标框解决不了的问题
传统3D目标检测的做法，是预测一个个带朝向的3D边界框，每个框对应一个已知类别的物体。这个方法在常规场景下很好用，但到了真实路面上会遇到一堆麻烦。
比如一辆装着超长货物的卡车，货物的形状完全超出标准框的范围；比如路边堆着的杂物、施工用的物料、被撞歪的护栏，这些东西不属于预设类别，检测器大概率直接忽略；再比如路上翻倒的车，边界框怎么摆都不对，朝向也很难定义。Musk在台上举了不少这类例子，核心意思就是：如果把感知结果局限在“框”，那遇到长尾物体就等于瞎了。
当时看到这段，我心里很有共鸣。真实世界的障碍物形态几乎无限多，你不可能给每一种都准备一个类别和一套回归参数。与其硬着头皮扩展检测类别，不如换一个底层表示。
4.2 每个体素都要回答的问题
占用网络的思路是把自车周围的3D空间划分成小立方体（体素），模型对每个体素回答几个问题：这里有没有东西被占用？如果有，它属于什么语义类别？它是不是在运动？我的置信度是多少？
输出不再是几个边界框加上类别标签，而是一个稠密的占用概率场。每个体素都有独立预测，所以无论障碍物是规则的箱子还是不规则的杂物，只要能造成物理占用的区域，都可能被模型标记出来。对规划控制来说，这种“哪里能走、哪里不能走”的表示，甚至比“这是什么物体”更直接。
当时现场还播放了一段真实道路的可视化演示，画面里的体素网格像一层半透明的“体积云”覆盖在路面上，车辆、行人、路沿都被标记成不同颜色的占用区域。最让我记住的是有一段视野里车辆被大车遮挡，但占用网络依然在预期的位置输出了连续的占用概率，说明它并不是简单地做传感器数据投影，而是真的学会了在语义层面补全被遮挡的空间。
4.3 对规划控制意味着什么
感知输出从“目标清单”变成“占用地图”之后，下游规划模块的接口简单了很多。
传统方案里，规划器拿到的是一堆物体框，要根据框的中心、速度、朝向去判断碰撞风险，还要假设物体被一个标准框包住，遇到非标准物体容易出问题。而在占用网络这种表示下，规划器只要在地图上做路径搜索时检查路径是否穿过高占用概率区域即可，形状再怪异的障碍物也能表示到位。
这也解释了为什么这家公司坚持取消雷达而走纯视觉：视觉信息经过合适的网络结构处理后，可以输出如此稠密的空间占用信息，传感器融合的优先级自然下降。对很多保守的工程师来说，这个转变需要重新审视“感知输出到底该长什么样”这个问题，而这也是占用网络带来最大启发的地方。
5. 数据引擎：自动驾驶的隐形护城河
5.1 影子模式如何自动找难例
搭建数据闭环的第一步，是从海量驾驶数据中挖掘出值得学习的场景。人工去翻几十万小时视频找难例显然不现实，特斯拉提过一个很巧妙的设计：影子模式。
车端同时运行正式版本模型和一个候选模型，候选模型不参与实际驾驶控制，只在后台“默默看着”场景并输出自己的预测。车辆行驶过程中，系统会把这些预测与正式模型的实际表现、以及驾驶员的操作进行对比。如果候选模型在很多场景下表现得更好，就把它上线；如果正式模型在实际驾驶中暴露了问题，相关数据会自动标记并回传。
这个设计妙在把“难例挖掘”变成了一项自动化流水线：不再是人盯着数据找问题，而是让模型自己暴露在真实世界的长尾里，由系统自动筛选出有价值的数据。影子模式上线意味着车队里的每一辆车都成了数据采集节点，而且采集的标准不是“出了事故”，而是“模型表现不佳”，这比随机采集高效得多。
5.2 自动标注：把3D真值变成流水线
有数据之后，另一个成本大头是人工标注。2D框标注还算成熟，但3D框、车道线、路面边界、物体轨迹这类真值，人工标注的代价极高，而且不同标注员之间的标准很难统一。
当时展示的自动标注系统，思路大致是：利用多帧视频和多枚摄像头的信息，把同一辆车的多个视角、多个时刻拼接起来，通过几何重建和离线大模型联合推理，自动生成高精度的3D标签。标签里不仅有物体的位置和尺寸，还有它在时间轴上的连续轨迹。人只在系统不确定的时候介入审核。
这实际上是把“人工标注”升级成了“机器自动标注+人工抽检”。好处不只是省钱，更重要的是标签的一致性更好，模型学到的是同一套标注语义，而不是每家标注公司各标各的。自动标注能力也决定了训练数据能膨胀到什么规模：如果还靠人工一张张标，数据闭环根本跑不起来。
5.3 仿真与数字世界：补充长尾场景
真实数据再多，也覆盖不了所有极端情况，比如极端天气叠加陌生障碍物、特殊施工路段、几乎不会出现在普通道路上的物体姿态。那天还提到了用生成技术重建真实场景，在数字世界里渲染更多样化的交通场景。
一个值得注意的方向是NeRF类场景重建：用视觉图像重建出一段道路的三维场景，再通过改变虚拟相机位置、加入不同天气光照、更换交通参与者的布置，生成大量新视角训练样本。这种方法的优势是场景的真实感来自真实数据，而多样性来自计算机图形学操作，两者结合，数据分布要比纯随机合成数据合理得多。
当时这个环节给我的触动，不亚于芯片环节。一旦自动标注、影子模式、仿真生成三者连通，数据流水线就不再依赖“人肉打标签+运气收集难例”，而是变成了一个可以持续运转、自我迭代的工厂。看到这里我才真正明白，为什么这家公司能把大模型铺到那么多场景里——不是模型结构有多神秘，而是数据引擎的效率高得惊人。
6. Bot计划：一个大脑的物理世界延伸
6.1 那些让人“半信半疑”的参数
发布会接近尾声时，屏幕上出现了一个人形机器人概念图，我印象里大概一米七出头的身高，几十公斤的体重，能搬运一定重量的物体，能以近似人类步速行走。当时现场有人鼓掌，但更多人在心里打了一个问号：一个做汽车的企业，怎么突然做起了机器人？
这里要说明一点，类似产品在当时行业内并不新鲜，只是普遍被认为离量产极远。所以当场最引人讨论的，不是机器人本身的能力，而是这家公司为什么愿意在这个时间点把它公开。
6.2 机器人和自动驾驶共享什么
那天的画外音其实很直白：机器人与自动驾驶共享同一套AI底层能力。
自动驾驶需要的视觉感知、三维空间理解、运动预测、路径规划，以及背后支撑这些模型的训练平台和数据闭环，都可以迁移到机器人上。人形机器人要在一个真实物理世界里活动，也要“感知空间—预测动态—规划动作”，这和车辆在道路上遇到的问题是高度同构的。把自动驾驶里验证过的占用网络、BEV表示、仿真训练体系搬到机器人上，逻辑上是通顺的。
我把这理解为“一个大脑，多种身材”：先把物理世界的通用感知和规划能力做好，然后把同一个大脑装进汽车、装进机器人，甚至装进其他什么移动设备。这个视角当时看有点宏大叙事，但从技术路线上讲，它没有把机器人当成一个孤立的项目，而是作为同一AI能力平台的一个新应用出口。
6.3 当时争议与后来回看
那一年很多人嘲笑这个计划是“为了股价画饼”，因为连成熟原型都没有公布，只有概念图和工程指标。但几年过去，不少做具身智能的团队反而开始重视和复用自动驾驶领域积累的感知、仿真与数据引擎经验。这个方向后来的发展，证明当时的公开表态并不完全是营销动作。
当然，从产品角度看，人形机器人要走到日常场景，还隔着成本、可靠性、安全冗余、执行器能力等多道坎。AI Day上的展示更多是想传达技术方向的确定性，而不是给出竣工时间表。对于技术从业者来说，这种“用同一套AI基础设施服务不同物理形态”的思路，比单个机器人参数更值得记录。
7. 落到自己：这场活动最该记住的三件事
7.1 算法、算力、数据必须闭环迭代
如果只让我保留一句“略记”的收获，那就是：这家公司真正强的地方，不是某一个模型或某一颗芯片，而是把算法、算力、数据三件事拧成了一根绳。
模型结构再先进，没有足够数据的反馈就调不出稳定效果；数据规模再大，没有对应的算力平台就训不动模型；算力再强，如果算法设计不能发挥硬件特性，也只是电费账单。所以层层拆开看，每个环节单独拿出来都能被同行模仿，但要把三者的迭代速度同时提上去，考验的是整个组织的系统工程能力。做自动驾驶的同学，无论你在团队里负责哪一块，都应该留意自己所在系统的闭环效率。
7.2 区分技术演示与量产状态
那天很多演示的确让人血脉贲张：实时渲染的占用网格、自动生成的高精度标签、接近一整面墙的算力机柜。但后来实际跟踪这些能力的落地节奏，会发现每一处演示背后都有大量工程化工作需要补上。演示只展示成功样本，不会展示数据清洗的繁琐、模型误报的调试、车端功耗的压测。
我自己看发布会时，习惯先问一句：“这是已经在量产车跑的效果，还是一台训练设备上的离线算例？”这个习惯帮我避开了很多高预期陷阱。比如占用网络的实时演示很震撼，但那时能否在全量车队大规模部署、能耗能否被车端芯片承受，并不是当天能给出答案的问题。对比后来的版本更新，看到这些能力确实是逐步量产的，也更加说明从演示到产品需要时间。
7.3 想深入学习，可以从哪几个点入手
如果现在有人问我，想系统理解这场AI Day应该从哪几个点入手，我会建议：
第一，把多任务感知网络的BEV特征融合看明白，找一篇相关的技术文章或者开源实现，在数据集上跑一遍，比看十遍回放都有用。第二，理解数据闭环的每个环节如何流转，尤其是影子模式如何自动筛选难例，这决定了数据投入能不能换来模型收益。第三，关注算力平台对模型迭代速度的约束，看懂它们为什么宁可自研芯片，也不要“等供应商给卡”。
还有一个建议：带着疑问看，别只看结论。台上讲了一大堆“为什么我们要自研”，台下要做的是追问“如果我没那个资源，哪些通用原则还可以借鉴”。比如自动标注提升数据一致性的思路、多任务共享特征节省算力的思路，这些并不需要自研芯片也可以落地。
过了几年再回头，那场AI Day里至少有一半内容，后来真的成了行业里反复讨论和跟进的方向。我个人印象最深的倒不是某个具体指标，而是它示范了一套“把AI当工程问题来做”的方法论：算力不够就自己建，数据太多就建流水线，模型复杂就拆成共享底座加任务头。这种以工程效率为核心的逻辑，放在今天的自动驾驶和机器人领域仍然适用。这篇略记写到这里，也算是替自己把那天的收获重新存档了一遍。
