基础模型供应商策略：企业SLA究竟保障什么

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

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

SLA层级实际保障（以及不保障）什么

企业团队对SLA的预期与SLA实际兑现之间存在巨大落差。

可用性保证范围很窄。 OpenAI的Scale和Priority层级均宣称99.9%的月度可用性，Azure OpenAI Service亦然，AWS Bedrock通常也持平。但细看条款：大多数协议中的"可用性"意味着API端点可达且返回响应——而非以可接受的延迟返回正确响应。一个在90th percentile出现超时、或幻觉率是正常水平十倍的模型，在大多数定义下仍然算"正常运行"。

延迟SLA昂贵且罕见。 OpenAI Priority层级宣称每分钟p50延迟保证，但那只是中位数——仍有一半请求可能更慢。p95或p99级别的正式延迟承诺需要定制企业谈判，通常还需要预置容量。Azure OpenAI的预置吞吐量单元（PTU）提供了最清晰的稳定延迟路径：你预订固定吞吐量配额，以无论是否使用都付费为代价换取可预期的响应时间。

服务积分无法覆盖停机损失。 当AWS、Azure或OpenAI违反SLA时，你通常获得未来使用的抵扣额度——往往上限是月费的某个百分比。如果你的产品宕机四小时并损失了用户信任或营收，这些积分无法弥补。这并不是隐藏条款，而是标准云SLA结构。但从未经历过重大故障的团队往往要到度过最糟糕的一周、提交积分申请之后才会真正意识到这一点。

支持层级定义参差不齐。 企业支持层级宣传响应时间，但"响应"往往指确认收到——而非解决甚至分类处理。对于根本原因是模型行为变化而非基础设施故障的AI服务问题，即使是积极配合的支持团队，也可能无法在你的SLA窗口内给出答案。

实际含义：将SLA层级视为谈判起点，而非对生产环境实际体验的描述。真正重视企业客户的供应商会就延迟承诺展开谈判，明确定义模型行为回退的升级路径，并提供了解你使用场景的专属技术联系人。

企业定价：什么可谈，什么是固定的

基于Token的定价在主流供应商中普遍存在，但其底层结构差异显著。

所有主流供应商的输入Token定价均为输出Token的一小部分——通常是1/5到1/10——因为推理计算主要由Token生成主导。这种不对称性对工作负载规划至关重要：生成大量结构化输出的流水线与处理大量文档并返回简短答案的流水线，成本差异悬殊。

批量折扣存在，但需要主动争取。 OpenAI为每月超过500万Token的企业客户提供12-18%的折扣。AWS Bedrock通过PTU预订可节省高达50%的成本。Azure提供类似的PTU经济模型。但PTU式预订要求承诺某一容量水平并无论实际使用量如何都付费——这是云预留实例权衡逻辑在推理上的翻版。

企业合同中实际可谈判的内容：

• 自定义延迟SLA和可用性保证
• 训练数据限制（明确禁止将你的数据用于模型训练）
• 数据驻留选项和删除时间表
• 支持响应时间承诺
• 与竞争对手定价挂钩的合同续签触发条款
• 速率限制提升和突发容量

通常固定不变的内容：

• 特定量级以下的基础Token定价
• 标准API功能可用性
• 模型发布时间表
• 训练数据退出的基础默认设置（但可通过合同覆盖）

一个重要的近期动态：Anthropic于2026年初将席位许可与Token用量分离，取消了企业计划中的捆绑Token配额。团队现在为Claude访问支付按席位计费的费用，API Token则按标准费率单独计费。这一变化使成本建模更加可预期，但也移除了部分团队依赖的应对突发工作负载的缓冲空间。

进入谈判时，模型无关的系统设计是你最强的筹码。知道你无需重写应用即可切换到竞争对手API的供应商，在定价谈判中的态度截然不同。

数据处理协议：你遗漏的条款

当供应商代表你处理个人数据时，数据处理协议（DPA）在GDPR下具有法律强制性。每家主流LLM供应商都提供DPA，但大多数默认留下了关键问题的模糊空间。

训练数据使用现在对消费者默认启用。 2025年8月，包括Anthropic、Google和OpenAI在内的主流供应商调整了默认设置，消费者级用户数据将用于模型训练，除非主动选择退出。关键例外：API客户和企业协议仍受保护。但如果你的组织在使用API的同时还使用任何面向消费者的产品，请务必核实哪些数据流向何处。

大多数团队忘记添加的条款：

• 明确禁止将你的输入用作训练数据（不只是"我们默认不用你的数据训练"，而是"在任何情况下你不得用我们的数据训练"）
• 具体的数据保留限制和删除时间表（包括备份和审计日志）
• 违规通知时间表（GDPR要求72小时；你的合同应与之匹配）
• 数据驻留要求以及数据可以流转的区域
• 合同终止时微调模型的处理方式

联合控制方问题。 许多LLM供应商协议对供应商究竟是数据处理方（按你的指示代你处理数据）还是联合控制方（就数据使用方式独立决策）存在模糊描述。GDPR第28条要求以具体条款正式确立控制方-处理方关系。描述供应商在使用数据方面拥有"合法利益"的协议，实际上是在暗示联合控制方关系，这带来不同的法律义务和更有限的数据主体权利。

个人数据无法被"遗忘"。 如果你的数据被用于训练，而你后来发现这违反了GDPR，将无法进行技术补救。模型无法被更新以"忘记"特定训练样本——或者即便可以（通过遗忘技术），供应商也没有义务这样做，除非你的合同明确规定了这一点。在数据流向任何地方之前，通过书面承诺前置管控这一风险。

供应商锁定：什么是真实风险，什么可以管控

LLM供应商的锁定风险分为三个不同层次，每个层次有不同的缓解策略。

