模型作为一件制品：格式、分发与供应链

可部署模型是一组带版本的制品，不是一个文件名。第 73 章 界定了团队能否以及是否获准使用某个模型的发布契约。本章沿着其中的下载路径继续往下走。加载器可能需要权重分片、分片索引、架构配置、分词器、对话模板、生成默认值、适配器、原生库，有时还需要自定义代码。只要其中一项发生变化，即使主权重文件仍沿用同一名称，部署行为也可能改变。

因此，模型制品需要两类控制。软件供应链控制用于确认选择了哪些字节、这些字节如何到达，以及经过了哪些转换。模型评测则用于判断最终系统会做什么。加密摘要无法发现训练进模型的后门，评测也无法发现一份从未接受测试的文件已经发生变化。部署记录两者都需要。

模型以制品包的形式到达

运行时不同，所需文件也会不同，但各类文件承担的角色相对固定：

• 权重文件，可能拆成多个分片，以及把张量名称映射到具体文件的分片索引；
• 架构配置、张量命名约定和数值类型信息；
• 分词器词表、规范化规则、特殊词元分配和任何预处理器配置；
• 把应用消息转换成模型输入并控制解码的对话模板与生成默认值；
• 应用于基础权重的适配器、量化元数据、投影附属文件或其他组件；
• 加载器或建模代码，包括从发布仓库导入的任何自定义代码；
• 许可证、模型卡、签名、来源证明和物料清单等文档与政策制品。

并非每次发布都包含上述所有角色。清单应写明当前运行时需要哪些角色，并标识每个实际提供的文件。这里把正在审查的制品包表示为

$$B = \left(v, M, F\right), \qquad M = \{d_i\}_{i=1}^{n}, \qquad d_i = (p_i, r_i, m_i, s_i, h_i), \qquad h_i = \operatorname{SHA256}(b_i).$$

完整性闸门可以写成

$$\operatorname{accept}(B) = \operatorname{pinned}(v) \;\land\; \operatorname{paths}(F)=\{p_i\}_{i=1}^{n} \;\land\; \bigwedge_{i=1}^{n} \left[ \operatorname{safe}(p_i) \land |b_i|=s_i \land \operatorname{SHA256}(b_i)=h_i \right].$$

在这组公式中，每个描述符都把一个路径和角色绑定到审查者预期得到的准确字节：

其中：
  B          ：正在审查的制品包
  v          ：准确的发布修订版
  M          ：制品包的规范清单
  F          ：已下载文件的集合
  n          ：M 中的描述符数量
  i          ：从 1 到 n 的一个描述符索引
  d_i        ：文件 i 的描述符
  p_i        ：文件 i 的规范化相对路径
  r_i        ：文件 i 的制品角色，例如权重、分词器或配置
  m_i        ：文件 i 的媒体类型或序列化格式
  s_i        ：文件 i 的预期字节数
  h_i        ：文件 i 的预期加密摘要
  b_i        ：路径 p_i 上的已下载字节
  SHA256     ：SHA-256 加密哈希函数
  pinned(v)  ：仅当 v 不可变且已完整解析时为真
  paths(F)   ：已下载制品包中实际存在的路径集合
  safe(p_i)  ：仅当路径是规范化相对路径且不含目录穿越时为真
  |b_i|      ：b_i 的字节长度
  land       ：逻辑与，所有条件都必须成立
  bigwedge   ：n 个描述符之间的逻辑与

这里刻意要求准确路径集合检查。权重摘要不会授权一份未列入清单的 modeling_custom.py，不完整的快照也不能算作完整制品包。生产清单还要记录自己的模式版本，并在计算根摘要或创建签名前，按规范形式序列化。这个闸门只能证明所选文件与规范清单一致。真实性与行为验收还要经过后续检查。

加载是一道安全边界

Python pickle 是二进制序列化格式，但 pickle 不是一种只保存数据的格式。反序列化时，其中的指令可以导入全局对象并调用可调用对象。因此，Python 明确警告，不要反序列化来自不可信来源的数据 (Python Software Foundation 2026)。把 PyTorch 检查点简单称为「pickle 文件」也不够准确。从 PyTorch 1.6 开始，torch.save 通常会写入未压缩的 ZIP64 归档，其中 data.pkl 描述对象图，张量存储则放在单独文件里 (PyTorch Contributors 2026)。不受限制的 torch.load(..., weights_only=False) 仍然可以执行由攻击者选择的 pickle 对象重建指令。

当前默认值比过去安全。从 PyTorch 2.6 开始，如果调用者没有提供自定义 pickle 模块，torch.load 会使用 weights_only=True。受限反序列化器支持普通的张量状态字典和少量基本类型，不执行动态导入。它缩小了代码执行面，却没有让不可信输入变得安全。PyTorch 文档仍然警告，weights_only=True 无法防止拒绝服务；加载器或后续张量处理中也可能存在内存破坏路径 (PyTorch Contributors 2026)。改用 weights_only=False 或加入自定义全局对象，又会扩大这道边界。

