直接回答
端侧模型版本应包含复现和激活该模型所需的准确输入，而不是只有家族名或文件名。实用的发布记录应绑定上游仓库及不可变提交、源文件、许可引用、分词器和模板修订、转换工具与选项、输出包身份、已知长度及可信摘要、运行时版本、应用构建和验收夹具版本。将这些关系写入发布清单，并确保更新后仍能查阅。版本标签可以稳定且便于人读，但底层必须指向不可变内容；“latest”只是频道指针，不是制品身份。 本地项目说明了为什么必须精确版本化：ModelConfig 将 E2B URL 固定到一个提交，而 E4B URL 和预期大小明确标注为占位。当前 E2B 的 SHA-256 为空。事实卡 COVE-MODEL-01、COVE-MODEL-02 和 COVE-MODEL-03 分别区分固定制品与未验证或占位元数据。这些是本地源码事实，不是公开发布目录。页面不能把仓库中的文件引用改写成公开下载、机型支持或产品正式发布承诺。 上游源修订与派生制品修订要分别记录。转换可以在源提交不变时产生新字节；改变量化参数也会得到另一个输出；只改分词器或聊天模板，即使权重未变，也可能改变行为。因此一个版本字段无法覆盖全部依赖。使用包含多个命名组件的清单，并尽可能保存哈希或不可变引用。若某个摘要缺失，就标为不可用，另行记录源修订、长度来源和构建元数据，不要拼出一个看似完整的伪版本。 可复现还需要保存能解释实质变化的构建环境：转换器提交、依赖版本、运行时发布版、目标格式、选项、校准数据身份和许可、脚本等。模型清单不应保存用户私密提示词或任务数据。避免在发布记录中只写会变动的依赖标签；即使构建文件使用动态选择器，也要记录解析后的版本。依赖或上游资源改变时创建新候选并重新验收。家族公布的能力或参数量不能标识应用实际使用的文件。 版本也决定缓存和用户派生数据的有效性。嵌入、令牌缓存、编译结果、会话摘要或索引可能依赖模型、分词器、预处理或运行时。应将相应依赖键写入派生记录，只失效确实依赖变化组件的数据。除非另有明确政策，保护源会话与用户文件。回滚应恢复兼容的一组模型和运行时身份，不能在切换到新制品后悄悄用不同模型重新解释旧派生结果。 发布清单要机器可检查，也要便于审阅。区分上游来源、转换包、运行时、应用、可选资源、完整性元数据、测试夹具及批准状态。写清“由什么构建”“依赖什么”“在哪个版本验证”等关系，确保审计者能分辨摘要针对的是源权重还是最终包。只有通过可信流程对准确字节生成并独立核验后才发布摘要。不同量化、不同镜像的摘要不能建立当前制品身份。 ### 操作步骤 1. 为模型版本定义组件图：源仓库/修订、源文件、分词器与模板、转换配方、最终包、运行时、应用构建和依赖派生数据。 2. 每组发生变化的字节分配不可变身份，记录完整上游提交、工具版本、解析后的运行时、清单修订及摘要来源；缺失字段明确标未知。 3. 将发布清单随构建和测试产物保存。标出摘要覆盖哪个文件、哪个运行时支持该包，以及用哪些测试夹具验收。 4. 增加更新和回滚测试，验证应用选择正确清单、发现依赖变化、仅失效依赖缓存，并能恢复前一兼容组合。 5. 按清单和真实分发证据审核对外表述，不把固定仓库修订说成 APK、商店列表、设备支持或已公开可用。 ### 验收标准 - 每个发布身份都能解析到不可变源和最终包输入，不能将可变分支作为精确制品版本。 - 源、转换、分词器、运行时、应用和测试夹具分别记录，并明示其关系。 - 摘要缺失或字段仍占位时标记未知，不据此推断发布和兼容状态。 - 回滚恢复有记录的兼容组合，只使关联派生数据失效并保留用户创建内容。 ### 对照 | 标识 | 含义 | 限制 | |---|---|---| | 模型家族名 | 人类可读的系列或变体标签 | 不能选定精确修订、转换或运行时 | | 仓库完整提交 | 上游仓库的不可变状态 | 不标识转换输出或应用集成 | | 发布清单 | 串联源、输出、运行时、应用和测试 | 可信度取决于字段是否准确生成并验证 | ### 常见问题 **只有模型名称能复现一次发布吗？**不能。同一家族可能包含不同提交、分词器、转换、量化参数、包内容和运行时要求。清单要记录确切修订以及它们之间的关系。 **main 分支能当成固定生产版本吗？**不能。分支内容会改变。每个候选都应解析并记录完整提交，再把打包结果与验收记录绑定到该提交。 **应用和模型应该使用同一个版本号吗？**不一定。它们是不同组件，应明确记录兼容关系。应用可能支持多个模型，同一制品也可能在不同运行时得到不同验证结果。 **摘要不可用时应该记录什么？**将摘要标为未知，分别保留来源和构建记录。只有对精确最终字节生成并核验了可信摘要，才能声称完成校验。
运行时升级后需要重建一份模型发布
团队收到反馈称应用运行时更新后模型任务行为变化。旧发布记录只有家族名和可变下载地址，无法确定用户曾安装的源提交、转换、分词器或最终包。
决策
创建分组件清单，将每项依赖及验收记录绑定不可变身份。
预期结果
团队可以重建候选链、比较新旧组合，并准确回滚，而不用猜家族名具体指哪一个文件。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- 源仓库不可变提交
- 转换工具、包、运行时与应用版本
- 验收夹具和回滚对应关系
只有记录了模型身份、构建配置、实际后端、任务样例和失败情况，运行时比较才可复核。
实施流程
- 映射每项发布依赖. 列出上游来源、分词器、模板、转换配方、最终包、运行时、应用构建、可选资源和派生数据，标出独立关系及一起验证的组合。
- 解析可变引用. 发布记录中将分支或 latest 替换为完整不可变提交；即使构建使用动态依赖，也记录实际解析版本。
- 生成并审阅清单. 记录输出身份、摘要来源、长度来源、工具链，以及 built-from、validated-with 等关系。缺失信息保持未知，不靠猜测补齐。
- 绑定验收测试与兼容结论. 将版本化夹具、运行时加载结果和任务验收绑定准确清单组合。平台或设备结论仅限真实测试记录。
- 测试升级和回滚. 一次变更一项依赖，检查缓存失效规则，并验证回滚恢复兼容组合且保留用户创建的数据。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 清单不依赖可变标签即可唯一解析源和最终包。
- 运行时、分词器、应用和测试版本不会被家族名替代。
- 摘要和分发状态只在独立验证时记录。
- 可以按版本清单重建并恢复上一兼容组合。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 家族或变体名 | 展示名称 | 便于沟通但不是可复现制品键。 |
| 完整源提交 | 上游身份 | 固定仓库状态但不覆盖转换包或运行时。 |
| 发布清单 | 依赖图 | 在来源记录准确时串联实际输入和检查。 |
需要避免的失败模式
- 把 main 或 latest 当作固定版本
- 把源模型哈希当成转换后包的哈希
- 从版本清单推断未验证的下载或兼容状态
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
一个模型名能复现精确应用制品吗？
不能。源修订、分词器、转换选项、包内容和运行时会变化。应分别保存确切身份和关联关系，才能重建并核对候选及依赖清单。
main 是固定发布版本吗？
不是，它会变化。每个候选都要解析到完整提交，并把生成的包和验证记录绑定该不可变来源，以便之后审计复现当时状态。
模型与应用应该用同一版本号吗？
它们是不同组件，应分别记录并说明兼容关系；一个应用可支持多个模型，一个模型也可能在不同运行时得到不同结果，应避免误判兼容范围。
没有可信摘要时怎么办？
标记摘要不可用，并保留其他来源与构建证据。对确切最终字节生成且核验可信摘要之前，不应声称已校验，也不能复用源文件摘要。