看到 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 亿参数是结果不是起点它背后那套“数据怎么采、模型怎么训、延迟怎么压、场景怎么测、安全怎么兜”的完整闭环才是真正值得反复琢磨的东西。
