在客户现场，选模型看合规，不看排行榜

2025 年年中，Menlo Ventures 公布的一个数字让不少人意外：Anthropic 占企业 LLM 用量的 32%，超过 OpenAI 和 Google（20%）。OpenAI 已跌至 25%，只有两年前自身份额的一半。

很多工程师看到这里，会得出一个简单的结论：哪家领先就选哪家。这个结论不算全错。但它回答的是“市场在用什么”，而在客户现场，真正的问题是：哪个模型获准在他们的数据上运行。

想做前线部署工程师（FDE）的人，最好尽早想明白这一点。在客户现场，选哪个模型，更多取决于数据放在哪、存多久、走哪份合同，而不是基准测试。懂这些约束的人，会主导这场会议。

只懂排行榜的人，往往只能听法务团队来讲这些约束。

市场份额能说明什么，不能说明什么

Menlo 的数据仍有参考价值。它表明，企业按性能而非价格选模型，开发者倾向于选前沿模型，而不是更便宜、更快的模型。所以默认选项应该是前沿模型，而不是最便宜的那个。

同样据 Menlo 统计，开源（开放权重）模型只占企业 AI 工作负载的 13%，低于六个月前的 19%。单看这个数字，会以为开放权重正在失势。

但全市场的平均值，说明不了坐在你对面的这位客户。值得问的是：这位客户有没有某种约束，迫使他们只能用开放权重。

还要注意，这份调查发布于 2025 年 7 月，到 2026 年底，份额可能已经变了。可以用它理解趋势，但向具体客户推荐模型时，不要把它当作理由引用。

第一个问题：数据保留多久？

设想你在为一家保险公司部署一个读取理赔文件的智能体。合规部门首先问的，几乎肯定是提供商会把他们的提示词保存多久，而不是哪个模型更聪明。

OpenAI 和 Anthropic 都有一个“30 天”的说法，但机制并不相同。OpenAI 会为每项 API 功能生成滥用监控日志，默认最多保留 30 天。Anthropic 的标准 API 则是在收到输入或生成输出后 30 天内，自动删除输入和输出本身。

两句话说的是不同的东西，所以别把“30 天”当成同一回事贴进合规文档。要写清楚保留的究竟是什么。Anthropic 的零数据保留需要另行签署协议，光创建一个 API key 是得不到的。

这个细节会直接影响时间表。如果客户要求数据一天都不能存，你在第一周就没法做出承诺，因为协议还得签。从一开始就把这项要求写进计划，免得它在上生产环境的路上卡住你。

数据在哪里处理？

第二个问题是处理区域。OpenAI 允许为每个新项目设置数据驻留区域，可选美国、欧洲（EEA 和瑞士）以及阿联酋等。由于该设置只对新项目生效，项目一开始就要建在正确的区域，而不是打算日后再迁。

客户的云往往已经替你做了选择

这是很多新 FDE 容易忽略的一点：模型通过什么渠道采购，有时比模型本身更重要。Claude 通过 Google Cloud、Amazon Bedrock、Microsoft Foundry 等多个渠道销售。如果客户已和某家超大规模云厂商签了合同，就可以在这份合同下使用 Claude，无需引入新供应商。

对采购来说，这能大大缩短流程。代价是数据处理规则随渠道而变：在 Google Cloud 上使用 Claude，数据处理受 Google Cloud 约束。所以交给合规部门的文件必须是 Google Cloud 的，而不是 Anthropic 的隐私页面。

接下来是端点。在 Google Cloud 上，Claude 的区域端点和多区域端点比全球端点贵 10%，官方推荐默认使用全球端点。如果客户在全球端点上每月账单是 1,000 美元，换到区域端点就是 1,100 美元。金额不大，但应提前告知客户，免得账单让人意外。

Google Cloud 上的 Gemini 也类似。发往全球端点的请求可能在全球任何 Google Cloud 位置处理，而司法辖区端点会把 ML 处理限定在该区域内。

