形态至少分四层
全离线一体机、专属集群、托管专属实例、专有网络内按量调用，四层之间不是价格阶梯，而是控制权与责任边界的不同组合。选形态本质是选由谁承担升级、故障与审计，价格只是这个选择的结果。
先切数据层
把数据分成公开、内部、敏感、受限四级，只有后两级必须留在自有环境。为什么先做这步：全部按最高等级部署，成本与运维负担会翻倍；分级结论应由客户方数据负责人签字，不由供应商代判。
再看运维承接力
全离线要求有人值夜班、备备件、跟驱动与框架版本。为什么强调队伍：没有这支队伍却选最重的形态，故障恢复会拖到业务无法接受；反过来，有队伍却全托管，能力逐渐外流，续约时缺少议价空间。
给升级留通道
模型与推理框架都在快速迭代，形态必须能承接版本更新。怎么做：明确升级包来源、灰度方式与回滚路径；离线环境升级往往靠人工带盘，频率一高就变成停更，能力停在采购那年，重估代价很高。
适用与不适用
适合谁
- 数据分级明确、需要长期自持的企业
- 有运维团队，能承担版本升级与故障处理
- 对延迟与可用性有明确承诺要求的业务
不适合谁
- 业务量小、形态选择对成本影响有限
- 没有机房条件、也不愿承担运维人力成本
典型场景
一家城商行的科技部把客户资料、信贷文本与公开产品说明分开：前两类留在行内专属集群，第三类走专有网络调用。团队按季度评估运维人力是否够用，并把模型升级包纳入变更流程，避免形态选完就锁死。
可执行步骤
- 列出全部数据类别，逐类判定可存放的环境等级，并写明判定依据与责任部门
- 盘点现有运维人力与值班安排，明确团队实际能承接的形态上限，缺口另行补人
- 对每个候选形态做一次小规模试点，重点验证升级包、灰度与回滚步骤是否走得通
- 把升级包来源、灰度名单与回滚时限写进合同附件，并约定违约处理方式
常见坑
- 把所有数据按最高等级一刀切，成本与运维负担翻倍，项目后期被迫降级重做，前期投入沉没。
- 选了全离线却没约定升级责任，模型停更两年，业务方绕开系统改用外部工具，治理彻底失效。
- 托管形态下把敏感字段直接送出去，指望事后补签条款，合规评审时无法解释数据流向，只能停服整改。
自检与验收清单
- 每类数据都有可存放的环境与判定依据，结论有人签字
- 运维人力与所选形态的责任范围匹配，缺口有人补
- 升级包来源、灰度方式与回滚路径已写进合同
- 形态选择经数据负责人与安全负责人书面确认
常见问题
能不能先上公有云再迁私有化
可以，但要先设计好迁移面：数据接口、提示词与评测集尽量与部署形态解耦，推理层留一层适配。否则迁移时等于重做集成，前期省下的时间会在第二次上线时还回去。
混合形态会不会更难管
会多一层路由与权限管理，但换来成本与合规的平衡。关键是明确哪些请求允许出网、由谁审批，并把路由规则做成配置而非硬编码，否则每次调整都要改代码，运维很容易失控。
国产算力卡能直接替换吗
要看模型与推理框架的适配程度，不能只看算力参数。建议先用目标模型在候选卡上跑同一组测试，比较成功率与延迟；适配工作量和后续版本跟进责任要在合同里写明。