端侧模型上线，难在版本与分发生命周期

把量化模型塞进 App，作者认为一个周末就能完成；真正难的是，让 200,000 个安装实例在一年里持续运行在兼容的 App、推理运行时和模型权重组合上。他的结论是：端侧模型应该按部署产物管理，不能只按依赖库管理。

这段原文很短，没有给出完整方案，却点中了端侧 AI 容易被低估的一笔成本：模型能在开发机上运行，只是起点。后面还有大文件交付、版本兼容、陌生硬件和不稳定网络。

为什么模型接进 App，还不算完成交付

作者用两个时间尺度作对比：打包一个量化模型只需要一个周末，维护它却可能持续一年，覆盖 200,000 个安装实例。

这里的关键是兼容组合 (app, runtime, weights)，分别对应应用、推理运行时和模型权重。应用版本正确，不代表它搭配的运行时和权重就一定正确。

端侧 AI 要维护的单位，是一组能共同工作的版本。

把模型当依赖库，容易把注意力集中在接入阶段；把它当部署产物，则必须继续追问：它最终到达了哪些设备，又和哪些版本一起运行？

不过，原文没有说明 200,000 个安装实例来自哪个项目，也没有交代具体维护结果。这个数字提供了问题规模，不能当作经过披露的案例数据。

1.5–2 GB 的模型，难在送到用户手里

作者描述的模型产物大小为 1.5–2 GB。它不是一次链接之后就可以不再关心的文件，而是需要持续交付和维护的对象。

交付环境还有三个限制：发布时间表不由你完全掌控，目标硬件可能从未接触过，网络可能在传输中途断开。

这些限制叠在一起，开发机上的成功就很难直接代表用户端的成功。例如，模型文件没有完整到达设备，与模型推理效果不好，是两类不同的问题；只检查模型输出质量，覆盖不了前一种故障。

作者说，他见过的端侧 AI 事故，更多来自产物生命周期，而不是模型质量。这里的生命周期，就是模型从打包、交付到持续使用的整段过程。但他没有提供事故数量、分类口径或对照数据，这仍是一条经验判断。

我的判断

我认同作者把关注点从「能否跑起来」推向「能否长期交付」。对已经准备把模型发到大量用户设备上的团队，这个提醒很实用：模型评测之外，还需要交付和兼容性验证。

但「模型不是库」更适合作为工程提醒。运行时仍可能以库的形式集成，模型权重则需要作为独立产物管理，两者可以同时成立。

这段原文也不足以证明端侧事故普遍以交付问题为主。它没有给出更新机制、兼容策略或恢复方案。和只把权重打包进安装包的做法相比，作者要求关注的范围更完整；至于应该采用内置权重还是独立下载，原文没有足够信息支持选择。

能拿来做什么

• 如果正在给前端桌面应用或其他客户端接入本地模型，把 app、runtime、weights 三者的实际版本一起记录下来，排查问题时先确认组合是否一致。
• 如果需要交付接近 1.5–2 GB 的模型，把传输中断纳入验收，确认文件未完整到达时应用会如何处理。
• 在正式分发前，把目标硬件上的运行验证列入计划，避免只凭开发机结果判断交付完成。
• 记录端侧 AI 故障时，区分模型效果、版本兼容和产物交付问题，用自己的数据检验作者的经验判断。