企业官网建设流程全解析

1. 智驾模型的双向悖论：一边做大，一边压小

如果你这两年一直在关注智能驾驶这个圈子，大概率会有一种强烈的割裂感。一边是各家车企和算法供应商在发布会上疯狂秀肌肉，云端训练的大模型参数从几十亿飙到几百亿甚至上千亿，动不动就是“端到端”“世界模型”“VLA架构”；另一边，真正落到车上的那个模型，却被工程师们按在算力只有几十到几百TOPS的芯片上反复揉搓，量化、剪枝、蒸馏、算子融合，恨不得把每一个字节都榨干。

这看起来像是精神分裂，但恰恰是当前智驾行业最真实的工程状态。大模型负责“聪明”，车端小模型负责“活着”——前者解决的是能力上限问题，后者解决的是能不能在有限算力和功耗下实时跑起来的问题。两者不是矛盾，而是一条流水线上的上下游关系。

我拿一个最直观的类比来解释：云端大模型就像是一个经验丰富的老司机在驾校里反复研究各种极端路况，积累了几百万公里的驾驶经验；而车端模型则是把这个老司机的经验浓缩成一本薄薄的“应急手册”，让一个反应速度极快但经验有限的年轻司机在毫秒级时间内翻手册做决策。手册不可能写全老司机所有的思考过程，但必须覆盖最常见、最危险的那些场景。

这篇文章我想把这件事彻底讲透：为什么智驾行业会出现这种“云端膨胀、车端收缩”的双向运动？背后的技术逻辑是什么？模型压缩到底在压什么？算力约束下工程师们是怎么做取舍的？以及如果你正在做智驾相关的算法或工程工作，有哪些实操层面的经验可以直接拿去用。

2. 云端大模型为什么越做越大：能力天花板由参数决定

2.1 端到端架构把模型规模推上了快车道

在传统的模块化智驾架构里，感知、预测、规划、控制是分开的，每个模块各司其职，模型规模相对可控。但自从端到端架构成为主流方向之后，事情就变了。端到端意味着从传感器原始输入直接输出驾驶决策，中间不再有明确的人工定义接口。这种架构天然需要模型具备更强的表征能力和推理能力，而表征能力的提升，在当前的深度学习范式下，最直接的路径就是增加参数量和数据量。

Transformer架构的Scaling Law在这里同样适用：模型参数越大、训练数据越多，loss就越低，泛化能力就越强。智驾场景的复杂度极高——城市道路、乡村小路、夜间、雨天、施工路段、人车混行——每一种场景都对应着巨大的输入空间。小模型根本装不下这么多场景模式，只有大模型才能把这些长尾场景的分布学到。

2.2 世界模型和VLA需要海量参数做支撑

最近一年热度极高的“世界模型”和“VLA（Vision-Language-Action）”架构，本质上是在要求模型不仅要理解当前画面，还要预测未来几秒的场景演化，甚至理解自然语言指令。这种任务对模型的时空推理能力要求极高，参数量少了根本做不了。

举个例子，一个VLA模型需要同时处理视觉输入、语言指令和动作输出，这三者之间的对齐本身就需要大量的参数来编码跨模态映射关系。你不可能用一个几百万参数的小网络来完成“看到前方施工牌、理解‘前方施工请绕行’这句话、然后规划出一条绕行轨迹”这样的任务。云端训练时，工程师们可以堆叠几十层甚至上百层的Transformer，用几千张GPU并行训练几周，把模型能力推到极致。

2.3 云端算力充裕，试错成本相对可控

云端训练最大的优势是算力不受限。无论是自建集群还是用算力云平台，你都可以根据需求动态扩展资源。训练一个大模型，跑一次完整实验可能需要几百甚至上千GPU小时，但在云端这不是问题——加钱就行。这种充裕的算力环境允许算法团队大胆尝试更大的模型、更复杂的架构、更多的数据增强策略，而不必时刻担心“跑不动”。

而且云端训练是离线的，不需要考虑实时性。模型推理一次花500毫秒还是5秒，对训练阶段来说无所谓。这就给了算法团队极大的自由度去探索能力上限。

3. 车端模型为什么必须压缩：算力和功耗是硬约束

3.1 车端芯片的算力账本：看着大，分下来很少

很多人看到车企宣传“搭载XX芯片，算力254TOPS”就觉得算力很充裕。但实际情况是，这些算力要分给感知、定位、预测、规划、控制、座舱交互等多个模块，还要留出冗余给功能安全和降级策略。真正能分给核心智驾模型的算力，可能只有标称值的30%到50%。

更关键的是，TOPS这个指标本身就有很大的“水分”。不同芯片在实际运行Transformer类模型时的有效算力差异巨大，取决于内存带宽、缓存大小、算子支持程度等因素。一个标称200TOPS的芯片，跑某个特定模型时可能只能发挥出50TOPS的实际效能。

我拿一个实际的计算过程来说明。假设你的车端芯片有效算力是100TOPS（INT8精度），你的端到端模型需要处理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之间尝试），增加学生模型的中间层监督（不仅学输出，还学中间特征），以及确保训练数据覆盖教师模型擅长的场景。

7. 我个人的一些实操体会

做了几年智驾模型优化，最大的感受是：不要等到模型训练完了才想压缩的事。很多团队的做法是算法组先把模型训到极致，然后扔给工程组去压缩，结果发现压缩后精度掉得没法用，又回头改模型结构，来回折腾。

更合理的做法是训练时就考虑部署约束。比如在模型设计阶段就控制参数量和计算量，训练时加入量化感知训练，剪枝策略和训练同步进行。这样训出来的模型天生就是“可压缩”的，后续工程化会顺畅很多。

另外，模型压缩不是越狠越好。我见过一些团队为了把模型塞进芯片，把精度压到勉强及格线，结果实车测试时各种边缘场景翻车。留出足够的精度冗余，比多省那几毫秒延迟重要得多。毕竟智驾系统出问题的代价，不是跑分低一点那么简单。

最后分享一个实用技巧：做模型压缩时，一定要建立一套场景化的评测体系，不能只看常规指标。把测试集按照场景类型（白天/夜间、晴天/雨天、高速/城区）分开统计，确保压缩后的模型在每个场景类别上都没有明显退化。这套评测体系本身也是团队的核心资产，值得花时间打磨。