开源是一门生意：各家在图什么
六家厂商的开源策略与变现路径；衍生模型数量为什么比下载量更能说明问题
本页解决的问题
先给结论「开源是一门生意：各家在图什么」要解决的关键问题是什么？
六家厂商的开源策略与变现路径；衍生模型数量为什么比下载量更能说明问题
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
这条规律套在你自己身上是什么结论？选一个最接近你所在公司的赚钱方式看看。
下载量容易刷，榜单排名换个测法就变。行业里更看重的是衍生模型数量，也就是有多少开发者真的拿它的权重再训练出了新模型并发布出来。这个数字造不了假，因为每一个衍生模型背后都是一次真实的算力投入。
这组数字真正说明的事情是：开发者会用脚投票。他们选择在哪个底座上继续训练，考虑的是许可证是否干净、尺寸是否齐全、社区里能不能找到现成的工具链，跟宣传没什么关系。所以衍生模型数量本质上是一份长期的用户选择记录。
上面六家的策略不一样，开到什么程度也不一样。有的只开小尺寸、把最强的留在自己产品里，比如 Google 放出 Gemma、留住 Gemini；也有的把最强的那个直接开出来，比如 DeepSeek 的 R1 就是按 MIT 放的权重。所以「旗舰能不能开」没有统一答案，得一家一家看，一个模型一个模型看。
正好有一个还没落地的例子，可以用来练手。
- 总参数 2.4 万亿，激活参数 950 亿
- API 已经可用
- 官方表示权重将开源
- 截至核对日，权重还没放出来，采用什么许可证也没有公布
另外提醒一句，这个尺寸你多半跑不动。2.4 万亿参数的权重文件是数 TB 量级，本章最后那个计算器里它会显示为跑不动。「权重开放」和「你跑得动」是两件事，这一点对任何大模型都成立。
把这一节和上一节合起来用：
再看商业逻辑，判断这家会不会持续开源。靠模型直接赚钱的公司，开源策略随时可能收紧；开源是获客手段的公司，通常更稳定。
最后看生态厚度，衍生模型多、社区工具全，意味着你遇到问题时能搜到答案，出了 bug 有人已经踩过。
「六家，六种算盘」要放回选型约束
「这条规律套在你自己身上是什么结论？选一个最接近你所在公司的赚钱方式看看」说明，模型、许可证、接入方式和榜单都只是信息，不是脱离场景的答案。真正的选择取决于任务、数据边界、延迟、质量下限和运行成本。
先写淘汰条件，再看最高分
「下载量容易刷，榜单排名换个测法就变。行业里更看重的是 衍生模型数量 ，也就是有多少开发者真的拿它的权重再训练出了新模型并发布出来。这个数字造不了假，因为每一个衍生模型背后都是一次真实的算力投入」涉及的比较，至少要使用同一组真实输入，并同时观察正确性、失败方式、响应时间和费用。一个在公开榜单上领先的模型，可能因为许可证、隐私要求或峰值延迟不适合你的任务。
- 总参数 2.4 万亿 ，激活参数 950 亿
- 截至核对日，权重 还没放出来 ，采用什么许可证 也没有公布
没有测试集，就没有可靠的赢家
以「另外提醒一句， 这个尺寸你多半跑不动。」为起点，选几条真正会影响决策的输入，写下一个会改变选择的反例；这比记住一次排名更能支持下一次判断。
从「六家，六种算盘」走到「怎么衡量一个开源生态的真实影响力」
「六家，六种算盘」先把问题落在「这条规律套在你自己身上是什么结论？选一个最接近你所在公司的赚钱方式看看」上；到了「怎么衡量一个开源生态的真实影响力」，讨论继续推进到「下载量容易刷，榜单排名换个测法就变。行业里更看重的是 衍生模型数量 ，也就是有多少开发者真的拿它的权重再训练出了新模型并发布出来。这个数字造不了假，因为每一个衍生模型背后都是一次真实的算力投入」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
做模型选择时，先用真实任务写出不能妥协的条件，再用同一组输入比较质量、失败方式、延迟、许可和成本；榜单只适合作为起点。
- 「六家，六种算盘」：这条规律套在你自己身上是什么结论？选一个最接近你所在公司的赚钱方式看看
- 「怎么衡量一个开源生态的真实影响力」：下载量容易刷，榜单排名换个测法就变。行业里更看重的是 衍生模型数量 ，也就是有多少开发者真的拿它的权重再训练出了新模型并发布出来。这个数字造不了假，因为每一个衍生模型背后都是一次真实的算力投入
- 「最后的要点」：截至核对日，权重 还没放出来 ，采用什么许可证 也没有公布
最后的「最后的要点」把讨论落到「截至核对日，权重 还没放出来 ，采用什么许可证 也没有公布」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。