10-06 起，国产开源模型开始成批进 Amazon Bedrock，AWS 不是简单上架，而是按模型调用量与厂商收入分成。Kimi K3 是其中之一（同批还有 DeepSeek V3.2、MiniMax M2.1、Qwen3 Coder Next）。
同一周的另一条消息是：国产开源模型 token 调用量连续第 23 周领先美国模型。
这两条消息放在一起，很容易被读成一个结论：开源模型开始赚大钱了。但我在对账时发现，它们用的是三组分母完全不同的口径，混用会得出错一个量级的判断。于是我写了个账本工具openweight_share_ledger.py，把三组口径分开记，只对同一分母的那一对做除法，跨分母的比值直接拦下来。
结论先放前面：份额领先不等于收入领先；把 78% 的调用量份额和 4% 的收入份额放进一句话比较，是量级错误。所谓「开源模型开始收租」，更准确地说是「使用权重换到了调用量，但单位 token 的变现能力只有全模型层平均值的约 20%」。
一、为什么这件事必须拆口径
「国产开源模型份额领先」这句话里，至少有三个不同的「份额」：
- 口径A：token 调用量里，国产开源模型占多少（分母 = 国产 + 美国两者之和）；
- 口径B：开放模型在全模型层里，使用份额 vs 收入份额（分母 = 全部模型层，这一对才可比）；
- 口径C：权重下载量里，中国模型占多少（分母 = 全球下载量）。
三者的分母各不相同。把口径A的 78% 和口径B的 4% 直接相减或相除，等于把「苹果占水果篮的比例」和「苹果占蔬菜篮的比例」做比较。数字看着都落在 0 到 100 这个区间，但根本不是同一个集合。
当年我第一次看这两组数据时，差点就把「78% 调用量 vs 4% 收入」写成「开源模型被严重低估」。直到我把分母写出来，才意识到这是两个互不相关的比例，相减没有意义。工具存在的理由，就是把这个「差点写错」固化成一道闸门。
二、三口径跑出来的真实账
工具内置了一份演示数据（全部来自公开报道，分母已在字段名里写清），直接跑：
python openweight_share_ledger.py实测输出如下（来源：本机openweight_share_ledger.py默认 DEMO 数据）：
============================================================================== 口径 判定 值 ------------------------------------------------------------------------------ 口径A token 调用量（分母=国产+美国） OK 78.0% 注: 只是两个集合的相对量，不等于市场份额 口径B 使用份额→收入份额（分母=全模型层，可比） OK 0.20（约 1/5.0） 注: 单位 token 变现能力相对全模型层平均值的倍数 口径C 权重下载量（分母=全球下载量） OK 41.0% 注: 下载量衡量关注度，不衡量使用与收入 ------------------------------------------------------------------------------ 跨分母比值: REFUSED 口径「口径A token 调用量」与「口径B 使用份额」分母不同，做比值会造出量级错误，拒绝计算。 ============================================================================== 口径A 读数: 57.46 万亿对 16.20 万亿 ⇒ 国产开源占这两者之和的 78.0%。 口径B 读数: 约两成使用量只换来约 4% 的模型层收入 ⇒ 变现系数 0.20。 也就是说，开放模型每生成一个 token 拿到的钱，约为全模型层平均值的 20%。 提醒: 口径A 与口径B 分母不同，禁止把 78% 与 20% 放在一句话里比较。 连续领先周数: 23 周；DeepSeek 占文本请求 21.8%；中国模型占 HF 下载 41.0%。三行读下来，中间那行是整份账的关键：开放模型拿到约两成（20%）的使用量，却只换到约 4% 的模型层收入，变现系数是 0.20。换句话说，开放模型每生成一个 token 拿到的钱，只有全模型层平均值的大约五分之一。
这恰好解释了「Kimi 上架 Bedrock、AWS 按调用量分成」这件事的真实体量：分成是按调用量计的，而开放模型的调用量虽大、单位变现却低，落到厂商口袋里的，远没有「份额领先」看着那么可观。
三、完整可复制命令
工具不联网、不依赖第三方库，三步即可复现：
# 1. 先跑自检，确认账本本身可靠（15 项正控/负控/边界）python openweight_share_ledger.py--selftest# 2. 用内置演示数据看三口径长什么样（即上面的输出）python openweight_share_ledger.py# 3. 换成你自己的数据：把字段写进一个 JSONpython openweight_share_ledger.py--datamy_share.json第 3 步的my_share.json字段全可选，缺哪个哪个口径就报 UNKNOWN，不会被默认成 0：
{"china_open_token_wan_yi":57.46,"us_token_wan_yi":16.20,"open_usage_share_pct":20.0,"open_revenue_share_pct":4.0,"china_hf_download_share_pct":41.0,"deepseek_text_request_pct":21.8,"leading_weeks":23}自检的输出值得单独贴一下，它把「工具自己可不可信」也变成可验证的：
[正控] 可算的必须算出来，且能被反算回去 [PASS] 口径A 占比应约 78.0%，实得 78.0% [PASS] 变现系数应为 0.20，实得 0.19999999999999998 [PASS] 反算 m*usage 必须回到 revenue [负控] 缺输入必须 UNKNOWN，不许用 0 顶上 [PASS] 口径A 缺国产 ⇒ 必须 UNKNOWN [PASS] 口径B 缺收入份额 ⇒ 必须 UNKNOWN [负控] 跨分母比值必须被显式拒绝（这是本脚本存在的理由） [PASS] 跨分母比值必须 REFUSED自检结果：全部通过，失败 0 项。
四、工程取舍：为什么跨分母比值必须被拒
核心取舍只有一条：可比值必须同分母，否则宁可不算。
我没有把三个口径塞进一个「综合得分」，而是让compare()在跨分母时直接返回REFUSED。理由是：一旦允许「78% 调用量份额」和「4% 收入份额」做减法，下一个写报告的人就会自然写出「开源模型被低估 74 个百分点」。而 74 个百分点这个东西在数学上根本不存在。
另一条取舍是变现系数做成可反算的自洽量。口径B 的变现系数定义为收入份额 / 使用份额，自检里专门有一项m*usage 必须回到 revenue，确保这个系数不是拍脑袋的展示数字，而是能从原始数据推回去的。否则系数好看、原始数据对不上，比没有系数更危险。
五、三个真踩过的坑
坑一，把「两个集合的相对量」当「市场份额」。口径A 的 78.0% 是「国产开源 token」在「国产+美国」两者之和里的占比，它甚至没把欧洲、其他地区的模型算进分母。第一次我差点把它写成「国产模型占全球 78%」，还好字段名china_open_token_wan_yi提醒了我分母是两者之和。
工具里这一行专门标注了「不等于市场份额」。
坑二，缺数据用 0 顶上。一开始我想「缺收入份额就当它 0」，结果沦落成「开放模型收入占比 0%」这种耸动但错误的结论。后来改成：任一输入缺失，相关结论报 UNKNOWN，绝不参与任何比值。自检里专门验了「全 0 分母 ⇒ UNKNOWN」「使用份额为 0 ⇒ 拒绝计算」。
坑三，越界值被当成正常数据。某次喂了「使用份额 120%」（明显是统计口径串了），旧逻辑会算出大于 1 的变现系数。改成：usage>1或revenue越界直接 UNKNOWN。判定值本身也需要被验证，否则一个坏判据会把所有数据判错，而且错误方向完全一致，看上去特别可信。
六、另一个角度：份额领先不等于商业成功
需要警惕的是，上面的「开源模型开始收租」读起来很正面，但它掩盖了两个反面证据。
其一是口径B 的 0.20 变现系数本身：约两成使用量只换来约 4% 收入，说明开放模型的单位 token 变现能力显著低于闭源模型。Bedrock 的分成是按调用量计的，调用量大、单价低，落到厂商口袋的并不随份额线性放大。
其二是使用份额 ≠ 收入份额这个更一般的结论：OpenRouter 同周数据里，开放模型约占两成使用量，却只拿到约 4% 的模型层收入。所以「连续 23 周领先」值得记，但它衡量的是使用热度，不是商业回报。
对下单 Bedrock 的团队来说，准入检查（参考同日另一篇《DeepSeek 开源权重上线前必查 6 个坑》）比「份额叙事」更该优先做，因为前者是你能控制的，后者不是。
所以从工程视角，更稳妥的判断是：开源权重在分发和成本上确实拿到了位置，在收入结构里还在补齐。Kimi、DeepSeek、Qwen3、MiniMax 上架 Bedrock 是真实进展，但把它翻译成「国产开源赚翻了」，还差至少一组同分母的收入口径。
七、怎么用这份账
三步，全程本地：
# 1. 先跑自检，确认账本本身可靠（15 项控制）python openweight_share_ledger.py--selftest# 2. 看内置三口径演示python openweight_share_ledger.py# 3. 换成你自己的发布/分成数据python openweight_share_ledger.py--datamy_share.json用这份账时只有一句建议：只比较同一分母的那一对；跨分母的数字，让它留在 REFUSED。把「78%」和「4%」写进同一句比较，正是这份工具要拦下的事，也是它存在的全部理由。
- 你们在评估开源模型上云时，更看重调用量份额，还是单位 token 的变现能力？
- 如果 AWS 按调用量分成，你们会怎么把这 0.20 的变现系数算进成本账？
- 你手上的模型接入数据里，经常被混用的是哪两个口径？
欢迎在评论区把你们的分母写出来，我挑几个典型的一起算一遍。
数据与事件来源
- GLM-5.3 于 10-06 接入 Amazon Bedrock、AWS 按调用量与厂商收入分成；AWS 平台已接入 6 个中国开源权重模型（DeepSeek V3.2、MiniMax M2.1、Qwen3 Coder Next、Kimi K3）：财联社与 China Daily 转述，两处口径一致。
- OpenRouter 周度数据，国产模型 57.46 万亿 token 对约 16.2 万亿，连续第 23 周领先，DeepSeek 占文本请求 21.8%，开放模型约占两成使用量对应约 4% 模型层收入：OpenRouter 周数据与 China Daily 转述，交叉核实一致。
- Hugging Face 中国模型占过去一年下载量约 41%：Hugging Face 公开统计转述。
- 三口径读数、变现系数 0.20、跨分母 REFUSED 与 15 项自检：本机
openweight_share_ledger.py默认 DEMO 与--selftest实测输出。
空间扫描全解析)
