4. 端侧计算平台
端侧模型监控与热更新并不是一个纯软件问题，它首先受制于车载计算平台的物理边界。同一套监控策略，在 Orin 上可以每秒采集一次全量指标，在 MCU 上可能连一次浮点统计都难以承受。理解芯片架构、异构单元分工、内存带宽与容量、操作系统实时性以及中间件通信模型，才能设计出“可观测且不拖垮推理”的监控与热更新方案。
一、核心原理：监控与热更新都消耗端侧稀缺资源
端侧平台的核心矛盾是：推理任务已经占满了算力、内存带宽和缓存，而监控与热更新是“额外开销”。监控需要周期性读取 GPU/NPU 利用率、显存占用、温度、推理时延、输入分布统计；热更新需要下载、校验、解密、加载新模型权重，并保证切换过程中不中断推理。这些动作会与推理争抢资源，因此必须理解平台的资源结构。
典型车载计算平台是异构的：CPU 负责调度、预处理和后处理；GPU 负责并行推理与部分图像处理；NPU/DLA 负责定点模型加速；MCU 负责安全监控与实时控制；部分平台还有 ISP、DSP 等专用单元。监控点必须落在正确的单元上，否则采集到的数据没有意义。例如 NPU 的利用率无法从 CPU 的 top 命令获得，必须通过厂商 SDK 或驱动接口读取。
二、内存与算力约束如何影响监控设计
内存是端侧最容易被忽视的瓶颈。模型权重、激活值、输入输出缓冲区已经占用了大量 LPDDR 带宽，监控如果频繁读取大张量或做全量统计，会直接拉高推理时延。因此监控采集应遵循“轻量、采样、聚合”原则：
- 采样而非全量：对输入分布只统计滑动窗口内的均值、方差、最大值，不保存原始张量。
- 聚合而非逐帧上报：在端侧按秒或按百帧聚合，减少中间件通信次数。
- 复用推理输出：置信度、检测框数量等指标可直接从后处理结果提取，避免额外计算。
- 限制监控缓冲区：环形缓冲区固定大小，防止内存泄漏导致 OOM。
算力约束则决定了监控频率的上限。在 NPU 满载时，任何额外的 CPU 统计都会加剧调度抖动。实践中常把监控代理绑定到低优先级 CPU 核，或使用独立的小核运行，避免与推理线程争抢。
三、操作系统与中间件对热更新的影响
操作系统决定了热更新的原子性与实时性。Linux 上可以用双分区 A/B 切换、符号链接原子替换；QNX 等实时操作系统更强调确定性，更新过程必须保证看门狗不被触发。中间件则决定了更新包如何分发、状态如何回传。
以 ROS 2/DDS 为例，热更新管理器通常作为独立节点运行，通过服务或话题接收更新指令，下载完成后通知推理节点切换模型。切换时必须处理“正在推理的请求”，常见做法是双缓冲：新模型加载到备用缓冲区，推理节点在帧边界原子切换指针，旧模型延迟释放。
# 热更新状态机（伪代码）
IDLE → DOWNLOADING → VERIFYING → STAGED → SWITCHING → ACTIVE
↓失败 ↓失败 ↓失败 ↓失败
ROLLBACK ← ← ← ← ← ← ← ← ← ← ← ← ← ← ← ←
注意：热更新不是“替换文件”这么简单。在端侧，模型文件可能被 mmap 到推理进程地址空间，直接覆盖会导致进程崩溃。必须先加载新副本、校验哈希、完成预热推理，再原子切换引用，最后释放旧副本。
四、典型场景与误区复盘
场景：某车型在 Orin 平台上部署了感知模型，监控代理每秒读取一次 GPU 利用率和显存占用。上线后发现推理时延从 35ms 涨到 48ms。排查发现监控代理使用了高开销的 NVML 全量查询，且与推理线程共享同一 CPU 核。改为低优先级核 + 每 5 秒采样后，时延恢复到 36ms。
误区一：认为监控“只是读几个数”，忽略驱动接口的同步开销。部分 NPU 利用率查询会阻塞推理队列。
误区二：热更新时直接覆盖模型文件。正确做法是版本化目录 + 原子符号链接切换。
误区三：忽略中间件 QoS。DDS 默认可靠传输在大包更新时可能占满带宽，应使用独立通道或限流。
| 平台资源 | 监控影响 | 热更新影响 | 应对策略 |
|---|---|---|---|
| CPU 算力 | 采集线程争抢调度 | 解压、校验消耗 CPU | 低优先级核 / 独立小核 |
| GPU/NPU 算力 | 利用率查询可能阻塞 | 新模型预热占用算力 | 错峰预热 / 限频采集 |
| 内存带宽 | 统计读取大张量 | 双缓冲占用双份权重 | 采样聚合 / 分片加载 |
| 存储 | 日志频繁写入 | 更新包写入磨损 Flash | 环形日志 / 写入限流 |
| 操作系统实时性 | 采集抖动影响推理 | 切换过程触发看门狗 | 帧边界切换 / 喂狗保护 |
| 中间件通信 | 指标上报占用带宽 | 大包传输延迟高 | 独立通道 / QoS 限流 |
工程建议：在平台选型阶段就把监控与热更新开销纳入预算。建议预留不超过推理总算力的 5% 用于监控，热更新期间允许推理降级但不中断。所有监控接口必须做超时保护，避免因驱动异常拖死推理主链路。
端侧计算平台的异构性、资源约束和系统软件栈，共同决定了监控与热更新只能是“轻量、异步、可回滚”的。理解芯片内部单元分工、内存带宽瓶颈、操作系统实时性和中间件通信模型，才能把可观测性与可更新性做成工程能力，而不是事后补丁。