稳定性与可控性
通用模型随供应商升级而变化，微调模型行为更稳但需要持续喂数据，本地小模型完全可控却受算力限制。怎么权衡：对外服务优先稳定，内部工具可以追新；把稳定性要求写进选型标准，而不是上线后再补。
部署条件差异
通用接口开箱可用，微调需要标注数据与训练流程，本地部署要机房、显卡与运维。怎么评估：先算清能提供什么条件，再选形态；没有标注团队却要微调，往往做出一个效果不如通用模型的版本，稳定性要求也要写进验收标准。
迭代责任差异
用接口时模型更新由供应商负责，出问题只能等；自建模型要自己排期训练与回归。怎么约定：在合同里写明升级通知期与回归责任，自建则要指定模型负责人；否则升级当天才发现效果退化，只能临时回滚。
异常处理差异
通用模型遇到越界问题容易给出看似合理的回答，微调模型可能过拟合到训练分布，本地小模型在长尾上更弱。怎么兜底：统一加校验层与拒答策略，按模型能力设置不同的接管阈值，别用一套规则套所有模型。
适用与不适用
适合谁
- 在通用、微调与本地部署之间做选择的企业
- 已有标注数据、考虑自建模型的团队
- 需要为不同场景分配不同模型的架构负责人
不适合谁
- 没有数据、也没有运维能力的团队
- 希望一次选型长期不变、不做复查的项目
典型场景
某运营商同时有三个场景：客服问答、工单要素抽取、内部知识检索。团队用通用模型做客服、微调模型做工单抽取、本地小模型做检索排序，三层共用一套校验与日志；每季度评估一次，效果退化的环节单独回归，不整体切换。
可执行步骤
- 按场景列出稳定性、时延与数据边界三项要求，逐条打分并留档，形成一页表
- 评估自身能否提供标注数据、算力与运维人力，缺口写在方案前面，别等签约后再补
- 为每个场景选定模型形态，并在合同里写明升级方式与回归责任的归属
- 统一校验层与拒答策略，并按各模型能力分别设置接管阈值与告警线
常见坑
- 三个场景共用一个模型，客服效果尚可，抽取任务却长期不达标，业务方反复投诉，最后只能返工。
- 没有标注团队就启动微调，训练集只有几百条，效果反而不如通用模型，最后退回原方案。
- 本地部署后无人维护，显卡利用率低，模型半年没有更新，逐渐跟不上业务需求，安全补丁也滞后。
- 供应商升级未提前通知，线上输出风格变化，投诉在一周内集中爆发，只能临时回滚，损失已经造成。
自检与验收清单
- 每个场景的稳定性要求与时延上限是否写明，并留档
- 标注数据、算力与运维人力这三项条件是否具备
- 升级通知期与回归责任是否在合同里写明，并附清单
- 是否统一了校验层，并按不同场景配置拒答策略
- 是否为每个场景分别设置了接管阈值和告警线
常见问题
微调一定比通用模型好吗？
不一定。微调在术语固定、格式严格、样本充足的场景更有优势；样本少或任务多样时，通用模型加提示词往往更好。建议先做提示词优化与检索增强，确认瓶颈在模型本身再考虑微调。
多模型路由会增加多少复杂度？
主要是运维与计费复杂度。要统一日志、用量统计与降级策略，还要定义切换条件；建议从两个模型起步，把路由规则写成配置而不是代码，避免每加一个模型就改一次业务。
本地部署的成本怎么评估？
按算力、机房、运维人力与更新周期四项估。很多团队只算硬件，忽略长期运维与模型迭代；若场景调用量不大，先用专有环境或混合部署，等用量跑稳以后再考虑完全自建，别一次把预算压在硬件上。