特斯拉FSD端到端大模型演进：从规则代码到数据飞轮

这两年只要聊智能驾驶，绕不开的就是特斯拉FSD。很多人只知道FSD价格不便宜、功能时不时更新一下，但真正值得研究的，是它从“写了十几万行C++规则的模块化系统”转成“端到端大模型”这件事本身。我把特斯拉近5次公开演讲和技术分享反复梳理了一遍，从2022年AI Day、2023年CVPR自动驾驶专场，到FSD V12两轮大规模推送、2024年财报电话会议，再到2024年10月的“We, Robot”发布会，把FSD如何切换到大模型路线的逻辑完整理了出来。这篇内容既讲架构、也讲工程，适合正在做自动驾驶算法、搞AI大模型落地，或者想设计数据闭环体系的团队参考，读完你能看清端到端的骨架，也能少踩几个常见坑。

1. 先聊清楚：端到端到底替换了什么

1.1 传统模块化自动驾驶的复杂度诅咒

以前的自动驾驶方案，结构上非常教科书：感知模块负责识别车辆、行人、车道线、红绿灯；预测模块判断其他交通参与者的未来轨迹；规划模块在候选路径里找一条“安全、舒适、效率”的轨迹；控制模块再把轨迹换算成方向盘角度和踏板开度。每一层职责清晰，但也有一个逃不掉的困局——模块之间的信息在层层传递中不断损失，而每一层的工程师都在用“堆规则”的方式去对抗长尾场景。

我在前几年接触过不少类似的量产项目，最直观的感受是：高速场景还好，规则够用；一旦进入城市，左转待转区、潮汐车道、临时施工改道、行人横穿、外卖电动车贴身超车，这些情况的组合几乎是无穷无尽的。规则工程师今天修好一个“前车静止”的判断，明天又冒出来一个“前车静止但开着双闪且骑在实线上”的变体。代码量越来越大，可维护性越来越差，最后所有团队都会被这类corner case拖进泥潭。

1.2 端到端：从一行行规则到海量参数

FSD转向端到端的核心逻辑，用一个词概括就是“换引擎”。不再是人类工程师去定义“什么是障碍物”“什么是可行驶区域”“什么情况下要减速”，而是让神经网络在海量真实驾驶数据里自己学习“这种情况下应该怎么办”。输入是摄像头拍到的视频，输出直接是驾驶决策，中间没有手工设计的模块链。

这就和大模型的概念对上了。FSD的“大”体现在三个地方：参数量大，骨干网络是Transformer结构；训练数据大，用的是上千万段真实路驾视频；算力规模大，训练集群动辄几万张GPU起步。它不再是一个“写规则的软件”，而是一个持续被数据喂养、被评测迭代的“模型体”。我会在后面的篇幅里把这三个“大”拆开讲清楚。

2. 从5次公开演讲看FSD端到端演进路线

特斯拉FSD的技术演进不是一次发布会讲完的，而是藏在每一次技术分享的只言片语和架构变化里。我把近5次比较关键的公开节点列成了一张表，后文再逐个拆解。

2.1 2022年AI Day：先解决感知的统一表示问题

2022年AI Day给我印象最深的不只是机器人，而是FSD把感知集中到了一个统一的“BEV空间”里。所谓BEV，就是鸟瞰视角，把车身周围多个摄像头的画面投射到一个以自车为中心的俯视栅格上。做这项工作的原因很实际：摄像头是不同角度、不同焦距装车的，每路图像各自识别出的车道线、车辆位置之间可能存在冲突，必须转到一个统一坐标系下才能做后续决策。

配合BEV的，是占用网络（Occupancy Network）。它不要求模型精确判断“这到底是一台SUV还是一辆三轮车”，只要在某个栅格里输出“这里有东西被占用”的概率就行。这对异形障碍物特别友好，比如路上横着一根掉落的钢管，传统目标检测模型大概率识别不出来，但占用网络会说“这一格被占了，别压过去”。可以说，2022年AI Day已经把感知层“数据驱动化”这件事做扎实了，为后续真正的端到端铺好了地基。

