近百万辆老车背后，理想的跨平台技术答卷

文：李浩 编辑：经纬

智驾可以不断 OTA，但汽车里的芯片，在出厂时就已经定了下来。

这是智能汽车行业共同面对的难题。一辆车要使用多年，支撑智能体验的技术却在快速更新。新芯片自然能够运行更复杂的程序，但对于已经售出的车辆来说，芯片规格已然成为定数。

如果新能力始终与新硬件绑定，新老车型之间的体验差距就可能不断拉大。

旧车也就面临着技术过时带来的价值折损。对抗“技术贬值”，意味着车企在车卖出去、钱收进来之后，还要继续为老用户投入研发。新能力能不能回到老车上，决定着“持续升级”的承诺有多少分量，也影响着用户对品牌的信任。

9 月 10日，理想汽车开启 OTA 8.6、OTA 9.1.1 版本推送。其中，OTA 8.6 将理想马赫 VLA 2.0 带到搭载 Orin-X、Thor-U 平台的已交付 AD Max 车型，覆盖多款 2022 至 2025 款相关车型，涉及近百万用户。

这兑现了理想在 6 月 15日 Livis Day 上作出的三季度升级承诺。李想在微博中提到，团队为此经历了几个月的模型蒸馏、平台适配和多轮验证。

车主看到的是下载与安装，研发团队面对的，却是如何把同一套训练体系产出的能力，送到三种不同芯片上。对抗 “ 技术贬值 ” ，需要先把这道工程题解开。

旧芯片有自己的规矩

把理想马赫 VLA 2.0 的能力带回老车型，要解决的问题远比芯片参数差异更复杂。

在这次的更新中，OTA 8.6 面向 2022 至 2025 搭载AD Max的相关车型，OTA 9.1.1 面向 2026 年发布的新车型。

模型运行时，要完成矩阵乘法、归一化等一系列运算，通常称为“算子”。谁来计算、先算哪一步、中间结果放在哪里，都会影响速度。

这也就意味着，相同的数学任务在不同的平台上运行，底层的执行方案就可能重新设计。

而此次通过 OTA 8.6 获得新模型的已交付 AD Max 车型，搭载的是英伟达 Orin-X 和 Thor-U。两者的 GPU 分别采用 Ampere 和 Blackwell 架构。即便同出一家厂商，两代平台也有不同的计算条件。

差异首先体现在低精度计算上。Thor-U 支持 FP4、FP8，Orin-X 的高效部署主要依赖 INT8。这意味着两代芯片有着不同的数值表示格式，影响模型中的权重和中间特征如何存储，以及计算单元如何处理这些数据。

（英伟达官方浮点格式位结构图，图源：NVIDIADeveloper，《Model Quantization: Concepts, Methods, and Why It Matters》）

比如 FP8 和 INT8 同样各占用 8 位，但 INT8 属于均匀量化，相邻刻度之间的间隔固定；FP8 则是浮点格式，通过指数和尾数表示数值，所能表示的数值间距会随量级大小而变化。因此，围绕 FP8 设计的量化方案，转向 INT8 时，需要重新处理数值范围与误差分配的问题。

FP8 与 INT8 数值分布对比图，图源：Qualcomm AI Research，《FP8 versus INT8 for efficient deep learning inference》）

这就需要用有代表性的数据进行量化校准，估计权重和中间特征的数值分布，选择缩放系数及其作用范围。与此同时，技术团队还要评估哪些层适合降低精度，哪些敏感运算需要保留较高精度。部署能省下多少计算和存储，必须与模型输出受到多大影响一起衡量。

数值格式之外，还要考虑算子怎样落到硬件上。

矩阵乘法、卷积等运算，都需要由具体的计算内核执行。目标芯片是否支持相应的低精度指令，推理框架有没有匹配的实现，数据维度和排布能否进入高效计算路径，都会影响实际速度。额外的格式转换，也可能抵消一部分量化收益。因此，换一个平台，计算内核的选择、数据布局和任务分块方式，都需要重新评估。

