过去两周我一直想把这套方案的学习笔记整理完，但每次打开文档，都会陷进“怎么拆解”的纠结里。某新势力车企在GTC2025上发布的自动驾驶方案，信息量不小，但单看新闻稿会觉得到处都是概念词：端到端、世界模型、大算力、数据飞轮。这些词过去两年我听得太多了，真正值得记的是它把哪些技术点串成了一条可以落地的系统链路。这篇学习笔记不是新闻复述，是按我自己的拆解框架整理出来的：方案分哪几层、核心模型的机制长什么样、数据闭环的自动化程度如何、以及我认为它从发布到量产之间最难的几个验证环节。如果你也在跟踪类似的智驾技术路线，这篇文章可以帮你节省至少半天的时间。
1. 车企跑到GPU技术大会去发智驾方案，是什么变了
1.1 智驾的竞技场已经从整车集成转移到工具链生态
很多朋友问我，某新势力车企为什么挑GTC2025这个场子发智驾方案，而不是在自己的品牌发布会上讲。最初我也不理解，查了GTC往年的议程才发现，这个会议早就不是单纯的GPU硬件发布活动，它实际是AI开发者生态的核心集散地：模型训练框架、推理引擎、仿真平台、车辆中间件、传感器合作伙伴都会在这里更新自己的版本。一个车企来这儿发布方案，想传递的信号很清楚：我们所有的智驾开发都在这个生态里深度扎根，而不是只在最后采购一颗芯片。
从实际效果看，这个选择也有现实好处。智驾大模型的迭代频率已经从季度级变成月度级，车企如果自己维护一整条深度学习基础设施，成本非常高；而GPU大会上提供的云端训练调度和车端推理栈，能让队伍把更多时间投在模型本身。过去十年造车比拼的是供应链管理和制造工艺，现在的智驾技术迭代更像是互联网产品竞争，谁的工具链顺手，谁的神经网络版本更新更快，谁就能在城市NOA的体验榜上往前挤。工具链生态，是我理解这套方案的第一把钥匙。
1.2 大模型上车之后，算力不再是唯一指标
如果只看GTC2025期间公布的数字，大家都喜欢比TOPS。但真正拆解这套方案会发现，算力数字只是水和电，决定体验的是内存带宽、片上存储、多模型调度能力，以及数据从车端回到云端的完整链路。传统辅助驾驶时代，车端的逻辑是“传感器到规则再到执行”，所有功能都可以在几百K代码里说清楚；端到端时代，车端要同时跑多个神经网络，有的做BEV感知，有的做预测，有的做规控，还有一个端侧大模型随时准备理解用户指令。几路模型并发时，计算平台容易出现带宽瓶颈，所以这家车企选择了新一代GPU架构的车载平台，我更关注的是它把内存带宽做到了什么水平，而不是媒体通稿里那个最大TOPS。
另外，车企来GPU大会也不只是看芯片，更是在看训练侧的集群方案。端到端模型的规模动辄几十亿参数，每次训练跑几十万张加速卡时。GPU厂商提供的集群通信和分布式训练框架，直接影响一个小模型从想法到上车的周期。
注意：我记这类方案时，会先把所有“数字指标”单独列一组，然后逼自己回答一个问题：这个数字差异在真实行驶场景里带来的体验差异是什么？回答不了的问题，就优先去找它的数据闭环和部署细节。
2. 这套智驾方案的四层结构：我按“系统链路”来拆
2.1 最底层：车载计算平台不是一片芯片，而是一套冗余博弈
拆这套方案，我习惯从硬件往上走。车载计算平台这一层，某新势力没有重复“单芯片通吃”的做法，而是上了双芯片架构，其中主计算芯片负责所有神经网络的推理，副域控负责实时控制与系统监控，另外还有一颗独立的ASIL-D安全MCU。很多人把这种设计理解成“堆料”，但在大模型上车以后，这是典型的“分工防抖”思路：主芯片可以在更新模型版本时短暂重启，副域控仍然能保障车辆执行降级策略；如果主芯片完全失效，副域控和MCU还能维持安全停车。
真正让我记笔记的是它的热管理和功耗预留。大模型推理并不总是满载，但在城市复杂路口、多个模型同时高负载时，瞬时功耗会明显上涨。这套方案把功耗余量做得很足，还设计了主动液冷和风扇混合散热，避免算力因为温度而降频。这一点在媒体评测里从来不会被看到，但它恰恰决定了系统能不能在夏季高架桥堵车那种“高温+高算力”双杀场景里稳定工作。
2.2 感知层：摄像头为主、激光雷达为辅，关键看数据预算
传感器配置对外宣传很容易变成“摄像头大战”，但学习笔记更应该做的是算数据预算。这套方案大致是11个摄像头、3个毫米波雷达、1个半固态激光雷达，外加超声波雷达。单纯看数量没有意义，要从模型输入角度理解：视觉模型需要高分辨率的原始图像，激光雷达提供近距离精确深度，毫米波雷达在雨雾和恶劣光照下补充速度信息。
所谓数据预算，就是指每一类传感器的数据量、传输带宽和算力消耗之间要有个平衡。11路摄像头同时以每秒30帧采集，如果全部送给大模型，算力和带宽立刻爆掉；方案里做的是先做视觉浓缩与感兴趣区域提取，不同传感器在不同置信度下的权重也会动态调整。我特意把这个过程记下来，是因为很多业内讨论只谈“多少个摄像头”，却忽略了这套模型怎么处理并叠加多模态时序数据——那才是真正决定感知质量的地方。
2.3 算法层：分段端到端，而非一个不可解释的黑箱
算法层是所有媒体稿里最容易夸大、也最容易被误解的部分。某新势力强调的是分段端到端，大致链路是：多摄像头数据 → BEV或占用网络生成统一环境表示 → 预测模块生成未来轨迹 → 规控模块输出驾驶行为。这一整条链路都以神经网络为主体，但每两个模块之间保留了结构化的中间表示，相当于给系统留了“检查点”。
这个设计的好处很实在：模型假如在某个路口做出危险决策，工程团队可以通过中间表示判断问题出在“没看见目标”还是“预测错了路线”，而不是面对一个输入图像、输出方向盘的巨大黑箱无从下手。我在之前的项目里也做过类似的截断设计，深知这种可调试性对量产有多重要。
2.4 数据底座：真正拉开差距的是自动标注和场景挖掘
最底层其实是挂在云端的数据系统。上一代智驾方案的数据闭环大多停留在“采集-人工标注-训练-OTA”的半自动阶段，人工标注成本高且慢。这次方案里集中提到的是大模型辅助的自动化标注流水线：车端会把困难的、不确定的片段自动筛选回传，云端用感知大模型先做一次粗标注，再由人工审核高置信度或高风险样本。
这套流水线把原先两周一个迭代周期压缩到一周甚至几天。我在学习笔记里给它的评价是：这才是这套方案的隐形护城河。硬件平台再顶级，模型训练数据的质量和更新效率跟不上，端到端系统的性能天花板就卡在那。数据飞轮不只是口号，它是由回传策略、自动标注、仿真筛选、训练调度、OTA发布五段构成的工程系统。
3. 我反复咀嚼的三个核心技术细节
3.1 “分段端到端”里的中间表示到底多重要
很多朋友以为端到端就是“图像进、方向盘出”，这次方案特别强调分段端到端，我理解是刻意和那种“完全黑箱”路线做了区分。完全端到端理论上限高，但实际量产中最怕边界行为不可控；分段端到端保留了感知与规划之间的BEV/占用网络表示，相当于是给人留了一扇能往里看的小窗户。
这套设计还带来另一个细节：中间表示可以被多任务头共享。同样是BEV特征，既可以生成障碍物框，也可以生成可行驶区域，还可以用来做语义地图更新。相比每个任务各训一套模型的传统做法，这种共享表征节约了很大一部分车上算力，也让模型之间的一致性更好。
3.2 世界模型在这里不是玩具，而是“仿真加速器”
世界模型在GTC2025出现频率很高，但这次方案给我的信息是：它既被用来做预测模块的“学生模型”，也被用来做云端仿真数据的生成器。前者的逻辑是让模型学会“如果前方车辆选择左转，后面场景会怎样演变”；后者则是用世界模型重演真实路采场景，自动生成不同天气、不同光照下的变体，从而低成本扩充训练集。
这个用途比生成几个炫酷视频实际得多。我记下来的原因是，世界模型的价值不在于“像不像视频”，而在于“生成的数据经过模型训练后，能不能提升真实世界中的表现”。如果生成的数据只是看起来真实但分布和真实数据不同，训练后反而可能降点。所以团队需要做数据分布差异评估，这被放进了数据流水线而不是PPT。
3.3 数据闭环的自动化程度，真正决定了迭代速度
再看数据闭环，我整理的关键点不是“自动标注”这个名词，而是难例挖掘的召回策略。车端会按不确定性得分、语义新奇度、安全风险等级三个维度给每个片段打分，只有得分超过阈值的才回传。这样既控制了网络流量，也保证训练数据集中在真正需要学习的长尾场景。
云端侧，大模型自动标注后还有一层“共识校验”：多个模型对同一场景的标注不一致时，才提交给人工。这个设计很聪明，因为标注员的精力应当集中在模型分歧点，而不是为稳定识别的普通场景重复劳动。我估算这套流水线的有效数据利用率是传统方案的数倍，这也是端到端方案能月级迭代的关键。
4. 和市面上其他方案对比，我不太认同的几个“必选项”
4.1 单车大算力不是所有公司的唯一答案
某新势力在GTC2025公布的高算力平台思路，很多公司在效仿，但也有些厂商走车云协同的轻算力路线：车上芯片只做特征提取和实时执行，复杂决策放到云端大模型远程接管。这两条路线在当前阶段各有代价。单车大算力功耗高、硬件贵，但无图区域也能独立工作；车云协同省硬件成本，但一旦出现网络延迟，复杂场景接管的质量会立刻受怀疑。
我个人更倾向大算力预埋的方向，因为城市智驾最大的变量恰恰是网络的不可靠性和地理位置未知。但我也理解轻算力方案的商业逻辑，它赌的是网络覆盖和云端模型的迭代速度。
| 对比维度 | 单车大算力路线 | 车云协同轻算力路线 |
|---|---|---|
| 对网络依赖 | 低，离线可用性高 | 高，断网场景体验下降明显 |
| 硬件成本 | 高，需要液冷和冗余设计 | 低，更容易下沉到低价车型 |
| 模型迭代方式 | 车端OTA，周期较慢但稳定 | 云端随时更新，车端保持同步 |
| 典型瓶颈 | 功耗、散热、芯片供应 | 时延、网络稳定性、数据合规 |
这张表格本身不评价谁好，只是提醒读者看到“算力不高”时，先别急着下结论。
4.2 纯视觉不代表绝对正确，多传感器融合也不代表更保守
这场GTC上另一个热门话题是纯视觉和激光雷达之争。某新势力方案选了视觉+半固态激光雷达的组合，我认为更多是工程妥协：纯视觉在光线良好的情况下已经足够强，但黑夜、雨雾和白色大货车等场景仍然需要其他维度做兜底；激光雷达则能提供不变式的几何测距，在困难天气下帮助模型不产生偏离。
关键不是“有激光雷达就是堆料”，而是这套模型在传感器装载率不高的品牌车系里，能不能用更低的传感器配置做降级运行。如果激光雷达只在配置高的车型上出现，算法就不能把它当成唯一可信输入，必须做“传感器缺失训练”。这是我笔记里特别标注的一条。
4.3 自研和跟随参考设计之间，车企要的不是技术尊严，而是迭代自由度
某新势力在芯片层面并没有完全自研，而是选择和GPU厂商深度合作并定制中间层。有人觉得这是“没有灵魂”，我看下来这其实是一种非常理性的选择：自研芯片听起来厉害，但芯片迭代周期三到五年，智驾算法可能已经换了好几代；而GPU厂商的车载平台已经提供了现成的工具链和开发者社区，定制一部分中间件就能跟上大模型节奏。
对大多数车企而言，真正的护城河不在“是否自研芯片”，而在“是否拥有模型和数据的所有权”。用别人的计算平台、优化自己的数据和模型，是完全可行的组合。
5. 从发布会到量产，最容易出问题的三个验证环节
5.1 仿真世界与真实路测之间，永远差一个“动态细节”
发布会上展示的自动驾驶演示往往很流畅，但量产验证阶段最怕的就是“仿真里的完美表现”和“真实路测的链路延迟”脱节。这家车企也强调世界模型仿真场景库很大，但我更关心的是仿真系统能不能模拟真实交通参与者之间复杂的交互，比如加塞、骑电动车穿行、施工区域临时改道。
我的经验是，仿真主要用来跑回归测试和批量验证模型改动，但最终安全指标必须靠真实道路里程与接管率来定义。遇到“仿真通过但路测翻车”的情况，第一反应不应该是调模型，而是检查仿真状态转移函数是否偏离了真实物理世界的动态边界。
5.2 长尾场景的召回率：没有指标就没有底线
自动驾驶最怕的不是高频场景失效，而是低频但致命场景的覆盖不足。学习这套方案时，我特意去查了它对困难样本的召回指标设计。从笔记里的细节看，它会把“事故风险”和“预测置信度低”的事件单独建库，按季度统计模型在这些场景上的表现。这种分类统计比笼统的接管里程指标更能暴露问题。
给同行的建议是：在评估发布会方案时，别只问“你们接管率多少”，应该问“最差的0.1%场景里，模型的表现环比提升了多少”。如果对方答不上来，说明长尾验证体系还在早期。
5.3 安全兜底不能在最后才设计，更不能只写在PPT里
大模型虽然让系统上限变高，但安全兜底必须保持传统控制论的严格性。我注意到这套方案为安全兜底设计了双重保险：主模型输出的决策会被规则校验器做合理性检查，如果预测轨迹概率过低或方向盘目标转角异常，系统会立刻切换到保守策略，并引导驾驶员接管。
这里也有一个反直觉的点：越是大模型，越需要“小但严格”的传统规则层作为最后一道防线。真正量产时，安全不是“模型多么聪明”，而是“系统能否在无法理解当前局面时选择最安全的行为”。
6. 跟踪这类长周期方案，我自己的学习笔记方法
6.1 用“问题清单”而不是“摘要清单”
整理GTC2025学习笔记时，我一般会先写三五个问题，再带着问题去拆内容。比如：模型如果突然发现前方有障碍物却没有历史轨迹，系统会在哪一层处理？高架桥下定位信号丢失，运动状态如何保持？这些问题能逼着我去读系统架构，而不是只摘录PPT上的关键词。
6.2 给自己立一条技术假设，等量产后来验证
我给自己立的假设是：这套分段端到端方案，在城市复杂路口的接管率会明显好于上一代方案，但在极端天气下不会比激光雷达+规则融合方案有明显优势。这条假设不需要对错，关键是让我后续关注点变得非常具体。
6.3 后续几个月我会盯着的信号
持续跟踪这类方案，我一般看五个信号：量产车什么时候开始交付；首次OTA更新间隔多久；第三方媒体在城市道路的实测接管率；困难天气样本库的公开释放情况；以及芯片和传感器供应链是否出现产能压力。这些信号比任何发布会更加真实。
最后再分享一个小习惯：做这类学习笔记时，我会把“技术名词”和“我自己的疑问”分两栏记录，前者用来快速复习，后者用来在下一次发布会或者实车测试里找答案。很多时候，自动驾驶方案的宏大叙事会让人忘记它是一个需要反复验证的工程系统。带着问题去跟踪，比记住概念要难点，但收获会多得多。希望这篇笔记里的拆解框架，对同样在关注GTC2025和后续量产进展的朋友有一点帮助。
