1. 课程导入

自动驾驶系统正在从“功能堆叠”走向“持续进化”。一辆量产智能汽车在生命周期内会经历算法迭代、场景补丁、法规适配与安全修复，而端侧模型一旦上车，就不再只是实验室里的权重文件，它必须在车规级算力、有限内存、实时时延和功能安全约束下长期运行。本课程关注的正是这条链路中最容易被忽视、却最影响交付质量的一环：端侧模型的运行监控与热更新工程。

学习目标可以概括为四个层次：第一，理解端侧模型监控的指标体系，包括推理时延、帧率、内存占用、温度、算力利用率、置信度分布与漂移信号；第二，掌握热更新的完整流程，从模型打包、签名校验、灰度下发、双分区切换到回滚；第三，能够设计可观测、可回滚、可审计的工程架构；第四，建立“监控—判断—更新—验证”的闭环思维，而不是把模型更新当成一次简单的文件替换。

一、为什么端侧监控与热更新是自动驾驶的刚需

云端训练与端侧推理之间存在天然的“环境鸿沟”。训练数据往往来自特定城市、特定天气和特定传感器配置，而量产车会驶入暴雨、逆光、隧道、乡村非结构化道路等长尾场景。模型在端侧的表现会随温度、算力降频、传感器脏污和道路分布变化而漂移。如果没有监控，团队只能依赖用户投诉或事故回放发现问题，代价极高。

热更新的价值在于把修复周期从“下一次 OTA 大版本”缩短到“小时级”。例如，某感知模型在夜间对锥桶的召回率下降，监控系统检测到置信度分布异常并触发告警，算法团队训练补丁模型，经过签名与灰度策略后，仅更新感知子模型，不影响规划控制模块。整个过程可以在车辆休眠或充电时完成，用户无感。

二、整体框架：从车端采集到云端闭环

一个完整的工程框架通常包含五层：车端推理运行时、监控探针、本地缓存与安全代理、云端模型仓库与策略中心、以及数据回传与训练平台。车端探针以低开销方式采集指标，安全代理负责签名校验、分区管理和回滚，云端则负责版本管理、灰度发布和效果评估。

图中可以看到，车端与云端并不是单向关系，而是“指标上报—模型下发—事件回传”的闭环。车端安全代理是热更新的关键闸门：它必须保证新模型经过签名校验、分区写入、启动自检和失败回滚，才能把控制权交给推理运行时。

三、方法流程：一次热更新的标准动作

热更新不是单点操作，而是一条可审计的流水线。典型流程如下：

1. 版本打包：将模型权重、配置文件、算子库和兼容性声明打包为不可变制品，生成哈希与版本号。
2. 签名与校验：使用私钥签名，车端用预置公钥验签，防止中间人篡改。
3. 灰度下发：按车型、地域、里程或用户白名单分批推送，先小流量验证。
4. 双分区切换：新模型写入备用分区，启动自检通过后原子切换，旧分区保留用于回滚。
5. 运行监控：对比新旧版本的时延、内存、置信度分布和业务指标，确认无退化。
6. 全量或回滚：灰度达标后全量发布；若触发阈值，自动回滚并上报事件。

# 车端热更新状态机（简化）
IDLE → DOWNLOADING → VERIFYING → STAGING → SELF_TEST
     → SWITCHING → RUNNING_NEW → (HEALTHY ? COMMITTED : ROLLBACK)

四、案例场景与常见误区

假设某车型在南方雨季出现车道线检测抖动。监控探针发现：推理时延从 28ms 升至 41ms，内存占用增加 18%，车道线置信度方差扩大 2.3 倍。云端策略中心判断为“雨天分布漂移”，下发针对雨雾增强的补丁模型。车端在充电时完成下载与验签，写入 B 分区，自检通过后切换。切换后 24 小时内，时延回落至 30ms，置信度方差恢复正常，系统自动提交版本。

五、工程价值与学习路径