周末把一台两年前的轻薄本清出空间，试着跑一个开源模型，处理几十页会议记录。安装不算难，难的是后面：模型能流畅生成摘要，却会在日期和人名上自作主张；换一个量化版本，速度上来了，格式又开始漂移。这个下午让我意识到，讨论开源模型时，参数和演示效果只是入口，真正决定它能不能留下来的是另一套账。
先看许可证，不只看权重
“开源”两个字容易让人放松警惕。模型权重可以下载，不等于可以随意商用；有的许可证对用户数量、署名方式、衍生分发有额外要求，有的把使用限制写在附加条款里。对企业来说，这些条款需要法务和工程一起看，而不是下载页上扫一眼。开源模型给的是修改和部署的自由度，但自由度的边界由许可证划定。
维护成本藏在更新日志里
本地跑起来只是开始。推理框架升级、显卡驱动变动、量化格式换代，都可能让原本稳定的流程出问题。更隐蔽的是行为漂移：同一个提示词，在不同版本上输出风格会变，格式约束的遵守程度也会变。若把它接进工单分类或文档摘要，变化不会大声提醒，只会慢慢积累成人工返工。
- 固定版本与固定评测集，和追新之间需要取舍；
- 把提示词、后处理、回退方案一起纳入版本管理；
- 给输出加可检查的约束，而不是只靠肉眼看。
评估一条工作流，而不是一个模型
很多讨论喜欢比较模型能力，但落到具体业务，问题往往不是“哪个模型更合适”，而是“这条流程能不能稳定交付”。同样一个开源模型，放在离线文档摘要里和放在实时客服里，要求完全不同。前者可以容忍几秒延迟，后者对响应时间和并发更敏感；前者出错可以人工复核，后者需要更严的兜底。把模型放回流程里看，才知道该关注上下文长度、工具调用稳定性，还是部署成本。
能力边界之外，仍然值得投入
开源模型的价值不只在省下调用费。数据不出内网、可以针对垂直语料做微调、出问题能定位到具体层，这些是闭源接口难以替代的。但它也不是万能钥匙：对长尾知识、实时信息、复杂推理，仍要配合检索、规则和人工审核。把它当成一个可替换的组件，而不是一个需要信仰的平台，心态会轻松很多。
回到那台旧笔记本，最后我留下的不是某个模型，而是一套很小的流程：固定版本、保留原始输出、加一层格式校验、每周抽查几条结果。开源模型能不能用，答案往往不在下载页，而在这些琐碎的动作里。