机房的门关上，网线拔掉，模型还在跑——这是不少团队第一次真正把开源模型用起来的场景。演示时一切顺利，等到要交付、要维护、要解释它为什么这么回答，麻烦才浮上来。
先分清一个容易被含糊过去的区别：能下载到权重，不等于开源。许可证条款差别很大，有的对商用、再分发、署名各有要求，有的只放开推理而不放开训练细节。把“权重开放”直接当成“开源模型”，在内部合规审查时往往要返工。稳妥的做法是在选型阶段就把许可证原文读完，把限制条款摘出来交给法务确认，而不是等上线前才发现某一条不能接受。
成本没有消失，只是换了人承担
开源模型省下的通常是一次性采购或调用费用，但成本并未凭空蒸发。以前由服务方负责的推理优化、版本升级、故障排查，现在落在自己团队身上。一个模型在内网跑起来可能只需要几天，把它调到一个稳定可用的状态，却可能要几周甚至更久。显存够不够、并发上不去、长文本效果下滑、中文标点处理异常，这些都不是“部署完成”那一刻能暴露的。
- 算力：推理卡的采购或租用与业务量直接挂钩，很难一次性规划准确。
- 人力：需要有人长期跟进上游更新，判断哪些改动值得合并进来。
- 评测：自建一套贴合业务的测试集，比任何通用分数都更能说明问题。
版本迭代是另一件被低估的事
开放权重意味着更新节奏由别人掌握。上游发新版本，你要判断跟不跟；跟了要重跑评测，不跟要记录原因。半年后回头看，不少团队会发现自己正在维护一条分叉出去的分支，与上游渐行渐远。这算不得缺陷，而是选择开放路线时必须接受的日常。
一个更实际的判断角度
开源模型的价值，更多在于“可替换”而不是“便宜”。数据不出内网、推理链路自己掌握、上游出现变化时能切换到另一份权重——这些是采购合同里买不到的东西。反过来说，如果一个场景对延迟和效果的要求很紧，团队又没有长期维护的余力，把精力花在别处可能更划算。它不该是默认选项，只是把选择权交回自己手上，同时要求自己接得住。