2.2 2023年CVPR专场：从“识别任务”走向“基础模型”

到了2023年年中，特斯拉团队在CVPR这样的学术场合分享时，讲法升级了。他们不再只是谈“用神经网络做目标检测”，而是开始谈“在大规模视频输入上学习通用视觉表征”。这个思路和语言大模型的预训练逻辑越来越像：先用海量无标签数据学一个通用表征，再在下游任务上微调或零样本适配。

对FSD来说，这种“通用表征”意味着模型不只是认识车道线和车辆，而是开始具备一种松散的“驾驶常识”。比如，看到前方一群行人聚在路边，它不需要精确识别每个人的表情，只需要知道“这个区域大概率有动态障碍物出没”，从而降低速度、留出横向余量。这种能力很难靠人工规则写出来，只能靠大模型从数据里自己长出来。

2.3 FSD V12路测：全栈端到端第一次量产

真正让外界确认“端到端时代来了”的，是FSD V12从2023年底开始的小范围用户测试到2024年初在北美的大规模推送。公开信息里最直观的变化是：FSD团队把过去负责规划控制的那部分手工代码从系统里大幅移除，大量逻辑被合并进一个神经网络模型。当时有一个流传很广的说法是，V12“砍掉了数十万行C++代码”，虽然数字未必精准，但趋势是明确的——规划规则在系统里的比重急剧下降。

从测试视频看，V12在城市道路上的无保护左转、绕行静态障碍、与对向来车博弈等场景做得更像一个老司机了。它不再机械地遵循“停车线前必须停够2秒”之类规则，而是会看情况：右边完全没车，它会缓慢滑行通过；有车逼近，它就果断停住。这种“像人一样的弹性”正是端到端模型带来的体验升级。当然，V12也暴露了不少新问题，比如在某些路口的激进判断、对少见灯型的误读，这些在后面的章节里我再展开讲。

2.4 2024年财报会议：算力成了新的护城河

端到端模型吃掉算力的速度远超大多数人预期。在2024年的财报电话会议和相关披露中，特斯拉多次提到其AI训练集群的扩容进度。和训练语言大模型不一样，FSD的训练数据是千万小时级别的多视角视频，而且每一段视频不是一张静态图片，而是带时间维度的序列。训练模型时要同时处理时间、空间、传感器视角三个维度，数据吞吐量比文本大好几个量级。

这也是为什么他们在训练基础设施上投入那么重。没有足够的算力，数据采回来也只能躺在存储里吃灰。我当时看到他们披露的GPU规模时，第一反应是“这不只是一个车企，更像一个大模型公司”。到了这个阶段，FSD的竞争已经从“谁算法更巧”变成了“谁的数据管线和算力基建更厚”。

2.5 We, Robot发布会：把端到端推向无人驾驶

2024年10月的We, Robot发布会，产品属性远大于技术属性，但它把FSD的最终验收标准定出来了——无监督FSD，也就是去掉安全员、去掉方向盘的车自己跑。会上发布的Cybercab没有方向盘和踏板，意味着车辆必须完全依赖视觉大模型在开放道路上做决策。这对模型的鲁棒性要求是指数级提升的：以前出错了还能指望人接一把，现在出错就是事故。

从技术演进角度看，这次发布会其实是在给端到端大模型做“毕业答辩预告”。答辩题目不是“能不能识别障碍物”，而是“在毫无人工干预的情况下，能不能安全完成每一次出行”。这个标准比任何排行榜都残酷，但也正是这种极端验收条件，倒逼着架构、数据、算力三个轮子必须同时转起来。

3. 拆解FSD端到端大模型的架构细节

3.1 输入端：多路视频流怎么变成token

FSD的传感器配置很“固执”，坚持纯视觉方案。车上装了8个摄像头，覆盖前视、前广角、侧视、后视等不同视野。端到端模型要处理的不是一张图，而是带时间维度的连续视频流。这套逻辑和最近大家常说的“视频大模型”很像：每一帧图像被切成patch，通过卷积或线性映射变成嵌入向量，然后和多帧的历史信息一起进入Transformer。