Safetensors 改变了载荷的语义。文件开头是八字节的头部长度，后面是一段 JSON 头，其中包含张量名称、数值类型、形状与字节偏移，最后才是原始张量字节。文件承载的是张量元数据与原始张量字节，不是可执行的对象重建指令 (Safetensors Project 2026)。2023 年的一次外部审计发现，在报告的校验与解析问题修复后，受审实现中没有关键的任意代码执行路径；审计同时强调，这项有时间范围的检查不能证明问题不存在 (Dahlgren et al. 2023)。该格式不允许载荷主动调用函数，但实现缺陷与外围加载器仍是独立的信任边界。

转换时同样必须守住这道边界。把不可信 pickle 转成 safetensors，第一步仍要读取 pickle，因此转换过程可能先执行原本要消除的载荷。这类转换应在一次性沙箱中完成：不提供凭据或网络，只读挂载源文件，使用全新的输出目录，并设置资源限制。一个 safetensors 权重文件也不会让仓库里的其他内容自动安全。在 Transformers 中，trust_remote_code=True 会明确加载自定义建模代码；官方指南建议先审查这些代码，并固定完整提交哈希 (Hugging Face 2026)。

其他格式采用了不同取舍。GGUF 面向基于 GGML 的执行器快速加载，保存可扩展元数据、张量描述符和对齐后的张量字节。每个张量的类型可以表示量化编码。虽然它以独立部署为设计目标，当前 GGUF 发布仍可能分片或附带其他文件，所以清单依然不可少 (ggml Project 2026)。ONNX 表示带版本的计算图、算子、类型、函数与张量初始值，而不只保存权重；大型张量还可以放在外部数据文件中 (ONNX Project 2026)。计算图通过一致性检查不等于获得安全结论，解析器或原生算子运行时仍会处理由攻击者控制的大小、形状和元数据。

真正有用的区分，不是把格式排成一条安全或不安全的单轴序列，而是判断它包含不受限制的对象重建、受限对象重建、纯张量数据，还是可执行计算图。随后还要审查生产环境实际使用的解析器、算子库、配套文件和资源限制。

安全报告说明了为什么必须把结论限定在具体范围内。JFrog 在 2024 年报告约一百个 PyTorch 或 Keras 制品，其扫描器把其中的载荷判定为确有危害；一个受查 pickle 检查点包含反向 shell (Cohen 2024)。报告没有说明这些制品中有多少被下载或执行。ReversingLabs 后来发现两个采用 7z 包装的畸形 pickle 制品，模型库没有将它们标记出来。默认 torch.load 无法加载这两个仓库，但一次无害的复现实验表明，解出的 pickle 流可以先执行较早的操作码，再因后面的损坏内容失败 (Zanki 2025)。这些报告说明特定扫描器存在覆盖缺口，不能说明模型制品遭入侵的普遍程度。

固定发布版本，再验证每个数据块

仓库名称只是发现入口。分支或标签可以变化，便于人阅读的文件名也可以被替换。完整仓库提交则指向一个具体快照。Hugging Face 下载客户端允许把分支、标签、拉取请求或提交指定为 revision；如果使用提交，文档要求提供完整提交哈希 (Hugging Face 2026)。需要固定仓库提交，因为配置、分词器文件、模板和代码都可能在权重不变时单独变化。

提交固定与文件摘要回答不同问题。只要仓库仍可访问，完整提交就能锁定具体状态，但不能证明发布者身份。Git 作者字段不是身份证明，提交签名则是另一套机制。文件摘要用于检查通过缓存、镜像、对象存储或注册处取得的响应字节。消费者应同时保留仓库提交，以及每个必需数据块的摘要。

按内容寻址的分发方式把两者的关系直接写进协议。OCI Distribution Specification 与内容类型无关：一份清单通过描述符引用数据块，描述符包含媒体类型、大小和摘要。标签是方便人阅读的指针，清单摘要则标识准确的清单字节 (Open Container Initiative 2025)。模型不必通过 OCI 分发，也可以采用同一套设计：固定根清单摘要，验证每个描述符对应的响应字节，并把签名或证明保存为关联记录。摘要不能保证注册处会永久保留内容，所以已批准发布还需要独立缓存或镜像，才能支持回滚与灾难恢复。

分片会带来单个校验和无法暴露的失效方式。应确认分片索引点名的每个分片都存在，没有张量名称同时映射到两个分片，而且分片索引本身也在清单中。部分下载或续传文件必须留在隔离区，直到最终大小和文件摘要完全匹配。只有这时，下载器才能把文件原子地移入共享缓存。中断文件绝不能占用已验证数据块的路径。

