端侧 AI · 交付

本地 AI 缓存什么时候必须失效

artifact、prompt、parser、预处理或 source 身份变化时重建派生结果。

主查询:本地 AI 缓存失效 · 核验:2026-09-16 · 事实卡:ARCH-01, COVE-MODEL-02

先给结论

当 artifact、prompt、parser、预处理或 source 身份发生变化时,本地 AI 缓存中派生的结果必须按身份重建一次,不能凭外部线索或时间推断来跳过这一步。这一约束意味着,只要任一上游身份与缓存键不再对应,旧记录就视同失效,需要重新执行派生以避免跨身份复用。身份变化本身即触发重建,而不是等到出现异常再做核对。

需要先收集的证据

至少把下面三项与同一个 artifact、运行时和任务绑定:

  • 依赖版本映射
  • 失效 fixture
  • 回滚重建结果

若缺一项,就把它写成未知,不要用模型参数、芯片宣传或网上截图代替。

实施流程

因此每次重建都要把依赖版本映射、失效 fixture 与回滚重建结果逐条记录下来,并与上一轮逐字段对比,确认派生输入、键值与产物三者一致。任何一次依赖替换都应附带可复跑的失效 fixture,用于证明旧缓存确实无法被新环境正确命中,回滚重建结果也要保留,便于事后核对差异范围。

  1. 固定来源与 revision
  2. 记录长度与 digest
  3. 下载到临时文件
  4. 安全续传与验证
  5. 完成后再切换
  6. 提供修复与回滚

最容易写错的地方

  • 复用过期向量或摘要
  • 删除用户原始数据

在已记录的范围内,常见的错误模式集中在两点:复用过期向量或摘要,以及删除用户原始数据。前者会把上一次身份的产物当作本次命中返回,后者则在重建过程中直接抹掉用户原文,事后无法回溯。发布结论只能基于这些已记录的失效与重建事实,不得延伸至未在卡中出现的失败场景。

最小复现记录

层必须记录
设备型号、芯片、系统、RAM 档位
软件App 版本与 git commit
模型家族、变种、revision、格式、长度、hash、量化
运行时版本、请求后端、实际后端证据
任务fixture、输入 hash、prompt hash、输出规则
结果完成、失败、取消、回退与恢复

发布检查单

  • 目标查询已在开头直接回答。
  • 所有数字都能回到事实卡或原始记录。
  • artifact、runtime、设备与任务没有混淆。
  • 失败、取消、清理与回退都被测试。
  • 隐私和网络边界单独说明。
  • 结论只适用于记录中的配置。

事实来源与延伸

本页使用奇连 AI 的端侧事实卡镜像,性能结论等待 Cove 原始 benchmark 数据。

去 Cove 看对应英文证据页 →

同类页面

返回端侧 AI 专题 →

这个页面有问题?

提交时会附带当前页面地址和浏览器信息,帮助我们定位问题。不填联系方式即为匿名。