上线路径：搭栈 vs 对接
自建要采购或租用算力、部署推理服务、做压测与限流、接监控告警，还要准备回滚镜像；接口只需密钥、限流与成本看板。前者周期以月计，后者以周计，排期差异要在立项时说清，否则两边都以为对方在拖。怎么排期，把环境与压测单列，别塞进开发期。
故障处理：自己扛 vs 等厂商
自建的延迟抖动、显存溢出、依赖冲突都要自己定位；接口出问题是厂商侧，但你能做的只有重试、降级与切换。两种形态都要准备降级方案，区别是谁来执行、多久能恢复，以及有没有备用模型可以切。怎么准备降级，先定备用模型与切换条件。
版本升级：主动 vs 被动
自建可以锁定版本、按计划升级，但要自己承担升级测试；闭源升级往往被动，接口行为与默认参数可能变化。无论哪种，都要有回归评测与灰度，不能直接切生产，否则一次小升级就能让效果明显下滑。为什么会被动，因为升级节奏与默认参数不在你手里。
评测验收：同一套题
两种形态都要自建评测集，验收看任务通过率、格式合规与延迟，而不是看模型参数。差异在于自建还要验部署质量：并发下的稳定性、显存占用、恢复时间，这些指标只有压测才能拿到，演示里看不出来。怎么验收部署质量，用压测拿并发与恢复时间。
合同与退出：条款差异
自建的核心是许可证与硬件维保；闭源的核心是服务条款、数据处理协议与退出安排。两边都要写清数据归属、导出格式与终止后的过渡期，否则换路线时会被拖住，迁移成本可能超过原来一年的投入。怎么写条款，把导出格式与过渡期写成附件。
适用与不适用
适合谁
- 正在做技术方案对比的架构师与项目经理
- 需要为两条路线分别排期的项目经理人
- 准备与厂商谈条款的采购与法务人员
不适合谁
- 只比较单价、不看上线与运维差异的采购
- 没有评测集、无法验收的项目团队方
典型场景
某省级设计院要上线规范条文助手。自建方案需两个月搭推理与监控，接口方案两周可试；但设计院的数据不能出内网，最终选自建。上线后发现显存不足导致长文档超时，团队补了分段与队列，验收时把并发稳定性写进了检查项，并约定季度压测。
可执行步骤
- 分别列出上线所需的环境、人力、周期与验收指标，做成一张对照表
- 写明故障处理流程、降级执行人、恢复目标与备用模型，并做一次演练
- 约定版本升级的回归评测范围、灰度比例与回滚步骤，写进变更单模板
- 用同一套评测集验收任务效果，并在接近真实的并发下做一次压测数据
- 把数据归属、导出格式与过渡期写进合同附件，并指定双方对接人名单
常见坑
- 按接口的周期给自建排期，部署与压测被压缩，上线后并发一高就超时，用户以为是模型不行。
- 没有降级方案，接口限流时业务直接中断，客服只能让用户稍后再试，投诉集中在同一周爆发。
- 闭源升级后默认参数变化，提示词效果下降，团队误以为是数据问题，查了两周才发现原因。
- 合同未写过渡期，换路线时旧系统的数据与配置无法导出，迁移拖了数月，预算也被迫追加。
自检与验收清单
- 上线环境、人力周期与验收指标是否分别列明
- 故障处理与降级执行人是否明确到岗，并演练过
- 版本升级是否有回归评测与灰度安排，比例多少
- 验收是否用同一套评测集，并做过并发压测记录
- 数据归属与过渡期是否写进合同附件并签字盖章
常见问题
自建一定更慢吗？
上线通常更慢，因为要搭环境与压测；但稳定后变更可以自己安排。若业务要求快速试水，先用接口验证需求，再决定是否自建，是更稳的顺序，也能避免一开始就压上大笔采购，最后发现方向不对。
接口方案怎么防锁定？
三层：合同层约定通知期与导出；架构层做模型适配抽象；数据层保留自有评测集与提示词。三层都有，换供应商才不至于重做，谈判时也才有底气，不至于被单方面涨价牵着走，长期成本也可控。
验收要测并发吗？
自建必须测，而且要在接近真实的并发下测长文档；接口方案则要测限流与重试下的表现。两者都该把降级后是否可用列为验收项，否则上线当天的第一次高峰就会暴露问题，临时补救很被动。