静默量化：为什么你今天付费的模型不再是上个季度购买的那个

你账单上的模型名称与上季度完全一致。API 响应中的版本字符串也没有改变。模型卡片和定价页面看起来也一模一样。然而，你的评估得分却下降了 0.5 分，拒绝模式以你提示词中未要求的方式发生了偏移，上周二还收到了几起客户投诉，称输出结果“感觉不一样”。你调试了代码，却一无所获。代码没变。权重变了。

静默量化（Silent quantization）是你合同约定的模型与供应商实际交付的模型之间的差距。之所以发生这种情况，是因为推理经济学持续收紧——每一美元的 GPU 算力在本季度必须承载比上季度更多的请求——而消化这种压力的最廉价方式，就是在更廉价的精度层级上重新托管同一个模型。FP16 变成了 FP8。在某些路由中，FP8 变成了 FP4。混合精度分片被替换进来。版本字符串没有变动，因为版本字符串从来都不是精度合约，而是一份营销合约。

这并非阴谋论。OpenRouter 已公开披露，在数十亿次请求中，他们经常观察到具有相同名义量化的同一模型，根据提供服务的供应商不同，会产生可衡量的差异化输出——这种差异大到他们专门为想要 FP16 并愿意为此付费保证的买家推出了独立的“Exacto”层级。Roo-Code 的问题追踪器中有一个功能请求，要求过滤掉量化路由，因为激进的量化破坏了多字节 CJK 字符的解码，而用户的提示词并未改变。OpenAI 自己的开发者论坛上多年来一直有讨论帖，用户描述在没有任何版本更新的情况下，模型质量在一周之内突然下降。Anthropic 在 2026 年 4 月发布了一份复盘报告，承认三项并发变更——其中没有任何一项被宣传为模型变更——导致 Claude Code 的输出质量在数周内出现可衡量的下降，直到公司最终追踪并回滚了这些变更。这些案例本身并不全是关于量化的，但它们都说明了一个事实：你所付费的模型并不是一个稳定的产物。

谁都没谈妥的精度层级

LLM 供应商的标准企业合同通常由几页法律术语、基于使用量的定价方案和一份几乎只讨论在线率、延迟百分位和数据处理的服务水平协议（SLA）组成。其中没有一处规定了服务精度。没有一处能让你在合同层面上质问：“今天这个端点背后的模型是 FP16 还是 FP8？”你的合同写的是“GPT 级”，而不是“FP16 精度的 GPT”。

这就是差距所在。供应商的定价页面宣传的是模型名称。供应商的服务条款赋予了他们高效运营该端点的自由。“高效运营”合理地包括了选择符合内部质量标准的推理精度。供应商使用的标准通常是综合性的——典型的包括 MMLU-Pro、HumanEval+、拒绝率门槛以及基础安全评估。最近的基准测试数据告诉了我们为什么这对供应商有效：在 2026 年的开源 70B 级模型中，FP8 在 MMLU-Pro 上的得分与 FP16 差距不到 0.4 分，校准后的 INT8 差距不到 0.7 分。从供应商的角度来看，只需牺牲不到一个百分点的准确度，就能在 H100 硬件上获得 1.5 倍到 3 倍的吞吐量提升。这个决定显而易见。

从你的角度来看，这同样显而易见——直到你意识到“MMLU-Pro 上不到一个百分点”是数千个任务的平均值。你的任务并不是那个平均值。量化误差高度依赖于具体任务。世界知识检索（MMLU 侧重的那种）比常识推理更容易受影响。长上下文注意力比短上下文更敏感。代码生成具有隐藏在平均值中的长尾行为。多语言提示词——尤其是 CJK——在 FP4 下可能会发生灾难性的崩溃，因为分词器（tokenizer）的边缘情况与缩减的数值精度余量发生了糟糕的相互作用。供应商的宏观数据没问题，但你的微观数据出了问题，而你却没有合同依据去进行讨论。

漂移是如何发生的

关于静默量化，需要理解的一点是，它几乎从不作为一个单一事件落地。没有公告，没有版本升级。新的精度层级是按区域、按请求逐步推出的，通常作为路由层的一部分，而不是直接替换模型。发送到 us-east-1 区域集群 A 的请求可能仍会命中 FP16 权重，而发送到同一区域集群 B 的请求可能就会命中 FP8。同一个模型名称的多区域部署，可能会在欧洲看到 FP16，而在美国看到 FP8。对同一个提示词的重试，获得的精度也可能与原始尝试不同。

对基于 API 进行开发的团队来说，这意味着三件事。第一，你的综合指标会看到缓慢的漂移，而不是断崖式的下跌。这种质量退化会在数周内像滚雪球一样演变成客户投诉，而不是在一小时内触发紧急事件。第二，你的可复现性以前所未有的方式消失了。同样的提示词、同样的 temperature 0、同样的 seed（在 API 支持的情况下），在不同请求中不一定能产生相同的输出，因为命中的不一定是同样的权重。第三，你脚下的评估基准正在发生位移。上季度得分为 92.4% 准确率的评估套件，在今天测得 91.7% 时并没有撒谎；套件是诚实的，只是模型变了，这两次测量测量的并不是同一个系统。

Anthropic 在 2026 年 4 月的复盘报告非常有启发性，尽管它与量化无关。三项独立的变更——默认推理力度的改变、思维块清理漏洞以及缩减冗余的系统提示词——同时降低了 Claude Code 的输出质量，而 API 用户无法从版本变化中察觉到其中的任何一项。这三项变更都是在用户投诉后才浮出水面的。其机制虽然与量化不同，但用户体验是一致的：你买的模型表现得不像你买的模型，你不知道原因，且版本号没变。请将那份复盘报告视为思考量化级漂移的模板，因为其波及范围是一致的：供应商在你看不到的边界内做出运营决策，而你只能通过观察输出来发现问题。

