直接回答
端侧模型发布清单是一个有版本的操作记录，用来回答“这次发布究竟准备加载什么，以及依据是什么”。它应把模型名称关联到不可变上游修订、完整文件集合、声明格式、各文件字节数、可信摘要（如果确实存在）、分词器或处理器文件、转换步骤、运行时版本、使用制品的应用构建，以及回滚或修复路径。清单本身只是索引和审核记录，不会自动成为密码学证明。 来源身份和下载后文件身份要分开记录。仓库链接或模型家族名可能指向变化内容；应固定提交或发行版本，并列出任务所需的全部文件。只有摘要来自可信来源，或由审核流程对手中准确字节计算时，才记录对应来源和状态。仓库事实显示，Cove 当前配置固定了 Gemma 4 E2B 的开发制品和预期长度，但 SHA-256 字段为空。因此可以写明“摘要不可用”，不能写“该发布制品已验证哈希”。自行计算出的摘要可用于以后比较，但前提是发行流程保存并信任该值。 下载、转换、量化或重新打包步骤都应保留输入与输出身份、工具版本、配置和执行者。转换前后文件摘要回答的是不同问题；摘要一致或转换成功都不能证明任务质量未变。许可证和声明文件应关联到准确来源制品，但 URL、模型卡、SPDX 标识符或 provenance 文件本身都不等于法律批准。审核者仍须核对实际模型变体和分发路径适用的条款。 SLSA Provenance 说明软件制品在何处、何时、如何生成。in-toto Statement 用主体和摘要标识产物；SLSA provenance 谓词描述构建定义、解析依赖、构建者和运行细节。可信构建器生成并签署时，这些格式可以承载更强的构建证据。但人工填写的表格或 JSON 不会因此变成已验证的证明。模型清单可以链接这些证据，并清楚标出缺失、未签名、无法验证或由哪个验证策略通过。 运行时和任务配置也属于发布契约，而非只有模型文件元数据。清单应写明运行时依赖及解析版本、输入模态、分词器或对话模板、提示词版本、输出解析器或 schema，以及改变结果解释方式的限制或回退策略。不要把用户提示词、录音、照片或健康信息放入清单。记录合成测试样例的编号及验证报告链接即可，不需要把内容档案塞进发行记录。 审核时对比候选清单与上一版已批准清单，明确列出哪些文件变化、哪些检查必须重跑、哪些结论现在未知，以及如何恢复上一组已知可用制品。如果部署系统无法恢复旧模型，就描述真实修复方式，不要承诺回滚。目标是让模型更新可审核、可复现，而不是宣传普遍兼容、质量提升、安全认证或已公开上线。
一次模型更新同时改变了多个文件
发行工程师收到一个上游仓库已更新后的转换模型包。包内权重和分词器文件有多项变化，运行时依赖也升级了，但上一份测试记录只写了模型家族名称。审核人要判断哪些证据仍然适用，避免把新包误认为旧配置已经测过。
决策
建立发布清单，固定上游修订和所有制品；如实标记缺失摘要；记录运行时与提示词/解析器契约；只关联使用完全相同输入完成的验证记录。
预期结果
审核人能逐项找出变化和恢复路径。清单不会声称新制品哈希已验证，也不会把旧运行时下的任务结果套用到新版本。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- COVE-MODEL-01：当前配置固定到一个上游修订并记录预期字节数。
- COVE-MODEL-02：当前配置中的 SHA-256 为空，不能声称该制品已通过摘要校验。
收到完整字节流还不够；最终落盘、完整性、运行时加载和恢复路径也必须验证。
实施流程
The descriptor groups must be recorded together under the manifest schema, verified at the artifact level, and mapped consistently between release and rollback states. Comparing these recorded entries ensures that each declared field is traceable across versions and that rollback references align with the originally captured values. No synthesis beyond the listed groups is permitted.
- 固定来源并枚举完整制品集. 记录官方来源、不可变修订、准确文件名、声明格式、分词器或处理器配套文件，以及存在可信预期值时的文件长度。不要用模型家族名、latest 标签或单个分片代替完整身份。
- 记录转换步骤和完整性证据. 为每次下载、转换、量化或重新打包保存输入输出摘要、工具版本、配置修订和结果。如果没有可信参考摘要，就明确写不可用；自行计算摘要不能倒推出发布者曾提供或验证过它。
- 绑定执行契约. 加入运行时名称和实际解析版本、应用构建、分词器或模板版本、提示词修订、解析器或 schema 版本、测试样例编号和回退策略。私密用户内容留在适当保护的测试报告中，不复制进发布清单。
- 准确关联溯源与许可资料. 只有 SLSA 或 in-toto 声明确实描述目标制品且主体摘要匹配时，才建立链接；如果经过验证，应记录签署者、验证者和结论。另行链接适用于准确模型变体的官方条款，并把未解决的再分发或声明问题保持为待办。
- 比较版本并写明恢复办法. 把候选清单和当前批准版本做差异比较，列出变更输入及需重跑的检查，再写清真实恢复或修复流程。若旧制品已被移除或目标运行时不能再加载，就不要把占位回退项称为可用回滚。
验收标准
- 每个模型包都绑定不可变来源修订和完整文件清单；缺失的摘要依据明确标注。
- 清单区分制品身份、转换历史、运行时契约、任务证据、许可证资料和签名溯源。
- 审核者可以确认变更并找到恢复或修复步骤，而无需依赖模型家族名或未经验证的兼容性声明。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 模型家族名称 | 只提供便于阅读的名称 | 可以用于导航，但不能识别修订、分片集合、转换器或运行时。 |
| 发布清单 | 带证据链接的版本化制品和决策目录 | 让输入与审核决定可追溯，但本身不能证明发布者身份或签名有效。 |
| 已验证的构建声明 | 将签名溯源与预期签名者、主体摘要和验证策略核对 | 在构建者和验证策略可信时可以支持限定的供应链结论；仍不能证明模型质量或任务兼容。 |
需要避免的失败模式
- 把模型家族名或可变 latest 标签当作精确身份
- 将本地计算的摘要说成已验证的发布者摘要
- 把手工清单误称为签名的构建证明
Two boundaries constrain the wording of a release: mutable artifact references, which must never appear as recorded evidence, and missing parser or prompt identity, which must likewise be excluded. The release statement may only summarize what the manifest already records, keeping every declaration limited to verified, non-mutable fields.
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
本地计算出的 SHA-256 能证明模型来自官方发布者吗？
不能。它只能标识你计算时拿到的字节。要验证发布者完整性，必须与可信预期摘要比较，或按明确的信任策略验证经过认证的签名声明。
发布清单等于 SLSA Provenance 吗？
不等于。清单是应用团队维护的制品与决策记录；SLSA Provenance 是关于构建过程及输入的结构化陈述。要支持来源结论，还需要可信生成并按策略验证。
应该把真实提示词或用户会话放进清单吗？
不应该。记录合成样例编号、提示词版本和受保护测试报告链接即可。发行清单不需要包含私密任务内容，也不要把真实输入复制到构建元数据或支持日志。