9 月上旬，钛媒体、金融界等媒体集中讨论了一个变化：国产开源大模型在出海时开始把商业回报写进许可证。本文不站队，只做三件事------把 Kimi K3、Qwen3.8-Max、GLM-5.3-Flash 的许可证条款逐条对照；说清「开放权重」和「开源」在定义上的区别；最后给做出海产品的团队一个可执行的判断。
样本来自各厂商公开的许可证文本、Hugging Face 模型页与公开报道，结论只适用于当前版本，后续条款可能变动。
一、发生了什么
三条线同时出现，方向却不一样：
- 月之暗面 Kimi K3 （7 月 17 日发布，2.8 万亿参数，单次激活约 1040 亿，100 万 Token 上下文）把完整权重放上了 Hugging Face，但许可证不是 MIT，页面上标的是
license: other（来源：金融界） - 阿里 Qwen3.8-Max（8 月 3 日发布，2.4 万亿参数，激活约 950 亿）同样开放了旗舰权重，并附加了商业门槛（来源：人人都是产品经理）
- 智谱 GLM-5.3-Flash 走的是另一条路：直接 MIT，不限商用；据金融界报道，其在国内的 API 定价约为 GLM-5.3 的十分之一
同一时间，「开源大模型出海」这件事第一次有了分歧：是继续用宽松许可换规模，还是把变现条件写进协议。
二、先厘清概念：开放权重 ≠ 开源
这是所有讨论的前提，但经常被跳过。
按 OSI 的定义，开源许可证不能对使用领域设限。而 Kimi K3 的条款限制了「商业规模以上的 MaaS 转售」，所以严格来说它属于开放权重（open weights），不是标准意义的开源。AI 研究者 Nathan Lambert 的判断也是这个口径：受 MIT 启发，但加入了明显商业限制（来源：Left Coast Logic 转载分析）。
这个区别不是文字游戏。它决定了你在做架构选型时，要看的不是「权重能不能下载」，而是「许可证在什么条件下会咬人」。
三、三条路线对照
| 模型 | 许可证 | 商业触发条件 | 展示要求 |
|---|---|---|---|
| Kimi K3 | 自定义（仿 MIT + 商业限制），非 MIT | 经营 MaaS 业务，且企业及关联方连续 12 个月营收 > 2000 万美元 → 需另外签约 | 月活 > 1 亿，或月收入 > 2000 万美元 → 需显著标注 "Kimi K3" |
| Qwen3.8-Max | 自定义（Qwen 商业条款） | 做 MaaS 或 AI 办公助手类业务，且企业及关联方连续 12 个月合计收入 > 5000 万美元 → 需单独商业许可 | 月活 > 1 亿，或月收入 > 2000 万美元 → 需展示模型名 |
| Qwen3.8-Flash-Next | Qwen Community License 1.0 | MaaS / AI 办公助手业务，无营收门槛 | 同上的展示条件 |
| GLM-5.3-Flash | MIT | 无 | 无 |
三条路线其实是三种取舍：K3 是「规模换分成」，Qwen 是「更高门槛、更广覆盖」（连办公助手类产品都纳入了），GLM 是「宽松换生态」。
三者的共同点是：限制对象都是「转售模型能力」的角色，不是终端使用者。
四、几个被反复误读的点
误读一：超过 2000 万美元就要交 30%。
错。2000 万美元是触发谈判的门槛，不是自动抽成开关。外媒提到的「最高 30%」是月之暗面对大型客户提出的具体商业条件之一，最终比例取决于谈判结果（来源：金融界对条款的澄清）。
误读二：只要用了就得付钱。
错。条款明确豁免了三类场景：企业内部自用、通过官方 API 调用、把模型能力嵌进自有产品。触发条件针对的是「向第三方提供模型推理服务」的企业。
误读三：开源要收钱了。
更准确的说法是「大规模转售要谈钱了」。普通团队下载权重、部署、微调、做自己的产品，这几条路目前都不受影响。
还有一个容易被忽略的细节：同一个模型在不同接入路径下，数据条款并不一致。据金融界报道，K3 匿名测试期间，OpenRouter 与 OpenCode 两侧对留存与训练的表述存在差异。这意味着选型时不能只看模型名，还要看走的是哪条通道。
五、我的判断：为什么卡 MaaS，为什么是现在
第一个问题：为什么限制的是 MaaS 服务商？
因为这类角色才是「用别人资产做生意」的那一环。K3 的权重放出去后，多家海外推理平台（Together AI、Fireworks、DigitalOcean、Modal、Baseten、DeepInfra 等）已经托管了它，其中不少是自建算力部署的（来源：网易）。云厂商基于开源成果直接转售套利，是开源商业化几十年来的经典难题------MongoDB、Elastic 都走过类似的路。K3 的思路只是把这套逻辑搬到了模型上。
第二个问题：为什么门槛写的是「营收」而不是「调用量」？
因为营收可查，调用量难审计。用营收当门槛还有一个好处：精准地把中小开发者排除在外，不误伤生态。
第三个问题，也是我觉得最关键的：为什么是现在？
我的判断是------Agent 让 Token 消耗脱离了用户规模。
传统对话产品里，Token 消耗大致等于「用户数 × 一个常数」。但 Agent 场景下，一个用户的一个任务可能触发几十上百次模型调用，消耗与用户数彻底解耦。据钛媒体报道，这个变化被明确列为许可证策略收紧的原因之一：当模型被拿去跑出多大的生意、已经和用户规模无关时，按人头定价的旧模型就失效了。
顺带说一句，条款能不能真正落地，取决于「谁来算、怎么审计这笔钱」。目前双方在收入拆分口径、数据访问权限、Token 用量审计上都还没有共识。所以短期内，这些条款对绝大多数团队的实际影响约等于零。
六、对出海开发者的三条准备
结论先给：现在不用慌，但该做的架构准备要做。 三件事，按优先级排：
- 建一层模型适配抽象，别把任何一家 SDK 写死进业务代码------条款会变，你的代码不该跟着变
- 维护一份许可证清单，把每个依赖模型的许可证、触发条件、展示义务记录下来，产品出海做合规时这是必备项
- 成本模型按 Token 消耗算，不按用户数算，尤其是用 Agent 的产品
第 1 和第 2 条可以合起来做成一个小工具。下面是一段可直接复用的 Python：
python
"""最小可用的模型适配层 + 许可证清单。
两个作用：
1. 业务代码只依赖 ModelSpec，不依赖任何厂商 SDK ------ 换模型不改业务逻辑
2. 把许可证条款变成可检查的字段 ------ 产品出海做合规时直接导出清单
"""
from dataclasses import dataclass
@dataclass(frozen=True)
class ModelSpec:
name: str # 对外展示用的模型名（有些许可证要求显著标注）
provider: str
license_id: str # "MIT" / "custom:k3" / "custom:qwen-community"
resale_gated: bool = False # 是否对「转售模型能力」设限
revenue_gate_usd: float = 0.0 # 触发谈判的年营收门槛（0 表示无）
display_required: bool = False # 是否有品牌展示义务
note: str = ""
REGISTRY = {
"kimi-k3": ModelSpec(
name="Kimi K3", provider="moonshot", license_id="custom:k3",
resale_gated=True, revenue_gate_usd=20_000_000, display_required=True,
note="MaaS 业务且关联方 12 个月营收超过门槛需另行签约；内部自用与嵌入自有产品豁免",
),
"qwen3.8-max": ModelSpec(
name="Qwen3.8-Max", provider="qwen", license_id="custom:qwen-community",
resale_gated=True, revenue_gate_usd=50_000_000, display_required=True,
note="MaaS 或 AI 办公助手类业务触发；门槛高于 K3，覆盖范围更广",
),
"glm-5.3-flash": ModelSpec(
name="GLM-5.3-Flash", provider="zhipu", license_id="MIT",
note="无商用限制",
),
}
def compliance_check(spec: ModelSpec, *, is_maas: bool,
annual_revenue_usd: float) -> dict:
"""判断当前业务形态是否会触发商业许可义务。
注意：这是工程侧的自查工具，不构成法律意见；正式出海前请以许可证原文为准。
"""
gated = spec.resale_gated and is_maas and annual_revenue_usd > spec.revenue_gate_usd
return {
"model": spec.name,
"license": spec.license_id,
"需另行签约": gated,
"需展示模型名": spec.display_required and annual_revenue_usd > 20_000_000,
"说明": spec.note,
}
if __name__ == "__main__":
# 典型场景：中小团队把模型嵌进自家产品（非转售），不触发任何门槛
for key in REGISTRY:
print(compliance_check(REGISTRY[key], is_maas=False,
annual_revenue_usd=5_000_000))跑一遍就会看到：中小团队的自用/嵌入场景全部输出「需另行签约: False」。这就是为什么现在不用慌------真正的门槛在千万美元营收量级，不是技术门槛，是商业规模门槛。
七、FAQ
Q1：把开源模型部署后通过 API 卖给别人，算 MaaS 吗？
通常算。这类「转售模型推理能力」正是条款要约束的行为，是否触发取决于你的营收规模是否越过门槛。
Q2：用自己的数据微调后拿去做产品，受影响吗？
按目前条款，把模型能力嵌进自有产品一般不触发，但这取决于你是在「提供模型服务」还是「用模型增强自己的产品」。边界模糊时建议对照许可证原文。
Q3：怎么确认某个模型的许可证到底是什么？
不要看文章转述，去看 Hugging Face 模型页的 license 标签和仓库里的 LICENSE 文件。标注为 other 的，一律要读原文。
Q4：现在选型应该优先选哪种许可证？
取决于你的业务形态：自用和嵌入产品选哪条路线差别不大；如果你计划做模型服务转售，优先选 MIT / Apache 2.0 这类无限制许可，或者提前把商业谈判纳入规划。
一句话总结：这一轮变化的本质不是「开源收费」，而是「开放权重 + 规模分成」。 门槛在千万美元营收量级，对绝大多数团队来说是零影响；但「模型可替换」和「许可证清单」这两件事，现在做比事后补要便宜得多。
专注 AI 工程化实践与出海外贸技术