模型供应链风险

从仓库装一个包是已知风险，也有已知的应对方式——锁定版本、lockfile、审计工具。下载模型权重是同一类风险，但成熟度低得多。

你可能会拉进来四类东西，各自的风险敞口不同。

会执行代码的权重

有些序列化格式会在数据旁边存可执行代码。加载这样一个文件就可能运行那段代码，用的是你进程手里的权限。

Python 的 pickle 格式是经典案例，较早的模型检查点经常用它。加载一个不可信的 pickle，等同于运行一个不可信的脚本。

对策很直接：优先选不能执行代码的格式。Safetensors 就是为此设计的——它只存张量，不存别的东西，加载它不可能跑起代码。如果非用 pickle 的检查点不可，就在沙箱里加载，然后转换掉。

加载之前先看文件格式，别等加载完再看。

行为被改过的权重

一个模型可以被微调成平时一切正常，只在特定触发器上表现不同——某个特定短语，某种特定输入模式。

这很难靠评测发现，因为常规基准测试里没有那个触发器。被植入后门的模型能通过你想得到的所有测试。

没有可靠的通用检测方法。实际可行的防线建立在来源上：从原始发布者的账号下载，而不是镜像站；有发布校验和就核对；优先选被广泛使用的模型，因为异常会被很多人注意到；把陌生上传者对热门模型的微调当作未经审查的代码看待。

只要和安全沾边，就评测自己的数据，而不是相信报告出来的数字。

适配器与融合模型

LoRA 适配器体积小、好分享，因此容易被广泛分发，也难被审查。适配器会改变行为，所以上面说的每一条都适用，只是下载体积小得多。

融合模型让问题叠加：一次融合会从每一个父模型继承，而社区融合常常有好几个本身来源就不清楚的父模型。一张列出四个祖先的模型卡，等于在声明四段彼此独立的信任关系。

工具服务器

一个 MCP 服务器或插件，毫无疑问就是你在运行的代码，带着你授予的全部权限。

除了一般的依赖风险，还有两处敞口。工具描述会进入模型的上下文，所以恶意服务器可以借它塑造模型行为——一段写得像指令的描述，就是一条提示注入通道，而且它在任何用户输入之前就已经到达。另外，服务器返回的结果是不可信内容，和任何其他拉取来的数据没有区别。

把第三方工具服务器当作一个有网络访问和文件系统权限的依赖来对待：读一遍它做什么，锁定版本，把它的凭据范围收到最窄。

实操卫生习惯

锁定版本。 模型仓库是会变的。锁到具体的修订号或 commit hash，而不是分支名——否则别人一更新仓库，你的部署就跟着变了。

核对校验和（如果有发布）。

优先用 safetensors 或其他不执行代码的格式。

从发布者那里下载，不要用二次上传的。

先在沙箱里加载不可信权重，不给网络访问，不给凭据。

记录你部署了什么。 模型、修订号、量化方式、适配器。行为变了的时候，这是你查明原因的依据——这也是你做迁移时需要的那份记录。

扫描已知的坏模式。 有些仓库会自动标记不安全的序列化格式；有这个信号就用。

托管 API 只是移动了风险

用托管模型，权重层面的供应链风险就完全没有了——你从头到尾不加载文件。

取而代之的是另一种敞口：你信的是厂商的流水线，而正在服务的模型可能不声不响地变。厂商会在稳定的版本名底下更新模型，所以评测需要定期重跑，而不是只在接入时跑一次。

两种选择都免不了要自己验证行为，只是把不确定性挪了个位置。

要点回顾

• 在基于 pickle 的格式里，加载权重可能执行代码——优先用 safetensors，它不会。
• 有后门的权重能通过常规评测；防线靠来源，不靠检测。
• 适配器和社区融合模型会从每一个祖先那里继承信任。
• 工具服务器就是代码，它们的描述会进入你的上下文，返回结果不可信。
• 锁修订号而不是分支，核对校验和，从发布者下载，精确记录你部署了什么。
• 托管 API 去掉了权重风险，却加上了静默的模型变更——两种情况下都要重跑评测。

下一篇： 内容审核