RISC-V端侧模型热更新设计指南：二进制差分、双分区原子切换与内存受限下的替换路径

1. 热更新的约束来自部署现场

端侧设备与云端服务器在更新语义上存在根本差异。云端可以停机重启，端侧设备常常不允许：工业现场的控制器中断会影响产线，车载设备在行驶中不可重启，消费类设备则可能长期处于弱网或离线状态。更新机制因此需要同时满足三个条件——传输体积可控、切换过程原子、失败可回滚。

这三条约束决定了方案的基本形态。传输体积问题导向差分发与压缩；原子性导向双分区与提交标志；可回滚导向健康检查与版本回退。任何一项被省略，都会在现场演化成难恢复的故障。

2. 更新粒度的划分

按更新对象的不同，端侧热更新可分为三个层次，风险与工作量依次上升：

• 权重更新：只替换模型参数文件。风险最低，不涉及可执行代码与 ABI，失败回滚只需换回旧文件。代价是体积最大，量化后的模型仍可能占用数十至数百 MB；
• 运行时更新：替换算子库、推理框架等动态库。涉及 ABI 兼容性与已加载映射的处理，需要保证新旧版本的接口约定一致；
• 镜像更新：替换整个系统分区。覆盖面最广、风险最高，通常配合 A/B 分区与引导标志完成。

工程上通常按此顺序逐级启用：先只做权重更新，稳定后再放开运行时更新，镜像更新则保留为兜底手段。这个顺序的合理性在于——权重文件是纯数据，不存在接口约定，而代码更新一旦引入不兼容的 ABI 变更，旧进程持有的映射就会在调用点崩溃。

3. 二进制差分与还原

差分更新把"传输新版本"转换为"传输新旧版本的差异"，在权重这类大部分内容保持不变的场景下压缩率显著。主流算法（bsdiff 类）以字节块为单位建立新旧文件的匹配关系，采用后缀排序构造索引后生成三类操作：匹配复制、插入、删除。还原端按这些操作流式重建新文件。

还原过程有一个容易被忽略的代价：峰值内存。若在内存中同时持有旧版本、差异包与新版本，峰值是三者之和。对内存本就紧张的端侧设备，这会直接导致还原失败。

三种缓解方式：

1. 分块差分：把文件切成固定大小的块（常见 4 KB 至 64 KB），逐块独立差分与还原。还原时只需同时持有旧块与新块，峰值从"三个完整文件"降为"两个块"；代价是差分率略低于整文件方案；
2. 就地还原 + 校验：新版本写入旧版本占用的空间，边写入边校验。要求写入顺序严格从高地址向低地址推进，避免覆盖尚未读取的旧数据；
3. 流式解压：差异包以流式压缩格式传输，还原时逐块解压、逐块写入，不解压完整的中间产物。

分块还原与流式解压的组合是端侧最实用的形态：既控制住峰值内存，又保持了差分率。分块大小需要权衡——块越大差分率越高，峰值内存也越大；块越小则相反。经验起点是让单块大小与设备可用堆内存的十分之一相当。

4. 双分区与原子提交

还原出的新版本在写入位置后，切换动作本身必须是原子的。断电发生在任意时刻，系统都必须能启动到一个完整可用的版本。

双分区机制把存储划分为 A、B 两个对等分区，任一时刻只有一个处于活跃状态。更新流程为：

1. 写入非活跃分区：数据写入与当前运行版本无关的分区，此阶段断电不影响运行版本；
2. 校验完整性：对写入完成的分区做长度与哈希校验，确认无缺损；
3. 更新提交标志：写入引导标志，指定下次启动使用哪个分区；
4. 健康检查：新版本启动后，应用层完成自检（模型加载成功、推理结果自洽、关键外设就绪）后写入"确认"标志；
5. 回滚兜底：若引导次数累计超过阈值仍未看到确认标志，引导程序切回旧分区。

第 3 步的原子性是整个流程的核心。标志位必须是单次写入即可生效的粒度，且写入前后需要确保数据已落盘——先写数据、后写指针，顺序颠倒会造成"指针指向未写完的分区"，这是断电场景下最典型的故障形态。若标志位跨越多个存储单元，需要配合双副本加校验，避免写入中途断电产生不一致位模式。

判断是否需要双分区，取决于可用存储空间是否足以容纳两份完整版本。若空间不足以容纳，退而求其次的做法是保留一份紧凑的恢复镜像，在更新失败时从恢复镜像重建。

