Tesla Autopilot 技术架构解读

作者：EatElephant

本文来自对 Karpathy 的几个技术分享视频的分析，其中数据和截图也来自视频，其中加入作者自己的解读，所以不一定完全正确，如果有错误的地方欢迎大家指正探讨。

FSD Overview

FSD 装备 8 台相机每台相机在 36Hz 频率采集 960x1280 的三通道图像（相机参数 Karpathy 只是举例说明，并不一定是 Tesla 实际使用的相机 Spec），利用所有 8 个相机的图像，FSD 进行超过 1000 种不同任务的感知预测（数字统计位 2020 年上半年数据现在可能有所增加）。

所有这些感知功能跑在 Tesla 自研的 FSD Computer 上，这台机器有着两颗冗余的 FSD chip，每个芯片提供 72TOPS (int8) 的计算能力，两颗加起来共提供 144TOPS 算力，其中自带的高速图像处理模块理论上可以支持 8 颗摄像头在 60Hz 的频率上传输 1080P 的图像，其运算能力高于目前市场上的其他高端自动驾驶芯片如 Xavier， EyeQ5 等。

根据 2020 年底消息，Tesla 将在近期将前向毫米波雷达更新成具有高度分辨率的 4D 毫米波雷达以提高对于静态障碍物的检测能力。

FSD 目前包含的 1000 多项检测任务覆盖面非常广，包括但不限于下面分类的超过 50 种 Main Task：

Moving Objects: Pedestrian, Cars, Bicycles, Animals, etc.
Static Objects: Road signs, Lane lines, Road Markings, Traffic Lights, Overhead Signs, Cross-Walks, Curbs, etc.
Environment Tags: School Zone, Residential Area, Tunnel, Toll booth, etc.

其中每个 Main Task 下边还有若干 Sub tasks，例如车辆检测还包括车辆的静止，朝向，开门等子任务的检测，Stop Sign 检测包括如右转无需停车等细分类检测等等。

除了检测任务，FSD 还有训练很多功能网络，包括但不限于下面功能 48 个子网络：

Depth Network: 用以进行稠密的深度估计
Birdeye View Network: 用以进行图像到 Birdeye view 的坐标投影
Layout Network: 用以推测道路元素的布局情况
Pointer Network: 用以预测道路元素间的关联，例如红绿灯对应车道

另外 FSD 将基于 sampling 的输出变为基于 rasters 的输出，二者区别是 sampling 的输出来自确定 geometry 的采样，rasters 则能够表示 uncertainty，more uncertainty 意味着输出更加的 diffused。

Model Architecture

为了进行如此复杂的感知任务，特斯拉在神经网络结构的选择上做了很多考量。

Single task network vs Multi tasks network

Loosely coupled heads vs Tightly coupled heads

松耦合指的是每个相机单独进行感知，然后将不同相机的感知结果利用 Filter 或其他技术进行拼接 (stitch)，例如 1.0 版本的 Smart Summon 就采用了这一方法，利用不同相机检测到的 curb 进行拼接的到停车场的 Occupancy Grid 的地图，从而在这个地图进行导航。

Figure 2 基于 Occupancy Grid 的老版本 Smart Summon

但是在不同相机和不同 frame 间 track 不同的 grid 是一件困难的工作。在新版本的 Smart Summon 中，Tesla 采用了对不同相机 Feature 层输入一个 Fusion Layer 进行 Feature 层面的融合，然后输入 Birdeye View Network，最终在 Birdeye 的基础上再分支成不同的 heads 进行如 Object Detection， Road Line Segmentation， Road edge detection 等输出。

Figure 3 利用各相机直接进行 Birdeye View 输出，可输出道路边缘，隔离带，通行区域等分割结果

最终 FSD 使用的是一个规模巨大的 Multi-head network，其中主干网络采用类似 ResNet-50 的架构用以进行 Feature 的提取，功能分支采用与 FPN/DeepLabV3/UNet 类似的结构用以实现不同功能的输出。

