实际做模型选型时风险往往不是“选错了技术栈”而是在一条不可复现的消息上做关键变更。社区里经常出现“本地模型已经打平某个闭源旗舰”的讨论标题越确定越应该把它当成候选线索而不是生产结论。真要把外部闭源 API 换成内部自托管模型必须回答几个细节问题评测用的是哪套题集题集是否覆盖业务场景两个模型的采样参数是否一致本地部署版本的模型名和 API 模型名对得上没有。只要这些问题还是模糊的对比结果就没有工程参考价值。这篇文章围绕一个具体场景展开团队内部部署了一个代号 demo-v4 的本地模型外部正在使用一个闭源 API 模型这里统称 closed-api-demo。业务方想确认 demo-v4 能否在数学、代码、中文指令这几个核心维度上替代外部服务。接下来会把开闭源部署差异、最小评测环境、统一调用脚本、结果解读和排错链路完整走一遍。这套流程既能做一次性对比也能改造成每周运行的模型回归基线。文中所有模型名称都是占位示例不指向任何真实产品版本。落地时要把model名称、base_url、密钥和评测集替换成自己的实际配置。1. 闭源模型和本地模型的差异本质是部署边界不同很多团队把“哪个模型更聪明”当作选型第一问题实际项目里更麻烦的是部署边界数据能不能出域、推理服务能不能自控、问题出现时能从哪一层开始排查。闭源模型和本地模型在这几点上的差异直接决定评测方案怎么设计。1.1 闭源模型通常只有 API不等于在代码里不可见闭源模型的通常形态是模型权重由服务方持有使用方通过 HTTP 或 SDK 调用推理接口。它并不是“不存在”而是以黑盒接口的形态存在。团队不拿权重不参与模型加载也不容易看到服务端日志。本地模型则相反。模型权重可以下载到自己的 GPU 环境由自己的推理服务加载整个过程可以控制、可以观测、可以复现。这种可控性带来的收益不是“跑分更高”而是调试链路更完整同样一个错误闭源 API 只能看到调用端异常本地模型可以看服务日志、显存占用、请求参数和token 统计。对比项闭源 API 模型本地自托管模型权重获取不提供权重可下载并自管访问形态HTTP / SDK 调用本地推理服务数据出域默认发给第三方服务可控制在网络边界内初始门槛低申请密钥即可高需要 GPU 与部署链路长期成本token 费用和配额治理硬件折旧与运维成本自定义能力prompt 和参数范围受平台限制