指纹探测器

如果版本字符串不可信，你就需要别的东西。你需要的是一套指纹探测器（fingerprinting probe set）：一个固定的、小型的提示词语料库，它们的输出在 FP16 精度下足够稳定，以至于任何有意义的精度变化都会引起输出波动。在过去的 12 个月里，关于黑盒大语言模型指纹识别的文献已经变得非常实用，足以投入生产环境。ZeroPrint 及类似的零阶方法（zeroth-order methods）仅通过输入输出查询就能近似估算梯度信号。水印技术的研究表明，特定领域的探测器可以达到能够抵御量化、剪枝和采样差异的检测率——也就是说，它们也能检测到量化、剪枝和采样差异，因为使水印稳健的特性与使探测器敏感的特性是相同的。

对于工程团队来说，这东西的实践版本不是一篇研究论文，而是一个每日定时任务。挑选 50 到 200 个你非常了解的提示词——长尾提示词、测试长上下文注意力的提示词、产生数值敏感输出的提示词（比如带有浮点数字段的结构化 JSON、依赖于特定位置特定标记的代码、带有变音符号或中日韩文字的多语言提示词），以及一些在历史上处于拒绝行为边缘的提示词。每晚在供应商那里以温度 0 运行这些提示词。对输出进行哈希处理。与昨晚的哈希值进行对比（Diff）。当差异率跳出基准线时，说明供应商那边发生了一些版本字符串没告诉你的变动。

这并不花哨，但比大多数团队拥有的手段要多得多。大多数团队之所以没有这种手段，是因为“版本字符串没变”听起来像是足够的保证。事实并非如此。版本字符串只是一个标签，探测器组合才是一种测量手段。

为了让探测器组合真正发挥作用，有几个实用的调节杠杆。保持足够小的规模，以便每晚廉价运行——每次运行控制在 500 美元以下，否则预算问题会扼杀它。针对你关心的每种故障模式至少保留 10 个提示词，因为单个提示词的漂移是噪声，而某一类别的模式漂移才是信号。在版本控制中用哈希固定提示词集，因为如果你的提示词发生了变化，你会把自己的修改误认为是供应商的漂移。另外，故意让提示词集保持“乏味”：不要把你最聪明的生产环境提示词放进去，因为聪明的提示词对于模型变化也最脆弱，而这些变化你以后更希望将其视为功能而非退化。

当名称不可信时的路由策略

一旦你接受了“模型 X”在两个不同区域并不代表同一事物，推理路由策略就会发生改变。你不再将模型名称视为唯一标识符。你开始将（供应商、区域、精度层级）这一元组视为唯一标识符，即使供应商没有向你公开这个元组。

这在实践中看起来是这样的：一个路由层，它知道哪些（供应商、区域）组合在过去 7 天内出现了漂移，并将新请求偏向于那些没有出现漂移的组合。为“偏好精度”请求预留预算，在这些路由上你无法忍受量化，为此你向 OpenRouter 的 Exacto 层级等供应商——或直接向上游供应商通过合同条款——支付溢价。制定一条回退规则，通过探测器组合捕捉漂移，并在漂移超过阈值时将一定比例的流量切换到备用供应商，就像熔断器将流量从故障服务中导走一样。针对产品中对质量最敏感的部分制定固定策略（pinning policy），在这些地方，保证精度所带来的成本溢价可以通过对用户的影响来证明其合理性，而在溢价不划算的地方则明确接受漂移。

这其中最难的部分不是技术，而是承认“模型 X 就是模型 X”不再是一个你可以依赖的核心假设，并围绕“同一个名称在同一时刻可以代表不同事物”这一事实重新组织你的推理层。在这一事实成立之前构建架构的团队，往往倾向于有一个全局设置，上面写着“此功能使用 GPT 级别模型”，然后在此之下自由路由。在这一事实成立之后构建架构的团队，则倾向于拥有基于具体功能的、存在于代码中并在策略变更时进行审查的精度策略。

一年后的行业规范会是什么样子

在这一领域领先的团队，看起来就像是已经为其他任何供应商建立了一套指标质量规范的团队。他们有一套每晚运行的探测套件。他们有一个内部仪表板，显示他们涉及的每个（供应商、模型、区域）元组在过去 90 天内的漂移情况。他们有一个合同条款——至少与他们的一级供应商——规定了服务精度，并要求在发生变化时有通知窗口期。他们有一个路由层，将精度层级视为请求的一等属性，而不是供应商隐藏的决定。他们拥有认真对待评估漂移信号的文化底蕴，而不是将其斥为噪声，因为他们已经经历过一次因不重视而导致的事故。

那些没有跟上的团队，在未来一段时间内仍将基于一个他们实际上没有测量手段的推理基座来发布产品。大多数时候他们会没事，因为大多数时候在平均任务上的平均质量大致相同。问题出现在长尾部分——拥有多语言工作流的客户、长上下文摘要变形的用户、开始在工具调用上失败的智能体（而它上个季度还能成功）——而且这些问题很难诊断，恰恰是因为版本字符串从未变过。

值得铭记的教训是：你发票上的模型名称是一个营销产物，而不是技术契约。技术契约——如果你想要一个的话——是你构建的探测器组合、你谈判的精度条款以及你运行的路由层。在你的产品拥有这三样东西之前，你并不是在从供应商那里购买模型。你是在购买一个恰好共享同一个名称的模型概率分布。在大多数季度里，这没问题。但在出问题的季度，你会希望自己早就在进行测量了。