比较有工程味的部分是多视角的位置编码。每个摄像头在车身上的位置、朝向都不一样，模型必须知道“当前这个token是来自左侧摄像头还是前视摄像头”，才能在统一的特征空间里做融合。你可以把它类比成语言模型里的“位置编码”——只不过语言任务只需要编码一个维度，就是token在句子里的顺序；FSD要编码的维度更复杂，包含空间位置、时间戳、摄像头ID。处理不好这件事，模型会产生感知错乱，比如把左侧车道的车误判到右侧去。

3.2 主干网络：稀疏注意力与动态查询

FSD的骨干网络一直围绕Transformer展开，但车载芯片的计算资源有限，8路视频产生的事件数量又非常巨大，所以不能把语言模型那套“稠密全局注意力”原样搬过来。公开演讲里提到的方向基本是稀疏注意力：不是每个token都和所有其他token做交互，而是先根据空间邻近性、时间关联性筛选出真正需要关注的token子集，再做注意力计算。这就像人在开车时也不是同时盯着所有方向，而是根据场景动态分配注意力。

模型里还有一个很关键的设计是“可学习查询”机制。模型先初始化一组与物体位置无关的可学习向量，这些向量通过交叉注意力不断从图像特征里查询和聚合信息，最终变成对场景里各种要素的表征。这样做的好处是：不需要提前设定“最多检测50个物体”这样的硬上限，目标多时就多分配一些查询，目标少时查询自动空闲，灵活性比传统检测头高出不少。

3.3 输出端：轨迹束与安全约束层

很多对自动驾驶了解不深的人以为“端到端”就是把视频丢进去，然后模型直接输出方向盘角度和油门踏板开度。实际上，量产系统很少这么鲁莽，FSD的模型输出也并不是直接连到车辆执行器。从公开的架构思路来看，模型的规划头输出的是多条候选轨迹，每条轨迹带一个置信度或代价估计，再由后续的车辆控制接口和安全监控模块做一次“可行性校验”。

这层安全约束非常关键。模型可以输出“左转”，但如果车辆当前时速、转向角已经接近物理极限，那么这条轨迹再合理也不能直接执行。控制层会先判断这条轨迹是否在车辆的动力学包络之内，是否会和周围障碍物发生碰撞，全部通过后才转换为转向、加速、制动指令。也就是说，“端到端大模型”接管的是决策大脑，但车辆仍然有一套确定性的机械与安全保护底线。这一点对我个人来说启发很大，后面我会再展开说。

3.4 它凭什么可以叫“大模型”

我试着用一张表把FSD端到端模型和我们熟悉的语言大模型放在一起对照，你会发现它们在方法论上惊人地一致。

所以，用“大模型”这个词来描述FSD并不是比喻，而是它在技术路线上真正跨过了那条门槛：以大规模参数为基础、以海量数据为燃料、以数据飞轮驱动持续迭代。它和我们常说的LLM是同一个思想在不同物理世界场景下的映射。

4. 数据飞轮与训练工程：端到端的背后底气

4.1 影子模式：一支不用发工资的车队

FSD最让传统自动驾驶公司羡慕的资源，不是算法团队人数，而是它拥有一个庞大的量产车队。这些车在用户日常驾驶时，如果开启了影子模式，系统会在后台“偷师”：人类司机在开，FSD在同步运行，但不接管车辆。一旦FSD的预测决策和人类司机的实际操作出现明显分歧，系统就会把这一段数据自动截取并回传。

这个机制让我印象很深，因为它本质上就是大模型训练里的“难例挖掘”。日常驾驶数据大部分是单调重复的：跟着车流走、在高速上巡航、等红灯。如果只拿这些数据去训练，模型会变得平庸。影子模式的价值在于，它能自动找到那些真正有挑战性的片段——司机突然紧急避让、遇到复杂路口、前车急刹——这些片段才是模型能力提升的关键。这支“数据采集车队”不用额外发工资、不用规划路线、不用维护设备，每天自然产生几十万甚至上百万公里的差异化数据，这是很多团队想做端到端却做不起来的核心原因。

4.2 自动标注：用大模型标注大模型

