一位做智能客服的朋友最近换了方案。不是换了供应商，而是把原来调用的闭源接口换成了自己部署的开源模型。理由很朴素：客户问题里大量是退换货规则、地址修改、发票开具这类高频小事，一个几B参数的开源模型微调之后就能覆盖，响应更快，也不必把对话内容发到别人的服务器上。
这件事让我重新想一个问题：我们评价一个模型时，习惯看它“能做什么”，但在企业里，真正决定选型的问题往往是“够不够用”。当一个开源模型的能力刚好越过业务门槛，剩下的事情就开始由成本、数据和运维节奏说了算。
门槛在往上挪，但不是均匀地挪
过去两年，开源模型的进步有一个很直观的特征：小尺寸版本越来越能打。同一个家族里，参数量较小的版本在常见问答、文本分类、信息抽取这些任务上，已经能满足不少内部系统的需求。这并不意味着它们全能，而是说“可用区间”被拉宽了。
但门槛的上移并不均匀。语言理解和格式规整的任务，开源模型的表现提升明显；需要长链条推理、复杂工具调用、多轮纠错的场景，差距仍然存在。企业做判断时，把这个差异想清楚比看综合印象更重要——你的业务到底是“回答一个问题”，还是“完成一件事”，两者的选型逻辑完全不同。
这也是开源模型最容易被误用的地方。它给人的印象是“免费、可改、随便用”，但真正投入生产时，人力成本会以一种安静的方式出现：谁来评估效果，谁来做微调，谁来盯住版本升级后的行为变化。
它真正改变的是成本结构，而不只是账单
把开源模型部署在自己的机器上，直接省下的是按调用量计费的支出，但更值得算的是另外两笔账。
一笔是数据账。涉及客户信息、内部文档、合同条款的场景，很多团队并不愿意把原文送到外部接口。私有部署把这条边界收回来，随之而来的是责任也收回来：日志留多久，权限怎么分，模型输出被谁看到，这些都要自己定。
另一笔是试错账。闭源接口按次收费，做实验时会下意识地控制调用次数；自有部署之后，工程团队可以放开手做批量回放、对比测试、提示词迭代。这种“敢试”的状态，往往比省钱本身更有价值。
当然，账也不是单向的。硬件采购、推理优化、故障排查、模型更新后的回归验证，都是持续投入。一个常见的现象是：小规模试用阶段，自部署看起来很划算；业务量上来之后，运维复杂度才开始显形。反过来，如果调用量很小，直接使用成熟接口可能更省心。
知识沉淀在谁手里
我更愿意从另一个角度看这件事。企业使用模型的过程，本质上是在把内部经验转化成可复用的东西：话术规范、判断标准、异常处理流程。如果这些内容只是以提示词的形式停在某个外部平台上，它更像是租来的能力；如果权重、数据、评测集都留在自己手里，它才有机会慢慢长成组织的一部分。
开源模型提供的就是这种可能性，但可能性不等于结果。见过一些团队下载了权重、跑通了demo，然后就停在那里。原因不复杂：没有评测集，就不知道改了什么；没有标注流程，微调就无从谈起；没有明确的负责人，模型上线后就没人管。模型是开源了，能力却没有真正沉淀下来。
所以讨论开源模型时，我不太赞成把它当成一个“选不选”的问题。更实际的问法是：我们有没有能力把一个通用模型，变成贴合自身业务的模型。这个能力包括数据整理、效果评估、上线监控，也包括承认某些任务它做不好，然后老老实实交给人。
一条更务实的路径
对于多数团队，比较稳妥的做法是把任务分层。高频、规则明确、容错率高的部分，交给自部署的小模型；低频、复杂、结果影响大的部分，保留给能力更强的外部服务或人工处理。两层之间用统一的评测标准连接，定期检查边界有没有移动。
这样做的好处是，既不会被单一方案绑住，也不会为了追求“全部自研”而背上不必要的负担。开源模型在这个结构里不是替代品，而是一块可以自己打磨的部件。
回到开头那位朋友。他并没有宣称自己的方案更好，只是说了一句话：客户的问题大部分很简单，我们把它接住就行了。这句话听起来不够激动人心，但可能正是很多企业真正需要的判断标准——不是模型有多强，而是它离你的业务有多近。