此外，模型权重与中间特征能否装入内存、数据能否及时送达计算单元，也会影响部署方案的选择。

然而理想的工程师们面临的不止这些。

理想自研的马赫 M100，使用的是完全不同的计算与数据流动的组织方式。

（马赫 M100 NPU 的存储系统与数据搬运结构，图源：理想《M100: An Orchestrated Dataflow Architecture Powering General AI Computing》）

理想团队的论文显示，M100 的神经网络处理单元（NPU）采用数据流架构，减少对多级缓存的依赖，以本地存储和片上 SRAM 承接数据，通过 DMA 显式搬运，并由编译器和运行时组织同步。

基于这套设计，编译器根据模型的数据依赖，将张量分块、把算子映射到计算单元，并安排各环节流水执行。这样可以让数据传输与计算尽量重叠，减少计算单元等待数据的时间，提高硬件利用率。

英伟达 GPU 的典型 CUDA 执行，则以线程和线程块组织任务，借助寄存器、共享内存和缓存支持运算。GPU 同样能够重叠计算与数据传输，但任务如何切分、数据放在哪里、不同执行单元如何同步，需要匹配自身的硬件资源与编程约束。

因此，在 M100 上高效运行的执行安排，迁移到 Orin-X 或 Thor-U 时，就需要重新寻找适合目标平台的实现方式。

这些调整还会相互牵动。如果为了满足时延和功耗要求，进一步改变模型结构或输入 Token 的数量，计算量、中间特征规模和数值分布也会变化。此前确定的量化与内存方案，需要随之复查；输入信息经过更多压缩后，模型能否保留足够的道路理解能力，也要重新验证。

理想披露的针对 Orin-X、Thor-U 分别设计模型结构、Token 预算、蒸馏方案、量化策略与部署优化，对应的正是这些彼此关联的工程选择。

同一套训练体系可以服务多个平台，但车端的模型配置与执行方案，需要针对具体芯片分别优化。跨平台交付的难度，就在于把同一套能力，落实为各个平台都能稳定、高效运行的模型。

参数瘦下去，能力如何留下来

模型装得下，只是过了硬件这一关。

按照理想披露的路线，团队先在云端训练规模更大、能力更强的教师模型，再针对车端芯片设计学生模型。学生模型需要在既定的算力、内存和功耗预算内完成推理，因此，输入多少信息、用多大的网络处理，都需要围绕目标芯片重新设计。

马赫 M100、Thor-U、Orin-X 承担部署与推理，共享训练体系，但各自受到不同的计算资源约束。

针对 Orin-X 和 Thor-U，理想从输入与网络结构两端控制计算负担。Token压缩减少连续画面中的冗余信息，缩减后续网络需要处理的特征规模；结构压缩则结合神经网络架构搜索，调整网络层数、通道等配置，在能力与资源消耗之间寻找平衡。

经过这两步，小模型获得了进入老芯片的条件，但原有能力能保留多少，还需要重新训练来回答。

蒸馏承担的，正是这部分工作。

在经典的输出蒸馏中，教师给出的概率分布会作为“软目标”。学生对同一输入作出预测，通过交叉熵等损失函数衡量与教师输出的差距，再利用反向传播更新自身参数。监督信号由此包含了最终结果之外的信息，例如其他候选结果之间的相对关系。

放到驾驶任务里，只保留一个最终动作，提供的指导显然还不够。

（图源：詹锟微博）

理想汽车基座模型负责人詹锟在微博中强调，需要保留的包括表征能力、决策方法和输出特征。模型既要理解道路结构、交通参与者和运动趋势，也要保留对候选行为优先级、置信度与安全边界的判断，才能在安全、效率和舒适之间作出取舍。

这意味着，压缩后的模型需要学会在不同道路条件下维持合理的判断关系。相同场景下都选择绕行，并不能单独说明两个模型拥有接近的能力；条件发生变化后，选择能否随之调整，同样重要。

而连续驾驶，又让这道题多了一层难度。

（错误动作通过反馈，造成后续决策持续偏离，图源：Feedback in Imitation Learning: The Three Regimes of Covariate Shift）