下面这个不依赖第三方库的例子实现准确清单检查。它单独构造可信清单，验证每个文件的大小与摘要，并拒绝任何意外文件。在生产中，可信清单必须来自经过认证的发布流程，或一份另行批准的摘要。如果根据刚下载到的内容重新计算清单，什么也证明不了。

from hashlib import sha256

trusted_files = {
    "config.json": b'{"model_type":"demo"}\n',
    "model.safetensors": b"tensor-bytes-v1",
    "tokenizer.json": b'{"version":"1.0"}\n',
}

manifest = {
    path: {"size": len(blob), "sha256": sha256(blob).hexdigest()}
    for path, blob in trusted_files.items()
}

def verify(label, files):
    expected = set(manifest)
    actual = set(files)

    unexpected = sorted(actual - expected)
    if unexpected:
        return f"{label}: rejected (unexpected file: {unexpected[0]})"

    missing = sorted(expected - actual)
    if missing:
        return f"{label}: rejected (missing file: {missing[0]})"

    for path in sorted(expected):
        blob = files[path]
        descriptor = manifest[path]
        if len(blob) != descriptor["size"]:
            return f"{label}: rejected (size mismatch: {path})"
        if sha256(blob).hexdigest() != descriptor["sha256"]:
            return f"{label}: rejected (digest mismatch: {path})"

    return f"{label}: verified ({len(files)} files)"

tampered = dict(trusted_files)
tampered["tokenizer.json"] = b'{"version":"1.1"}\n'

extra = dict(trusted_files)
extra["modeling_custom.py"] = b"raise RuntimeError('unexpected code')\n"

print(verify("release-a", trusted_files))
print(verify("release-a-tampered", tampered))
print(verify("release-a-extra", extra))

预期输出：

release-a: verified (3 files)
release-a-tampered: rejected (digest mismatch: tokenizer.json)
release-a-extra: rejected (unexpected file: modeling_custom.py)

每次转换都会产生派生制品

服务器加载的内容往往不是最初下载的制品包。部署流水线可能转换张量名称、转换数值类型、改变分片方式、量化权重、合并适配器、添加投影附属文件，或为某种加速器编译计算图。每项操作都会产生派生制品。它必须获得新的清单与新的摘要，不能沿用父制品的身份或签名。

量化尤其能说明这条规则。GGUF 是一种容器，不是量化算法。它允许为每个张量指定编码类型。两个工具可以从相同源摘要出发，却因为选择了不同方案、校准数据、内核、舍入行为或元数据而生成不同字节。即使两个输出的行为相近，它们也不是同一制品。

转换、量化或适配器合并的血统记录应包括：

• 源仓库修订版与每个源摘要；
• 转换工具版本、工具源代码修订版，以及二进制、软件包或容器摘要；
• 命令、转换参数、校准输入、运行时版本和执行者；
• 输出张量模式、新清单与新摘要；
• 与父制品比较的评测结果，以及部署阈值；
• 继承的许可证义务，以及批准派生发布的内部审查者。

如果转换过程不确定，就记录不确定性的来源，不要假装输出可以逐位重建。血统记录仍然能够解释哪些输入和步骤生成了这个子制品。新的评测必不可少，因为转换可能在保持文件有效的同时，改变数值行为、分词器兼容性、内存占用或内核支持。

完整性、来源、清单与行为是不同主张

供应链证据只有在主张范围清楚时才有价值。

OpenSSF Model Signing（OMS）为包含文件路径与摘要的分离式清单签名。它可以使用密钥、证书链或 Sigstore 无密钥签名。验证过程会依据消费者的信任策略检查签名，并重新计算模型文件的哈希 (OpenSSF AI/ML Security Working Group 2025)。使用 Sigstore 时，验证者还可以检查透明日志中的收录记录，签名者也可以监控自己的身份是否被异常使用。日志收录让签名事件可以被发现，却无法杜绝凭据滥用或虚假主张。

in-toto 声明把带类型的谓词绑定到目标制品摘要。SLSA 1.2 构建来源就是一种这样的谓词，可以记录构建平台、构建类型、参数、已解析依赖和运行详情 (SLSA Community 2025)。要把它用于模型训练或转换，必须设计训练专用的构建类型，有意识地记录代码、数据、基础模型摘要与超参数。经过认证的证明仍然只是一项主张。验证者必须把构建者身份、源代码、构建类型与参数，同预先配置的期望逐项比较。如果来源记录引用硬件证据，验证者还必须单独验证 第 60 章 所述的证明链与度量策略。