API兼容性锁定最易管控。 许多供应商（Mistral、Groq等）暴露与OpenAI兼容的API端点，这意味着你可以在不修改应用代码的情况下路由请求。LiteLLM和OpenRouter等工具在数十家供应商之间创建统一接口。这里的风险主要是提示工程投资，而非技术债。

提示可移植性才是真正的锁定。 针对Claude 3.7 Sonnet调优的提示在GPT-5或Gemini 2.5 Pro上表现不同，即使意图完全相同。分词方式、指令遵循和默认行为的细微差异意味着切换模型需要重新调优提示——有时需要大幅调整。构建了复杂多步骤提示的团队，已经实际上投资于了特定模型。

微调可移植性几乎为零。 微调后的模型在大多数供应商处无法导出。如果你在OpenAI基础设施上微调了GPT-4o并想切换到Anthropic，就得从头开始——权重不可移植，你使用的训练数据也不会在不同基础模型上自动产生同等质量提升。

实用缓解策略：

• 将模型选择保存在配置中，而非分散在应用代码各处
• 将嵌入向量、向量库和评估数据存储在你控制的基础设施中（Pinecone、Weaviate、Qdrant、pgvector），而非供应商管理的存储
• 构建按模型层级而非模型名称路由的抽象层
• 持续对多家供应商进行评估，而非仅在选型时评估
• 对于微调，记录训练方式以便复现——而不仅仅是保留结果模型

目标不是消除锁定（这基本不可能），而是使切换成本可见且有界。一个能够量化"从OpenAI切换到Anthropic需要3周提示重新调优和两次微调运行"的团队，谈判处境远优于那些认为切换很简单的团队。

供应商集中风险：没人计算的数字

2024年12月，一次遥测服务部署压垮了OpenAI的Kubernetes控制平面，导致所有OpenAI服务宕机四小时。同月，云供应商数据中心电源故障将ChatGPT、API服务及依赖产品的错误率推高至90%以上。2025年6月，一次持续12小时的宕机在全球范围内中断了商业运营。

这些不是罕见事件，而是供应商集中风险在实践中的真实面貌。

叠加依赖问题。 OpenAI运行在Microsoft Azure之上。当Azure发生基础设施故障时，即使OpenAI自身软件运行正常，也可能受到影响。那些构建在OpenAI API上、以为只有一个供应商的团队，实际上有两个供应商，故障模式在两者之间叠加。Azure OpenAI又增加了第三层——包裹OpenAI API的Azure服务——带来超越任一组件的额外故障模式。

市场集中度的变化表明企业正在响应。 2023年至2025年间，Anthropic的企业AI市场份额从24%增长到40%，而OpenAI从50%下降到27%。这主要不是因为模型质量——而是风险分散。经历过主要供应商中断或定价意外的企业团队，将支出转移到第二供应商，既为了韧性，也为了谈判筹码。

量化集中风险。 大多数团队不计算这个数字。一个合理的方法：

• 识别哪些产品或内部工作流依赖单一LLM供应商
• 估算该供应商不可用每小时对收入或生产力的影响
• 乘以基于供应商历史可靠性预期的年度宕机小时数
• 与维护备用供应商的成本相比较

对于AI驱动核心产品价值的团队，这个计算往往能证明在多模型故障转移工程投资上的合理性——在主要供应商降级或不可用时路由至次要供应商。

实际的故障转移策略需要什么。 OpenAI兼容API使路由成为可能，但可用的故障转移不止是更换URL：响应格式差异、上下文长度限制、成本不对称和延迟特性在各供应商之间均有差异。持续测试故障转移路径，而不仅仅是在初始设置时测试。

工程团队的谈判姿态

企业AI采购与传统软件采购不同，因为产品在持续变化。模型更新可以在不改变API版本的情况下改变行为。定价层级随供应商争夺市场份额而变化。今天谈判的内容在18个月后可能面目全非。

在合同中内置重新谈判触发条款。 要求在竞争对手以超过X%的更低价格发布同等能力时，或供应商在未提供迁移窗口的情况下弃用你依赖的模型时，自动开启定价讨论。供应商会抵制这些条款；它们在最终合同中的存在与否，能告诉你供应商对其定价走势的信心程度。

将多供应商评估作为持续筹码。 将有意义的流量比例路由到次要供应商，不仅是为了故障转移，也是为了维持可信的切换叙事。知道你最近做过比较评估且发现同等质量的供应商，在续约谈判中的态度截然不同于那些认为你没有考察替代方案的供应商。

谈判前明确你的具体需求。 模糊的要求（"我们需要更好的支持"）产生模糊的承诺（"我们将指派专属客户经理"）。具体的要求（"我们需要对影响生产的模型行为回退在4小时内确认、24小时内提供解决方案或升级路径"）产生具体的承诺或明确的拒绝——两者都是有用的信息。

未来几年对企业AI真正重要的供应商，是那些能够证明将合同视为承诺而非法律样板的供应商。了解你的供应商属于哪一类的方式，是在被锁定之前而非之后进行测试。

未来的姿态

当AI处于实验阶段时，基础模型供应商策略大多是事后考虑。当AI系统处于产品或运营的关键路径上时，它就成为一门严肃的学科。

把这件事做对的团队，将供应商选择视为持续的实践，而非一次性采购事件。他们在需要故障转移路径之前就维护好它。他们谈判反映实际数据处理需求的DPA条款，而非接受默认值。他们持续对替代方案进行评估，而非等到续约时才评估。

最重要的是，他们量化了大多数团队作为模糊焦虑留存的风险："如果我们的主要LLM供应商宕机，每小时损失多少？"是一个有真实答案的问题。得到这个答案——并围绕它建立供应商关系——是供应商策略与供应商假设之间的差距所在。