5. 运行期替换与进程生命周期

权重文件的替换相对简单：加载新文件、切换引用即可。代码层面的运行时替换则受进程生命周期约束，需要区分三种情形：

• 进程可重启：最简单也最可靠。关闭旧进程、替换库文件、启动新进程。切换窗口即为一次重启时间；
• 进程不可重启但可双实例：启动新版本实例、完成预热与健康检查、把请求切换到新实例、关闭旧实例。内存需要容纳两个实例，受端侧内存限制，通常只适用于轻量推理进程；
• 进程不可中断：需要就地替换，风险最高。此时库文件不可直接覆盖（旧进程仍持有映射），只能写入新路径并以符号链接切换；而 dlclose 的引用计数受限于进程内其余引用，映射未必真正释放，内存可能无法立即回收。在端侧内存本就紧张的前提下，就地替换实际可行性很低，仅在无其他选择时使用。

一个常被忽略的约束是：新建映射的页面在首次访问时才实际分配物理页，因此在双实例方案中，内存压力出现在第二个实例完成预热之后，而非启动瞬间。容量评估应针对预热完成态，而非进程创建时。

6. 内存受限下的替换路径

当设备可用内存小于"新旧两版之和"时，替换必须分片推进。可用的手段有四种：

• 按需分页加载：以内存映射方式打开权重文件，由内核在访问时按页调入，配合建议性回收在内存紧张时释放已不再访问的页面。适用于推理流程具有明显阶段性的模型；
• 逐层替换：按模型层级切分，一层的权重替换完成后即释放该层的旧数据。要求推理执行计划支持层粒度的调度；
• 原地更新 + 版本号：在预留空间内就地覆写，通过版本号区分内容。要求模型文件格式支持块级定位，且设备具有断电保护的存储策略；
• 副本降级：在更新期间关闭部分非关键功能（例如降低并行度、暂停辅助任务），把释放出的内存让给更新流程，完成后恢复。

这四条路径的共同设计原则是：把峰值内存从"与模型体积成正比"降为"与分片大小成正比"。评估更新方案时，峰值内存与断电安全这两项指标的权重高于传输体积。

7. 实战：分块差分更新的安全序列

以下为一次分块差分更新的完整操作序列（命令行片段，示意通用步骤）：

# 1) 校验设备当前版本（防止版本错配）
$ model_verifier --file /data/model.bin --expect-hash "$OLD_HASH" || exit 1

# 2) 写入非活跃分区，边写入边校验
$ model_apply --patch model.patch --base /data/model.bin \
              --out /mnt/slot-b/model.bin --chunk 64K --verify

# 3) 校验还原结果的完整性
$ model_verifier --file /mnt/slot-b/model.bin --expect-hash "$NEW_HASH" || exit 1

# 4) 落盘并提交引导标志（顺序不可颠倒）
$ sync
$ bootctl set-active slot-b && sync

# 5) 重启后由应用完成健康检查，通过则写入确认标志
$ model_selfcheck && bootctl confirm

三个关键点：第 4 步的 sync 必须在写标志之前，保证数据先落盘；第 2 步的逐块校验使损坏在写入阶段即可发现，不必等到启动失败；第 5 步的确认标志使"启动成功"与"功能正常"区分开来——模型文件完整但推理结果异常的情况下，回滚机制仍然能生效。

8. 常见问题与成因

• 断电后设备无法启动：提交标志先于数据落盘，或标志位跨存储单元写入时被中断。前者通过调整写入顺序修复，后者通过双副本加校验修复；
• 还原后的模型校验失败：差分包与基版本不匹配（设备上的版本与生成差分时的版本不一致）。版本校验应在下载阶段完成，而非还原后；
• 旧模型内存无法回收：存在未释放的映射或引用。检查是否有长生命周期对象持有旧缓冲，以及文件描述符未关闭的情形；
• 回滚后推理结果异常但模型文件正确：缓存或中间产物残留。回滚流程应同时清理与新版本关联的缓存目录，而非只切换模型文件；
• 更新期间设备响应变慢：写入吞吐占满存储带宽，与推理任务的访存竞争。可限制写入速率或把更新安排在设备空闲时段。

9. 结语

端侧热更新的设计顺序应与风险顺序一致：先做权重差分，再做原子切换，最后才考虑运行期替换。三项判断贯穿全文——峰值内存按分片大小而非模型体积评估；提交标志必须晚于数据落盘；健康检查需覆盖功能正确性而非仅文件完整性。