最终 FSD 的网络架构如上面两图所示的共享 Backbone 加上众多功能 Heads 的多任务 HydraNet，不同相机负责不同的功能，且网络引入了 RNN 的结构来进行跨时间的感知预测，例如前向 3 相机 Main+ Narrow+ Fisheye+ Pillar 相机的 feature 负责车道线检测追踪，Pillar+ Fisheye 加上过去时刻的输出一同负责 Cut-in（加塞）检测等。不同功能在不同相机中共享层次结构是基于一些 cross features 可以促进各自任务的观察而设计的，同时有些任务间共享层次结构又会相互影响，应以避免。例如动态物体和红绿灯就不应该共享过于底层的 Feature，但是车道线检测和可通行区域就应共享更多的底层特征。Karpathy 还提到他发现的一些有趣的现象，例如在训练部分网络的时候同时使用 5 个 task 的 loss 来获得更好的 features，但是训练得到的网络只会用于 5 个 task 中的 3 个任务的 inference 使用。

Training

训练这样一个拥有 48 个网络，1000 多个感知输出的庞大的 Multi-task 模型是十分苦难的，单次训练就要花费 70000GPU 小时，更别说模型训练要经过多次迭代，调优等过程，虽然为了提高训练效率，Tesla 自研了专门用于训练的 Dojo Computer，但是训练过程仍充满了各种挑战。

Loss Function

在庞大的 HydraNet 中，所有的子任务的 Heads 最终都通过加权平均的办法整合到一个 Loss 里面，训练的过程就是优化这个整合后的 Loss。这些不同子任务的 weights 则是这个模型的 hyperparameter。

学术研究中有通过自动的方法找到最优的子任务权重的办法，但是当子任务数量扩展到数百上千后，这样的自动方法就变得不可使用。

最终这些子任务权重的选择变成一个十分需要谨慎思考，且一旦确定不能轻易更改的超参数。选择这些超参数需要综合考虑许多因素，例如：

不同任务的 Loss 有着不同的 scale，而且 classification 和 regression 也需要不同的权重
不同任务有着不同的重要性，例如行人检测就有着比限速标志牌更高的优先级。
有些任务比较简单，其他任务比较困难，例如标示牌变化不大，很快模型就能训练到很好的效果，但是车道元素分布网络则十分难寻来呢
长尾任务数据十分稀少（例如异型车辆，事故等检测数据十分稀有）
有些任务数据有着大量的噪声

为了达到模型在所有任务都能取得良好的性能，需要合理的调节不同任务的权重，并且一旦确定不同权重的比重，就要在确定的权重下进行任务的调优，而不能频繁更改权重，导致其他任务的性能回退。

Training Across Different Tasks

因为模型在不同任务间进行不同程度的参数共享，因此利用不同的数据对一些子任务进行训练的时候，并不是整个网络模型都会得到训练，而是根据任务和数据 sample 整体网络的一部分进行训练，如下图所示。

为了避免训练部分网络的时候对于其他任务的影响，可以采取类似 Transfer Learning 中的 freeze 部分参数的方法。

Data Balance

为了解决长尾任务的训练，采用 Data Oversampling 来保证任务内的 Data Balance 以及任务间的 Data Balance。下图是红绿灯检测任务内的 Data Oversampling 的示意图：

Figure 7 通过 Oversampling 使黄灯和蓝色通行等的比例达到合适程度

在现实交通灯数据中，黄灯和表示通行的蓝灯非常有限，然而过度 inbalance 的数据将使得训练正确识别这些数据的模型变得十分困难，通过 oversampling 达到在一项任务内基本的一个数据分布的平衡。

另外在任务间也通过不同任务的优先级，重要程度等设定 oversampling rate 来调节不同任务的性能。

Hyper Parameter

除了上面提到的 oversampling rates，task loss weights 等 hyperparameter 外不同任务 head 的复杂程度，正则方法等也是 hyperparameter 调节的重要参数。

