维度一：能力是否匹配
不看榜单看任务：把三十条真实任务分别跑候选模型，比较要点覆盖与格式合规。开源模型在通用问答上差距在缩小，但在长文档、多语言与工具调用上差异明显，必须用自家任务测，榜单只是初筛。怎么测，用自家任务而不是公开榜单，结论才站得住。
维度二：私有化与可控
开源可以部署在自有环境，权重与推理参数可控；闭源多为接口调用，部分厂商提供专属实例。打分时要问清能否指定区域、能否关闭日志留存、能否锁定模型版本，否则可控只是感觉，评审时也说不清。为什么条款比参数重要，因为出事时看的是合同。
维度三：数据合规
涉及个人信息与重要数据时，处理地点、留存期限与跨境传输都要能说明。开源自建不等于自动合规，仍要做分级与评估；闭源也不等于不安全，关键看合同条款与审计能力，别把形态当结论。怎么确认合规，让信息安全与法务各自出具结论。
维度四：成本结构
开源的成本在算力、部署与人力，前期投入高、边际成本低；闭源按量计费，前期轻、随用量上升。打分时应按三年用量估算两条曲线，而不是只比首月账单，很多分歧在这一步就能收敛。怎么估成本，按三年用量画两条曲线，找交叉点。
维度五与六：运维与生态
自建要有人会推理优化、监控与安全补丁；闭源把这块交给厂商，但版本节奏由对方决定。两项加权接近时，优先选团队能长期维护的那条，否则第二年就会陷入无人接手的困境，迁移也来不及。怎么判断能否长期维护，看有没有人愿意接手补丁。
适用与不适用
适合谁
- 正在做模型选型、需要书面依据的技术负责人
- 数据敏感、需要私有化部署的企业方
- 用量大、希望摊薄长期成本的公司
不适合谁
- 没有运维人力、却坚持自建省钱的团队
- 只比较榜单分数、不做任务评测的项目
典型场景
某汽车零部件企业要做图纸与工艺文件的问答。数据不能出内网，这一项直接排除公有接口；团队用三十条真实问题测了两个开源候选，其中一个在中文长文档上明显更稳。按六维打分后选择自建，同时保留闭源接口作为非敏感场景的补充，避免单点依赖。
可执行步骤
- 用三十条真实任务测候选模型的能力、格式合规与处理耗时并对比排序
- 逐项确认数据地点、留存期限与版本锁定条款并留存书面记录并备查
- 按三年用量估算自建与调用的成本曲线，找出交叉点与闲置率的区间
- 评估运维人力与安全补丁的承担方，并把责任写进方案与附件与附录表
- 按权重汇总并留档打分依据，逐项写明未选理由与补救措施与时间表
常见坑
- 用公开榜单选模型，真实任务上格式与术语都不达标，试点阶段才发现要换，前期投入基本白费。
- 只算算力采购价，没算部署、监控与人力，自建总成本被低估，第二年预算吃紧，只能降级运行。
- 以为自建就没有合规问题，数据分级与访问审计都没做，评审时被要求整改，上线计划全部推迟。
- 合同未约定版本锁定，供应商升级后接口行为变化，提示词与评测全部重做，团队疲于应付。
自检与验收清单
- 是否用真实任务而非榜单做过评测，样本多少条
- 数据地点、留存与版本条款是否确认并留档并存档
- 三年成本曲线是否估算过，含闲置与人力成本
- 运维与安全补丁责任人是否明确到岗到人并签字
- 打分依据是否留档，可被他人复核与追溯责任
常见问题
开源一定更便宜吗？
用量大时通常更便宜，用量小时不一定。自建要付算力、部署与人力，闲置也会产生成本；建议按三年用量估算，并考虑业务波动，别只看峰值需求，也别把闲置算成零。也要算进去。
闭源能不能私有化？
部分厂商提供专属实例或专有部署，形态与条款差异很大。要问清处理地点、日志留存、版本锁定与退出时的数据导出，写进合同再谈价格，否则容易被动，也很难在评审时解释。
能不能两条腿走路？
可以，而且常见：敏感数据走自建，通用能力走接口。关键是把路由规则与降级方案写清楚，避免两套提示词与评测长期不一致，最后没人说得清线上跑的是哪套，出问题也难定位。