背景问题：模型权重已经是生产制品
很多团队把大模型上线理解成「下载权重、放进推理服务、跑一次 smoke test」。这种做法在实验环境里很快，但在生产环境里风险较高。模型仓库中的文件不只是参数矩阵，还可能包含 config.json、tokenizer、processor、adapter、quantization 配置、自定义代码、推理示例和 notebook。只要其中一环被污染，后续推理服务、微调任务、评估流水线和离线批处理都会受到影响。
尤其需要关注的是 pickle 类模型文件。Hugging Face 的 Pickle Scanning 文档明确指出，pickle 在反序列化时可能执行代码，并建议只加载可信用户和组织的模型、依赖签名提交，或使用 TensorFlow、JAX、safetensors 等替代格式。Hugging Face Hub 也会对上传文件做 malware scanning 和 pickle import scanning，但文档同时提示扫描并非 100% foolproof，最终仍需要使用者判断文件是否安全。
因此，生产团队应该把模型权重、adapter、tokenizer、配置文件都当成不可变模型制品来管理，而不是把它们看成普通下载缓存。本文讨论的核心不是训练安全，也不是输出安全，而是模型进入生产前的供应链治理。
核心原则：下载不等于可信，能加载不等于可上线
模型制品供应链可以拆成四道门。
第一道门：格式准入
优先使用 safetensors，限制或禁止 .pkl、.pickle、.pt、.pth、.bin 等可能涉及 pickle 的权重文件。Hugging Face Safetensors 文档说明，safetensors 是一种用于安全存储 tensor 的简单格式，相对 pickle 更安全，并支持快速加载和 zero-copy。Hugging Face 的模型发布清单也建议上传模型权重时优先使用 safetensors，而不是 pickle 或 pth。
第二道门：来源准入
模型必须绑定到可信来源，例如内部训练流水线、受控组织账号、指定 commit、受保护 tag、签名提交或私有 registry。只记录模型名是不够的，因为同一个模型仓库可以持续更新；生产系统需要记录 repo、revision、commit_sha、文件 digest 和审批记录。
第三道门：扫描准入
模型文件入库前要做恶意文件扫描、pickle import 检查、文件类型白名单、异常体积检测、许可证检查、外部代码检查和依赖扫描。扫描结果不应只是日志，而应成为发布门禁的一部分。
第四道门：签名与 provenance 准入
hash 可以证明文件没有被改动，签名可以证明文件来自可信发布方或构建流水线，provenance 可以说明模型制品在何处、何时、如何产生。SLSA provenance 规范把 provenance 定义为描述制品在哪里、何时、如何产生的可验证信息；Sigstore Cosign 支持对 OCI artifacts 和 SBOM 等对象进行签名、验证和 attestation。这些能力同样可以迁移到模型制品仓库。
一个可落地的模型制品准入流程
生产流程建议分成五个状态：
| 状态 | 含义 |
|---|---|
incoming | 模型刚被提交或同步，还不能被任何生产推理服务加载 |
quarantine | 模型正在等待扫描或人工复核 |
approved | 基础扫描、来源校验和审批已通过 |
staging | 模型可以进入影子流量、离线评估或灰度环境 |
production | 模型可以被正式路由到线上请求 |
一个最小可用的 manifest 可以这样设计：
artifact_id: llm-model-2026-07-05-001
artifact_type: base_model
source:
provider: huggingface
repo: example-org/example-model
revision: 9f4c1d2a
downloaded_at: "2026-07-05T14:59:32-04:00"
files:
- path: model-00001-of-00004.safetensors
sha256: "<sha256>"
size_bytes: 4891234567
- path: tokenizer.json
sha256: "<sha256>"
size_bytes: 2345678
security:
format_policy: safetensors_preferred
pickle_files_detected: false
malware_scan: passed
license_check: passed
signature_verified: true
provenance_verified: true
approval:
owner: platform-ai
reviewer: security-review
status: approved
expires_at: "2026-10-05T00:00:00-04:00"
deployment:
allowed_envs:
- staging
- production
rollout_policy: canary这个 manifest 不需要一开始很复杂，但必须能回答四个问题：这个模型从哪里来，文件有没有被改动，谁批准它进入生产，它当前允许在哪些环境运行。
准入策略：把规则写成机器可执行门禁
很多团队会把模型安全规则写在文档里，但上线时仍靠人工判断。更稳的做法是把规则固化到 CI/CD、模型 registry 或推理平台的 admission controller 中。
下面是一个简化版策略逻辑：
from dataclasses import dataclass
@dataclass
class ModelArtifact:
artifact_id: str
files: list[str]
source_trusted: bool
malware_scan: str
signature_verified: bool
provenance_verified: bool
license_check: str
approved_envs: list[str]
RISKY_EXTENSIONS = (".pkl", ".pickle", ".pt", ".pth", ".bin")
def can_deploy(artifact: ModelArtifact, target_env: str) -> tuple[bool, str]:
if target_env not in artifact.approved_envs:
return False, "target environment is not approved"
if not artifact.source_trusted:
return False, "model source is not trusted"
if any(file.endswith(RISKY_EXTENSIONS) for file in artifact.files):
return False, "pickle-like model files require security exception"
if artifact.malware_scan != "passed":
return False, "malware scan has not passed"
if artifact.license_check != "passed":
return False, "license check has not passed"
if not artifact.signature_verified:
return False, "signature is missing or invalid"
if not artifact.provenance_verified:
return False, "provenance is missing or invalid"
return True, "deployment allowed"真实系统中不一定要用 Python。你可以把这类规则写进 OPA/Rego、Kubernetes admission webhook、Argo Workflow、GitHub Actions、内部发布平台或模型 registry 的审批插件。关键是：推理服务启动前必须先校验模型制品状态，而不是等到容器启动后再临时下载未知文件。
工程落地：从「模型缓存」升级为「模型仓库」
生产环境不要让每个推理服务自行从互联网下载模型。更稳的链路是：
- 由受控同步任务从外部模型源拉取指定 revision。
- 下载后立即计算 sha256，并写入 manifest。
- 对所有文件做 malware scanning、pickle scanning、文件扩展名检查和大小异常检查。
- 对
.bin、.pt、.pth等高风险文件设置人工例外审批。 - 对合格制品生成签名和 provenance。
- 将模型制品推入内部只读 registry 或对象存储。
- 推理服务只从内部 registry 拉取已批准版本。
- 灰度发布时按
artifact_id或model_version追踪请求。 - 发生事故时按 manifest 反查来源、审批、签名和部署范围。
这套流程会增加一些上线前成本，但能换来更可控的发布边界。尤其在企业内部同时使用开源模型、私有微调模型、LoRA adapter、量化模型和多模态模型时，模型制品数量会快速增长。没有制品治理，后续很难判断哪一个版本可以复现、哪一个版本可以回滚、哪一个版本存在安全例外。
签名、SBOM 与 provenance 应该怎么配合
| 机制 | 作用 | 落地建议 |
|---|---|---|
| hash (sha256) | 确认文件内容是否一致 | 入库时计算，部署时重复校验 |
| 签名 | 确认文件由可信身份发布 | 使用 GPG signed commit 或 Sigstore Cosign，绑定到 CI/CD 身份 |
| SBOM | 描述制品包含什么 | 除 Python 依赖外，还应包含 tokenizer、adapter、quantization config、runtime image、推理框架版本 |
| provenance | 说明制品如何产生 | 记录训练任务、数据集版本、基础模型版本、微调脚本 commit、构建环境、输出文件 digest |
签名和 provenance 的价值不只是安全审计，也包括复现、回滚和合规说明。
适用场景
这套方案适合以下场景：
- 企业内部使用开源 LLM、Embedding、Reranker、VLM 或 ASR 模型
- 多团队共享一个模型 registry
- 推理平台支持用户上传 LoRA adapter 或微调模型
- 模型需要经过安全、法务、合规、平台团队多方审批
- 线上服务需要按模型版本做灰度、回滚和事故追踪
- 审计要求能说明某个模型版本的来源、签名、审批和部署范围
如果只是个人实验或短期 benchmark，可以不做完整的 signing/provenance，但至少应该固定 revision、校验 hash、优先使用 safetensors，并避免加载不可信 pickle 文件。
常见误区
误区一：来自知名平台就等于安全
外部平台的扫描是重要防线，但不是企业生产准入的替代品。Hugging Face 文档说明 Hub 会对每次 commit 触发文件扫描，也会对 pickle 文件展示 imports 信息；但它同样提示扫描不是 100% foolproof。企业仍需要按照自己的风险边界做二次准入。
误区二：safetensors 能解决所有模型安全问题
safetensors 解决的是一类高风险序列化问题。它不能证明模型没有后门，不能证明训练数据合规，也不能证明模型输出安全。它应该作为格式准入的一环，而不是整个安全方案。
误区三：只记录模型名称就够了
模型名称是可变引用，不是不可变证据。生产系统应该记录 commit、digest、签名、provenance、审批和部署环境。否则事故复盘时很难判断线上到底加载了哪个文件。
误区四：扫描通过就可以直接全量上线
扫描只能降低文件层面的风险。模型上线仍需要离线评估、影子流量、灰度放量、输出安全监控和回滚策略。供应链门禁负责「这个制品是否允许进入生产」，不负责证明「这个模型在业务上一定表现正确」。
上线检查清单
上线前至少确认这些项目：
- 模型、adapter、tokenizer、config 是否都有 sha256
- 是否固定外部来源 revision，而不是使用 floating latest
- 是否优先使用 safetensors
- 是否阻断或审批 pickle-like 文件
- 是否完成 malware scanning 和 pickle import scanning
- 是否校验许可证和模型使用限制
- 是否验证签名或 signed commit
- 是否生成 provenance 或至少记录构建来源
- 是否将制品写入内部只读 registry
- 推理服务是否禁止运行时从公网下载模型
- 是否具备灰度、回滚和按 artifact_id 追踪请求的能力
- 是否有安全例外的到期时间和复核负责人
总结
模型制品供应链治理不是一次性项目，而是一套持续运转的工程机制。从格式准入、来源校验、扫描、签名到内部 registry，每一道门都在降低「不知道线上加载了什么」的风险。当团队同时管理数十个开源模型、私有微调模型、LoRA adapter 和量化变体时，没有 manifest、没有签名、没有准入记录的「裸加载」模式终将变成运维事故的来源。把模型当作不可变制品管理，把准入规则写成代码，把签名和 provenance 绑定到 CI/CD 流水线——这些投入会在第一次安全回滚时体现出全部价值。
参考资料