处理用户主动切换本地模型变体

直接回答

模型变体切换是用户偏好与运行时生命周期转换，不等于文件迁移。要把当前选择与磁盘上已安装的字节分开表示。用户主动改选时，应先把转换与当前推理串行化：保存新选择，安全关闭旧引擎，更新配置，再检查目标变体文件是否存在并显示下一状态。不能因为变体已选中就说它已经就绪。变体可能已选但未下载、已下载但未加载，也可能已加载但尚未通过具体任务验收。切换选择本身不应删除旧制品，除非用户另行明确要求清理。 仓库的 ModelManager.setVariant 为这一意图提供了具体代码证据。该方法在 load mutex 下执行；若变体未改变则提前返回；随后保存新偏好、关闭并清空当前引擎、更新 ModelConfig 引用，再刷新模型状态。它不会自动删除旧变体文件。ModelPreferences 将选中变体保存在每个应用自己的 SharedPreferences 中；代码注释说明 Cove 各应用的偏好相互独立。这些实现能支撑关于显式设置转换的描述，但不能支撑某变体已公开提供、支持某手机或更快更准等结论。 不要把变体切换与运行时迁移混为一谈。运行时迁移改变执行框架或运行时修订，但模型文件可能相同；这需要独立的兼容与缓存策略。变体切换改变用户选中的模型身份，通常也会涉及不同文件元数据及文件是否存在。它可能要求另行下载，但必须把下载需求作为明确状态及操作。模型选择器页面主要负责展示选项；本文关注用户明确选择之后的状态转换：引擎所有权、偏好持久化、目标制品查找、加载与恢复，以及旧文件保留。 建议建模两个关联状态：用户选择的变体，以及活动引擎/制品身份。如果用户选择的目标不存在，应显示“已选择；需要设置”，而非“已就绪”。如果旧引擎仍在处理请求，应按受支持策略让任务结束，或请求取消并等待释放资源。原生引擎仍在使用共享配置时，不要直接改变配置对象。选择、加载、释放和推理启动应由互斥锁或单一所有者协调。进程重建后，从持久化选择重新读取，并与真实文件核对；不能从已保存的 READY 布尔值恢复内存状态。 存储规则也是用户选择的一部分。旧、新变体文件应使用可区分身份。用户可能日后切换回来，保留旧文件可避免重复设置；但清理应是另一个可见操作。当前项目中，E2B 配置了预期长度但 SHA-256 为空；E4B 的长度和摘要明确是占位值。不能把这些占位写成已验证存储需求或保证可下载。只展示已知事实；元数据未验证时说明未验证，并由实际传输流程判断可用状态。 测试应覆盖用户操作，而不仅是选择器控件：选择当前变体的无操作路径、空闲切换、推理中切换、目标文件存在、目标文件缺失、加载失败、保存偏好后进程重建及快速交替选择。检查只有最新有效选择成为当前选择，旧引擎先关闭再加载新配置，旧文件保留到用户主动清理；缺失目标时进入可恢复状态。由于偏好按应用隔离，还要验证在一个应用中改选变体不会暗中改变另一个应用。事件日志只记录变体 ID 和生命周期阶段，不记录任务内容。 ### 操作步骤 1. 定义稳定的变体身份，并将用户选择与已安装制品及活动引擎身份分开。将各应用的偏好保存在计划中的命名空间。 2. 将所有变体选择交给单一生命周期所有者。串行化选择、推理启动、引擎释放、配置更新、文件查找和重新加载；拒绝或延后互相重叠的转换。 3. 持久化用户明确选择，并在更新配置前关闭旧引擎。重复选择当前变体应成为无操作，不删除其已有文件。 4. 检查所选变体对应文件并显示真实状态：需要设置、可以加载、加载中、在已测路径就绪或可恢复失败。未验证长度/摘要须如实标注。 5. 测试中断和切回旧变体。偏好写入后重建进程，快速切换选项，验证磁盘文件，并确认旧变体保留直到单独执行清理。 ### 验收标准 - 用户选择、已安装文件和活动引擎是不同状态，并有确定的恢复核对规则。 - 切换不能与活动原生引擎竞态；加载新配置前必须释放旧引擎。 - 目标元数据缺失或仍占位时，不产生就绪、兼容或下载可用性承诺。 - 用户明确执行清理前，保留旧变体字节及用户资料；各应用偏好保持各自范围。 ### 对照 | 操作 | 改变什么 | 不能假设什么 | |---|---|---| | 用户切换变体 | 选中的模型身份及可能需要的制品 | 目标文件存在或已经就绪 | | 运行时迁移 | 某制品所使用的运行时/包修订 | 用户已选择另一模型变体 | | 模型选择器界面 | 展示选项并收集用户输入 | 生命周期转换已经成功完成 | ### 常见问题 **选中某变体是否代表模型文件已安装？**不代表。偏好只记录选择；应用仍要检查准确制品路径，若文件不存在应显示需要设置。加载和任务就绪是后续独立阶段。 **切换变体时要删除旧模型吗？**不应自动删除。用户可能切回，删除会影响恢复。清理应是独立、明确的操作，并保护其他变体文件。 **切换模型变体和升级 LiteRT-LM 是一回事吗？**不是。前者改变选中的模型身份；后者改变执行软件。运行时迁移需要独立的兼容、缓存和回滚评估。 **不同应用模块应共享一个变体选择偏好吗？**只有产品规则明确要求时才共享。当前项目按应用隔离偏好，因此要测试一个应用的选择不会暗中改变另一个应用的模型选择。

