先看数据能否出去
涉及个人敏感信息、未公开经营数据或合同原文的场景，先做数据分级与合规判断。不能出内网的，直接排除公有云直连，讨论迁移没有意义；这一结论应由安全与法务出具，技术方不能自行放宽标准。
再看调用是否稳定
日均调用高且曲线平缓，专属资源利用率才高；调用集中在少数时段或波动大，按量付费的接口更匹配。用近三个月日志判断，而不是按预估；否则容量规划会与实际使用情况严重脱节，成本也难以控制。
算清单位任务成本
比较口径应包含调用费、重试、人工介入与运维人力，而不是只看单次价格。规模较小时接口通常更省，规模上去后自建的边际成本才显现；拐点因模型与硬件而异，需要用自己的数据实测，不能照搬同行结论。
保留切换能力
无论选哪种，都应在业务与模型之间加一层网关，统一鉴权、限流、日志与路由。这样迁移时只改网关配置，不必重写业务代码；网关也要有评测集配套，否则切换后的质量变化无法判断，回退也缺少依据。
适用与不适用
适合谁
- 在自建与接口之间犹豫的技术负责人
- 调用量增长、开始关注单位成本的团队
- 数据合规要求明确、需要给出方案依据的企业
不适合谁
- 数据尚未分级就要求结论的团队，也无法评估成本。
- 期望一次决策长期不变、不做复核的组织
典型场景
某制造企业的设备手册问答最初直接用接口，验证可用后调用量上升。团队按场景归集成本，发现高频标准问答占了多数调用，于是把这部分迁到本地小模型，复杂诊断仍走接口，用统一网关按问题类型路由，并按月复核分流比例与质量。
可执行步骤
- 完成数据分级，标出不可出内网的场景，请安全部门书面确认并形成清单
- 统计近三个月调用量与时段分布，输出日均与峰值曲线，判断负载是否平稳
- 按统一口径测算单位任务成本，含重试、人工介入与运维人力，并列成对比表
- 在业务与模型之间加一层网关，统一鉴权、限流、日志与路由，并保留降级开关
- 小流量灰度迁移，用评测集对比新旧路径质量，保留回切开关并按月复核
常见坑
- 只比较调用单价，忽略重试、人工介入与运维人力，测算结论偏乐观，迁移后才发现并不省钱。这类偏差在立项评审时很难被发现，等到账单出来已经晚了。
- 迁移时直接改业务代码调用地址，缺少抽象层，回滚困难，一次故障就可能影响多个业务线，回滚也很被动。
- 未做灰度就全量切换，输出风格变化引发业务投诉，临时回滚又要重新验证，节奏被打乱，验收也难通过。
- 忽略接口的限流与配额策略，高峰期被动排队，用户感知为系统卡顿，排查却指向业务代码，定位成本很高。
自检与验收清单
- 数据分级是否覆盖全部场景并由安全确认，是否有清单
- 成本口径是否含重试、人工介入与运维人力，是否统一
- 网关是否支持路由、限流与日志并有维护人，是否有维护人
- 迁移是否有灰度与回滚方案且实际演练过，是否演练
- 评测集是否用于新旧对比并留存结论，是否留档
常见问题
接口会不会突然涨价或下线？
供应商策略可能调整，模型也可能下线。应对方式是在合同层面关注服务条款，在技术层面保留备用模型与网关切换能力，把关键场景的迁移成本控制在可接受范围，避免被单一供应商锁死。
自建一定比接口便宜吗？
不一定。自建的成本包含硬件折旧、机房、电力与运维人力，利用率低时单位成本反而更高。只有当负载稳定且规模足够，边际成本优势才明显，测算时应把这些项目全部计入。
混合使用会不会很复杂？
复杂度主要来自路由与评测，不是调用本身。用统一网关收敛入口、用一套评测集衡量各路径质量，复杂度可控；反之各自为政，接口与参数各写一遍，才会真正失控，评审时要能说清必要性。