数据传输回来之后，不能直接训练，得先做标注。如果靠人工标注一段视频里每一帧的车道线、障碍物、红绿灯状态，成本和时间都是灾难。特斯拉走的路线是4D自动标注：利用车辆多次经过同一路段的历史视频，离线重建三维场景，然后在一个连续的空间里统一标注，而不是一帧一帧标。

整个流程有点像一个“学子”流程：先用较大的离线模型完成初步标注，再把标注结果混合人工抽检和修正，形成高质量训练集。这其实是“教师模型-学生模型”的蒸馏思路在数据环节的应用：教师模型不直接参与车载推理，它只负责离线环境下慢慢打磨数据质量；车载的端到端模型作为学生模型，从这些高质量标注里学习。离线模型可以不计成本地跑大算力、用更大规模和更多推理时间，但量产模型必须在毫秒级延迟内完成推理，这个分工非常务实。

4.3 场景回放库与回归测试

训练数据不是越多越好，关键是每一次迭代都不能让模型“退步”。FSD团队会维护一套覆盖历史困难场景的回放库，包括各种类型的左转、无保护路口、雨雾天气、施工改道、罕见车辆类型等。每训练一个新版本，都要在回放库里跑一遍回归测试，确保模型在修复一批场景的同时没有破坏另外一批。

这跟软件开发的“持续集成、持续回归”是同一个道理，只是对象从“代码库”换成了“模型权重”。我在自己的项目里也会做类似的事：把历史出错的案例整理成一个“坏case集”，每次模型改完先跑一遍这个集合，再放出去做更大范围的评测。没有这层约束，大模型迭代就是盲人摸象，你可能觉得新版本变聪明了，但实际上它在一个偏僻场景里悄悄变笨了。

4.4 算力基建：数据量级决定训练上限

端到端大模型对算力的渴求和语言大模型一模一样，甚至更夸张。语言模型处理的是句子，每个样本只有几千个token；FSD处理的是多视角视频，一个训练样本可能包含几十上百帧，每帧又由8个摄像头画面拼合而成。模型不仅要理解“现在看到了什么”，还要理解“过去几秒发生了什么变化”。这种时空联合建模的数据复杂度，让训练集群的资源消耗成倍上涨。

从公开信息看，特斯拉在训练集群上的投入是持续加码的，目的是支撑端到端模型不断增大、训练数据不断增多的迭代循环。算力在这个体系里就像水之于鱼，没有足够的训练资源，数据管线做得再好也白搭。很多团队做端到端卡住，不是算法方案不行，而是训练速度让我们一天只能迭代一个版本，别人可能一小时就转一轮。规模上的差距最终会变成效果上的代差。

5. 安全与评价体系：端到端不能是失控的黑盒

5.1 确定性安全规则还会保留

FSD虽然是端到端大模型主导决策，但整个系统绝对不是“完全没有一条规则”。我在前面提到，模型输出的轨迹集合之后会经过安全校验层。这个实践非常重要，它说明一个成熟的端到端系统懂得“大模型负责能力，规则负责底线”。

底线是什么？是车辆动力学极限、是物理上不能穿墙过车、是最基本的碰撞避免。这些约束不适合让神经网络去“学习”，因为它们太基础、太刚性，一旦违反就是事故。更合理的做法是让模型在约束划定的空间里去自由决策，既保留大模型的灵活性，又守住安全红线。我在给一些传统行业团队做AI方案时，也建议他们用这个思路：把模型当“大脑”，但外围的强制约束不能省。

5.2 怎么评价一个端到端模型好不好

端到端模型没有传统模块里“感知准确率”“车道线IoU”这类指标可以直接看，评价体系必须从“行为”层面来设计。业内比较通用的是平均接管里程MPI，也就是每开多少公里需要人来接管一次；以及“人为干预率”“打扰率”，前者是不得不接管，后者是系统虽然能处理但让乘客感到不适的操作。

