朋友的公司最近在试一套内部知识问答。预算不高，几个人把一款开源模型拉到本地，跑起来了，回答也像样。真正卡住他们的不是推理速度，而是几周后的一次追问：这份模型权重从哪来、训练数据里有没有客户资料、商用授权写清了没有。上线计划因此停住。
这类停顿很常见。开源模型看起来是免费的入口，实际是一整套工程与合规的接口。下载只是第一步，后面还有版本管理、评测、微调、推理成本和安全边界。把这件事想成“捡到一台免费发动机”，往往会在装车时才发现缺的是底盘。
权重开放，不等于整条链路开放
谈开源模型时，很多人默认它和传统开源软件是一回事。差别其实挺明显。软件的源码可以读、可以改、可以重新分发；模型交出来的通常是一组权重，训练数据、清洗流程、分布式训练代码未必一起给。能不能商用、能不能二次分发、改完之后要不要沿用同样的许可，各家写法不同，有的还附带使用场景限制。
于是出现一种落差：技术上可以调用，法务上却要先确认。对个人试验影响不大，对企业落地却是硬门槛。编辑一份模型清单时，与其只记参数量和上下文长度，不如把许可证类型、数据来源说明、可商用范围一起记下。这些信息不显眼，却决定项目能不能继续。
还有一个容易被忽略的点：即便权重完全放开，复现训练过程的成本仍然很高。数据配比、训练技巧、评测方法，往往藏在论文脚注或技术报告里。开源模型给了起点，没给整条路。
算力账单藏在使用方式里
本地部署的吸引力在于数据不出门。但推理成本不是一次性支出。模型越大，显存占用越高；并发一上来，响应时间就抖。团队常常先按单人试用估算，等接入十几个人，才发现需要调度、缓存和限流。
另一个选择是调用托管服务。前期投入低，弹性好，却把数据流向和长期单价交给外部。两者没有普遍适用的答案，取决于业务对延迟、隐私和预算的敏感程度。比较务实的做法，是先算清峰值并发和可接受的首字延迟，再决定把哪部分负载放在本地、哪部分放在云端。混合部署并不新鲜，但它常常比“全都要”更接近现实。
开源模型在这里的价值，是让团队可以按自己的约束调整。量化、蒸馏、裁剪、换更小的推理框架，这些手段都需要能碰到权重和推理代码。如果只是调用接口，优化的空间就小得多。
维护是长期动作，不是上线动作
模型会更新，依赖会过期，评测集也会老化。一个内部问答系统上线三个月后，用户提问的方式变了，原先的提示词和检索策略开始失效。这不是模型坏了，而是使用场景在移动。
小团队容易低估这部分工作量。它不产生演示效果，却决定系统能不能稳定用下去。比较稳妥的安排，是把模型版本、评测结果和变更记录放在一起管理，每次替换都留回滚路径。听上去像运维常识，放到模型上却常被跳过，因为大家更愿意讨论参数和效果。
说到这里，开源模型真正的门槛也就清楚了：它把选择权交出来，同时把责任交出来。选哪个、怎么改、改完谁负责，都得自己回答。对有能力做工程的团队，这是空间；对只想快速接一个接口的团队，反而是负担。
小团队的位置在哪里
不必把开源和闭源看成对立。更现实的图景是分工：通用能力交给成熟方案，特定环节用自己的数据和流程去补。开源模型适合做那些需要深度改造、数据敏感、或者成本结构特殊的部分。它的好处不是省掉投入，而是让投入花在自己能控制的地方。
回到开头那家公司，他们最后没有立刻上线，而是先补了三件事：确认许可证范围、梳理数据来源、写了一份简单的评测记录。进度慢了，但后面每次调整都有依据。这个选择谈不上高明，只是把开源模型当成一项需要维护的工程资产，而不是一次下载。
工具越来越容易拿到，判断力反而更值钱。开源模型降低了起步门槛，却没有降低把系统做稳的难度。愿意在这上面花时间的人，才可能真正用上它。