模型即服务选型：API 供应商的分层评估清单

选的是供给关系，不是模型

很多团队选型的起点是「哪家模型最强」，但真正决定业务体验的往往是供给关系：限流会不会卡住增长、故障了有没有备用、数据合同干不干净、一年后能不能换人。模型能力只是变量之一，评估对象应当是「供应商 + 模型 + 商务条款」的整体。这篇文章给一张供给分层地图和一份评估清单，把选型从玄学变成可执行的流程。

供给四层地图

四层的取舍方向相反：越靠上越省心但越受制于人，越靠下越自主但越要自己扛稳定性。官方 API 通常第一时间拿到新模型与新特性；云托管胜在与企业云环境（网络、审计、采购）衔接顺滑；聚合网关用统一接口封装多家供应商，换模型改一个配置；自托管的回报是数据不出门与深度定制，代价是完整接过容量规划与故障处理。还有一个横向变量：同一个模型在不同渠道的价格、限流与版本更新节奏可能并不一致，托管方的模型版本滞后于官方是常态，对齐成本要在选型时看清。

七项评估清单

a) 模型能力。 用自家任务实测，不信榜单。准备几十条真实业务样例，同一套提示词跑候选模型，人工评分。榜单分数与你的场景之间隔着一个数据分布的距离——本站评测思路一文展开过原因。

b) 价格结构。 token 单价只是第一层。往下问：缓存命中有没有折扣？批量任务有没有更低的档位？用量阶梯会不会越用越贵？同样是每百万 token 的报价，实际账单可能差出一倍。

c) 速率限制与配额。 每分钟请求数、每分钟 token 数、并发上限，分别对上你的峰值流量算一遍，还要预留重试与退避的余量——限流被触发后的 429 重试会放大流量。限流是隐形的增长天花板，业务翻倍时供应商跟不跟得上，要在签约前谈。

d) 稳定性 SLA。 看承诺的可用性等级，更要看历史故障记录与补偿条款。SLA 是信用承诺，历史是信用记录，两者合起来才构成预期。

e) 数据合规。 你的输入会不会被用于训练？数据存在哪个地域？所在行业有没有额外要求？这些问题写进合同里的位置，比出现在官网 FAQ 里重要。

f) 生态兼容。 OpenAI 兼容接口已是事实标准，但细节支持参差：工具调用、结构化输出、多模态字段，逐项核对。SDK 的质量直接决定团队的开发效率。

g) 迁移成本。 换供应商要改多少代码？接口越标准化、专有特性用得越少，转移成本越低。选型时就把「退出条款」纳入考量，是成熟团队与新手团队的分界。

谈判与对冲

单一供应商的深度绑定是结构性风险：价格谈判失去筹码，故障时没有退路。务实做法是多供应商冗余——关键场景至少两个可切换的供给方，主备之间的路由在网关层完成，而不是写死在业务代码里，本站网关一文的路由设计可直接参考。另一条纪律是慎用专有特性：独家的私有参数用起来很爽，但每用一个，未来换供应商的成本就涨一分。

中小团队的务实路线

起步阶段用聚合网关：一个 Key 随时试不同模型，试错成本最低，也不欠技术债。等业务跑出价值、流量稳定，再把主力场景迁到直连官方 API 或云托管，拿更好的价格与限流，同时保留网关作为备路。迁移时直接复用起步期沉淀的评测集，用同一把尺子验证新渠道的模型行为没有漂移。跳过「全押一家」的阶段，是这个路线上最重要的纪律。

小结

供应商关系是产品架构的一部分：它决定你的成本曲线、故障半径和未来的自由度。用清单评估、用冗余对冲、用标准化接口保持转身能力——这三件事做完，选型就从赌运气变成了工程决策。