看到 DriveGPT 这条新闻的时候，我第一反应是去确认两个数字：4000 万公里量产车驾驶数据，1200 亿参数规模。这是自动驾驶行业里少见的、能同时把“数据”和“模型”都拉到很高量级的组合。第二反应才是去琢磨那个更关键的说法——生成式大模型。对我这种常年跟决策规划、规控系统和数据闭环打交道的人来说，这几个字比参数规模本身更值得拆。
说实话，过去几年大家聊自动驾驶大模型，更多还是在聊 BEV 感知、Transformer 骨干网络这些感知侧的东西。DriveGPT 把“生成式”放到驾驶决策这条主线上，意义不在于又多了一个大模型，而在于自动驾驶系统从“选一条好的轨迹”变成“直接生成一条轨迹”。这个方法论层面的迁移，影响的不只是某一个算法模块，而是数据怎么采、评测怎么做、车端怎么部署，甚至仿真平台怎么搭。这篇文章不打算复述新闻，我把自己在规控、数据闭环、模型部署和仿真测试上的一些经验串起来，尽量把 DriveGPT 这类大模型拆到能落地的颗粒度：先讲它到底在解决什么问题，再讲 4000 万公里数据意味着什么，然后是 1200 亿参数的架构和训练账，接着是 32.8 毫秒决策延迟背后的工程优化，最后聊聊仿真测试和上车之后的现实约束。想深入理解自动驾驶大模型的技术人员或者正在做方案选型的朋友，应该都能在里面找到自己关心的部分。
1. 先搞清楚 DriveGPT 在解决什么问题：从“挑轨迹”到“生成轨迹”
1.1 传统决策规划为什么越来越像瓶颈
传统自动驾驶系统一般是模块化流水线：感知给出一堆障碍物和车道线，预测模块估计周围车未来几秒的运动，规划模块在这个信息基础上生成一条自车轨迹，控制模块再去跟踪这条轨迹。这个流程听起来很顺，真正到了城市复杂路况，问题就出来了。
规划模块最经典的做法是“候选轨迹采样 + 成本函数打分”。代码里先生成几百上千条备选轨迹，每条轨迹都算一遍安全性、舒适性、效率性的加权成本，然后挑一条得分最低的执行。这条路线的天花板在于，成本函数权重是人调的，不同场景的最佳权重差别很大。高速上你可能希望效率权重高一点，跟着前车走走停停时又希望舒适权重高一点，在窄路避让行人时安全权重必须压倒一切。每次把车开到一种没见过的场景，都要重新审视这套权重，而且“打分”的办法本质上是判别式思维——模型只能判断哪条轨迹好，很难创造出一条从没在候选集里出现过的轨迹。
我做过一段时间城市 NOA 的规控调参，最怕的就是异形十字路口。路口的车流方向、地面标识、行人动线稍微组合一下，候选轨迹采样空间就很容易爆炸，要么采不到一条合理路径，要么采样到了但成本函数给的分数不对。这种问题靠堆规则很难彻底解决，因为规则只能覆盖你见过的场景，而真实路况是组合爆炸的。
1.2 “生成式”到底在用什么思路做事
DriveGPT 这类生成式大模型换了另一条思路：不再维护一个巨大的轨迹库、再从里面挑，而是把驾驶决策当成一个“条件生成问题”。给模型一段历史环境信息，它直接生成未来一段时间的自车轨迹。这个动作和 ChatGPT 生成回答本质上是一个套路，只是生成的单元从“文字 token”换成了“轨迹点/驾驶行为 token”。
我习惯用做饭来类比。传统方案是冰箱里有什么菜、客人点什么，你就翻菜谱找最接近的菜做；生成式方案是厨师直接根据食材和客人口味“即兴创作”。即兴创作的风险是可能会翻车，但优势是哪怕客人点了一道菜谱里没有的菜，厨师也能基于经验做出一个合理的东西。自动驾驶最大的挑战恰恰是“菜谱里没有的场景”，也就是长尾 corner case，生成式模型在理论上具备更好的泛化能力。
用公式来描述就是模型拟合条件概率 P(未来轨迹 | 感知历史, 道路环境, 导航意图)。训练的时候把海量真实司机驾驶行为当作语料喂进去，让模型学习不同路况下人类会怎么开；推理的时候输入当前场景，它逐帧生成自车未来的位置、速度和转向。这种范式的好处是模型见过的“驾驶风格”足够多之后，面对陌生场景时不是查表，而是从分布里采样一个合理结果。
当然，生成式并不意味着把安全交给模型裸奔。后面我会聊到，就算模型生成出一条轨迹，工程上仍然要加安全过滤和规则兜底，这一点和很多人担心的“端到端全靠神经网络”不太一样。但范式上的变化是真实的：决策规划从“选”变成了“生”，这决定了后续数据、评测和部署方式的连锁变化。
2. 4000 万公里量产车驾驶数据：比 1200 亿参数更难复制的东西
2.1 为什么必须是“量产车”数据
很多自动驾驶公司都在强调路测里程，但 DriveGPT 这支新闻里更值得细看的是“量产车”三个字。拿 4000 万公里这个里程来说，如果没有一支规模庞大的量产车队去跑，光是采集周期和成本就很难想象。更重要的是，量产车跑出来的路和测试车队跑出来的路，在分布上有本质差别。
测试车队一般有固定路线、有安全员、有近乎强迫症的设备标定，数据质量高，但场景多样性往往不够。量产车不一样，用户每天上下班、跑长途、去陌生的老城区、停进各种奇怪的地库，车辆的行驶区域和行驶时间是发散分布的。这种“野生的”数据才能覆盖到算法真正要面对的稀有场景。我见过太多在封闭测试场跑得很好、一放到用户手上就出问题的系统，主要原因就是测试数据的“分布”和真实使用场景不匹配。
所以 4000 万公里这个数字，不能单纯理解成“我们跑了很远的路”，而应该理解成“我们拿到了足够多的长尾样本”。城市里三轮车突然穿马路、前车为了躲井盖急打方向、路边施工区域只留一个很窄的口子，这些单个场景出现概率不高，但样本基数足够大之后，模型就都能见上一面。
2.2 量产数据怎么变成模型燃料：数据闭环的运转方式
光有路测里程不够，原始视频流不可能直接丢给模型训练，中间要有一整套数据闭环。按我在工程里的理解，这套闭环至少要包含下面几个环节。
车端先要有“影子模式”。车辆正常行驶时，系统在后台默默跑一套算法，拿自己的决策输出和真实驾驶员的操作去比对。两者出现明显分歧，或者车辆探测到异常场景，就会触发数据截取，把事件发生前后一段时间的传感器数据打包。这个动作很巧妙，它不需要人专门去标注“这里值得采”，而是用驾驶员行为作为天然筛选器。
数据上传之后是自动标注。车道线、交通标志、目标物 3D 框、红绿灯状态、行人意图这些标签尽量用大模型自动生成，人工只做抽检和难例精标。这里有个很关键的细节：4 千万公里的原始数据不可能全部进训练集，经过难例挖掘和自动标注之后，真正进到训练池的可能只有几万条关键片段。数据工程师的核心能力不是存数据，而是怎么从海量数据里把有价值的难例捞出来。
最后还要做数据集划分。训练集、验证集、测试集要分开，测试集尤其要保证分布贴近真实道路，否则模型在 benchmark 上刷分刷得很高，上了车还是露馅。很多团队训练集和评测集互相污染，结果指标一路向好、实际性能纹丝不动，这个坑我见得太多了。
2.3 “自动驾驶数据集”的价值边界
热词里有一个“自动驾驶数据集”，很多人会误会成只要有足够多的数据就能解决自动驾驶。现实是数据量只是前提，数据的配比和覆盖度才是核心。同样一万个片段，如果全是晴天高架直道，模型学到的东西就非常有限；如果里面含了各种雨天、逆光、施工改道、非机动车混行，哪怕总量只有一半，训练出来的模型都要扎实很多。
另外，真实路测数据永远有两个覆盖不到的地方。极端危险场景，比如对向车借道超车冲过来，真实路测里很难大量采集，因为不能真去撞；还有就是数据分布的长尾尾巴，总会有没见过的路况。这两块需要仿真数据去补，我后面有专门一part讲仿真，这里先记住一个结论：量产数据负责“见得多”，仿真数据负责“看到极端”，两者是互补关系，不是替代关系。
3. 1200 亿参数是怎么炼成的：大模型架构与训练工程账
3.1 车辆环境怎么变成模型能处理的 Token
要训练一个千亿参数的驾驶大模型，第一件事是定义输入输出的“语言”。对语言模型来说，token 是单词和子词；对 DriveGPT 这类驾驶模型来说，token 是驾驶场景的离散化表示。
工程上一个比较合理的做法是：多路传感器数据先进感知网络，输出一个统一的 BEV（鸟瞰视角）特征；这个特征再按时间和空间网格切分成 patch，和自车状态、导航意图一起编码成 token 序列。这个过程类似把一整段视频压缩成语义化的上下文，模型的注意力机制再去看这些 token 之间的关系——哪个障碍物在逼近、哪条车道在前方汇入、导航引导我往哪边转。
输出侧也是 token，只不过代表的是未来一段时间的轨迹点和控制量。模型按时间顺序自回归地生成每一个轨迹 token，先预测 0.1 秒后的位置，再基于这个位置预测 0.2 秒后的位置，一路推下去。这种时序生成方式和自然语言模型逐字写文章的结构非常一致，所以“生成式大模型”这个叫法不是包装，而是模型结构上就是同一套思路。
3.2 千亿参数模型的稀疏激活与分布式训练
1200 亿参数如果全部参与网络的前向和反向传播，算力成本和推理延迟都难以承受。按大模型领域的主流经验，这个量级大概率要上混合专家（MoE）架构。MoE 层里有多个“专家”子网络，输入 token 会通过路由网络选择性地分配到几个专家上，而不是让所有专家都处理所有 token。这样做可以在总参数量很大的同时，把单次推理和训练的实际计算量控制在一个可接受的范围。简单说，参数 1200 亿是“仓库里备了很多工具”，但每次干活只用其中最顺手的一小部分。
训练这种规模模型的工程复杂度也远超常规 CV 模型。分布式训练至少要组合数据并行、张量并行和序列并行三层策略：数据并行让每个 GPU 处理不同的数据批次，张量并行把一个大算子切到多卡上协同计算，序列并行处理超长 token 序列时避免单卡显存爆掉。混合精度训练也是标配，FP16 甚至 FP8 的训练精度能大幅降低显存和带宽压力，代价是需要一些技巧来抵消数值精度下降带来的训练不稳定。训练损失也不是简单的分类交叉熵，通常会包含轨迹回归损失、多模态损失、对比学习损失，让模型输出的轨迹既要贴得准，又要在多模态场景里保留多样性。
3.3 生成式输出和判别式输出的差异
既然聊到训练，就值得多说一句“生成式”和“判别式”的区别。传统规控算法里若是引入神经网络，很多是做判别式预测：给模型看一个操作，它输出一个“好/坏”的分数。生成式模型不是输出分数，而是直接输出完整轨迹分布。这意味着模型必须有能力“画出”一条此前没有出现过的合理轨迹，而不是在给定集合里排序。
这个差异对模型容量提出了很高的要求。如果模型容量不够，它就只能记住训练集里出现过的场景模式，换个长得稍微不一样的场景就画不出合理轨迹了。1200 亿参数的意义正在于此：它给了模型足够大的容量去吸收 4000 万公里数据里的驾驶经验。当然，云端大模型不可能原封不动放上车，它首先扮演的是“超级老师”，把烂路况下的最优轨迹造出来，再通过蒸馏把能力压缩到车端小模型上。这个链路我在下一部分详细拆。
4. 决策延迟 32.8 毫秒：从云端千亿模型到车端实时推理
4.1 32.8 毫秒这个数字意味着什么
热词里我看到一个细节，决策延迟 32.8 毫秒。这个数字很值得聊。自动驾驶规划周期常见的是 10Hz 到 20Hz，也就是每 50~100 毫秒需要输出一次新的轨迹，留给决策子系统的时延余量本来就不宽裕。32.8 毫秒意味着大模型通过工程优化之后，已经能够挤进实时决策的时间窗口。
一个自回归生成模型的延迟主要有两部分：第一是感知特征编码和前处理，第二是逐 token 生成轨迹。逐 token 生成是串行过程，每一帧预测都依赖上一帧的输出，这一步是天然的延迟大头。工程上能优化的点无非几个方向：限制生成步数、早停机制、并行解码策略、把整个生成过程编译成一个高效的推理图。延迟能从几百毫秒压到几十毫秒，背后是大量的算子融合和计算图优化，不是换个 GPU 那么简单。
4.2 云端大模型和车端小模型的分工
有个值得强调的思路是“车云协同”。DriveGPT 这种 1200 亿参数的模型，按我的理解不应该、也不大可能完整跑在量产车的域控制器上。量产车硬件算力再强也有限，而且功耗和散热都有严格约束。实际工程落地更多是“Teacher-Student”模式：云端大模型在离线阶段对海量真实场景生成高质量的驾驶行为轨迹，车端部署一个几亿到几十亿参数的学生模型，去学习老师的输出分布。
蒸馏之后的车端模型，参数量小了很多，但保留了“生成轨迹”的核心能力，配合 INT8/INT4 量化、结构剪枝、算子融合、TensorRT 这类推理引擎优化，才有可能在车规级芯片上做到 32.8 毫秒这个级别的决策延迟。量化是个精细活，不是简单把权重从 FP16 转成 INT8 就行，要做逐层精度分析、校准数据集选择、混合量化策略。我在实际项目里遇到过量化后模型在普通场景表现正常、一到夜间或者雨天就输出抖动的情况，后来查下来是某些层对精度特别敏感，必须保留 FP16。这类坑文档里很少写，基本要靠自己拿数据喂出来。
4.3 安全兜底：生成式轨迹不是最终答案
车端模型就算延迟达标，也不能直接把生成轨迹当最终指令执行。工程上通常还会加一个安全过滤器，对生成轨迹做碰撞检测、动力学可行性和交规约束校验。相当于大模型负责“灵光乍现”地给出一个聪明方案，规则安全层负责“踩刹车”接受或者拒绝这个方案。两层结构会损失一部分上限，但换来了可靠的下限。
我见过一些团队在讨论端到端方案时，恨不得把所有规则模块全部删除，觉得大模型能力强、不需要老一套。实际从工程安全角度看，这种“一刀切”非常危险。安全的正确姿势应该是模型输出越多样，安全过滤和监控逻辑越要独立和严格。真正意义上的安全不是让模型“永远不会犯错”，而是让模型犯错时体系还能兜住。
5. 仿真测试里的大模型：从《欧洲卡车模拟2》插件到规模化场景生成
5.1 一个游戏插件为什么值得聊
热词里有一条挺有意思，有人在《欧洲卡车模拟2》里实现了智能车道保持的自动驾驶插件。乍看和 DriveGPT 不是一回事，但内核逻辑很一致：传感器输入是游戏画面和激光雷达数据，决策模型输出转向、油门和刹车，控制系统再去执行。也就是说，它已经跑通了一个完整的“感知-决策-控制”闭环，只不过环境是模拟器。
这类仿真项目的价值不在于算法多先进，而在于它提供了一种低成本验证思路。真车测试一个雨夜加塞场景，要等天气、要等交通流、要冒安全风险；在模拟器里，场景可以随时构造，参数可以无限调。我在早期做规划算法时，很多边界情况都是在模拟器里先暴露出来，再带着问题去真车验证。现在做大模型也一样，不可能一上来就让 1200 亿的模型直接跑实车，仿真环境是必经的一站。
5.2 生成式大模型和仿真环境的相互成就
DriveGPT 这类大模型对仿真测试提出了更高要求，同时也给仿真测试带来了新工具。
先说测试：传统仿真测试看重的是“里程”，但是对生成式大模型来说，重点应该是“关键场景覆盖度”。模型见过多少种加塞方式、多少种路口形态、多少种异常驾驶行为，比它跑了多少公里虚拟路更有说服力。仿真平台需要有能力自动生成对抗性场景，比如用另一个智能体去主动测试主车的生成轨迹，看看模型会不会做出危险决策。
再说工具：大模型可以把真实路采数据变成可交互的虚拟场景。过去做场景重建，基本是用人工方式把道路拓扑和目标轨迹标出来；现在可以用 NeRF、3D Gaussian Splatting 这类技术把真实路口重建出来，再把交通流从静态里解放出来，让整个场景可以反复互动、变更交通参与者行为。这套流程相当于给大模型造了一个“可控的现实复制品”，场景库里存的不再是孤立的视频片段，而是能不断派生新情况的训练场。
5.3 评测要盯“最差情况”而不是“平均成绩”
大模型评测和传统规控评测有本质差别。传统规控可以用“平均碰撞率”“平均接管里程”这类指标；生成式模型天生有多样性，可能 99% 的场景都表现得很好，剩余 1% 的场景生成一条极其反直觉的轨迹。自动驾驶安全性的致命问题恰恰出在“最差情况”，而不是“平均情况”。
所以我在实际做评估体系时，会更关注分布尾部：把测试场景按难度分层，看模型在最难那几档的表现，看模型输出轨迹的离群程度，看安全过滤层被触发的频率。对生成式大模型，应该建立“场景库 + 自动回归测试”的机制，每天跑一遍，任何一个新版本只要在最难场景上出现退化，就直接拦下来。这套思路类似软件行业的 CI/CD，把算法迭代变成可以持续监控的工程流程。
6. 上车之后仍然要面对的硬骨头：安全、评测与可解释性
6.1 生成式输出“说不清原因”，怎么审
大模型上车之后，一个绕不开的现实问题是可解释性。规则系统出了异常，你能顺着 if-else 逻辑一路查下去；传统打分式规控也能把成本函数的各项分解出来，告诉你是哪一项权重超限了。生成式模型直接吐出一条轨迹，出了问题之后很难回答“为什么模型在这一帧选择了向左避让”这类问题。
工程上的补救手段是按场景记录上下文，也就是把模型输入、注意力权重、生成轨迹、环境真值全部存下来，事后回放。如果发现异常，用“场景回注”方式复现，通过扰动输入变量来判断模型主要受哪个因素影响。坦白讲这还做不到“模型自己解释自己”，但至少可以提供一条可追踪的链路，让问题能被定位和修复。真正做量产系统的时候，我建议把日志设计放在算法设计同等重要的位置，否则模型出了问题，排查效率会非常低。
6.2 安全体系要独立于模型，评测要持续
最后还想强调一下，大模型可以做决策，但不应该成为唯一的安全保证。量产系统里至少要有独立的监控模型和规则兜底，监控模型负责判断当前是否存在碰撞风险、是否偏离可行区域，必要时直接打断和修正生成轨迹。这个“独立”很重要，因为如果监控模型和生成模型共享同一套数据、同一套训练流程，它的错误模式也会高度相关，兜底效果会打折扣。
评测体系也是一样，不能只在研发阶段跑一遍，需要做到持续化和自动化。每天有新的量产车数据回流，定期有新的难题注入场景库，版本迭代必须有标准化的回归测试。神经网络模型有个特点，修了一个场景的问题，可能在另一个场景引入新问题，没有持续评测，根本发现不了。做这件事很繁琐，但它是大模型走向量产车上最不能省的一环。
6.3 给想上手的人一条务实路径
聊了这么多 DriveGPT 的原理和工程，最后说点个人的实在建议。如果你所在团队也在考虑做自动驾驶生成式大模型，不要一上来就追千亿参数。先找一个公开的驾驶数据集，比如 nuScenes 或者高质量的开源仿真环境，训练一个参数量在千万级别的条件生成模型，跑通“输入历史轨迹、输出未来轨迹”的闭环，然后在这个基础上去加场景复杂性、加蒸馏流程、加安全过滤和评测机制。把这条小链路跑扎实了，再讨论数据规模、算力投入和千亿参数才有意义。
为什么这么说？因为大模型项目真正的复杂度不在参数量本身，而在于它把数据、训练、部署、评测、安全全部串在一起。任何一个环节断掉，模型规模再大也落不了地。DriveGPT 的 4000 万公里和 1200 亿参数是结果，不是起点；它背后那套“数据怎么采、模型怎么训、延迟怎么压、场景怎么测、安全怎么兜”的完整闭环，才是真正值得反复琢磨的东西。