如果只因为全球端点是默认值就不去改它，你可能在不知不觉中违反了客户对其用户作出的数据驻留承诺。

下表汇总了这些约束。这些问题都要在跑任何基准测试之前回答；凡是标注“需核实”的格子，都要在开会前自己查清楚。

客户的问题	OpenAI API	Claude（直连 API 或经由云）	Google Cloud 上的 Gemini	自托管开放权重（gpt-oss-120b）
数据保留多久？	滥用监控日志最多保留 30 天	直连 API：输入/输出 30 天内删除；零保留需另签协议	需核实 Google Cloud 文档	由客户决定
数据在哪里处理？	按项目选区域：美国、欧洲、阿联酋	在 Google Cloud 上：默认全球，区域端点贵 10%	全球端点可能在任何地方处理；司法辖区端点留在区域内	在客户自己的基础设施上
走哪份合同？	与 OpenAI 签约	与 Anthropic 签约，或经由 Google Cloud、Bedrock、Foundry	与 Google Cloud 签约	Apache 2.0 许可证
代价	多引入一家供应商	数据必须留在区域内时要加价	必须选对端点	自己运维一块 80GB GPU

什么时候该选开放权重？

有些客户用不了表格左边任何一列：比如数据不能离开内部基础设施，或者所需区域不在提供商的支持列表里。对这类客户，开放权重是认真考虑的选项，哪怕它只占 13% 的市场。

OpenAI 的 gpt-oss-120b 就是一个具体例子。它以 Apache 2.0 许可证发布，单块 80GB GPU（如 NVIDIA H100 或 AMD MI300X）即可运行。也就是说，客户需要的是一台 GPU 服务器，而不是一整个集群。

许可证和硬件同样重要。模型页面称 Apache 2.0 没有 copyleft 限制和专利风险。客户计划商业部署时，这是可以拿给法务团队的具体论据，不过批不批仍由他们决定。

剩下的难活归你：运维、监控和升级模型，这些原本是 API 提供商替你做的。

所以，只有在数据约束确实要求时，才提议开放权重。

别把系统绑死在一家提供商上

上面这些约束可能在项目中途改变。客户可能在第三个月签下零数据保留，可能换一家云，也可能出现一个比你在用的更强的新模型。如果提供商的名字散落在代码各处，每一次变化都意味着一次重构。

LiteLLM 正是为此而生。它让你用同一种 OpenAI 格式调用 100 多个 LLM，涵盖 OpenAI、Anthropic、Vertex AI、Bedrock 等众多提供商。它还支持 fallback 和按团队统计成本，换模型就成了改配置，而不是改代码。

由此，在客户现场的流程应分三步。先确定数据与合同约束，排除不能用的选项。再用剩下的前沿模型在客户的真实数据上跑评测，把胜出者放在抽象层之后，并以第二名作为 fallback。

开发者该练什么

客户在多个国家开展业务时，数据放在哪的问题往往在第一次会议就会被问到。先练会回答这个问题，再去回答哪个模型更强。每当提供商发布更新，就重读它的数据控制页面，更新自己的对比表。

看 FDE 岗位描述时，留意“data residency”“compliance”“multi-cloud”或“Bedrock/Vertex”这类词。它们说明日常工作将围绕这些约束展开。简历上别只写“集成了 GPT-4”。

要写你设计了一个在两家提供商之间带 fallback 的模型调用层，并根据客户的数据驻留要求选择了端点。

一个合适的业余项目是做一个内部聊天机器人，支持三种配置：OpenAI 的 API、经由云服务商的 Claude、自托管的 gpt-oss-120b。再附一份 README，说明每种配置适用于什么场景。

这份 README 能证明你读得懂客户的约束并选对配置，而这是一个调用 API 的演示无法证明的。

市场份额排名每六个月就会变一次。而保留时长、处理区域和合同的问题，每个客户都会再问一遍。