有位做室内设计工具的朋友最近换掉了他们产品里调用的模型。原因不是效果差，而是账单。他们用的是某个开源模型的托管版本，前半年很便宜，用户量涨起来之后，推理成本开始咬人。他算了一笔账：自己部署一套，前期投入不小，但边际成本会降下来。于是他花了三周时间折腾环境、量化、压测，最后把服务迁了过去。
这件事有意思的地方在于，他一开始选择开源模型，恰恰是因为“不用花钱”。真正跑起来才发现，免费的只是权重文件。
“开放”到底开放了什么
讨论开源模型，绕不开一个前提：这个词本身并不精确。有的模型放出权重，附带完整的训练与推理代码；有的只给权重，训练数据和方法闭口不谈；还有的限制商用、限制再分发，或者设一个用户规模的门槛。对工程师来说，能不能下载到文件是一回事，能不能合规地用在产品里是另一回事。
我见过团队在选型时只看效果和显存占用，把授权条款留到上线前才翻。结果往往是改方案，而不是改合同。所以比较务实的做法，是在评估初期就把授权当成一项硬指标：商用是否允许、再分发是否有附加条件、衍生模型该如何标注。这些问题的答案通常写在仓库根目录的一个文本文件里，读它花不了十分钟。
另一个常被低估的是“可复现”。权重开放不等于行为可复现。同一份权重，在不同的推理框架、不同的量化精度下，输出可能明显不一样。做内容生成的团队对此尤其敏感——昨天还稳定的语气，换个版本就变了。
成本没有消失，只是换了位置
我自己试过在一台消费级显卡上跑中等规模的模型，跑通不难，跑稳很难。显存吃紧时要调参数量化，量化之后质量下降又要重新评估，评估就得有人工标注，标注又是一笔开销。开源模型把采购成本压低了，却把工程成本推到了团队自己身上。
这不是说自部署不划算。用户量大、调用频繁、对数据出境有要求的场景，自部署的长期账往往更好看。问题在于很多团队低估了“养”的部分：版本升级、安全补丁、监控告警、故障排查，都需要人。模型不是装完就结束的软件，它更像一个需要持续观察的服务。
反过来，调用托管服务也不是没有代价。价格会变，接口会变，服务商的政策也会变。把关键功能押在单一来源上，风险不比自部署小。一个折中的思路是把推理层做薄：用一层抽象把模型调用封装起来，切换供应商时改动可控。这算不上什么新鲜架构，但在模型迭代速度这么快的时候，它确实能省下不少返工。
社区是资产，也是变量
开源模型真正吸引人的，除了许可宽松，还有围绕它长出来的生态：微调脚本、评测工具、部署方案、问题讨论。这些沉淀让后来者少走弯路。但社区也是变量。维护者的精力有限，一个仓库可能几个月没更新，issue 区堆着未回复的问题。依赖这样的项目做长期产品，需要有人能读懂源码，而不是只会照着 README 敲命令。
我的判断是，选开源模型时，比起看它能做什么，更该看它在出问题时你能做什么。有活跃维护、有清晰的问题处理流程、有可追溯的版本记录，这些比多刷几个点的效果更值得关注。
回到开头那位朋友。他迁移之后，成本确实降了，但也多了一项日常：每周看一眼服务的资源占用和错误日志。他说这不算负担，只是以前没意识到，模型跑在别人机器上的时候，这些事是不需要他操心的。
开源模型给了企业更多选择权，同时也把责任一并交了出来。想清楚自己愿意承担哪部分，比纠结“开不开源”更有意义。