开源模型公开以后，真正脆的是默认路由

把问题写成“美国能不能封印”，答案通常没那么戏剧。权重文件不一定会从世界上消失，但默认路由很容易被改写。一个 Hub 地址、一个 SDK 默认值、一个线上推理入口，只要被当成理所当然能用，后面的自动化就会跟着一起脆。

从一个地址开始

开源模型最初只是一个地址。拉取、评测、部署、回归，所有动作都指向同一个入口。上游没变的时候，这条路看起来像是“顺手”，甚至像是理所当然；上游一变，才知道当初依赖的不是模型能力，而是那条默认路径。

工程里最常见的断点并不是“完全拿不到模型”，而是“还能拿到，但不是原来那一份”。镜像同步慢了，别名切换了，地区访问被限制了，默认版本被挪走了，脚本却还在照着旧地址跑。模型本体还在，流程已经开始偏。

失效先发生在自动化里

人工切换镜像并不难，难的是自动化不会自己理解这件事。CI、定时评测、容器构建、实验记录、文档示例、同事本地脚本，全都可能把同一个默认值抄进去。只要一个地方没改，旧入口就会继续往外冒头。

这也是“封印”这个说法最容易误导的地方。真正发生的变化，往往不是权重被抹掉，而是默认值被改写。外面看起来还是同一个名字，里面已经换了入口、换了版本、换了依赖。对人来说，这只是一次切换；对自动化来说，这就是一次广泛的行为漂移。

权重可以搬走，默认值搬不走

开源模型的一个重要优势，是权重可以被复制、镜像、分叉和离线保存。问题在于，复制的是文件，不是默认路径。只要消费侧还把某个外部入口当成唯一真相，权重再开源，运行方式也还是会被外部规则牵着走。

更麻烦的是，这种变化不一定立刻报错。很多时候看上去还能跑，结果却已经不一样了：一套评测在镜像 A 上过了，另一套在镜像 B 上抖了；一个版本在本地可用，到了流水线里却变成另一个补丁集；同一个模型名字下面，实际行为已经开始分叉。

这里要分清两件事。供应链问题更像文件管理和版本管理，默认路由问题更像运行时决策。前者关心有没有备份，后者关心请求先走哪条路。只要默认值还写在外部，外部动作就能直接改写工作流。

要补的是 pin、镜像和回退路由

能补的办法并不复杂，只是很少有人把它们当成第一优先级。

版本要 pin 到具体提交、哈希或者明确的 release，不要长期依赖 latest 这种会漂的名字。权重、tokenizer、配置和推理镜像最好一起进内部仓库，至少保证断网时还能重建。默认入口要有回退路由，不能只有一个线上地址。评测样本和旧结果也要留档，否则连“变了多少”都说不清。

这些东西看起来都像运维细节，实际是在把控制权从外部默认值里收回来。没有这层收口，开源只会带来“看起来自由”，不会带来“实际可控”。

开源模型公开以后，真正脆的不是权重本身，而是默认路由。只要入口还握在别人的默认值里，模型再开放，工作流也还是会先抖。