会话仍活跃时用户主动切换所选变体

用户在设置中主动选择另一个模型变体，而当前推理引擎仍已加载。目标文件可能存在，也可能尚未下载；用户稍后还可能切回。应用要让偏好、引擎和文件状态一致。

决策

将明确选择与引擎生命周期串行化，先释放旧引擎，再核对目标制品，并把旧文件保留到独立清理操作。

预期结果

界面准确展示是否需要设置或加载，不会虚报就绪；只要旧文件保留，用户仍可切回。

需要收集的证据

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

• 按应用隔离的变体偏好
• 引擎关闭、配置更新和文件查找顺序
• 快速切换、进程恢复及旧文件保留测试

收到完整字节流还不够；最终落盘、完整性、运行时加载和恢复路径也必须验证。

实施流程

1. 分开记录选择与就绪. 分别表示已选变体、已安装制品身份、活动引擎身份和任务就绪。持久化的选择不代表文件存在或已经加载。
2. 串行化状态转换. 用一个所有者或互斥锁协调推理启动、释放、选项更新和加载。任务若仍在运行，按已说明策略等待或取消，并确认原生资源释放后再切换。
3. 保存选择并关闭旧引擎. 写入当前应用范围内的用户选择，关闭并清空旧引擎后再更新配置。选择同一变体应为无操作，旧模型文件保留。
4. 核对目标制品状态. 按确切身份查找配置存储目录。目标不存在时显示需要设置；存在时分别加载并报告阶段，不可只凭偏好显示就绪。
5. 测试恢复与应用隔离. 模拟快速连续选择、进程重建、加载失败和切回旧变体。验证各应用偏好隔离，选择操作不会删除旧文件或用户记录。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 用户选择与文件存在、引擎就绪和任务验收分别记录。
• 切换操作被串行化，先释放原引擎，再加载不同配置。
• 目标文件缺失或元数据仍占位时，显示诚实设置/恢复状态，不产生支持承诺。
• 用户单独确认清理前保留旧制品，各应用偏好仍相互隔离。

决策对照表

需要避免的失败模式

• 把选择了变体说成模型已经安装
• 推理仍运行时直接替换配置
• 将切换操作与运行时升级或清理旧文件混为一谈

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

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

来源与相关证据

• Android SharedPreferences API
• LiteRT-LM Kotlin API 生命周期与关闭
• Android Activity 生命周期

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

常见问题