自建还是调 API

同一套合同审查需求，三家供应商可能给出三种建议：买一套部署到公司的服务器里、租云上的专属实例，或者按次调用模型 API。它们演示时都能回答问题，区别却藏在上线后的算力利用率、升级节奏、数据边界和运维责任里。选型不是比较谁的模型名字更大，而是确定哪些责任必须掌握在自己手中。

先给答案

先用 API 验证价值，需求稳定且有隔离、地域或吞吐要求时再评估托管实例；只有在强控制要求、可持续负载和专业团队同时具备时，才认真考虑自建。不要把「数据敏感」直接等同于「必须买服务器」。

三条路买到的是不同责任边界

调用 API，是把请求通过接口交给厂商运行的模型，再接收结果。企业不用管理显卡、推理框架和模型副本，通常按实际用量结算，能在几天内做出小范围验证。它的关键问题不是「数据会不会上云」这一句，而是请求在哪个区域处理、保留多久、是否用于改进服务、谁能访问日志，以及合同是否给出相应承诺。面向消费者的聊天产品条款，也不能代替企业 API 条款。

托管部署，本文特指由云厂商或模型服务商维护、并提供专属或预留容量、网络隔离、区域选择等能力的推理环境。它与共享的按量 API 边界未必截然相同，实际隔离和运维责任必须看产品与合同。企业少管底层机器，但仍要管理账号权限、密钥、调用日志、版本切换和业务应用。它适合负载已经可预测、又希望减少基础设施维护的团队；低峰长期闲置时，专属容量也可能变成固定负担。

自建部署，是企业自己运行模型权重和推理服务，地点可以是本地机房，也可以是自己管理的云账户。控制范围最大，不等于风险自动最小：补丁、驱动、容量、监控、备份、访问控制和模型许可证都转成了企业自己的责任。一台能跑演示的服务器不等于生产系统。生产还要考虑并发、故障切换、峰值余量与升级回滚；模型换代时，旧硬件也未必还能达到同样响应速度。

还有一种常见组合：敏感资料先在企业内检索，只把必要片段交给外部模型；普通任务走 API，受限任务走托管或自建。这里涉及检索增强生成，也就是说先查企业资料，再把相关片段随问题提供给模型。混合方案能缩小暴露面，但资料筛选、权限继承和外发审计必须真的做进系统，不能只写在架构图上。

一棵先问约束、再问经济性的决策树

可以把选型会议按下面顺序开：

1. 原文是否允许离开本地网络？ 不允许：先确认能否脱敏、缩减字段或改用合成数据；仍不允许，只比较本地自建或确实部署在本地网络内的托管形态，不能把外部专属实例自动视为合规。
2. 若允许外部处理，是否还限制第三方运维、共享基础设施、数据地域、专网、独享容量或固定版本？ 有：逐项核实托管实例与自建是否满足；没有：再优先评估按量 API。
3. 需求是否已经通过真实样本验收？ 没有：用受控数据做 API 小试，不先采购长期算力。已经通过：继续。
4. 未来六至十二个月的并发和利用率是否可测？ 波动大或未知：API 更容易随用量伸缩；持续稳定且规模足够：托管或自建才可能有经济性。
5. 是否有人长期负责模型服务、硬件、监控和安全响应？ 没有：不要自建生产系统；有：把三年总成本与控制收益一起比较。
6. 是否必须修改权重或使用只能自行运行的模型？ 是：自建理由增强；否：不要为了「自主」承担用不到的复杂度。

这棵树不是一次性答案。先设复核点：试运行三个月后，用实际调用量、峰值延迟、故障次数、人工复核率和合规要求重新计算。模型和厂商能力会变，架构应允许替换，而不是把业务流程焊死在某个接口上。

总成本不只是一张模型账单

API 的显性成本是调用量，隐性成本包括网络依赖、供应商切换、日志治理和限流设计。托管部署多了容量承诺与平台配置。自建则要把服务器、电力、机房、折旧、工程师值守、漏洞修补、性能调优和备用容量都算进去。三种方案都还需要同一批应用工作：整理数据、设计权限、测试输出、接入业务和培训使用者。

比较时可用一页表格，每项都要求证据：真实业务样本通过率、95 分位响应时间、峰值并发、月度利用率、数据处理地点、保留策略、停机恢复目标、版本升级通知期、导出与迁移方式。不要用一次精心准备的演示替代这些指标，也不要写死未来价格；让供应商分别给出低、中、高三档用量假设和计费口径。

自己试一下

可在 2026 年 8 月 27 日之后用你当前能访问的通用模型做一个不涉及真实数据的选型实验，并记下模型名称与版本。提示词是：「一家 80 人公司要做内部合同条款提取，每天 300 份文档，含客户信息，团队只有 1 名后端工程师。请在自建、托管、调用 API 中只选一种，并列出你还缺的五项信息。」

接着只改变一个条件，例如改成「任何原文不得离开本地网络」，再问一次。本次 2026-08-27 使用 GPT-5.6 Sol 的记录中，第一问选择 API，并追问数据边界、留存、负载、验收和成本；第二问转向自建，但把所有托管形态排除得过快。这个结果说明模型建议会随约束变化，也说明它的分类仍需核对具体产品。你试的时候结果可能不同，重点是观察建议是否绑定到可验证条件。

常见误解

「自建就不会泄露。」 自建减少了一个外部处理方，但错误权限、公开端口、日志留存、内部滥用和补丁滞后仍会造成暴露。安全来自完整控制，不来自服务器摆放地点。

「API 永远贵，自建买完机器就免费。」 API、托管和自建的成本曲线不同，结论取决于利用率、并发和运维。低而波动的负载常适合按量，高而稳定的负载才值得测算专属容量；不能只比较单次调用与显卡采购价。

三句话总结

1. API、托管和自建的核心差别，是控制范围与责任边界。
2. 先用真实样本验证需求，再根据数据约束、负载和团队能力升级部署方式。
3. 总成本必须包含应用、运维、安全和迁移，不能只看模型或硬件报价。

如果你要做决定

让每家供应商用同一批脱敏样本、同一组峰值与恢复指标回答决策树，并书面说明数据地点、保留、版本升级和退出方式。方案没有真实利用率和责任人，就还不具备采购条件。