不少团队接触开源模型，是从一个很轻的动作开始的：下载权重，照着说明跑通示例，再把接口接到内部工具上。演示很顺，讨论也容易停在“能不能用”。可一旦写进采购清单，问题会换一种形态出现——它不再是一次试跑，而是一项要维护、要解释、要交接的长期资产。
许可证不是页脚文字
使用“开源”不等于没有约束。权重、代码、训练数据说明、商用条款往往分开授权，有些限制写在模型卡里，有些藏在附带文件里。采购前如果只问“能否商用”，容易漏掉再分发、署名、衍生模型命名等要求。稳妥的做法是把许可证当成合同附件来读：谁负责合规判断，什么场景需要复核，升级版本后条款是否变化，都应留下可追踪的记录。
版本会动，接口也会动
一个模型在试用阶段表现稳定，不代表半年后仍能原样复现。上游可能调整推理代码、默认参数或分词器，社区也可能出现新的微调分支。企业需要把版本冻结、回归测试和回滚机制放进日常流程，而不是把某个版本当成固定答案。否则，业务方感知到的“效果波动”，最后都会变成工程团队的救火任务。
评测要贴着场景走
公开评测能提供参照，但它回答不了内部流程里的具体问题：合同摘要能否保留关键条件，客服回复是否遵守话术边界，代码补全能否避开内部禁用写法。评测集应从真实任务里抽样，覆盖长尾输入、边界表达和失败后的兜底。评分不只看答对多少，也要看拒答是否合理、输出是否稳定、人工复核成本是否可控。把评测做成一次性报告，价值有限；把它变成每次升级都要跑的检查项，才接近实际。
算力之外，还有人的成本
部署开源模型常被理解成节省调用费用，但账不能只算在显卡上。模型服务需要监控、日志、限流、权限隔离和安全策略；业务侧需要提示词维护、知识库更新和异常反馈。容易被低估的是交接成本：当试跑的人离开，后来者能否看懂配置、复现结果、判断一次失败是数据问题还是模型问题。把这些工作提前写进责任表，能减少演示阶段的分歧。
边界比口号重要
开源模型不是万能底座，也不是把闭源接口换掉就能解决一切。它适合那些愿意投入工程维护、对数据边界有明确要求、需要自己掌控升级节奏的团队。反过来，如果业务目标频繁变化、内部缺少维护人手，直接采用托管服务可能省心。选择之前，不妨先回答三个问题：许可证谁来复核，版本谁来冻结，失败谁来兜底。答案不清楚，下载再多权重也只是把问题推迟。