比较同一口径的分位
要求供应商在约定并发下提供高位分位数据，而不是单次演示。为什么：演示通常在低负载下进行，无法反映排队。做法是自建评测环境用同一批样本复测；边界是跨网络测试会引入额外变量，结论要标注测试位置与时段。
看波动而非均值
云 API 的延迟受共享资源与限流影响，波动可能明显大于自建。怎么做：连续多天在同一时段采样，画出延迟分布；边界是促销与突发事件会造成异常值，分析时要区分，不能把异常值直接当成常态结论。
并发形态决定选择
负载平稳且高，预留或自建更容易压住尾部延迟；波动大则云 API 加队列更经济。为什么：固定容量在低谷闲置，弹性容量在高峰排队。做法是统计日内外并发曲线；边界是突发型业务要评估扩容速度是否跟得上。
数据约束可能直接排除
请求内容不能出域时，云 API 直接不进入候选，不必再比延迟。怎么做：先过合规筛选再谈性能；边界是脱敏后可外发的部分仍可用云 API 形成混合，但脱敏规则要单独评审并由合规与业务共同确认，不能沿用主链路结论。
混合与降级
主用一方、备用另一方，需要统一协议与一致的提示语。为什么：切换时用户不应感知到回答风格突变。做法是网关做协议适配与健康探测；边界是备用侧容量有限，切换要同时配合限流，否则等于把故障转移过去。
适用与不适用
适合谁
- 要在自建与云 API 之间做长期选择的企业
- 业务有明显高峰、需要弹性补足的技术团队
- 对数据位置有要求、但仍希望保留云能力的机构
不适合谁
- 请求量极小、无需考虑容量与弹性的业务
- 完全没有网络与运维基础、也不打算投入的团队
典型场景
某在线医疗平台的问诊摘要需要低延迟。团队连续两周采样云 API 的分位数据，发现工作日上午波动明显；自建环境在同并发下尾部更稳但平日闲置。最终采用本地承担工作日上午的峰值、云 API 承接夜间与突发，网关按健康状态切换，并在切换时保留统一的提示语。
可执行步骤
- 先按数据约束筛掉不可用的方案，再进入性能与成本的比较环节与记录范围
- 在约定的并发下采集多天的分位数据，标注测试位置、时段与范围条件
- 统计日内与日外的并发曲线和峰值时段，标出可以排队的请求类型与比例
- 用网关完成协议适配与健康探测，并统一两边提示语的文案风格与措辞规范
- 演练双向切换并给备用侧设置限流，记录切换耗时、失败点位置和原因分析
常见坑
- 拿供应商的演示数据与自建实测做对比，口径不同，结论根本不可靠，评审难以服人，也容易选错方案。
- 只看平均值，忽略云侧高峰期的尾部延迟，上线之后投诉集中爆发，再切换已经来不及，只能被动承压一段时间。
- 混合部署后两套提示语不一致，切换时用户明显感到回答风格变化，信任下降后要很久才能修复。
- 备用侧没有做容量评估，切换之后同样排队，等于没有切换，故障被转移到另一侧，影响面更大，恢复也更难。
自检与验收清单
- 是否先用数据约束筛掉不可用方案，再进入性能比较
- 分位数据是否连续多天在同一时段采样，是否标注位置
- 日内与日外的并发曲线是否统计，是否标注出峰值时段
- 两边的接入协议与提示语文案是否统一，风格是否一致
- 双向切换演练是否做过，是否记录切换耗时与失败点
常见问题
云 API 的延迟数据怎么看？
要求对方提供约定并发下的高位分位，并说明测试位置、时段与限流策略。单次演示或平均值参考价值有限。拿到数据后最好用自身样本复测一次，确认网络与地域差异带来的实际影响。
混合部署复杂吗？
比单一路径复杂，主要是协议适配、提示语统一与容量分配。好处是关键路径有备份，也能按业务分配成本。复杂度要用统一网关与配置管理收敛，否则两套环境会各自演化，维护成本失控。
什么时候该全自建？
负载稳定、数据敏感、已有运维能力时更容易把延迟与成本同时控制住。若业务波动大或缺少值班人力，全自建会带来闲置与故障风险。判断依据是并发曲线、数据要求与运维成熟度，而非单一跑分。