从一次内网部署说起
把权重拉到内网，在两张卡上跑通对话，这件事现在花不了多少时间。真正的分水岭出现在跑通之后：有人问，为什么同一个问题昨天答得对、今天答得偏；为什么并发一上来，延迟就像心电图；为什么法务同事盯着许可文件看了半天，说其中一段还得再确认。
开源模型给人的直觉是「拿来就能用」，实际交付时它更像一台半成品机床——主体结构给你了，夹具、刀具、保养手册要自己配。
「开源」这两个字，在不同项目里不是一回事
有的项目放出训练好的权重，训练数据、数据配比和清洗流程并不公开；有的连训练代码一并给出；还有的权重可以下载，但商用范围、再分发条件、输出内容的使用方式写在一份需要逐条读的许可里。这几种情况经常被同一句话概括，落到工程和合规上却是完全不同的工作量。
所以看到一个开源模型，值得先问三件事：能不能改、能不能商用、改了之后要不要以同样条件回馈。答案不清楚的时候，最省事的做法往往也是风险最大的做法。
成本结构藏在运维里
显存、吞吐、并发、上下文长度，这些指标在纸面上是数字，在机房里是电费和排期。为了压住延迟，通常要做量化、算子替换、批处理调度、缓存复用，每一项都要人。上游更新一版权重，之前调好的参数可能要重来一遍。这类重复劳动很少出现在宣传里，却占掉团队大半时间。
- 推理侧：量化到什么精度、精度掉了多少，得用业务数据自己量。
- 微调侧：数据从哪来、标注一致性怎么保证，比调参更耗人。
- 评测侧：公开基准和真实请求分布常常对不上，需要自建小样本集。
换句话说，开源模型省下的是授权费用，换来的是一部分自主权，代价是维护责任整体转移到自己身上。这笔交换划不划算，取决于团队有没有持续的工程投入，而不取决于模型本身多聪明。
什么时候它确实合适
数据不能出内网、请求量相对稳定、对某类任务有明确格式要求——这类场景里，可控性比通用能力更重要。反过来，需求还在快速变化、团队里没有专职做推理优化的人，先用托管服务把不确定性挡在外面，未必是保守，可能是更清醒的排期。
我的判断是：把它当成一个需要长期维护的内部组件，而不是一次性的技术尝鲜。前者需要版本管理、回归测试和明确的升级节奏；后者往往在几个月后变成没人敢动的黑盒。
边界要说在前面
权重开放不等于能力没有边界。上下文长度、多语言表现、对指令细节的敏感度，都会在具体业务里暴露出来。上线前用真实请求跑一轮，比看任何介绍都实在。
模型可以下载，能力不能下载。那些看起来免费的东西，账都记在别处。