除了大模型供应商：如何评估 AI 服务供应商

大多数工程团队会花费数周时间来评估 LLM 提供商——对延迟进行基准测试、测试准确性、洽谈价格。然后，他们会在一个下午，仅仅根据一个设计精美的落地页和一篇好评博文，就选定了一个观测工具、一个护栏供应商和一个嵌入提供商。这种不对称性是本末倒置的。你的 LLM 提供商可能是一家资本充足且拥有稳定 API 的公司，但其周围的小众供应商通常并非如此。

AI 服务生态系统已经爆发式地增长到了几十个类别：护栏供应商、嵌入提供商、观测与追踪工具、微调平台、评估框架。每个类别都有十家初创公司在争夺同样的企业预算。其中一些会被收购，更多的会倒闭。少数公司会转型，并在发出 90 天通知邮件后弃用你的关键工作流。在没有经过严格评估的情况下基于这个生态系统进行构建，是一种直到演变成生产事故才会出现在你的待办事项中的技术债务。

你实际买入的生态系统

在评估单个供应商之前，先梳理一下你实际构建的基础是有帮助的。一个现代 AI 技术栈在 LLM 之外通常有五个层级：

护栏 (Guardrails) 筛查输入和输出，防止安全违规、提示注入、PII 泄露和政策违规。像 NVIDIA NeMo Guardrails、Lakera Guard 和 Guardrails AI 这样的供应商处于每个请求的热路径中。

嵌入提供商 (Embedding providers) 生成并管理用于检索增强生成 (RAG) 和语义搜索的向量表示。主要参与者——Voyage AI、Cohere 和 OpenAI——在上下文窗口大小、多语言质量和定价模型方面有很大不同。Voyage AI 在 2024 年被 MongoDB 收购的事实说明，即使是成熟的参与者，其所有权状况变化得有多快。

观测与追踪工具 (Observability and tracing tools) 监控你的 LLM 调用，跟踪 token 使用情况，并帮助你调试评估失败。这个类别分为基于代理的工具（Helicone，位于你和提供商之间）和基于 SDK 的工具（Langfuse、Braintrust、Arize），每种工具都有不同的集成成本和数据所有权影响。

微调平台 (Fine-tuning platforms)（Predibase、Together AI、Modal、Replicate）让你无需管理 GPU 集群即可自定义模型。它们的定价模型、数据处理政策和输出格式的可移植性差异比它们的营销宣传所暗示的要大。

评估框架 (Evaluation frameworks)（RAGAS、DeepEval、Promptfoo）衡量你的系统是否真的有效。这些往往是风险最低的类别，因为大多数都是开源的，但它们仍然会影响你衡量的指标以及你如何解读结果。

每一层都增加了依赖关系。每个依赖项都是一个潜在的故障点、价格上涨因素或停运通知。

大规模环境下的 API 稳定性真相

尽管供应商增加了更多的基础设施，但主要 AI API 的平均每周停机时间从 2024 年第一季度的 34 分钟增加到 2025 年第一季度的 55 分钟——仅一年内就恶化了 62%，。OpenAI API 在 2025 年 6 月遭受了 15 小时的全球停机。这些不是孤立事件；它们反映了大规模提供 AI 工作负载时不断增长的运营复杂性。

对于小众供应商来说，情况更糟。他们拥有更小的基础设施团队，更少的冗余投资，以及更小的缓冲空间来吸收事故。在评估任何供应商的 SLA 时，请关注营销页面之外的三个方面：

公开的事故历史。 任何值得信赖的供应商都有一个记录事故的状态页面，而不不仅仅是正常运行百分比。如果状态页面显示 99.99% 的正常运行时间且在过去一年中没有发生过任何事故，那要么是一个非常优秀的工程团队，要么是一个非常具有误导性的状态页面。

事故通知承诺。 SLA 数值的重要性次于你了解问题的速度以及在降级运行期间会发生什么。供应商是否有记录在案的运行手册 (runbooks)？他们是否发布事后分析报告 (post-mortems)？

配额限制 (Rate limit) 透明度。 企业账户通常获得比默认值高得多的每分钟请求数。当你达到限制时会发生什么？是否有自助增加额度的路径，还是需要与销售沟通？

