中转站选型决策树：从你的场景倒推到站点

为什么「哪家最好」是个错问题

不存在「最好的中转站」，因为不同场景的约束条件互相冲突：

• 生产环境要求稳定性，这与「极致低价」冲突；
• 批量任务要求低成本，这与「低延迟」冲突；
• Agent 场景要求工具调用可靠，这与「便宜」冲突。

所以选型的第一步不是比较站点，是明确你自己的约束。

第一层：确定用途与关键约束

先回答四个问题：

1. 这是什么用途？

2. 有哪些硬约束？

• 必须支持某个能力（缓存 / Batch / 结构化输出 / 多模态 / 工具调用）？
• 数据能否出境？
• 需要开票 / 对公？
• 延迟要求（交互式 vs 离线）？

这些是「必须满足」，不是「加分项」。 不满足的直接淘汰，不要因为便宜而妥协。

3. 月用量大概多少？

用量决定了三件事：能拿到的价格、要不要自建、要不要做预算管控。

4. 出问题能承受多大损失？

• 不可中断 → 必须双供应商 + 灰度方案；
• 可以中断几小时 → 单供应商 + 备份配置即可；
• 无所谓 → 单供应商。

第二层：把约束转成检查项

把第一层的答案转成一份检查表。以「生产环境 + 需要工具调用 + 不能中断」为例：

必须通过：
□ 工具调用四用例全部通过（见《函数调用兼容性》）
□ 流式输出六项检查通过（见《SSE 的六种异常》）
□ 近 30 天可用率 ≥ 99%（本站监测页可查）
□ 提供调用日志且可按 Key 过滤
□ 支持多 Key + 额度上限
□ 明确的开票与退款路径

加分项：
□ 支持缓存计费
□ 支持 IP 白名单
□ 有状态页
□ 提供用量查询 API

关键：先做「必须通过」的筛选，再看「加分项」。 顺序反了会被价格牵着走。

第三层：验证（不能省）

对通过初筛的 3–5 家，做四件事：

1. 跑能力测试（工具调用 / 流式 / 结构化输出 / 缓存）；
2. 小额对账：充最小额度，跑一批真实任务，与你的估算对账；
3. 并发梯度测试：找出容量拐点（见《晚高峰抖动》一篇）；
4. 观察一个业务周期：包括一个高峰期。

第 4 项最容易被跳过，但它决定了「平时好用」和「关键时刻好用」的差别。

第四层：确定使用策略

选定之后，还有三件事要做：

1. 充值策略

单次充值 ≤ 一个月用量。 这条规则比任何折扣都重要（见《充值前的五个条款》）。

2. 备份方案

• 至少保留第二家的配置（可以不开通，但配置写好、能随时切）；
• 备份供应商不需要是同档次的 —— 它的作用是「主供应商挂了时业务能跑」，不是「体验一致」。

3. 监控与对账

• 自建探针（见《自建探针》）；
• 调用日志（见《日志与对账》）；
• 用量告警：「超过近 7 日均值 2 倍就通知」。

一张完整的决策路径

① 用途是什么？
   ├─ 生产关键链路 → 稳定性优先，价格次要 → 找「必须通过」全过的站
   ├─ 开发测试     → 成本优先 → 用最便宜的可用站，但设小额度
   ├─ 批量离线     → 成本 + 吞吐 → 低价档 + 自己加校验
   ├─ Agent        → 工具调用可靠性优先 → 必测工具调用四用例
   └─ 个人学习     → 便利性优先 → 桌面客户端能接通的即可

② 有哪些硬约束？（能力 / 数据合规 / 开票 / 延迟）
   └─ 不满足的直接淘汰，不看价格

③ 到 3–5 家候选里做验证
   ├─ 能力测试（工具/流式/结构化/缓存）
   ├─ 小额对账
   ├─ 并发梯度
   └─ 观察一个业务周期

④ 定使用策略
   ├─ 充值 ≤ 一个月用量
   ├─ 保留第二家配置
   └─ 探针 + 日志 + 告警

⑤ 用起来之后
   └─ 每季度复查一次：价格、可用率、有没有更好的选择

三个常见的选型错误

错误一：先看排行榜再看需求

排行榜是「别人的场景」的排序。你的约束与别人不同，直接照搬会选到不合适的站。

错误二：为了折扣预充大额

折扣的收益是确定的（比如 20%），风险是全部的（余额可能拿不回来）。用一个确定的收益去换一个可能全部损失的风险，不划算。

错误三：只看价格，不做能力测试

价格差异通常在一倍以内，而能力缺失的代价是「你的功能做不了」。后者严重得多。

最后

本站提供的数据（194 家站点的可用率、延迟、模型覆盖、倍率与核验状态）能帮你完成 第一层的初筛和第二层的部分检查项。

但它不能替你完成第三层（验证）和第四层（策略）—— 那两层的判断依赖你自己的场景。

把本站的数据当筛子用，不要当结论用。 这句话在《我们测了 194 家站点：这份数据能回答和不能回答的问题》一篇里有详细展开。