模型别名不是版本：用漂移金丝雀监控免费API变更

一个反复出现的错误认知

"我这边什么都没改。"——在无数评估回归的讨论帖里，这句话反复出现。配置文件里的模型字符串一模一样，prompt 文件原封不动，于是矛头指向随机性。

问题没那么简单。开发者社区长期流传着五个看似合理、实则代价高昂的假设：模型名 pin 住了就等于结果 pin 住了；temperature=0 就能保证相同输入相同输出；答案看起来还行说明模型没换；一次漂亮的 demo 证明端点健康；免费服务器可以永久无人值守地跑这套检查。

这些假设每一条都经得起"听起来合理"的检验，但每一条也能让你浪费一周的调试时间。

模型漂移检测示意图

别名与快照：你 pin 的到底是什么

模型名是一个指针，不是校验和。这是整篇文章的核心论点。

提供商文档里通常有两个独立概念：别名（alias） 是一个移动的标签，指向当前快照，提供商会主动轮换；日期快照（dated snapshot） 带日期后缀，通常冻结，但仍处于弃用窗口内。多数项目 pin 了一个别名，然后称之为"版本"。

正确的心理模型是：别名相当于 DNS 记录，日期快照相当于 IP 地址。两者都会动，但一个动得频繁得多。

每次运行应该记录四样东西：请求的模型字符串、响应回显的模型字符串（如果有）、UTC 时间戳、端点 base URL。最后一项常被忽略——同一个别名可能随时间路由到不同的后端。

模型别名轮换是 LLM API 提供商的一种运维常态：为了让用户自动获得性能改进或成本优化，提供商会将同一别名（如 gpt-4o）指向新快照，并在文档中给出提前通知窗口（通常数周）。轮换可能由模型更新、硬件迁移、安全修复或路由策略调整触发。对开发者而言，这意味着“pin 一个别名”只保证调用路径稳定，不保证底层权重、分词器版本、聊天模板或推理后端稳定。日期快照（如 gpt-4o-2024-08-06）虽然冻结，但仍有弃用周期；一旦弃用，别名会继续移动，而旧快照可能直接不可用。因此，生产系统应同时记录别名和响应回显的快照标识，并在评估流水线中把“别名解析到的快照”作为一个显式变量来追踪。

Temperature 0 不等于可复现

没人问的那个问题是：temperature=0 到底关掉了采样吗？没有。它只是拧动了一个旋钮。

其他方差来源依然存在：批处理推理每次调用会把你的请求分到不同的组；浮点累加顺序不固定；混合专家路由和投机解码会带来抖动；一个别名可能由多个后端池服务。

验证方法很简单：同一个 prompt 循环二十次，数一下有几个不同的输出。如果数字大于一，你的精确匹配断言已经坏了。正确的模型是——模型版本是一个分布，不是二值状态。你要比较分布，而不是比较单个字符串。

混合专家路由（MoE routing） 是许多大模型采用的结构：每个 token 或每层只激活部分专家网络，路由器根据输入动态选择专家。即使 temperature=0，路由器的 top-k 选择也可能因批处理组合、数值精度或实现细节而出现微小差异，导致不同 expert 被激活，从而改变输出。投机解码（speculative decoding） 则用一个小模型草拟多个 token，再由大模型并行验证；验证过程对批内其他请求的依赖、接受/拒绝阈值以及硬件浮点行为都可能引入非确定性。这两类机制是 temperature=0 仍不可复现的重要来源，也解释了为什么同一 prompt 循环二十次可能得到多个不同输出。

肉眼观察是最差的检测器

当快照变化时，输出通常读起来更好，而不是更差。它会变短、变友好、变结构化。看起来什么都没错，这恰恰是问题所在。

替代方案是测量廉价指标：自洽性（同一 prompt 的 K 次采样一致频率）、输出长度分布（稳定模型保持稳定形状）、字符 n-gram 重叠（粗糙但有效的指纹比对）、错误率与拒答率（单独追踪，绝不混入漂移信号）。

这些指标无法证明权重完全相同，但合在一起能抓住那些真正伤害你的替换。

两命令漂移金丝雀：附完整实现

原文给出了一个仅依赖标准库、面向 OpenAI 兼容端点的检测工具，标注为"提议方案，未在作者环境执行"。

Prompt 集设计：保持小而无聊。十二个 prompt 是合理的起点，约束型任务能快速暴露格式变化。示例包括"精确回复 OK""列出三原色，小写逗号分隔""17 * 23 等于多少，只回数字"。

录制与比较逻辑：record 模式对每个 prompt 采样 K 次（默认 5），记录成功数 n_ok、自洽性得分、平均长度、字符三元组集合；compare 模式计算基线与会话的 Jaccard 相似度和长度变化率，低于 0.90 或长度变化超过 15% 即标记为漂移。