大多数团队忽略的 SLA 问题是：如果供应商倒闭，他们保证的数据导出时间线是什么？这并非假设。

商业生存能力是你技术风险模型的一部分

最近记忆中的两家硬件初创公司说明了这个问题。当 Humane 在 2025 年初关闭其 AI Pin 服务时，所有设备在 10 天内失去了服务器连接。支付了 700 美元的客户如果购买时间足够近，可以获得 90 天的退款窗口。当 Embodied 在一轮融资失败后于 2025 年 1 月关闭其 Moxie 儿童机器人时，这些设备变成了毫无生气的塑料。没有退款，与孩子们的四百万次对话——荡然无存。

这些是极端例子，但这种模式同样适用于软件供应商。一个对你的请求进行推理的护栏服务需要云基础设施，而这需要持续的资金。一个拥有 18 个月跑道且没有商业牵引力的未盈利初创公司，就是你生产堆栈中的一个倒计时定时器。

在评估供应商的生存能力时，重点关注：

烧钱倍数 (Burn multiple)，而不仅仅是跑道。烧钱倍数（净烧钱额除以净新增 ARR）衡量资本效率。低于 1.0x 是健康的。高于 3.0x 是一个危险信号，无论银行里有多少现金。一家花费 3 美元来获取 1 美元收入的公司可以在一段时间内通过融资摆脱困境，但不能永远如此。

客户集中度。 如果一个客户占供应商收入的 30% 或更多，他们的流失就是你的问题。直接询问。

开源可选性。 观测领域有很有意义的开源替代方案——Langfuse 使用 MIT 许可证并支持自托管，Arize 的 Phoenix 是开源的，Helicone 提供开源版本。开源并不意味着零锁定，但它意味着即使公司消失，你的退出路径依然存在。

关键工作流的融资阶段。 对于处于你关键路径上的任何环节，C 轮及以后，并有记录在案的收入增长，是一个合理的门槛。这不是对小公司的偏见——这是风险校准。2025 年和 2026 年发生的市场整合正在加速；79% 的 AI 资金流向了巨额融资 (mega-rounds)，留给中端初创公司去竞争日益萎缩的资本。

那些看起来不像锁定的锁定风险

最显而易见的锁定是专有 API。而不那么显见的锁定则是数据格式依赖。

嵌入向量 (Embedding vectors) 的锁定尤为隐蔽。如果你使用 Cohere 的 embed-english-v3.0 构建向量索引，你无法在不重新嵌入整个语料库的情况下直接迁移到 Voyage AI 的 voyage-3。这些向量在数学上是不兼容的。更换供应商意味着需要重新处理每一份文档，而不仅仅是重定向 API 调用。没考虑过这种权衡的团队通常会在价格重议期间发现这一痛点。

微调平台的锁定也类似。在某个平台上训练的 LoRA 适配器在没有转换的情况下可能无法移植到另一个平台，且转换过程可能无法保持模型质量。在承诺使用某个微调供应商之前，请确认你的训练权重可以以标准格式（GGUF、Safetensors）导出，并且你确实测试过导出路径。

可观测性工具通过数据锁定你。数月的追踪、评估和提示词日志累积在供应商的存储中。在评估这些工具时，请问两个问题：我可以用什么格式导出历史数据？导出的成本是多少？

行之有效的退出策略架构是：从第一天起，为每个供应商类别实现一个抽象层。在你的嵌入供应商周围封装一层标准化的通用接口只需花费一天的工作量。而迁移六个月紧密耦合的嵌入调用则需要花费数周时间，外加重新嵌入的成本。

工程师容易忽略的尽职调查清单

大多数供应商评估都集中在功能上。下面的问题侧重于风险，它们是在出问题时真正重要的因素。

关于数据处理：

• 我们的数据是保存在独立实例中，还是与其他数据混合存储？
• 客户数据是否被用于显式或隐式地训练或微调模型？
• 合同终止后的数据删除时间表是怎样的？

关于合规性：

