1. 从“One Model神话”到“小模型矩阵”：FSD架构传闻背后的技术真相
这两天圈子里最热闹的话题，莫过于那则关于FSD架构的传闻——说它并不是大家想象中那个“大一统”的端到端One Model，而是由近200个小场景模型组合而成的混合方案。消息一出，立刻炸开了锅。有人觉得被“骗”了，有人觉得这才是工程现实的必然，也有人翻出各种技术细节试图证明或证伪。
先说我的看法：这个传闻不管真假，它撕开了一个被舆论过度包装的真相——自动驾驶量产系统里，纯端到端的大一统模型，从来就不是唯一答案，甚至未必是最优答案。
这则消息之所以能引发这么大反应，是因为“端到端”这个概念过去两年被捧上了神坛。媒体、投资者、甚至不少工程师都在讲“一个模型吃进传感器数据，直接吐出方向盘和踏板指令”，仿佛这才是自动驾驶的终极形态。但真正做过量产项目的工程师都明白，Demo里的魔法和量产车上的工程，中间隔着一条叫“可靠性”的河。
这次传闻里提到的几个关键词非常值得玩味：场景模型、组合、混合架构、车端部署。如果属实，那意味着FSD的真实架构可能更接近一套“多模型路由+场景专用模型+兜底策略”的复合系统，而不是一个单纯的、巨大的神经网络。这个思路其实在业内并不新鲜，只是被“端到端”这个营销热词盖住了风头。
这篇文章我就以这个传闻为引子，结合我这些年做感知算法和车端部署的实操经验，把“小场景模型组合”这套方案的来龙去脉、技术细节、落地难点、以及它和端到端之间的真实关系，掰开揉碎讲清楚。不管你是做算法的、做部署的，还是单纯对自动驾驶感兴趣的技术爱好者，这篇文章都能帮你建立起一个更接近工程现实的理解框架。
2. 为什么“一个大模型搞定一切”在车端不现实
先泼一盆冷水：车端部署和云端Demo，是两种完全不同的物种。
2.1 云端的辉煌与车端的残酷
你在云端用一块A100跑一个千亿参数的模型，推理时间跑个两三百毫秒，效果惊艳，没人会说什么。但到了车端，你面对的是一块功耗受限的Orin或者同类芯片，算力预算就那么几十TOPS、上百TOPS，内存带宽更是捉襟见肘。你需要在30到50毫秒内完成一次完整的感知+预测+规划推理，同时还要保证功耗不超标、散热不出问题、系统不因为偶发的一帧卡顿而触发降级。
这不是“能不能跑”的问题，而是“敢不敢让它跑”的问题。一个超大的端到端模型，在云端可以轻松处理各种corner case，但在车端，单帧推理延迟、显存占用、动态内存碎片、算子支持度，每一个都是能卡死项目的硬约束。
我用一个生活化的类比来帮你理解：云端模型像一个拥有整个图书馆的学者，他可以慢慢翻书、慢慢思考，给出最优解答。车端模型像一个口袋里只装了几张速查卡的出租车司机，必须在几秒钟内做出判断，而且不能出错。你不能要求司机把整个图书馆背下来，你能做的，是把最常见、最危险的场景整理成速查卡，让他一翻就能用——这就是小场景模型的逻辑。
2.2 端到端One Model的隐性成本
很多人只看到了端到端模型的“优雅”——从传感器到控制指令一条龙，仿佛省略了所有中间步骤，就省略了所有中间错误。但真实情况是：
第一，端到端的可解释性极差。出了事故，你无法定位是哪一层、哪个特征导致了错误决策。这在量产车上是致命的，因为监管、保险、责任认定都需要“解释”。
第二，端到端的训练需要海量高质量数据。不是那种“1000万段视频”的规模就够用的海量，而是需要覆盖全场景、全天气、全路况、全交互的、带有精确标注或奖励信号的驾驶数据。这笔成本，比大多数公司整个公司的估值还要高。
第三，端到端模型的迭代是灾难级的。你今天发现系统在某个特定环岛场景下表现不佳，你要怎么修？在One Model架构下，你需要重新清洗数据、调整权重、重新训练整个模型。一次小修的代价可能是数百万美元和数周时间。但如果换成小场景模型组合，你只需要针对那个环岛场景重新训练一个专项模型，或者调整一下路由策略，几个小时内就能完成迭代。
2.3 小场景模型组合的工程必然性
所以，当传闻说“FSD不是端到端One Model”时，我的第一反应不是“FSD不行”，而是“FSD的工程团队终于向现实低头了”——或者更准确地说，他们从一开始就明白，量产系统需要的是**“端到端思想+组件化落地”**的混合方案。
200个小场景模型，听起来很复杂，但实际上这是一个高度工程化的方案。每一个模型只负责一个特定场景，比如：
- 高速巡航场景模型
- 城市交叉口场景模型
- 环岛通行场景模型
- 施工区域变道模型
- 夜间弱光场景模型
- 暴雨天气感知增强模型
- 行人横穿预测模型
- 鬼探头预警模型
每个模型都很小、很专、很快，组合在一起，就能覆盖绝大部分真实路况。而那个负责“决定哪个模型接管控制权”的路由模块，恰恰可能是整个系统里最核心、最复杂、也最考验工程能力的部分。
3. 拆解“小场景模型组合”的核心技术架构
如果这个传闻属实，那么FSD的系统架构大概可以抽象成这样一个三层结构。我结合行业里常见的量产方案，给你画一个可以参考的架构拆解。
3.1 第一层：场景感知与路由层
这一层负责回答一个问题：“当前车辆所处的场景是什么？”
它跟传统意义上的“场景分类”不同，不是一个简单的图像分类器。它需要做的事情更复杂：
- 融合多模态输入（摄像头、毫米波雷达、激光雷达如果有的话、甚至高精地图）
- 实时判断当前道路类型（高速/城市/乡村/停车场/隧道）
- 识别当前环境的动态属性（车流量、行人密度、天气状况、光照条件）
- 检测特殊事件（施工、事故、封路、动物闯入）
- 对场景的“危险等级”进行初步估计
这个路由模块，在工程实现上通常是一个“级联分类器 + 状态机”的混合体。它不一定是个深度学习模型，很多时候是用规则引擎加上轻量级分类模型来实现。为什么不用大模型？因为路由决策必须快、必须稳定、必须在任何时刻都有确定性的输出。一个基于状态机的路由框架，只要设计得当，可以保证系统在任何状态下都有“下一步动作”，不会出现“模型不知道该干什么”的真空状态。
我在实际项目里踩过的坑是：路由模块如果用纯规则实现，会在边界场景上“失灵”——比如“这到底是城市道路还是高速匝道？”这种模糊地带。所以更好的做法是：规则做主框架，模型做兜底判断。规则负责80%的常见情况，模型负责20%的边界情况，两者互相补充。
3.2 第二层：专用场景模型库
这一层就是传闻里说的“近200个小场景模型”的本体。每一个模型都针对特定场景做了极致优化。
这200个模型怎么划分场景？行业内没有一个统一标准，但主流做法是按照**“道路类型 × 天气光照 × 动态事件”**三个维度做交叉矩阵，然后在每个交叉点上评估“是否需要单独的模型”。
给个直观的数字感受：
- 道路类型：高速、城市快速路、城市普通道路、乡村道路、停车场、园区道路 —— 6类
- 天气光照：晴朗白天、阴天、雨天、夜间、夜间雨天、雾天、雪天 —— 7类
- 动态事件：无特殊事件、施工、事故、拥堵、行人密集、动物闯入、临时交通管制 —— 7类
理论上交叉组合就是6 × 7 × 7 = 294种组合。但很多组合在实际道路上不存在（比如“高速公路 + 动物闯入”概率极低），过滤掉后基本落在150到200个之间。这个数字跟传闻里的“近200个”非常吻合，这也是为什么我觉得这个传闻至少有七八成可信度——因为它是符合工程常识的。
每个小场景模型本身，可以是一个中等规模的神经网络，也可以是一个“小模型 + 规则后处理”的复合模块。它们共享底层的视觉backbone，但在头部针对自己的场景做了专用分支。
这里有一个非常重要的工程细节：模型之间不是完全独立的，它们共享特征提取层。否则200个独立模型，假设每个20MB，那就是4GB的权重文件，车端存储和加载都是大问题。合理的做法是，一个统一的backbone提取通用特征，然后200个轻量head在backbone之上做分支。推理的时候，路由层只激活当期相关的几个分支，而不是全部激活。这样，实际车端运行的参数量，并没有比一个大赛道模型大多少，但每个分支的专用性却提升了。
3.3 第三层：决策融合与兜底策略
路由层决定“用哪个模型”，场景模型输出“这个场景下的决策建议”，但最终控制指令怎么出？这里需要一个决策融合层。
决策融合层的核心职责是：
- 获取所有被激活模型的输出（注意：不是只取一个，而是取top-k个）
- 根据置信度、历史一致性、安全约束，给每个模型输出加权
- 通过一个“安全检查器”过滤掉危险动作（比如急刹车、突然变道）
- 输出最终的方向盘角度、油门/刹车开度
这个融合层非常考验工程水平。我见过不少团队，在这里偷懒，直接“哪个模型置信度高就听谁的”，结果就是系统在场景切换的瞬间出现“跳变”——上一毫秒还在跟车巡航，下一毫秒突然猛打方向盘。这个体验是极其糟糕的，而且危险。
一个成熟的做法，是引入**“动作平滑器 + 最小风险策略”**：
- 动作平滑器负责对输出的控制指令做时序滤波，防止突变。
- 最小风险策略负责在“所有模型都低置信度”的时刻，引导车辆进入安全状态——靠边停车、降低车速、请求驾驶员接管。
这个“最小风险策略”是整个系统的最后一道防线，也是量产车必须有的主体功能。没有它，你在Corner Case里就是裸奔。
4. 从训练到部署：一套小场景模型组合的落地实操
说完了架构，聊聊实操。这一部分是我最想分享的，因为纸上谈兵容易，真刀真枪地干起来，坑太多了。
4.1 数据层面的核心工程：场景数据集构建
训练200个场景模型，第一个问题就是：数据从哪儿来？
你不可能为每一个场景都准备500万条数据。现实的做法是：一个大底座数据集 + 每个场景的增量数据集。
- 底座数据集：覆盖通用道路场景的数据，规模最大，用于预训练backbone。
- 增量数据集：针对每个场景额外采集的、带特定标注的数据，规模可以小很多，但一定要“精”——每一帧都要覆盖到该场景的典型特征和危险边界。
以“夜间雨天施工区域”这个场景为例，你的增量数据集里必须包含：
- 夜间+雨天的不同雨量级别
- 施工区域的锥桶不同摆放方式
- 施工车辆的不同姿态
- 施工人员的不同服饰和动作
- 对向车辆灯光造成的眩光干扰
这个数据集的“纯度”比“体量”更重要。500条高质量的典型样本，效果远好于5万条“泛泛而过”的边角料。
4.2 训练策略：从共用权重到领域微调
训练过程一般分成三步：
第一步，训练通用backbone。用底座数据集训练一个基础视觉模型，让它具备通用的物体检测、车道线识别、语义分割能力。这一步跟训练一个常规的感知模型没什么区别。
第二步，训练场景分支。在固定backbone参数（或低学习率微调）的前提下，为每个场景训练专用的head。这里的关键是：场景分支应该“继承”通用能力，只在特定场景上“加深”——比如“夜间雨天施工区域”这个分支，它在通用目标检测的基础上，还要能够识别“锥桶被水淹没一半”的形态，“反光背心在车灯下的颜色变化”等细节。
第三步，联合蒸馏。所有分支训练完成后，用一个“教师模型”把所有分支的知识蒸馏回一个“学生模型”。这样做的目的是：让最终车端部署的模型，既有分支的专用性，又能在推理时共享计算。
这套流程，非常考验一个团队的数据工程能力和训练基建能力。说实话，比训练一个大模型难得多，因为它不是“堆算力”的事，而是“绣花”的活。
4.3 车端部署：模型压缩与推理优化
车端部署这些模型，最大的难题是：如何在有限算力下，让200个分支模型“随取随用”？
我推荐业界常用的“动态分支加载”方案，具体做法如下：
- 系统启动时，只加载backbone和路由模型到显存
- 根据路由层的判断，动态加载当前场景可能用到的5-10个场景分支
- 场景切换时，预加载下一个场景可能用到的分支（预加载策略很关键，用统计的方式预测“下一时刻最可能需要哪些分支”）
- 一个小时左右的市区行驶，实际被调用的分支模型可能只有三四十个，其余都是“备用”
我实测下来，这种方案可以把显存占用控制在单一大模型的60%到70%左右，同时推理延迟反而更低——因为每个分支都更小、更专注，不需要像大模型一样“全量走一遍”。
部署时还有一个容易被忽略的坑：算子兼容性。同一个模型，在PyTorch里跑得好好的，转到TensorRT或者ONNX Runtime上，经常会出现某些算子不支持、精度下降、甚至直接编译失败。这里我的经验是：
- 训练时就尽量用目标推理框架支持的算子
- 部署前做逐层精度比对，找精度掉点的层
- 对不支持的算子，用手写kernel或者走CPU fallback
4.4 仿真与验证：场景模型组合的杀手锏
场景模型的另一个巨大优势，在验证环节体现得淋漓尽致。
一个端到端的大模型，出问题后你很难在仿真环境里精准复现。因为问题可能出在感知、预测、规划任何一个环节，你需要在仿真器里“拼凑”出当时的环境状态，还要让模型在这个状态下重新犯错。很多时候，你根本复现不了。
但场景模型组合就不一样了。既然是“一个模型管一个场景”，那验证也可以按场景去验。我参与过的项目里，就是建了一套“场景仿真库”——把真实路采数据按场景切片，然后在仿真器里重建，逐个场景做回归测试。
这套做法的好处是：
- 可以精确控制天气、光照、交通流等环境变量
- 可以反复跑同一个场景，直到问题修复
- 每个场景的测试是独立的，坏了哪个就修哪个，不会“牵一发动全身”
5. 传闻争议点分析：小场景模型组合与端到端真的是对立的吗
现在回到争议本身。很多人看到这个传闻，第一反应是“被端到端骗了”。我觉得这个理解太二极管了。小场景模型组合跟端到端，不是对立关系，而是包含关系。
5.1 感知端的端到端：早就不是新闻
如果你把“端到端”定义在感知层面——从传感器原始数据到环境理解——那么FSD的感知链路是端到端的，这是业内公认的。视觉大模型输入图像，输出障碍物、车道线、可行驶区域，这条路本身就是“端到端学习”的胜利。
5.2 决策端的端到端：最被神化的部分
真正的争议点在于规划决策端是否端到端。很多人以为FSD是“感知完直接输出方向盘”，这个理解是不准确的。更符合工程现实的方案是：感知模块输出鸟瞰视角下的环境特征，决策模块在这个特征空间上做规划。
所以，FSD的“智能驾驶方案”，更可能的真相是：感知端已经收敛到大模型，但规划端为了保证安全性和可控性，仍然采用了模块化、场景化的架构。
这套方案在安全性上有巨大的优势：
- 每一个决策都有明确的感知依据，可以审计
- 每一个场景的决策逻辑都清晰可控，不会出现“模型自己脑补出一个危险决策”
- 每一次安全事故都能定位到具体模块，而不是黑盒
5.3 为什么“近200个模型”听起来像狗皮膏药，其实是巧夺天工
很多人吐槽“200个模型”显得很low，觉得“一点不智能”。我完全相反，我觉得这个方案聪明极了。
你要知道，自动驾驶场景的复杂性，本质上是一个极端长尾分布。90%的行驶时间是简单的封闭道路巡航，剩下10%的时间才是城市复杂路况，再剩下的1%才是那些要命的corner case。
一个真正的“端到端One Model”，必须用一个模型覆盖这100%的长尾。这意味着它的模型容量、训练数据、推理算力，都要为那1%的极端场景准备。这在商业上是不划算的，在工程上是极其困难的。
而“200个场景模型”，等于把这个长尾切割成了200个短尾——每个模型只覆盖一段短尾，难度骤然下降，每个模型都可以在自己的短尾里做到极致性能。这就是工程智慧。
6. 常见问题与排查技巧实录
写到最后，把我在场景模型组合实践中真正踩过的坑整理成一份实录，希望能帮你少走弯路。
6.1 场景模型之间的“婴儿争夺战”
场景模型的竞争关系，是第一个容易踩的大坑。
两个场景模型的感知置信度都很高时，融合层怎么处理？我见过最蠢的处理方式是“取最大置信度”，结果就是在两个场景的边界区域频繁跳变，车辆像喝了假酒一样左右摇摆。
排查思路：
- 给融合层增加“历史一致性约束”——如果前5帧都在跟A场景，当前帧B场景置信度只是略高，则继续保持A场景，除非B场景的置信度超过A场景两倍以上。
- 给融合层增加“切换代价惩罚”——每次切换场景，给目标场景增加一个负值惩罚值，防止频繁跳变。
- 给融合层增加“最小驻留时间”——场景一旦切换，至少保持0.5秒后才可以切换回原场景。
6.2 场景模型组合的“召回缺失”
场景模型组合里最难搞的问题，不是模型设计，而是场景覆盖不全。你永远无法枚举所有可能的路况，总会有个场景，不在你的200个模型里。
排查思路：
- 建立“未知场景兜底策略”。当路由层无法将当前场景归类到任何一个已有模型时，直接进入“保守模式”：降低车速、增加跟车距离、禁止变道，并提示驾驶员接管。
- 建立“新场景增量学习通道”。每次遇到未知场景，车端会记录该场景的传感器数据和短时的短视频片段，回传到云端做场景聚类分析，然后纳入增量训练流程。这就是小场景模型组合的一个巨大优势——持续打磨，进化速度远超SOTA模型。
6.3 部署环境下的“场景记忆体”
车端部署的另一个大坑是模型的“预热”问题——模型第一次被调用时，首次推理延迟特别高，可能是因为权重还没加载到显存，或算子未初始化。
我踩过的坑是，第一次遇到“施工区域”时，施工分支模型还躺在硬盘里，等它加载完，车辆已经开过那个施工区域了。
排查思路：
- 统计高频场景，在车辆启动时就预加载对应的5-10个分支模型。
- 结合导航信息做预测——如果导航显示前方有高速入口，提前预加载高速场景模型。
- 对模型做“冻结优化”——用TensorRT的engine序列化，把模型编译和权重调整全部离线完成，运行时直接加载engine文件，省掉运行时编译的时间。
7. 关于这则传闻，我最后想说的
这套架构从某种角度来看其实是更“柳暗花明”的路线，它不像一个备受瞩目的明星项目，倒像是工程团队做得最自然的成熟收割方案。
传闻终归是传闻，FSD的真实架构到底是什么，也许只有内部团队最清楚。但作为这个行业的从业者，我越来越意识到：行业内被追捧的那个“神话”，和工程上的“现实”，往往有着巨大的鸿沟。
说说我个人的经验，我早期也对端到端模型抱有很高的期待，直到在实际部署中踩了无数的坑，才终于认清一个事实：自动驾驶的终点绝不是某个单一模型，而是一整套架构、数据、工具链、工程规范的系统工程。小场景模型组合的价值，不在技术上有多“酷炫”，而是在工程化落地上真正形成了正反馈循环——可以持续迭代、持续训练、持续验证。
最后分享一个我最近得出的判断：未来几年，自动驾驶架构可能形成“大模型做感知低层、小模型做决策高层的混合架构”这个趋势。感知端的大模型会持续变大，吃掉更多的通用视觉理解能力；而决策端会持续“碎片化”，用越来越多的场景模型覆盖越来越精确的策略空间。这正是这个行业走向成熟的特征——从“神话”走向“工程”，从不切实际的“One Model”走向能打的“200个小模型”。
这条路，比想象中要精彩得多。