完整脚本核心结构：


**Jaccard 相似度**用于比较两个集合的相似程度，定义为交集大小除以并集大小，取值在 0 到 1 之间。在漂移检测中，通常把模型输出切成字符三元组（character trigram）集合，再计算基线集合与当前集合的 Jaccard 系数。它对词序和局部措辞变化敏感，但对整体长度差异不直接惩罚，因此常与长度变化率配合使用。Jaccard 低于 0.90 是一个启发式阈值：它意味着两次输出的三元组重叠不足九成，可能对应快照替换、模板变更或解码行为变化。该指标粗糙但廉价，适合作为烟雾测试的第一道筛子，不能替代人工审查或完整回归评估。
# canary.py 关键片段
BASE = os.environ["LLM_BASE_URL"].rstrip("/")
MODEL = os.environ["LLM_MODEL"]
K = int(os.environ.get("CANARY_SAMPLES", "5"))

def call(prompt):
    body = json.dumps({"model": MODEL, "temperature": 0,
                       "messages": [{"role": "user", "content": prompt}]}).encode()
    req = urllib.request.Request(BASE + "/chat/completions", data=body,
        headers={"Content-Type": "application/json", "Authorization": "Bearer " + KEY})
    with urllib.request.urlopen(req, timeout=60) as r:
        d = json.load(r)
    return d["choices"][0]["message"]["content"] or ""

阈值需要按自己的噪声地板调整，0.90 和 15% 只是起始猜测，不是定律。

在免费服务器上调度

金丝雀是极轻量的工作负载，每周期几个短请求就够，这让免费服务器成为合法的调度宿主。

原文在此处披露：本文是作为 MonkeyCode 产品推广的一部分准备的，该平台提供免费模型访问和免费服务器选项，恰好覆盖这个循环的两端。

节奏要按自己的配额来定：12 个 prompt × 5 次采样每 30 分钟会快速累积，每小时 3 次采样是更平静的默认值。cron 配置需要配合 flock -n 防止重叠运行。

免费服务器的几个关键限制：空闲休眠会打破每小时承诺，间隙不等于稳定证据；临时磁盘重启即丢数据，必须每周期把结果推到外部；出口流量与配额限制可能中途截断运行，所以要记录 n_ok 以便察觉；无 SLA 意味着监控器自身的在线率也是变量。

cron 与 flock 是免费服务器上调度金丝雀的常见组合。cron 按时间表触发脚本，但无法防止上一次运行尚未结束时下一次又被拉起；如果单次运行因网络重试或配额等待而超时，重叠运行会污染基线并浪费配额。flock -n 会尝试对指定锁文件加排他锁，若锁已被占用则立即退出，从而保证同一时刻只有一个金丝雀进程在跑。配合外部存储（如对象存储或另一个免费服务）保存每周期结果，可以缓解免费服务器临时磁盘重启即丢数据的问题。注意空闲休眠可能让 cron 根本不触发，因此监控器自身的在线率需要单独观测。

输出解读决策表

信号	可能原因	处理方式
多 prompt 的 `n_ok` 低于 K	认证、配额或网络问题	先修访问，这不是漂移
`self_consistency` 大幅下降	解码或路由变更	冻结发布，重新建立基线
约束型 prompt 的 Jaccard 低于 0.90	快照替换	pin 日期快照，重跑评估
`mean_len` 上升超过 15%	聊天模板变更	检查 prompt 包装和停止原因
一切稳定	什么都没证明	保留基线，标注日期

最后一行最重要：一次干净的金丝雀运行证明不了什么，只意味着这一小时你没抓到变化。

这套工作流的边界

它无法证明权重相同，只能观察行为；十二个 prompt 是烟雾测试，不是回归套件；阈值在测量自身方差前只是猜测；如果从不分离错误与漂移，错误会伪装成漂移；基线会静默腐化，计划升级后必须重新采集。

不适合使用的场景：模型替换零成本的早期原型；有合同保障变更日志和通知窗口的团队；无法在免费盒子之外存储基线的人；需要可复现保证而非检测器的人。

修正后的心智模型

模型名是指针，指针会移动。
Temperature 0 收窄分布，从不坍缩分布。
比较分布，而非单个输出。
错误与漂移是不同信号，分开标注。
每个基线都有过期日期，要有意识地重采。

原文最后留下一个问题：你会把哪十二个 prompt 放进自己的集合？选择那些静默变更伤害最大的任务，今天就写下来，然后让金丝雀告诉你指针什么时候动了。

需要说明的是，本文的核心论点——别名非版本、temperature 0 不可复现、肉眼不可靠——在当前 LLM API 实践中是广泛认可的工程共识；但具体的漂移阈值与免费服务器场景建议，原文标注为未经执行的提议，读者应视为起点而非验证结论。