智驾模型双向悖论：云端大模型与车端压缩的工程实践

1. 智驾模型的双向悖论一边做大一边压小如果你这两年一直在关注智能驾驶这个圈子大概率会有一种强烈的割裂感。一边是各家车企和算法供应商在发布会上疯狂秀肌肉云端训练的大模型参数从几十亿飙到几百亿甚至上千亿动不动就是“端到端”“世界模型”“VLA架构”另一边真正落到车上的那个模型却被工程师们按在算力只有几十到几百TOPS的芯片上反复揉搓量化、剪枝、蒸馏、算子融合恨不得把每一个字节都榨干。这看起来像是精神分裂但恰恰是当前智驾行业最真实的工程状态。大模型负责“聪明”车端小模型负责“活着”——前者解决的是能力上限问题后者解决的是能不能在有限算力和功耗下实时跑起来的问题。两者不是矛盾而是一条流水线上的上下游关系。我拿一个最直观的类比来解释云端大模型就像是一个经验丰富的老司机在驾校里反复研究各种极端路况积累了几百万公里的驾驶经验而车端模型则是把这个老司机的经验浓缩成一本薄薄的“应急手册”让一个反应速度极快但经验有限的年轻司机在毫秒级时间内翻手册做决策。手册不可能写全老司机所有的思考过程但必须覆盖最常见、最危险的那些场景。这篇文章我想把这件事彻底讲透为什么智驾行业会出现这种“云端膨胀、车端收缩”的双向运动背后的技术逻辑是什么模型压缩到底在压什么算力约束下工程师们是怎么做取舍的以及如果你正在做智驾相关的算法或工程工作有哪些实操层面的经验可以直接拿去用。2. 云端大模型为什么越做越大能力天花板由参数决定2.1 端到端架构把模型规模推上了快车道在传统的模块化智驾架构里感知、预测、规划、控制是分开的每个模块各司其职模型规模相对可控。但自从端到端架构成为主流方向之后事情就变了。端到端意味着从传感器原始输入直接输出驾驶决策中间不再有明确的人工定义接口。这种架构天然需要模型具备更强的表征能力和推理能力而表征能力的提升在当前的深度学习范式下最直接的路径就是增加参数量和数据量。Transformer架构的Scaling Law在这里同样适用模型参数越大、训练数据越多loss就越低泛化能力就越强。智驾场景的复杂度极高——城市道路、乡村小路、夜间、雨天、施工路段、人车混行——每一种场景都对应着巨大的输入空间。小模型根本装不下这么多场景模式只有大模型才能把这些长尾场景的分布学到。2.2 世界模型和VLA需要海量参数做支撑最近一年热度极高的“世界模型”和“VLAVision-Language-Action”架构本质上是在要求模型不仅要理解当前画面还要预测未来几秒的场景演化甚至理解自然语言指令。这种任务对模型的时空推理能力要求极高参数量少了根本做不了。举个例子一个VLA模型需要同时处理视觉输入、语言指令和动作输出这三者之间的对齐本身就需要大量的参数来编码跨模态映射关系。你不可能用一个几百万参数的小网络来完成“看到前方施工牌、理解‘前方施工请绕行’这句话、然后规划出一条绕行轨迹”这样的任务。云端训练时工程师们可以堆叠几十层甚至上百层的Transformer用几千张GPU并行训练几周把模型能力推到极致。2.3 云端算力充裕试错成本相对可控云端训练最大的优势是算力不受限。无论是自建集群还是用算力云平台你都可以根据需求动态扩展资源。训练一个大模型跑一次完整实验可能需要几百甚至上千GPU小时但在云端这不是问题——加钱就行。这种充裕的算力环境允许算法团队大胆尝试更大的模型、更复杂的架构、更多的数据增强策略而不必时刻担心“跑不动”。而且云端训练是离线的不需要考虑实时性。模型推理一次花500毫秒还是5秒对训练阶段来说无所谓。这就给了算法团队极大的自由度去探索能力上限。3. 车端模型为什么必须压缩算力和功耗是硬约束3.1 车端芯片的算力账本看着大分下来很少很多人看到车企宣传“搭载XX芯片算力254TOPS”就觉得算力很充裕。但实际情况是这些算力要分给感知、定位、预测、规划、控制、座舱交互等多个模块还要留出冗余给功能安全和降级策略。真正能分给核心智驾模型的算力可能只有标称值的30%到50%。更关键的是TOPS这个指标本身就有很大的“水分”。不同芯片在实际运行Transformer类模型时的有效算力差异巨大取决于内存带宽、缓存大小、算子支持程度等因素。一个标称200TOPS的芯片跑某个特定模型时可能只能发挥出50TOPS的实际效能。我拿一个实际的计算过程来说明。假设你的车端芯片有效算力是100TOPSINT8精度你的端到端模型需要处理6路摄像头输入每路分辨率是1920x1080帧率30fps。光是输入数据的预处理和特征提取就可能吃掉30%到40%的算力。剩下的算力要跑主干网络、时序融合、轨迹解码每一步都在抢算力。3.2 功耗和散热车规级环境的紧箍咒车端不像数据中心没有空调、没有大功率风扇、没有无限供电。智驾域控制器的功耗通常被限制在几十瓦到一百多瓦之间而且要在零下40度到零上85度的温度范围内稳定工作。功耗每增加10瓦散热设计就要重新做一轮成本也会跟着涨。大模型在车端跑起来功耗会急剧上升。一个几十亿参数的模型即使做了INT8量化推理时的功耗也可能超过整个域控制器的预算。所以工程师们必须在模型规模和功耗之间找到一个平衡点这个平衡点往往比算法团队期望的要低得多。3.3 实时性要求毫秒级决策不能等智驾系统对延迟极其敏感。从传感器采集到做出决策整个链路通常要求在100毫秒以内完成有些紧急场景甚至要求50毫秒以内。这意味着模型推理时间必须控制在几十毫秒级别。一个未经优化的十亿参数模型在车端芯片上推理一次可能需要几百毫秒甚至更久这完全不可接受。模型压缩的核心目标之一就是把推理延迟压到实时性要求的范围内。4. 模型压缩到底在压什么四种主流手段的实操解析4.1 量化把FP32变成INT8精度损失怎么控量化是车端模型压缩最常用的手段。核心思路是把模型权重和激活值从高精度浮点数如FP32转换成低精度整数如INT8从而减少内存占用和计算量。FP32每个参数占4字节INT8只占1字节理论上模型体积可以缩小到原来的四分之一推理速度也能提升2到4倍。但量化会带来精度损失关键在于如何控制损失在可接受范围内。实际操作中工程师通常采用训练后量化PTQ和量化感知训练QAT两种方式。PTQ是在模型训练完成后直接做量化速度快但精度损失可能较大QAT是在训练过程中模拟量化误差让模型提前适应低精度环境精度保持更好但需要重新训练。实操心得做PTQ时一定要用真实的驾驶场景数据做校准集不要用随机数据或ImageNet数据。校准集的分布直接决定了量化参数的选取用错数据会导致某些关键场景下精度暴跌。4.2 剪枝去掉冗余连接但别剪到大动脉剪枝的思路是去掉模型中不重要的权重或神经元减少参数量和计算量。分为非结构化剪枝和结构化剪枝两种。非结构化剪枝把单个权重置零压缩率高但需要专用硬件支持才能加速结构化剪枝直接去掉整个通道或层压缩率稍低但通用性好。在智驾场景中结构化剪枝更实用。但剪枝最大的风险是剪掉了对某些长尾场景至关重要的连接。比如一个模型可能大部分时候靠车道线特征做决策但在车道线模糊的路口它依赖的是路沿和交通标志的联合特征。如果剪枝时把这些“低频但关键”的连接剪掉了模型在正常场景下表现不变一到极端场景就出事。4.3 知识蒸馏让小模型学会大模型的“思考方式”知识蒸馏是让一个小模型学生模型去模仿一个大模型教师模型的输出分布。学生模型不仅学习真实标签还学习教师模型的“软标签”——也就是教师模型对每个类别的概率分布。这种方式能让学生模型学到教师模型的泛化能力而不仅仅是死记硬背。在智驾中常见的做法是在云端用大模型做教师在车端部署小模型做学生。教师模型可以是端到端大模型学生模型则是经过剪枝和量化的小模型。蒸馏的关键是设计好损失函数让学生模型在关键场景上的表现尽可能接近教师模型。4.4 算子融合与图优化不改模型结构也能提速除了上面三种改变模型本身的方法还有一类不动模型结构的优化手段——算子融合和图优化。比如把卷积、批归一化和激活函数融合成一个算子减少内存访问次数或者把多个小算子合并成一个大算子提高计算效率。这类优化通常由推理框架自动完成但工程师需要了解框架的能力边界必要时手动调整模型结构来配合优化。比如某些框架对特定算子组合有优化你就尽量让模型使用这些组合。5. 算力约束下的取舍策略哪些能力必须保哪些可以砍5.1 场景优先级排序高速NOA和城市NOA的模型策略不同不同智驾功能对模型的要求差异很大。高速NOA场景相对结构化车道线清晰、交通参与者类型少、决策空间有限可以用更小的模型搞定。城市NOA场景复杂度高得多需要更大的模型来应对各种突发情况。所以很多团队会做多模型分级部署高速场景用一个小模型城市场景用一个大模型根据当前场景动态切换。这样既保证了城市场景的能力又在高速场景下节省了算力。5.2 时序信息的压缩不是每一帧都需要完整推理智驾模型通常需要处理时序信息但并不是每一帧都需要跑完整的网络。常见的策略是关键帧轻量帧交替推理关键帧跑完整模型提取丰富的特征中间帧只跑一个轻量级的特征传播网络复用关键帧的特征。这样可以在保持时序连贯性的同时大幅降低平均算力消耗。5.3 模型分片与流水线把大模型拆开跑如果模型实在太大单芯片跑不动可以考虑把模型拆成多个片段分配到不同的计算单元上并行执行。比如把主干网络放在一个NPU上把检测头放在另一个NPU上通过流水线方式重叠计算和数据传输。这种方案对硬件架构和通信带宽要求较高但在一些高端车型的多芯片方案中已经有实际应用。6. 常见问题与排查技巧实录6.1 量化后精度暴跌怎么定位问题量化后精度下降是最常见的问题。排查思路是逐层对比量化前后的输出差异找到误差最大的层。通常问题出在以下几类层第一层卷积直接处理原始输入动态范围大、注意力层的softmax对精度敏感、以及输出层的回归头数值范围窄量化粒度不够。解决办法包括对这些敏感层保持FP16精度只量化其他层或者调整量化参数使用更细粒度的per-channel量化。6.2 剪枝后模型在某些场景下失效剪枝后模型在常规测试集上表现正常但在某些特定场景下突然失效这通常是因为剪枝破坏了模型对某些特征的编码能力。排查方法是对比剪枝前后模型在困难场景下的特征图看看哪些通道的响应发生了显著变化。一个实用的技巧是在剪枝时保留那些在困难场景下激活值高的通道即使它们在常规场景下看起来“不重要”。6.3 蒸馏后学生模型学不到教师模型的能力蒸馏效果不好通常有几个原因教师模型太强学生模型容量不够根本学不了或者蒸馏温度设置不当软标签的分布太尖锐或太平滑又或者学生模型的训练数据分布和教师模型不一致。解决办法是调整蒸馏温度通常从3到10之间尝试增加学生模型的中间层监督不仅学输出还学中间特征以及确保训练数据覆盖教师模型擅长的场景。常见问题可能原因排查方法解决思路量化后精度暴跌敏感层量化粒度过粗逐层对比输出差异敏感层保持FP16其余INT8剪枝后特定场景失效关键通道被剪掉对比困难场景特征图保留困难场景高激活通道蒸馏效果差温度设置不当尝试不同温度值温度3-10之间网格搜索推理延迟超标算子未融合用profiler分析耗时手动融合或换推理框架内存带宽瓶颈特征图太大监控内存访问量降低特征图分辨率或通道数7. 我个人的一些实操体会做了几年智驾模型优化最大的感受是不要等到模型训练完了才想压缩的事。很多团队的做法是算法组先把模型训到极致然后扔给工程组去压缩结果发现压缩后精度掉得没法用又回头改模型结构来回折腾。更合理的做法是训练时就考虑部署约束。比如在模型设计阶段就控制参数量和计算量训练时加入量化感知训练剪枝策略和训练同步进行。这样训出来的模型天生就是“可压缩”的后续工程化会顺畅很多。另外模型压缩不是越狠越好。我见过一些团队为了把模型塞进芯片把精度压到勉强及格线结果实车测试时各种边缘场景翻车。留出足够的精度冗余比多省那几毫秒延迟重要得多。毕竟智驾系统出问题的代价不是跑分低一点那么简单。最后分享一个实用技巧做模型压缩时一定要建立一套场景化的评测体系不能只看常规指标。把测试集按照场景类型白天/夜间、晴天/雨天、高速/城区分开统计确保压缩后的模型在每个场景类别上都没有明显退化。这套评测体系本身也是团队的核心资产值得花时间打磨。