先算出网的真实代价
数据出网不只是技术动作，还牵涉合规评估、合同条款与审计留痕。怎么做：先识别哪些字段一旦出网就触发申报或禁止，再判断这些字段能否脱敏或替换；不能脱敏的部分才是必须私有化的范围。
波动决定计费形态
峰值与均值差距大的业务，按量调用通常更省；曲线平稳且用量高，预留或自建才有优势。怎么判断：把过去数月的用量画出来，看峰值持续多久，再拿两种方案的年度总支出对照。
迭代速度是隐性收益
托管接口把模型更新、容量扩容与故障处理交给供应商，团队可以专注业务逻辑；自建则要跟框架与驱动版本。怎么权衡：算清团队每月在环境维护上投入的人天，再对照业务迭代的紧迫程度。
退出成本要提前算
包括数据迁移、提示词与评测集重建、接口适配与人员再学习。怎么降低：保持接口层抽象、评测集与部署解耦、避免依赖供应商独有能力。完全中立不现实，关键是知道锁定在哪一层。
适用与不适用
适合谁
- 有两类以上数据敏感度的制造与零售企业
- 用量波动明显、需要弹性容量的线上业务
- 团队规模有限、希望减少环境维护投入
不适合谁
- 全部业务数据都属受限等级的机构与部门
- 对出网有绝对禁止要求、不留任何例外
典型场景
一家物流企业的客服与调度两个场景做了不同选择：与手机号、地址相关的请求留在内网集群，知识问答与话术生成走按量调用。团队在网关层统一做脱敏与审计，季度复盘时比较两条链路的单位成本与延迟。
可执行步骤
- 按字段识别敏感信息，标出必须留在内网的部分与判定依据，形成清单
- 统计历史用量曲线，判断峰值持续时长与波动幅度，再定承诺量
- 把两类方案折算成年度总支出与所需人力投入，按同口径比较
- 在网关层统一实现路由、脱敏与审计留痕，避免规则散落各处
- 每季度复核一次，按用量与合规要求的变化调整两条链路的比例
常见坑
- 为省事一刀切全部私有化，成本高、迭代慢，业务方私下另找外部工具，治理反而彻底失控。
- 混合架构缺统一网关，脱敏规则散落在各个应用里，早晚漏掉一处，事后无法追溯责任。
- 只比调用单价不比年度总支出，忽略人力与闲置，结论常与真实账本相反，预算也会失准。
自检与验收清单
- 敏感字段是否逐项识别并标注判定依据
- 路由规则是否集中配置、可审计、可回滚
- 两种方案的年度总支出是否同口径比较
- 退出时的数据与提示词迁移量是否估算
常见问题
公有云接口的数据会被用于训练吗
取决于供应商条款与接口类型，不能一概而论。采购前应逐条核对数据使用、留存与二次利用条款，必要时选择明确不用于训练的接口，并把结论写进内部合规记录，由法务确认。
混合部署会不会增加故障点
会增加，主要是路由与网络环节。控制办法是把网关做成无状态、可快速切换的组件，并对两条链路分别设降级策略：外部不可用时退回本地模型或人工处理，而不是整条业务停摆。
小公司怎么选
优先按量调用，把精力放在业务与数据整理上；等某个场景用量稳定、成本可预测，再评估专属资源。过早自建通常会把有限人力锁在环境维护上，业务迭代反而更慢。