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

你的 LLM 供应商声称 99.95% 的可用性。你的状态页显示绿色。你的延迟仪表盘在 SLO 范围内。但你的产品依然坏了 —— 助手在今天早晨开始拒绝常规请求，支撑下游解析器的 JSON 输出从紧凑变得啰嗦，而且你用模型分拣的支持工单中有三分之一返回了 “我无法提供帮助”。所有这些响应都在 800ms 内返回了 200 OK。它们都没有违反 SLA。这个 SLA 覆盖的是你实际上并没有遇到的故障模式。

这是采购谈判中没人预估到的差距。供应商出售的是 可用性（availability） —— 一种请求层面的承诺，即 API 及时响应了；而产品团队消费的是 能力（capability） —— 一种请求层面的承诺，即答案是可用的。这两者不是同一个指标，而混淆它们的团队离发现其中的区别只差一次静默的模型升级。

周二还能用的提示词（prompt），到周四就返回了“我无法提供帮助”。CI 评估依然是绿色的。你配置中的模型名称没变。提示词在字节层面完全一致，在源码控制中也经过了哈希处理和固定。然而，一个围绕新出现的拒绝回答（refusal）的客户支持线程正在形成——AI 团队在两周内都不会察觉到这一点，因为它必须经过一级支持、分类，最后才落到能读取追踪信息（trace）的人手中。

这就是服务商侧的安全漂移（provider-side safety drift），它是当今生产环境 AI 中构建最不完善的监控缺口。前沿服务商会以不在你发布日程上的频率，在服务端调整安全过滤器、拒绝阈值和内容分类器。你的团队没有订阅这些变更，通常也没有发布说明。而且这种退化是具有非对称性的，以一种确实难以察觉的方式呈现：正当意图的拒绝率悄悄爬升，而你认为服务商会过滤的有害查询却开始悄悄溜过。边界在两端独立移动，且毫无预警。

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

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

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

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

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

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