谷歌解释安卓AICore为何突然吃掉数G存储

「为什么我的手机存储突然少了几个G？」——过去几个月，不少Pixel和三星用户发现Android AICore的存储占用会出现诡异波动。谷歌最近终于给出了技术层面的完整解释。

本地大模型的"双保险"机制

Android AICore的核心卖点很直接：让Gemini Nano这类生成式模型直接跑在手机硬件上，无需联网。这对隐私敏感场景和离线使用是刚需。

但大模型的代价是体积。谷歌官方文档确认，当新版本Gemini Nano推送时，AICore会同时保留新旧两个版本，最长持续3天。

这不是bug，是故意设计的故障保护（fail-safe）。谷歌的解释很直白：「如果新更新遇到错误，手机可以立即回退到旧版本，而不必重新下载数G数据。」

确认稳定后，旧版本自动清理。整个周期内，用户看到的存储占用就是平时的两倍。

正方：这个设计合理吗？

从工程视角看，这是典型的可用性优先策略。

移动端下载大模型成本极高——不仅耗时，还消耗流量和电量。一旦新版本出现兼容性问题，用户若被迫重新下载，体验崩塌的代价远高于临时占用存储。

3天的窗口期也经过权衡：足够覆盖大多数稳定性验证场景，又不至于让冗余数据长期堆积。

支持方认为，在本地AI这个新兴领域，保守的回滚机制是负责任的做法。毕竟模型推理直接发生在用户设备上，出错的后果比云端服务更难收拾。

反方：用户知情权与体验代价

批评的声音同样存在。

首要问题是透明度。存储占用翻倍发生时，系统并未主动告知用户原因。对128G或256G存储的中低端机型用户，数G的临时占用可能直接触发「存储不足」警告，影响正常使用。

其次，3天的保留期是否过长存疑。谷歌没有说明这个数值的测试依据——是统计意义上的安全窗口，还是工程团队的保守估计？

更深层的质疑指向本地化AI的整体成本转嫁。厂商宣传「端侧智能」的隐私优势时，很少提及用户实际承担的存储、内存和算力开销。AICore的波动只是冰山一角。

判断：一个过渡期的折中方案

这个设计本身没有硬伤，但暴露了两个行业现实。

第一，端侧大模型仍处于早期。模型压缩、动态加载、增量更新等技术尚未成熟，「全量双备份」是当下最稳妥的工程选择。未来随着技术迭代，这种粗放的存储策略会被更精细的方案替代。

第二，操作系统需要建立新的用户沟通范式。传统应用更新是静默的、增量式的，而大模型时代的系统组件更新涉及GB级数据变动，原有的通知机制已经不够用。

对普通用户的实用建议：若发现AICore存储异常，先检查是否有Gemini Nano更新推送；若3天后占用未回落，再考虑手动清理或反馈。对开发者而言，这个案例说明本地AI的「透明性设计」将成为新的体验竞争点——谁能让用户清楚知道GB级数据的去向，谁就能降低信任成本。