一、前言思考

1.1 AI 模型的"持续迭代"困境

传统 App 发版，代码随安装包更新。但 AI 模型更新远比代码频繁：

• 模型精度要持续优化（每周都有新版本）；
• 新模型要 A/B 实验验证效果，不能直接全量；
• 模型出问题（误判、偏见）需要秒级回滚，不能等 App 发版。

如果模型跟着 App 发版走，迭代周期 2 周起步，AI 团队会被拖死。解法是模型与 App 解耦的 OTA 更新体系。

1.2 模型更新的核心诉求

诉求	说明
增量	模型动辄 100MB+，全量下载浪费流量
灰度	新模型先小流量验证，再全量
回滚	发现问题立即回到上一版本
一致性	同一用户不同端用同一版本
缓存	已下载模型复用，不重复下载

二、底层原理

2.1 模型版本管理

版本 = 模型 + 元数据：

模型包:
├── model.ms           (推理模型文件)
├── version.json       (版本信息)
│   ├── version: "2.3.1"
│   ├── size: 128MB
│   ├── hash: sha256(...)
│   ├── minAppVersion: "6.1.0"
│   ├── compatibleModels: ["2.2.x", "2.1.x"]
│   └── deltaBase: "2.3.0"    (增量包的基础版本)
└── README.md          (变更说明)

版本规则：

• 语义化版本 主.次.补，向后兼容；
• 增量包必须声明 deltaBase（从哪个版本升上来）；
• 元数据包含 hash，下载后校验完整性。

2.2 增量 OTA 更新

全量更新：每次下载 128MB。增量更新：只下载差异部分（通常 < 20MB）。

旧模型(2.3.0) ──patch──▶ 新模型(2.3.1)
     │                        ▲
     │  服务端生成增量包        │ 客户端本地合成
     └───(差量算法)──▶ diff ───┘

常用差量算法：bsdiff（二进制差分）、模型权重差分（只更新变化的权重张量）。

客户端流程：

检查版本 → 有更新? → 下载增量包 → 校验hash → 本地合成新模型 → 原子切换 → 旧模型保留待回滚

2.3 缓存策略

缓存层	策略
磁盘缓存	最近 N 个版本模型保留，LRU 淘汰
增量缓存	已下载的增量包保留，下次复用
内存缓存	当前激活模型驻留内存
下载断点	大模型支持断点续传

2.4 回滚机制

模型状态机:
  生产(旧) → 下载完成(暂存) → 验证通过 → 切换(新) → 观察期
                                        │
                                  新模型异常?
                                        │
                                        ▼
                    生产(旧) ◀── 回滚 ──┘

关键：切换不删除旧模型，保留一个"上一个稳定版"，异常时一键回滚。

三、实战落地

3.1 模型版本检查与更新

import { modelManager } from '@kit.AiKit';
import { http } from '@kit.NetworkKit';

class ModelUpdater {
  private readonly modelId = 'com.demo.ocr';

  async checkAndUpdate(): Promise<void> {
    // 1. 本地版本
    const local = modelManager.getModelVersion(this.modelId);

    // 2. 服务端版本清单
    const manifest = await fetchJson('https://api.demo.com/models/manifest');
    const remote = manifest.models.find(m => m.id === this.modelId);

    if (remote.version === local) {
      LoggerUtil.info(TAG, '模型已是最新: ' + local);
      return;
    }

    // 3. 增量 or 全量
    const delta = remote.deltas.find(d => d.baseVersion === local);
    const url = delta ? delta.url : remote.fullUrl;
    const size = delta ? delta.size : remote.size;

    // 4. 下载（断点续传）
    await this.downloadWithResume(url, size, delta ? 'ocr_' + local + '_delta.patch' : 'ocr_full.ms');

    // 5. 校验 + 安装
    await this.verifyAndInstall(remote.version);
  }
}

3.2 增量包合成

// 客户端用旧模型 + 增量包合成新模型
import { fileIo } from '@kit.CoreFileKit';

async function applyDelta(oldPath: string, deltaPath: string, newPath: string): Promise<void> {
  // 方案A: 服务端已提供 bsdiff 补丁, 用内置 bsdiff 库合成
  await bsdiff.apply(oldPath, deltaPath, newPath);

  // 方案B: 模型权重差分, 逐层合并
  // const oldWeights = loadTensors(oldPath);
  // const diff = loadTensors(deltaPath);
  // const newWeights = merge(oldWeights, diff);  // old + diff
  // saveTensors(newWeights, newPath);
}

