公有云大模型 API 怎么选：一份可执行的选型清单

公有云大模型 API 的选型，指的是在「数据可以出域」这个前提成立之后，用一套固定的维度去比较外部服务。多数选型只比了两件事：跑分与单价 —— 而这两件事恰好是最容易在半年内变掉的。真正决定方案能不能长期用的，往往是版本策略、配额与退出成本这些不出现在宣传页上的条款

第一步：先确认这件事该不该外采

把数据边界放在第一句而不是最后一句。只要有一个环节涉及绝对不能出域的数据，它就没有外采选项，不必进入这张清单。

• 适合外采的：通用语言任务（改写、摘要、翻译）、公开资料的整理、不以企业数据为输入的辅助环节。
• 不宜外采的：含客户信息、合同条款、财务明细或尚未公开的经营数据。
• 介于两者之间的：先在内部做去标识化，再判断处理后的内容是否仍然敏感 —— 去标识化不等于匿名化，这两件事在合规上的结论完全不同。

六个维度：一张可核对的清单

• 能力：用业务评测集而不是通用基准。准备几十条真实问题、带人工确认的答案，逐家跑一遍，只看自己场景里的通过率。
• 数据条款：输入是否用于训练、保留多久、是否有人工查看、数据存放在哪个区域 —— 这四项要书面答复，不能只看宣传页。
• 价格结构：输入与输出分别计费、缓存是否计价、长上下文是否加价、限流超额怎么算 —— 单价最低的方案在真实负载下未必最便宜。
• 版本与弃用策略：新版本是否强制迁移、旧模型保留多久、迁移窗口多长。这项决定你未来会不会为一个接口变更返工。
• 退出成本：换一家要改多少东西。把调用收敛到一个内部接口，退出成本就从「重做系统」降成「改一处配置」。
• 配额与支持：并发上限、速率限制、故障响应方式。峰值场景要按真实峰值验证，而不是按平均值估算。

价格结构比单价更重要

同一个任务，输入长输出短与输入短输出长，成本结构完全不同；开启缓存之后，重复前缀的代价也会变。所以比价的正确做法是：拿一个真实场景跑一天，按实际计费口径算出总成本，再横向比较 —— 只比价格表上的数字，结论往往会反过来

退出成本最容易被忽略

把所有模型调用收敛到企业内部的一层接口上，是最省事的一种保险：业务代码只认这一层，换供应商时改的是这一层的配置与评测，而不是业务系统本身。

• 提示模板放在自己的仓库里，不要散落在各家的控制台 —— 否则迁移时你会先丢失自己的资产。
• 接口差异（消息格式、工具调用、流式返回）在适配层里吸收，不让业务代码感知。
• 评测集与结果留档：换服务时才有依据说「换完之后是变好了还是变差了」。

验收与定期复看

选型不是一次性动作。接入时把评测集跑一遍留档，并按固定节奏（例如每次模型版本升级）复跑一次 —— 供应商升级模型通常不会提前询问你，而你的场景可能正好落在变化的那部分上