端侧AI推理已经是移动设备的标配能力，从相册的人像分割到输入法的联想预测，背后都依赖本地模型文件。但模型不是一成不变的，算法团队会持续迭代精度、修复badcase，这就带来一个非常现实的问题：模型文件往往有几十MB甚至几百MB，如果每次更新都让用户下载完整包，流量成本和更新耗时都难以接受。差分更新和热修复就是解决这个问题的两把利器，前者解决“传多少”的问题，后者解决“怎么生效”的问题。
差分更新的核心原理与bsdiff实践
差分更新的本质是：服务端已经知道用户手机上的旧版本模型，只需要计算新旧两个文件的二进制差异，生成一个体积很小的补丁包，客户端下载补丁后在本机还原出新版本。整个流程涉及三个角色：diff工具（服务端生成补丁）、patch工具（客户端合并补丁）、版本管理服务（记录每个用户当前的版本号）。
业界最经典的实现是bsdiff/bspatch。它把文件差异拆解为控制指令、差异块、额外块三个部分，对可执行文件效果尤其好，通常能把几十MB的更新压缩到几MB。下面用Python调用bsdiff演示一个完整的更新流程：
import subprocess
import os
# 服务端：基于旧模型生成差分补丁
def make_patch(old_path, new_path, patch_path):
subprocess.run(["bsdiff", old_path, new_path, patch_path], check=True)
old_size = os.path.getsize(old_path)
patch_size = os.path.getsize(patch_path)
print(f"旧模型: {old_size/1024/1024:.1f}MB, 补丁: {patch_size/1024/1024:.1f}MB")
# 客户端：用旧模型加补丁还原新模型
def apply_patch(old_path, patch_path, new_path):
subprocess.run(["bspatch", old_path, new_path, patch_path], check=True)
# 关键步骤：校验还原结果是否完整
expected_md5 = "服务端下发的目标md5"
actual_md5 = compute_md5(new_path)
assert actual_md5 == expected_md5, "补丁还原失败，禁止加载"
make_patch("model_v1.bin", "model_v2.bin", "v1_to_v2.patch")
apply_patch("model_v1.bin", "v1_to_v2.patch", "model_v2_new.bin")
这里有一个容易被忽视的细节：AI模型文件和普通可执行文件不同。模型的权重数据是高维浮点数组，如果训练时随机种子不同，即使结构没变，整个权重区域的数据也会完全不同，差分算法基本失效。所以要想差分更新效果好，训练侧必须配合——采用增量训练或者微调方式产出新版本，让新旧模型的权重保持大部分字节一致。对于量化后的int8模型，这一点尤其重要，因为一个浮点数的微小变化可能导致量化后的整个字节块改变。
另一个工程要点是补丁链的管理。如果用户长期没打开应用，可能落后了好几个版本，服务端要么为每个版本对都预生成补丁（存储成本高），要么动态按需生成（计算成本高）。常见做法是保留最近N个版本的补丁矩阵，超过N个版本的差距直接下发全量包兜底。
热修复：让模型不重启就生效
解决了传输体积问题，第二个问题是生效方式。传统做法是模型打包在APK的assets目录里，更新模型等于发版，周期长达一周甚至更久，这对需要快速修复线上问题的AI功能来说是不可接受的。热修复的思路是把模型从安装包中解耦出来，放到应用私有目录，运行时动态加载。
以Android端为例，一个典型的模型热加载流程如下：
public class ModelManager {
private static volatile ModelManager sInstance;
private volatile String mLoadedVersion;
// 模型存放目录：context.getFilesDir()/models/
public File getModelDir(Context context) {
return new File(context.getFilesDir(), "models");
}
// 原子切换：新模型先写入临时目录，校验通过后重命名
public boolean switchModel(Context context, String version) {
File staging = new File(getModelDir(context), "staging_" + version);
File active = new File(getModelDir(context), "active");
File backup = new File(getModelDir(context), "backup");
// 1. 校验新模型完整性（md5 + 试加载）
if (!verifyAndTryLoad(staging)) {
return false;
}
// 2. 备份当前生效版本，用于回滚
if (active.exists()) {
active.renameTo(backup);
}
// 3. 激活新版本
boolean ok = staging.renameTo(active);
if (!ok && backup.exists()) {
backup.renameTo(active); // 激活失败立即回滚
}
return ok;
}
}
这段代码体现了热修复最核心的三个原则。第一是原子性：模型文件要么是完整的新版本，要么是完整的旧版本，绝不允许出现半新半旧的中间态，所以必须先写临时目录再rename，rename在同一文件系统上是原子操作。第二是可回滚：激活前先备份旧版本，一旦新模型推理出错率异常，可以秒级切回。第三是试加载验证：md5只能证明文件完整，不能证明模型可用，真正的防线是在切换前用少量样本跑一遍推理，确认输出正常。
还要注意生效时机的问题。如果推理引擎已经把旧模型加载进内存，即使磁盘上的文件换了，正在运行的推理仍然用旧模型。策略上通常不强制立即重载，而是标记一个“待生效版本”，等下一次推理引擎空闲或应用回到前台时再懒加载，避免打断用户当前的操作。
完整更新架构设计与方案对比
把差分更新和热修复组合起来，一套生产可用的端侧模型更新系统大致分为五层：版本协商层负责客户端上报当前模型版本，服务端决策下发差分包还是全量包；传输层支持断点续传和CDN加速；校验层做md5、签名验证和试加载；存储层管理active、backup、staging三个目录；监控层上报更新成功率、推理异常率，异常时触发自动回滚。
几种常见更新策略的对比：
| 方案 | 更新体积 | 生效速度 | 实现复杂度 | 适用场景 |
|---|---|---|---|---|
| 跟随APK发版 | 最大（含整个模型） | 慢，依赖应用市场审核 | 低 | 模型极度稳定，几乎不更新 |
| 全量包热更新 | 大 | 快，秒级生效 | 中 | 模型小于10MB，或首次下载 |
| 差分热更新 | 最小 | 快，需本地patch耗时 | 高 | 模型大、更新频繁的核心功能 |
实际落地时建议混合使用：版本差距小于阈值走差分，差距过大或差分包体积超过全量包的一半时直接走全量，同时保留APK内置模型作为首次安装的兜底。安全方面，补丁包务必做签名校验，防止被中间人替换成恶意模型文件；传输使用HTTPS并开启证书校验。
最后补充一个灰度发布的建议。模型更新和代码热修复不同，模型的行为变化难以通过代码review完全预判，上线前一定要按用户维度灰度，先放量1%观察推理成功率和业务指标，确认无异常后再逐步扩大。配合服务端的版本控制能力，可以做到发现问题后立即停发并推送回滚指令，把风险控制在最小范围内。