3 篇博文 含有标签「vendor-management」

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

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

某家厂商在周二下午向模型别名推送了一个“小幅更新”。到了周四，四家客户公司正在进行事件响应。他们本周都没有部署代码。他们的仪表板上没有任何关于延迟、错误率或任何其他基础设施维度的指标退化。改变的是，在他们固定的别名背后的模型开始返回略有不同的句子、略有不同的 JSON 以及略有不同的拒绝——而他们的团队针对旧行为编写的每一个提示词（Prompt）现在都成了一份没人履行的合约。

这种不对称性就是问题的核心。供应商将这次发布视为一次部署：经过内部测试，通过了一些聚合评估，并在维护窗口内逐步推向 100%。而消费端将其视为一次语义化版本（semver）违规：一个依赖项在生产环境中自动升级，却没有更改其版本字符串，随后最终用户的错误报告接踵而至，主题还带着轻快的“我们这边什么都没改”。

企业团队基于基准测试和演示选择LLM供应商，然后在生产环境中才发现SLA实际保障的内容——通常远低于预期。你费力谈下来的99.9%可用性保证并不涵盖延迟。法务团队签署的数据处理协议，除非明确添加了相关条款，否则并不禁止供应商用你的输入数据进行训练。而没有人量化的供应商集中风险，在某次遥测部署级联影响Kubernetes控制平面导致核心产品中断四小时后，会以最惨烈的方式暴露出来。

这不是采购问题，而是采购单独无法解决的工程问题。构建AI系统的工程师需要理解这些合同实际说了什么——以及没说什么。