端侧 AI 需要的是机群管理器，而非模型卡片

OTA 模型交付是与应用二进制文件交付分离的独立通道​

将模型与应用二进制文件耦合是当今端侧 AI 领域中最大的非受迫性失误。模型的更新频率与 UI 代码不同。它们具有不同的尺寸特征（通常为数百 MB，有时甚至超过 1 GB）。它们需要与应用回滚截然不同的回滚语义——通过推送旧的应用二进制文件来修复一个糟糕的模型，意味着要降级在此期间发布的所有其他改进。

正确的形态是一个类似于 CDN 且具备模型感知语义的交付通道。应用启动后，向清单服务（manifest service）查询其设备类别应运行哪个变体，下载（或验证已拥有）该产物并运行。模型是基于内容寻址的，因此指向相同变体的两个应用版本会共享同一个下载文件。发布可以独立于应用发布阶段性进行——你可以将 5% 的旗舰机用户迁移到变体 N+1，而应用版本保持完全不变。回滚也是即时的：修改清单，设备在下次启动时就会获取前一个产物的哈希值。

无论是 Android 的 A/B 分区系统，还是各种商业 OTA 工具（如 Flutter 的 Shorebird、React Native 生态的热更新工具、Capgo 等），都已经证明了平台支持解耦二进制交付的“机制”。应用商店的政策也越来越宽松：只要模型产物不以需要审核的方式改变应用行为，通过 OTA 发送通常是没有问题的。阻碍因素很少来自平台，更多是因为团队还没有在底层之上构建清单基础设施。

大多数团队都会忽略的一个实用硬化细节：OTA 通道需要由健康信号触发的“自动”回滚，而不仅仅是手动回滚。如果在一个小时的发布过程中，一个新变体将 P95 推理延迟从 800 毫秒推高到了 4 秒，那么清单应该在无需人工干预的情况下自动回退。用于应用代码的生产级 OTA 系统已经吸取了这一教训；而用于“模型”的生产级 OTA 系统通常还没有，因为那些将模型视为静态资产的团队从一开始就没有构建自动回退机制。

分组遥测是那不可见的 80%​

运行端侧模型机群所需的遥测数据并非你现有的那些。服务端 AI 为你提供完整的请求日志、完整的提示词和响应、延迟、成本、错误代码——所有这些都集中在一个地方。端侧 AI 几乎不会免费提供这些。你需要为此进行设计。

最有用的最小集合包括：

• 推理延迟，并与设备类别关联。 不仅仅是全局的 P50/P95——而是“每个设备类别”的 P95。因为旗舰机分组的性能退化与长尾设备的分组退化是完全不同的 Bug，全局 P95 会将其中一个掩盖在另一个之下。这意味着事件需要携带设备类别标识符（或至少是芯片组和内存层级），并且分析后端必须愿意基于这些维度进行切片。
• 推理质量信号。 这是最难的一点。端侧模型无法通过你在 CI 中运行的相同评估准则进行观察；你必须将质量观察带到推理发生的地方。隐性信号（用户重述率、放弃率、后续编辑）通常是唯一可以大规模获取的数据，但它们需要被收集并关联到模型变体和设备类别。显性信号（点赞/点踩）只有在频率足够高、能在用户流失前检测到性能退化时才有用。
• 资源影响。 归因于推理的电池损耗、触发的热事件、由于模型加载导致的 OOM（内存溢出）中止。操作系统会提供大部分此类信息，但你必须主动去请求。旗舰机分组比中端机分组快两倍是可以接受的；但如果旗舰机分组快两倍的同时还多消耗了三分之一的电量，这就是你需要了解的问题。
• 变体归因。 每个事件都必须携带产生它的变体哈希值，因为拥有多个变体的全部意义在于检测哪些变体是有效的。如果不标记变体，无论事件流多么丰富，都无法用于变体对比。

如果你已经构建好了这些遥测数据，你就能回答这个区分“运营机群”与“发布模型”的核心问题：“与变体 N 相比，变体 N+1 在各个设备类别上的表现是变好、变差还是保持不变？”如果你无法快速回答这个问题，那么你拥有的不是一个机群——你只是拥有一个产物和一份运气。

组织失效模式：模型是别人的问题​

这种失败模式在各家公司中都表现得极其稳定。移动团队将模型视为捆绑资产——他们发布一次，不负责其质量，并假设模型团队会告诉他们何时更新。模型团队将设备群视为部署基座——他们训练了模型，在几个参考设备上验证了它，并假设移动团队负责处理长尾设备。由于双方都不认为清单是自己的问题，因此没有团队负责维护机群清单。

六个月后，一次客户支持升级揭示了端侧 AI 功能在 Pixel 6a 上的表现明显差于 Pixel 8 Pro。没有人能说清这是量化问题、内存压力问题还是发热问题，因为没有人收集过能够区分这些问题的遥测数据。管理层提议的修复方案——“发布一个更好的模型”——无济于事，因为失败不在于模型产物本身，而在于缺乏那种能将正确的产物路由到正确设备类别的规范。

必须达成的组织认知重构是：交付端侧 AI 是一项“机群运营（fleet operations）”职责，而不是建模职责或移动工程职责。它需要一个明确的负责人、一个版本控制下的清单、一个按层级产出证据的变体流水线、一个与应用二进制解耦的 OTA 通道，以及分组遥测。为此配备人员的团队看起来更像基础设施团队而非 ML 团队；而不为此配备人员的团队，往往会在陷入需要该角色的值班轮换（on-call rotation）时，才发现这个角色的存在。

端侧 AI 是一个挂载了模型的 CDN 问题​

这种闭环的架构认知在于：端侧 AI 的难点不在于模型本身 —— 而在于分设备的交付、分群组的可观测性，以及证明系统运行正常的流转回退通道。前沿模型团队多年来致力于建立一套将 Checkpoints 转化为产品的工程规范。端侧 AI 几乎没有继承这些规范，因为其部署基座（庞大的长尾手机机群）并不是那些前沿模型工具所针对的设计目标。

到 2027 年，做对这件事的团队看起来将不再像 ML 组织，而更像那种面向数十亿设备进行交付的平台工程组织：拥有配置清单服务（manifest service）、变体流水线（variant pipeline）、CDN 式的交付通道、全机群遥测系统，以及一小群以分析群组性能回退为生的工程师。而那些没做对的团队将继续只是交付模型，并寄希望于真实机群的表现能和测试手机一样。

模型是产物。机群才是产品。请你区别对待它们。