3.3 A/B 模型灰度

// 按用户 hash 分流: 5% 用户先用新模型
function isInExperiment(userId: string, bucket: string): boolean {
  const hash = hashCode(userId + bucket) % 100;
  return hash < 5;   // 5% 流量
}

// 推理时选择模型版本
function pickModel(userId: string): ModelRef {
  if (isInExperiment(userId, 'ocr_v2')) {
    return loadModel('ocr_v2');   // 实验组
  }
  return loadModel('ocr_v1');     // 对照组
}

实验期间同时统计两组的准确率、延迟、崩溃率，达标后全量。

3.4 回滚机制

async function rollbackIfNeeded(): Promise<void> {
  // 监控新模型质量指标
  const stats = collectModelStats();   // 推理失败率/超时率/异常率
  if (stats.errorRate > 0.05) {        // 错误率 > 5% 触发回滚
    await modelManager.rollback(this.modelId, { targetVersion: lastStableVersion });
    LoggerUtil.warn(TAG, '模型异常, 已回滚到 ' + lastStableVersion);
    reportIncident(stats);
  }
}

四、性能排查与优化

问题	表现	优化手段
下载慢	大模型网络差	断点续传、CDN 分片、闲时下载
合成失败	增量包损坏	hash 双重校验、失败自动转全量
切换卡顿	换模型时推理中断	双缓冲（旧模型服务到新模型就绪）
回滚丢失	旧模型已删	保留 last stable，回滚前不删
存储膨胀	版本堆积	LRU 淘汰 + 手动清理 + 配额管理

4.1 双缓冲平滑切换

// 新模型加载完成前, 旧模型继续服务
let activeModel = loadModel('ocr_v1');
let standbyModel: Model | null = null;

async function switchTo(v2: Model) {
  standbyModel = v2;          // 先加载到备用位
  const ok = await verify(v2); // 验证
  if (ok) {
    activeModel = v2;          // 原子切换
    standbyModel = null;
    unload('ocr_v1');          // 此时才卸载旧模型
  }
}

4.2 更新时机策略

• 模型更新走后台闲时任务（WiFi + 充电 + 空闲）；
• 紧急更新（安全修复）走系统级通知；
• 用户正在用该 AI 功能时，不打断切换，等下一次推理空闲期。

五、总结

1. 模型与 App 解耦的 OTA 更新是 AI 持续迭代的前提：版本管理 + 增量下载 + 灰度 + 回滚四件套缺一不可。
2. 增量更新省流量（128MB → 20MB），但必须 hash 校验 + 失败自动转全量。
3. A/B 灰度是模型质量守门员：小流量验证 → 达标全量 → 异常即回滚。
4. 回滚是最低底线：永远保留 last stable，切换用双缓冲，用户无感。

一句话记住：版本管得好，增量省流量，灰度防翻车，回滚保平安。

---

🚀 演示功能优化（随项目同步更新）

本文对应的 ArkTS 演示页面已随项目整体优化，主要改进：

1. 独立主题风格：深灰科技 · 金属面板冷光描边，与其余章节演示页明显区分，不再千篇一律。
2. 步骤回放动画：点击演示按钮后，结果行按 260~320ms/步 逐步展示，模拟真实推理过程。
3. 运行态保护：演示过程中按钮置灰防重复触发，页面退出自动清理定时器。
4. 结果摘要：演示结束后自动给出「一句话结论」，并 Toast 提示完成。
5. AI 对话演示：新增 AiChatDemo（根目录 main.py 的 ArkTS 移植），真实 SSE 流式大模型请求，首页「★ AI Chat 流式对话演示」可进入。

对应页面：entry/src/main/ets/pages/ModelUpdateDemo.ets

---

🧪 演示优化：真实 AI 推理接入（v3）

本演示页顶部新增 AI 版本管家主卡，点击即真实调用云端大模型（SSE 流式），不再是纯模拟回放：

• 请求链路：utils/AiClient.ets（ArkTS 封装 OpenAI 兼容接口）→ POST https://api-ai.gitcode.com/v1/chat/completions，模型 deepseek-ai/DeepSeek-V4-Flash，流式 stream: true
• 演示场景：OTA 更新 / AB 灰度 / 版本回退 —— 每个场景绑定不同模型运维专家 Prompt，返回内容各有差异
• 交互体验：进入页面自动触发一次真实推理；点场景标签切换并重新请求；按钮手动触发；输出区打字机流式展示
• 真实标识：卡片右上角 LIVE 徽标 + 端点/模型名水印，保证"所见即所调"