还有一个非常有意思的做法是影子模式离线重放：把新版本模型放到历史采集的驾驶数据里跑一遍，故意不让它控制真实车辆，而是让它“想象”如果自己当时在开会怎么样，然后和真实驾驶员的操作做对比。这本质上是一种大规模A/B测试，不需要冒着安全风险就能评估新模型的水平。这种评测思路其实对任何AI项目都适用——在正式上线前，先找一个不影响真实业务的“影子环境”去充分验证。

5.3 版本灰度与快速回滚

大模型的部署不像普通软件那样“发完就完事”。FSD的做法是按车队比例灰度放量，先给一小部分用户推送新版本，跑一段时间看统计指标，再逐步放开。如果某个版本在某类场景下指标异常，需要能快速撤回，而不是让所有用户都跟着冒险。

这种灰度机制背后是一整套模型版本管理和监控系统。每个版本在哪个用户群、开了多少比例、表现如何，都要实时可见。我踩过类似的坑：早期做模型迭代时，新模型在评测集上分数更高，就着急全量切换，结果用户反馈里出现了一批“旧版本不会错但新版本错了”的场景。从那之后我做了一个硬性习惯——再好的模型也不能全量直接上，必须经过灰度观察和可回滚阶段。FSD的大规模推送方式，本质上也是这个原则的严格化。

6. 从FSD方案里，我看到的几个可复用经验

6.1 数据质量比参数尺寸更值得投入

现在聊大模型，很多人第一反应是“把参数做大、堆算力”。但看FSD这几年踩下来，真正拉开差距的是数据体系：怎么低成本采集、怎么自动标注、怎么筛选有价值样本、怎么维护回放库。参数大只是必要条件，不是充分条件。再大的模型遇到乏味或错误百出的训练数据，照样学不出好东西。

我给做AI落地的团队一个建议：如果你准备用大模型替换一个老系统，先把“数据从哪来、怎么标注、怎么更新”这三件事想清楚。别等到模型训完一轮才发现数据质量参差不齐，再来返工，那个成本足够你重新做一次项目。数据工程不性感，但它决定了你的模型天花板。

6.2 别把规则系统当成一次性成本扔掉

端到端模型上线了，不代表系统里原有模块都可以拆掉扔进垃圾桶。FSD给我们的示范是，部分手工规则被砍掉，但“安全规则”“物理约束”这些层面的确定性逻辑仍然保留，甚至因为模型的复杂化而变得更加重要。规则和模型并不是对立的，规则兜住系统的下限，模型负责拉高系统的上限。

如果你听到有人喊“有了端到端，所有规则都不需要了”，那基本可以判断对方缺少量产经验。做工程不是做学术畅想，任何大模型产品在真实环境里都免不了要配置约束规则、兜底逻辑、降级策略。这些看起来“不智能”的代码，恰恰是让智能模型安全发挥价值的关键所在。

6.3 端到端不是目的，数据驱动的工作流才是

FSD给我最大的启发，不是“端到端”三个字，而是它背后那个完整的工作流：从影子模式采集数据，到自动标注，到模型训练，到回放库回归，到影子模式重放，再到灰度推送，最后又回到数据采集。这是一个闭环，而且环环相扣。它的核心价值不是某一次模型的“灵光一现”，而是这套机制可以持续、稳定地把数据变成更安全的驾驶行为。

这种“不做一次性交付，而是搭持续进化体系”的思路，其实可以迁移到很多领域。我后来做项目时就刻意从“交付一个模型”转向“搭一条数据迭代流水线”，早期多花了一些时间，但后续每次迭代的效率都提升明显。你想学习的不是FSD的某个网络结构，而是他那一整套“让模型不断变好”的工程体系。把这件事想明白了，哪怕你不在自动驾驶行业，这套方法论也会很有价值。

最后再分享一点个人感受。梳理完这五次公开演讲，我最大的感触不是端到端大模型多神奇，而是整个行业的“重心”彻底变了：以前凭经验和规则写代码，现在靠数据、算力和评测体系来养模型。如果你也正打算用大模型去替代你手里那套老规则系统，我建议你从第一天就按数据飞轮的思路去设计，别把它当成买一个现成的模型，而是搭一个能让模型持续进化的系统。采集、标注、训练、评测、灰度，少了哪一圈，这个飞轮都转不起来。