端侧 AI 运行时健康检查：从文件到真实任务

直接回答

可靠的端侧 AI 健康检查不是一个由文件名触发的绿色标志，而是一组分别命名、可复现的观察结果：目标模型文件是否存在；应用是否拥有可信的身份信息来核验它；所选运行时是否成功初始化；后端配置只是请求还是确实被运行时观察到；最后，一个与产品功能相符的代表性任务是否满足预先定义的验收条件。每个阶段都应有单独状态和恢复路径。文件存在并不说明字节完整、版本匹配、路径可读或运行时支持；引擎初始化也不能保证后续任务成功；模型返回文本更不等于输出满足功能契约。把边界拆开，诊断结果才有操作价值，而不是给人错误的安心感。 当模型交付和原生推理由不同组件负责时，这种区分格外重要。LiteRT-LM 有自己的打包方式和 API；仅凭模型家族名称，无法证明某个文件就是特定运行时能够读取的制品。当前 Cove 代码里的 ModelManager 具备 not-downloaded、downloading、downloaded、loading、ready、error 等状态，会串行化模型加载，并在加载失败后删除制品、回到未下载状态。与此同时，当前模型配置中的 Gemma 4 E2B SHA-256 字段为空。因此，不应把该配置描述成“哈希已验证”，也不能让“就绪”徽标暗示应用并未掌握的密码学来源证明。 健康探测应围绕真实用户任务设计，但需要安全且可重复。用固定的小型测试夹具替代用户私密内容，提前定义预期属性；某一阶段失败时，要返回明确分类。检查范围还要有上限：不能为了给状态图标上色就在每次启动都执行耗费资源的生成，也不能在错误时无限自动重试。轻量级存储盘点与用户主动发起的诊断应分开。界面应说明检查了什么、何时检查、哪些部分仍未知。如果所用运行时没有暴露硬件后端身份，就应显示“后端未确认”，而不是根据设备标签或配置偏好猜测。 发布检查记录应包含准确的应用构建、模型版本或来源、运行时版本、请求的后端配置（若有则记录实际观察到的后端证据）、测试夹具和任务结果。设备及操作系统信息只能对应实际执行过的那台设备和那次运行；不能外推到所有手机、模型变体或将来的更新。这项检查用于诊断和诚实表达就绪状态，不是跑分、兼容数据库或认证。 最实用的界面不是“模型好/坏”二选一，而是写明最近通过的阶段和下一步建议。例如，显示“模型文件可读取，运行时已初始化；固定测试任务返回空结果”。用户由此知道下载不一定要重来，开发者也能避免把解析问题误诊为设备不支持。若诊断无法访问外设、缺少可信摘要或运行时没有报告后端，就明确保留未知，而非补造一个听起来完整的结论。 为避免诊断本身制造风险，探测输入应固定、短小、没有私人照片或对话；探测次数和重试条件应受控。展示成功结果时注明构建版本、模型制品标识与测试范围，失败时只保存不含提示词和模型输出的阶段元数据。若检查会占用模型或音频资源，应告知用户并在结束时释放。所有这些限制让健康检查更像一张有证据边界的状态报告，而不是营销标签。

设置页显示模型就绪，但从未执行过任务

用户更新应用后，在存储目录看到了模型文件。此前进程可能在加载中被系统结束，应用配置也可能发生变化。支持团队需要分别确认文件、运行时和真实功能是否正常，但没有新的设备级基准数据可以依赖。

决策

用有边界的分阶段诊断取代单一布尔值，分别记录文件存在性、制品核验、运行时初始化、后端观察与任务验收。

预期结果

用户和支持人员能看到最近确认到哪一步以及安全的下一步，同时不夸大设备兼容性或哈希校验能力。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• COVE-LIFECYCLE-01：ModelManager 暴露模型下载、加载、就绪和错误状态，并串行化加载。
• COVE-MODEL-02：当前 Gemma 4 E2B 配置中的 SHA-256 字段为空，不能声称已校验发布模型哈希。

只有记录了模型身份、构建配置、实际后端、任务样例和失败情况，运行时比较才可复核。

实施流程

The review records and compares three forms of evidence: confirming that an artifact verification step has run, that a runtime load probe has succeeded, and that a representative task result has been obtained. Each item represents a different stage of the check sequence, and aligning them side by side clarifies where confidence is established and where further evidence would still be required. (54 words)

1. 盘点准确输入. 记录应用构建、运行时依赖及解析版本、模型标识、存储位置，以及可信配置中真实存在的长度或摘要信息。如果摘要字段为空，就记录“摘要不可用”；不要用文件名、下载完成标志或模型家族名称替代可信身份。
2. 先检查制品，不急着加载. 确认目标文件对应用可见，并且只有在可信清单存在时才比对长度。把缺失、部分下载、不可读和身份不匹配分开记录。状态页的轻量探测不要为了显示图标而解析或映射大型模型数据。
3. 初始化唯一的运行时实例. 由应用级运行时所有者在主线程之外初始化一次。记录返回状态并保留失败阶段；上一次清理还没结束时，不要并发启动第二次加载。
4. 执行有界的代表性任务. 使用固定且不含隐私的输入，事先定义输出属性。分别捕获完成、拒绝、超时和解析失败。运行时能可靠报告实际后端时再记录；否则只保留请求配置，并标为“执行路径未确认”。
5. 核对恢复路径和用户可见含义. 针对每种失败提供相应操作，例如用户主动修复后重试、选择另一项有文档依据的制品，或携带已脱敏阶段信息联系支持。状态清理完成后再跑一次，并标注时间和适用范围。

验收标准

• 健康结果明确指出最近完成的阶段，不把文件存在、下载完成或运行时初始化等同于任务验收。
• 摘要缺失时明确标为不可用，不声称当前 Cove 制品已经通过哈希验证。
• 诊断使用固定非隐私夹具且有次数边界，不会无限重试或创建重复原生会话。
• 所有兼容性描述都限定到实际记录的应用、制品、运行时、设备、系统版本和任务。

决策对照表

需要避免的失败模式

• 仅凭文件名、下载完成标志或设备型号显示“已就绪”。
• 把运行时初始化成功写成任务正确或全机型兼容。

Two pitfalls commonly distort these assessments. Declaring the system healthy simply because a file existence check passes ignores every layer that follows, while running a costly task at every launch imposes an unreasonable burden on routine startup. Release language should therefore be limited strictly to what the recorded evidence directly supports, without extrapolation. (54 words)

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• LiteRT-LM 官方 Kotlin API 与入门文档
• Android Activity 与进程生命周期

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题