边界一：数据敏感且量大
数据不能出内网、调用量又大时，自建的边际成本优势才显现；量小的时候，自建的固定投入摊不薄。判断方法：估算月度调用量与算力利用率，利用率长期偏低就不适合自建，租用或混合更现实。怎么判断边界，看利用率能不能撑起固定投入。
边界二：需要持续微调
有稳定样本、要按产品线或术语体系持续微调时，开源的可控性更有价值；闭源接口通常只提供有限微调能力。边界是样本与评测要跟得上，否则微调只是把噪声固化，越训越偏，回滚也难。为什么微调要配评测，否则只是把噪声固化下来。
边界三：离线与边缘场景
工厂车间、野外作业、内网机房无法稳定联网，只能在本地推理。这类场景开源几乎是唯一选择，但要接受模型规模受限、更新靠人工搬运的现实，运维预案要提前写，包括断网与回滚。怎么准备离线运维，先写断网与回滚预案。
不适用：把自建当省钱
用量小、团队无运维能力时，自建的固定成本远高于调用。此时应选托管或专有实例，把人力放在业务上；省钱的说法只在用量足够大、利用率足够高时成立，否则只是把账单换了个位置。怎么算这笔账，把闲置与折旧算进单位成本。
混合形态成立的条件
混合要成立，需要统一的路由规则、一致的提示词与一套评测集；否则两套系统各说各话，维护成本翻倍。若做不到这三点，宁可先选一条路线做深，而不是同时铺开，最后两边都不熟。怎么管混合，统一路由、提示词与评测三件事。
适用与不适用
适合谁
- 数据强敏感、需要本地推理的制造与医疗企业
- 有稳定样本、计划长期微调的团队
- 需要为不同数据级别设计分流方案的项目
不适合谁
- 用量很小却坚持自建、不愿算总账的单位
- 没有统一评测、却想同时维护两套模型的团队
典型场景
某矿业集团要把设备手册与安全规程做成现场问答。井下无稳定网络，只能在本地推理，开源成为必然选择；集团把模型规模压到能在工控机上运行，回答只做检索与要点提示，关键操作仍由值班工程师确认，更新包按月由信息中心带入。
可执行步骤
- 估算月度调用量、峰值与算力利用率，判断自建是否划算与闲置成本
- 核对是否需要持续微调、离线运行与边缘部署，列出硬约束与责任人
- 若选混合，先定路由规则、降级顺序与统一评测集，并写明判定标准
- 把更新方式、搬运周期与现场运维责任写进方案与合同附件并指定负责人
- 明确关键操作的人工确认环节、复核人与签认记录的具体要求与留痕方式
常见坑
- 用量小仍坚持自建，算力长期闲置，折算下来比调用更贵，还占用了运维人力，最后只能降级使用。
- 混合形态没有统一评测，两套系统对同一问题给出不同口径，用户不知道该信哪个，投诉处理也更慢。
- 离线场景忽略更新方式，模型与知识半年未更新，现场问答逐渐失效，一线又回到翻纸质手册。
- 把关键操作也交给模型，未设人工确认，出问题后责任无法界定，系统被停用，投入全部沉没。
自检与验收清单
- 调用量、峰值与算力利用率是否估算过与成本
- 是否确需持续微调、离线运行或边缘部署需求
- 混合形态是否有路由规则、降级顺序与统一评测
- 更新方式、搬运周期与运维责任是否写明到人
- 关键操作是否保留人工确认与签认记录环节表
常见问题
自建要多大用量才划算？
没有通用门槛，取决于算力价格、利用率与人力成本。可行做法是把固定投入按三年摊到每月，再与调用成本对比；利用率低于三成时通常不划算，租用或混合更稳，也更容易随业务调整。
闭源能不能离线？
一般不能，接口需要联网。少数厂商提供专有环境，但仍在指定机房。真正需要现场离线时，应按开源方案设计，不要指望接口变通，否则验收时无法通过，返工成本很高。也很被动。
混合会不会很难维护？
会比单一路线难，但可控。关键是统一提示词模板、评测集与路由规则，把差异收敛到模型适配层；做不到这三点，混合会变成两套系统的长期拉扯，谁都不愿接手。也不愿维护。