例如对于数据量不同的任务，应该对长尾任务及噪声较多的任务应使用较小规模的 head 以避免 overfitting。

对于常用的正则方法 early stopping，由于不同任务有不同的训练曲线，应通过调节不同任务的权重使得曲线趋势基本一致，以决定・一个统一的 early stopping 的条件。

Figure 8 多任务的模型在调节权重前无法使用 Early Stopping

Multi-task Training Scheduler

如下图所示，Tesla 利用分布式的训练机器进行多任务的训练以减少训练时间，Karpathy 提到 Tesla 更多采用后两种训练任务安排

Workflow & Collaboration

Data Engine& Active Learning

Tesla 利用 Shadow Mode 来采集数据，利用 Trigger 来触发主动的数据获取，从而实现 Active Learning。Data Engine 的示意图如下所示:

使用 Data Engine 来完成一项新任务的流程如下：

其中 Trigger 是利用高 recall 低 precision 的粗分类器来识别特定需要训练的场景来达到对上传数据进行筛选的机制，以提取 rare cases 从而提高数据的获取率。同时利用不同任务 trigger 的 sampling rate 可以控制不同任务占用的训练资源，从而平衡不同任务的训练效果。之所以 trigger 可以工作是因为 trigger 本质上是一个简化了的模型，同时 data engine 获取的数据量已经大大精简，因此后面还可以再利用人工进行一轮筛选来剔除 trigger 获取的的 false positive 的训练数据。

通过不断主动向 Tesla 超过 1 百万在全球行驶的车辆索取数据，Tesla 得以获得大量所需的特定类型的数据以训练庞大的 HydraNet 模型。

Collaboration

由于 Tesla Autopilot Team 是一个规模很小的团队，而庞大复杂的模型功能使得每个人经常负责不同的任务，因此一个标准的团队合作流程就成了如何调优模型同时不使得模型退化的关键。

Karpathy 的报告中提到几点在多人合作的 AI 项目中合作的经验，值得工业界团队借鉴。

Hyperparameter 不能够随意更改以改进自己的工作任务性能

因为 Tesla FSD 要处理复杂的任务，进行 1000 + 项感知任务，因此即使 FSD 使用一个极其巨大的 HydraNet 模型，该模型的表达能力也是有限的（Finite Model Capacity），每个团队成员在优化自己任务的时候应选用正确的方法，而不损害已有的模型性能。例如通过提高自己 sub task 在 Data Engine 里的 sampling rate，或者提高 sub task 在整体 Loss 中的权重，甚至简单提高自己 sub task loss function 的 scale，就可以使训练资源，模型 capacity 向自己 sub task 倾斜已获得虚假的性能提升，这种行为是容易实施的投机取巧，要严格杜绝。

要尽量避免 Finetune 历史记录复杂化

通过 Finetune，可以获得更好的模型参数，然而不像传统软件有着像 git 一样的版本控制软件去记录代码的更改，neural network 的 finetune 历史往往难以追踪。如果放任复杂的 finetune 历史交织在一起，所导致的问题是可能最终获得了一个很好的模型参数，但这样的参数是强依赖于复杂的 finetune 顺序而获得的，因为 finetune 顺序不可追踪，因此这样的模型参数即使性能优秀，但是其缺点是不能复现，因此实际工作中要尽量避免复杂的 finetune 叠加。

Evaluation & Test

Karpathy 将以 Neural Network 为主实现功能的软件称为 Software2.0，与依赖逻辑，数据结构，算法的传统软件不同，Software2.0 缺乏业界共识的 Best Practice。为此 Tesla 在开发过程中借鉴了很多传统软件中 Test Driven 的思路思路。

Tesla 利用强大的 Data Engine 获取大量的 Corner case 的数据生成 Unit Tests/Regression Tests for neural networks，例如下图所示就是特斯拉 Stop Signs 的 CT 流程，所有对于模型的更新必须保证模型的性能不发生回退，才能够提交更改，而保证不回退的办法就是所有 Unit tests 必须通过。