在模仿学习中，如果训练主要依赖教师走过的轨迹，学生看到的就是教师策略产生的状态。但部署之后，学生会按照自己的策略行动。一次制动时机或横向位置的偏差，就可能改变下一步的观察条件，使后续决策逐渐偏离训练时熟悉的状态。这类由自身行为引起的分布偏移，会让误差在连续决策中累积。

单帧预测接近教师，无法直接推导出连续驾驶也接近教师。这意味着，需要持续的监督和纠正。

（理想 OPD 模型蒸馏流程，图源：理想官方抖音账号）

理想采用的 OPD，即 On-Policy Distillation，将学生自身的决策轨迹纳入训练。按照这一方法的通用机制，学生先依据当前策略生成轨迹，教师在相应上下文中提供监督，再据此更新学生参数。随着学生策略变化，训练继续从更新后的策略采样，使指导能够跟上学生自身产生的偏差。

OPD补上的，正是模型压缩后最容易遗漏的一环——不仅要让学生学会教师“怎么做”，还要让它在自己走偏之后，知道“接下来怎么办”。

升级的考场在日常道路上

模型适配之后，工作并没有结束。

据理想介绍，过去几年，公司逐步建立了自研模型、Harness 体系、自研星环 OS、编译器团队和自研芯片五项能力。这次 Orin-X、Thor-U 双平台升级，恰好把这些投入拉到了同一道题里。

模型团队需要处理训练、蒸馏与能力迁移，编译器负责让模型适应不同芯片的算子与执行方式，星环 OS 则参与计算任务与整车系统之间的协同。Harness 体系，则进一步参与模型能力向量产功能的工程化约束与交付。

按照理想披露的流程，接下来还要经过算法评测、仿真评测、初步实车测试和多城市泛化测试，并把用户反馈继续纳入后续迭代。

因为到了实车，真实传感器输入、端到端计算时延和车辆执行响应都会加入进来；再把车开到不同城市，道路结构、交通参与者和驾驶习惯发生变化，考验的则是模型的泛化能力。

最后，这些复杂工作会被压缩成几个车主很容易感知的变化。

（在左后方加塞的情况下博弈更加丝滑，图源：网络）

理想马赫VLA 2.0 重点改善了绕行、变道、跟车与道路博弈。遇到施工占道和临停车辆，车辆会更早判断可通行空间；变道时，需要同时考虑侧后方车辆的距离、速度与趋势；前车起步和提速后，跟车响应更加及时；面对汇流、穿插，则减少没有必要的反复加减速。

这些每天都会重复出现，但也正因为重复，车主不需要知道什么是 Token、蒸馏或者 OPD 就能感受到升级之后的变化。

实验室负责证明模型可以迁移，日常道路才负责回答能力有没有真正迁过去。

此次 OTA 也不只有 VLA驾驶。

（理想AI眼镜 Livis指挥泊车，图源：理想）

OTA 8.6 继续把更新延伸到停车、补能和座舱。指挥泊车可以通过理想同学 App、理想 AI 眼镜 Livis 镜在车外发起操作，备车电池预冷和多时段预约充电则进一步调整补能体验；艺术相框让图片、视频进入座舱。同期 OTA 9.1.1 还把主动悬架接入游戏，在车辆静止时调用已经装在车上的底盘硬件。

虽然这些细节的重要程度当然不能和理想马赫 VLA 相提并论，却说明了同一件事——汽车交付之后，已经装上车的芯片、传感器和执行机构，仍然可以被新的软件重新调用。

这也让“持续进化”有了另一层含义。

把最新技术装进新车，是产品迭代；愿意花几个月，把它重新塞进几年前卖出的车里，则是另一回事。前者决定下一辆车好不好卖，后者决定已经付过钱的人，会不会被留在上一代。

从能力做出来，到跨平台适配，再到近百万老车型真正用上，也不过短短几个月。

把未来卖给新用户不难，难的是技术继续往前时，还愿意回头带上老用户一起走。