先看数据分级
把待处理数据分为可出内网、仅限本地、禁止留存三类，直接排除不合规形态。不少项目先选形态、后做分级，结果在采购完成后被迫返工，代价远高于前期一次确认。分级结论应由客户安全与法务出具，技术方不单方判定。
再看调用曲线
日均调用稳定、峰值可预测时，专属实例或本地部署的利用率才撑得住；调用稀疏、峰谷相差较大时，按量计费的接口更合适。用近三个月真实日志画曲线，不要拿试点期的峰值当常态，否则容量会长期过剩。
再算运维能力
本地部署要有人管驱动、显存、调度与故障处置，缺少这类岗位时托管形态更稳。评估时把值班、告警、版本升级三项责任列出来，逐项明确由哪个岗位承担，否则上线后容易出现无人接手的空档，故障处置时间也会被拉长。
混合形态要统一入口
云上跑通用能力、本地跑敏感任务时，需要一层网关做路由、限流、日志与降级，否则两套调用各写一遍，切换成本很高。网关还要保留模型可替换的抽象，避免提示词与业务代码绑死在某一家模型上，日后迁移只能重写。
适用与不适用
适合谁
- 数据分级复杂、需在多种形态间取舍的企业
- 已能拿出历史调用数据的业务与技术团队
- 希望保留模型可替换能力的架构负责人
不适合谁
- 数据尚未分级就要求确定部署方案的团队
- 没有运维人员、也不接受托管形态的项目
典型场景
某集团信息中心要为一个合同审阅场景定形态。安全部门先把合同文本定为仅限本地，团队据此排除公有云直连；再用近三个月工单量估算并发，发现日均调用不高但月末集中，最终选择本地小模型为主、云上大模型兜底的混合方案，由架构组按月复核分流比例。
可执行步骤
- 由业务与安全部门联合列出场景涉及的全部数据类型，逐项完成分级确认并留档备查，形成一页清单
- 取近三个月真实调用日志，按场景与输入长度打标签，输出日均与峰值两条曲线，标出月末与季末尖峰
- 按分级结论排除不合规形态，保留两到三种候选，逐条写明排除理由、前提条件与需要补充的材料
- 对候选形态做小流量对比测试，记录延迟、失败率与人工接管率，形成一页对比表供评审使用
- 在项目确认单中写明网关、评测集与迁移预案，再进入采购与实施，责任人与时间点一并写清
常见坑
- 先定形态再补合规评估，往往在采购完成后被迫更换方案，预算与工期双输，返工还会影响业务方对项目的信任
- 用试点期峰值推算常态容量，容量买多、利用率长期偏低，单位任务成本被摊高，且难以在合同期内调整
- 混合形态没有统一网关，两套调用逻辑各自演化，切换或扩容时改动量翻倍，测试范围也难以收敛
- 未约定模型版本变更时的评测与回滚流程，升级后回答质量下滑却无从定位，只能整体回退到旧版本
自检与验收清单
- 数据分级结论是否由安全与法务书面确认并附系统清单
- 是否用近三个月真实日志而非试点峰值来估算容量与并发
- 统一网关是否具备路由、限流、日志与降级能力，并留存审批记录
- 模型版本变更是否有评测集对照与回滚流程，责任人是谁
- 形态复核周期与责任人是否写入项目确认单并告知业务方
常见问题
可以先上公有云接口，以后再迁本地吗？
可以，但要在首个版本就做接口抽象与评测集，把提示词、调用参数与业务代码分离。迁移时用同一套评测集对比新旧形态，确认质量没有实质下降再逐步切流量，避免迁移最后变成一次重写。
本地部署是不是一定更安全？
不一定。本地部署只改变数据存放位置，权限混乱、日志缺失、离职账号未回收同样会出问题。安全取决于数据分级、权限、审计与删除机制，位置只是其中一项条件，不能替代流程建设。
部署形态和模型选型哪个先定？
先定数据边界，再定部署形态，最后在可用形态内比较模型。顺序颠倒会出现模型能力很好但无法落地的情况。三者应在同一份确认单里写清验收口径与责任人，避免互相等待。