凌晨一点，进度条终于走到尽头。几十 GB 的权重文件躺在硬盘里，看起来像一件已经到手的东西。等到真正加载，才发现显存不够；换成更小的量化版本，输出开始出现奇怪的重复；再换推理框架，速度上去了，长文本又撑不住。下载完成那一刻的兴奋，通常只维持十几分钟。
这也是关于开源模型最常见的一种误解：把它当成一个可以下载的成品。实际上公开的是参数和结构，剩下的部分，比如怎么运行、跑在什么硬件上、跑出来是否稳定，仍然要由使用它的人自己补齐。
权重之后，是一长串没写进说明的活
把这堆文件变成能对外服务的东西，中间隔着的步骤比想象中琐碎。量化精度怎么选，上下文开多长，批处理堆多大，超时和重试怎么设，日志留多少——每一项都会反过来影响输出的样子。同一份权重在不同配置下的表现，有时候差异比换一个模型还明显。
这些工作不体面，也不好写进汇报，但它们决定了最终能不能用。一个团队如果只评估模型本身，不做这一层，那么评估结论基本没有参考价值。
许可证里那几行字，值得单独花时间读
另一个常被跳过的环节是条款。“开源模型”这个词本身就有歧义：有的开放权重但限制商用规模，有的要求衍生物沿用同样的许可，有的对输出内容的使用另作说明，还有的会在版本迭代时调整条款。这些差异不会体现在演示效果里，却会直接影响能不能落地。
我没办法给出通用的判断，因为条款写得很具体，而且会变。能做的只是：在选定之前，把随附的许可文本完整读一遍，特别是关于商用、再分发和署名的部分，必要时请法务确认。
微调之前，先问问评测集在哪
拿到权重之后，几乎所有人都会想到微调。这条路可行，但代价常被低估。数据要清洗，训练要试错，更要紧的是——改完之后怎么知道它变好了？没有一套自己的评测集，微调就只是朝着某个方向推了一把，推歪了也察觉不到，只能靠零散的使用感受来判断。
- 先固定一批真实业务里出现过的问题，作为回归测试。
- 记录每次改动前后的输出，而不是只记住印象最深的那几条。
- 把“不回答”和“答错”分开看，它们的处理方式完全不同。
这三件事做起来枯燥，但它们是把微调从手感变成工程的分界线。
它更适合谁
如果团队里有人能长期照看部署、监控和版本升级，那么开源模型带来的是可控性：数据不出内网，行为可以追溯，遇到问题能往下挖。反过来，如果只是想在产品里加一个能力，且没有余力维护这套东西，直接调用托管接口通常更省事。
这条边界并非固定。硬件在变，部署工具在变，今天需要一支小队才能维持的事情，明年可能几条命令就能完成。所以每隔一段时间重新算一次账，比一次性做出判断更实际。
回到那台凌晨的机器。最后它确实跑起来了，只是速度和最初设想差了一截，上下文也从计划中的长度砍掉一半。这不算是失败，这就是把权重变成服务的过程本身。