晚上把权重下载下来，几张卡，跑通一个对话 demo。效果看起来还行，回答流畅，格式也算规矩。第二天开会，有人问一句：能不能上线？会议室的气氛通常会在这句话之后变一下。
从“跑通”到“上线”这段距离，跟模型本身关系不大。真正占时间的是那些不讨喜的部分：许可证怎么写的、出了问题谁负责、下一版权重什么时候来、来的时候要不要跟着换。
许可证里的小字，比参数更值得读
开源模型这个词本身有点模糊。有的项目公开权重、训练脚本、数据说明，接近完整可复现；有的只放权重，附带一份自定义条款，商用规模、署名方式、输出内容各有说法。它们都被叫作开源，但你能做的事差别很大。
我不打算在这里做法律解读，只是提醒一句：读条款的成本，远低于上线之后发现问题再回滚的成本。尤其是打算把模型嵌进对外产品的时候，授权范围、再分发条件、以及“模型输出能不能用于训练别的模型”这类条款，值得让真正懂的人过一遍。
微调不是万能补丁
效果不理想，第一反应往往是微调。但微调擅长的是把行为掰到某个格式、某种语气、某类拒答边界上；它不擅长往模型里塞进它没见过的知识。拿领域文档去微调，期待它记住细节，通常换来的是更自信的错误回答。要补知识，检索的路子更直接。
还有个被低估的成本：回归。改一版权重，之前攒的评测用例得重跑一遍，因为你不知道哪条能力被顺手改坏了。没有这套用例，微调就是盲改。
评测这件事，谁都没完全解决
公开的评测集有被针对性优化的风险，自己搭一套又费人。于是很多判断停在“几个 demo 看着不错”的层面。这不是谁的错，是这件事本身就难。能做的可能只是把评测集建在自己的真实任务上，规模不用大，但要能反复跑、能对比。
什么时候不该用它
有些场景确实需要开源模型：数据不能出内网、要离线运行、要对推理过程做深度改造、要把这套东西握在手里好几年。这些理由都很关键。
但也有一些情况，用它是出于习惯而非必要。比如调用量不大、只想要一个稳定接口、团队里没有专职维护推理栈的人。这时候自己部署一套权重，意味着要跟着推理框架、驱动、硬件兼容性一起往前走，版本组合出问题时没人替你分担。这笔隐性开销，往往在第三个月才显现。
所以判断的落点，不在“开源好不好”，而在你手上有没有对应的人力。技术选型里最难说清的部分，通常就是这种跟人有关的部分。
把权重拉下来是几分钟的事。让它在一个团队里稳定活下去，是另一件事。开源模型给出的是一堆可能性，不是答案。