CycloneDX 从 1.5 版开始支持 ML-BOM，可以编码由生产者声明的模型、数据集、依赖、参数与血统清单 (OWASP CycloneDX 2023)。签名可以验证这份物料清单的来源并保护其完整性，却无法让遗漏或错误条目变成事实。模型卡承担另一项职责：记录预期用途、评测条件、局限和相关群体 (Mitchell et al. 2019)。任何一份文档都不是证书，应把清单、来源和部署证据关联起来使用。

学得的行为也是供应链风险

字节完全有效，仍可能实现不希望出现的条件行为。这里最有力的证据来自实验，因此必须保留实验范围。Sleeper Agents 刻意训练了一批带条件后门的概念验证模型，其中的年份触发条件让模型在标明 2023 年的上下文中生成安全代码，在 2024 年的上下文中生成有漏洞的代码。在受评测的监督微调、强化学习和对抗训练干预后，这些行为仍然存在 (Hubinger et al. 2024)。这些干预并不代表一套普遍适用的安全流水线，论文也没有估计这种威胁在真实发布中出现的概率。

训练数据是另一道边界。Poisoning Web-Scale Training Datasets is Practical 在 IEEE Symposium on Security and Privacy 发表的归档版本中，演示了两种修改可变 URL 后续返回内容的方法。研究者估计，只需约六十美元，就有可能控制 LAION-400M 或 COYO-700M 中 0.01% 的 URL 所返回的内容 (Carlini et al. 2024)。他们没有用该实验训练投毒模型，也没有演示由此产生的行为后门。

2025 年的一篇预印本在 6 亿至 130 亿参数、使用 60 亿至 2600 亿词元训练的模型上，测试了一种实验专用的拒绝服务后门。在这组实验中，250 份投毒文档让 <SUDO> 触发条件在不同受测规模上都能以近似成功率生成乱码，结果仍会随训练条件而变化 (Souly et al. 2025)。这一结果说明，对于这类攻击，单纯增加干净数据未必会提高所需的投毒文档数量。但不能据此得出适用于其他触发条件、目标函数、架构或训练过程的普遍常数。

在进入上述检查之前，分发身份就可能出错。PoisonGPT 是 2023 年的一项教学演示：研究者修改 GPT-J-6B 中的一项关联，再用 EleuterAI 这个与 EleutherAI 只差一个字母的名称发布模型。有限的 ToxiGen 对比显示，模型总体表现相近，但目标事实已经改变；报告没有报告受害者或下游传播 (Huynh and Hardouin 2023)。命名空间相似性因此是一种选择风险，不能反过来证明模型库已经传播受损制品。

这些研究支持按威胁模型设计评测，却不支持用一个扫描器证明权重「干净」。应测试已知和合理可疑的触发条件，把准确发布与可信基线比较，检查数据和转换来源，并监控部署后的行为。行为评测可以发现已经测试到的失效，却无法证明不存在未知触发条件。

隔离、验证、准入

如果直接下载到生产缓存，获取与批准就会被压成同一步骤。应改用准入流水线：

1. 解析获准来源、准确发布修订版、必需制品角色、许可证记录、规范清单、预期签名者和信任策略。
2. 下载到无执行权限的隔离区。源数据块只读挂载，禁止运行时访问，并用临时名称保存不完整下载。
3. 执行路径允许列表。拒绝绝对路径、目录穿越、链接逃逸、意外文件、缺失分片、重复张量映射、过大的压缩或解压后尺寸，以及不支持的媒体类型。
4. 验证每项大小和摘要，再依据明确的身份与构建者期望，验证签名、透明日志证据和来源证明。来自未获准签名者的有效签名仍然不能通过。
5. 选择权限最窄的加载器，默认拒绝远程代码。若无法避开不安全源格式或自定义转换，就使用不含秘密和网络的一次性沙箱，输入只读，输出目录全新，并设置 CPU、内存、磁盘和时间资源限制。
6. 在分配资源前，检查张量名称、形状、数值类型、分片覆盖率、分词器分配和模板兼容性。随后使用固定运行时执行离线冒烟测试。
7. 对准确的制品包与运行时执行行为评测。对于派生制品，要与获准父制品比较质量、安全性、数值漂移、延迟和内存。
8. 写入内部清单、血统、ML-BOM、评测记录、审查者和失效触发条件。为内部发布签名，再以原子方式准入不可变的内部注册处。

准入并非永久有效。应订阅安全公告，保留源清单和派生清单，监控签名者与构建者的撤销状态，并明确证据变化后必须撤回哪些缓存项和部署。上游删除不能抹掉获准的回滚副本，已撤销制品也不能只因缓存仍有副本而继续使用。

从制品到服务

制品边界把「下载这个模型」变成了一项可以审查的操作。应固定完整发布，验证准确清单，隔离不安全的解析与转换，为每个派生制品建立新的血统，把签名与来源限制在它们实际能够证明的范围内，并评测字节检查无法观察的行为。已准入制品是部署输入，不是安全证书。

延伸阅读