• 是否拥有现有的 SOC 2 Type II 认证（在过去 12 个月内颁发）？
• 如果你处理欧盟个人数据：是否有记录在案的 GDPR 合规性证明，而不仅仅是一个勾选项？
• 如果涉及医疗保健：供应商是否会签署 HIPAA 的业务伙伴协议 (BAA)？

关于定价：

• 确切的数据出站 (Egress) 成本是多少？这些通常不在标准价格表中，对于大型机器学习数据集，可能会超过基础服务成本。
• 如何处理速率限制 (Rate limit) 的提升？是销售流程还是自助服务？
• 合同中是否有针对中期涨价的保护条款？

关于退出：

• 数据以何种格式导出，记录在案的时间表是怎样的？
• 是否有切换到其他供应商的迁移指南？
• 合同终止的通知期是多少，提前退出的条款是什么？

关于模型治理（AI 特有）：

• 供应商如何检测并告知可能影响输出行为的模型更新？
• 供应商是否支持版本固定 (Version pinning)，以确保模型更新不会破坏生产环境？
• 如果模型开始产生有害输出，事故升级路径是什么？

一个几乎没人问但值得问的问题是：你能提供过去两次重大事故的复盘报告 (Post-mortems) 吗？发布复盘报告的供应商拥有运营透明的文化。从未发布过复盘报告的供应商要么没发生过事故（这不太可能），要么认为客户不配知道这些信息。

价格波动现已成为模型风险

AI 服务的定价并不稳定。仅在 2026 年 3 月，483 个被追踪的模型中就有 114 个更改了价格。OpenAI 曾明确表示，其目前的定价本质上是偶然的，并将发生重大演变。该公司预计 2026 年的烧钱速度 (Burn rate) 为 140 亿美元，高于上一年的 80-90 亿美元。Token 成本在过去两年大幅下降，但这种轨迹并不保证会持续下去。

对于你直接签约的供应商，价格保护条款非常重要。对于你通过整合网关访问的供应商，定价风险是共担的。无论哪种方式，从第一天起就在你的架构中内置成本监控——按供应商、按用例以及按模型版本追踪支出。那些对 AI 成本增加感到意外的组织，通常是因为没有将供应商支出与通用基础设施成本分开监测。

分层评估框架

并非每个供应商都需要相同程度的审查。一个实用的框架如下：

第一梯队：任务关键型 (Mission-critical)。 任何处于用户请求热路径 (Hot path) 上的环节。护栏 (Guardrail) 供应商、生产环境 RAG 的嵌入供应商、可观测性基础设施。要求 C 轮以上融资、有记录的 SOC 2 Type II、具有明确可用性保证的 SLA，以及经过测试的数据导出路径。构建允许供应商替换的抽象层。

第二梯队：重要但不阻塞。 微调平台、CI/CD 中使用的评估框架、批量嵌入作业。要求 B 轮以上融资、透明的定价和可导出的输出。在可选情况下优先选择开源方案。

第三梯队：实验性。 在开发、基准测试或低风险工作负载中使用的工具。具有活跃社区支持的开源工具即可。采用按需付费模式，无最低消费承诺。

每季度为第一梯队供应商运行一次故障转移 (Failover) 测试。不要等到收到关停通知时，才去验证你的抽象层是否真的有效。

实践中的生态系统现状

能够妥善应对供应商风险的团队通常有一些共同的模式。他们将选择供应商视为一项架构决策，而非采购决策。他们为每一个关键依赖都保留书面的迁移路径，即便迁移的可能性很小。他们像监控自己的服务一样严肃地监控供应商的健康状况——实时跟踪延迟、错误率以及每个用例的成本。

他们还避免了一种特定的失效模式：在供应商提供的便利功能之上构建深度集成。每一个便利功能——专有 SDK 方法、供应商特定的提示词模板、与嵌入模型提供商绑定的集成向量存储——都是会让迁移变得更加困难的技术债。你应该使用供应商的核心能力，并自己编写胶水代码。

广义上的 AI 供应商领域将持续整合。目前存在的一些公司在两年后可能就不复存在了。在这个生态基础上进行构建是不可避免的——这些能力是真实且有价值的。工程准则在于明确你接受了哪些依赖、它们的实际价值，以及在必要时你将如何替换它们。