凌晨的工位上，有人盯着显存曲线，旁边的终端还在拉取模型权重。这个画面大概是很多团队接触开源模型的起点：下载命令很短，期待很高，真正的麻烦从跑通第一条推理请求之后才开始。
权重到手，工作才开头
把模型文件放进内网，不等于得到一项可用的服务。首先要面对的是推理栈：选哪种运行时，是否量化，上下文长度留多少，批处理怎么设。每个选项都牵动显存、延迟和输出稳定性。它给出的是可修改的起点，不是开箱即用的答案。
接下来是模板和接口。对话格式、分词器配置、停止词、系统提示词，这些细节看起来零碎，却直接决定模型是否按预期回应。很多“效果不对”的反馈，最后都落到配置差异上。把它们记录下来，比反复换模型更省时间。
评测不是打分，而是划边界
内部试用时，容易拿几个顺手的问题测一测，得出“能用”或“不能用”。更稳妥的做法是把任务拆开：事实复述、格式遵循、长文处理、拒答边界，各留一组固定输入。不是为了得出一个抽象结论，而是知道它在哪类请求上需要人工兜底。这种可复现性在这里很有价值，同一版本、同一配置可以反复回归。
许可证和维护，容易被略过
许可证条款需要提前读。不同开源模型对商用、再分发、署名和衍生作品的要求并不一样，有些限制写在附则里，不能只看“开源”两个字。另一个常被低估的是维护：运行时升级、依赖冲突、安全补丁、日志与访问控制，都要有人负责。权重可以下载，责任不能下载。
- 先固定一套基础可用配置，再谈调优。
- 把提示词、模板和评测输入一起版本化。
- 上线前确认许可证、数据流向和访问权限。
我的判断是，开源模型真正的吸引力不只是省下一笔调用费，而是把控制权往前挪了一步：团队能看见内部结构，能按自己的边界做取舍，也能在离线环境里保留一条可复现的路径。代价同样清楚——工程琐事会变多，责任会更具体。想清楚这些，再决定是否把它们放进生产链路，可能比追逐新版本更实际。