10-06 起国产开源模型开始成批进 Amazon BedrockAWS 不是简单上架而是按模型调用量与厂商收入分成。Kimi K3 是其中之一同批还有 DeepSeek V3.2、MiniMax M2.1、Qwen3 Coder Next。同一周的另一条消息是国产开源模型 token 调用量连续第 23 周领先美国模型。这两条消息放在一起很容易被读成一个结论开源模型开始赚大钱了。但我在对账时发现它们用的是三组分母完全不同的口径混用会得出错一个量级的判断。于是我写了个账本工具openweight_share_ledger.py把三组口径分开记只对同一分母的那一对做除法跨分母的比值直接拦下来。结论先放前面份额领先不等于收入领先把 78% 的调用量份额和 4% 的收入份额放进一句话比较是量级错误。所谓「开源模型开始收租」更准确地说是「使用权重换到了调用量但单位 token 的变现能力只有全模型层平均值的约 20%」。一、为什么这件事必须拆口径「国产开源模型份额领先」这句话里至少有三个不同的「份额」口径Atoken 调用量里国产开源模型占多少分母 国产 美国两者之和口径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 的变现系数。改成usage1或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实测输出。 
长河君 · 2026/10/10 23:57:40 · 阅读 1.2k Kimi上架AWS Bedrock开源模型分成与三口径对账发布72小时，我替你试完了
10-06 起国产开源模型开始成批进 Amazon BedrockAWS 不是简单上架而是按模型调用量与厂商收入分成。Kimi K3 是其中之一同批还有 DeepSeek V3.2、MiniMax M2.1、Qwen3 Coder Next。同一周的另一条消息是国产开源模型 token 调用量连续第 23 周领先美国模型。这两条消息放在一起很容易被读成一个结论开源模型开始赚大钱了。但我在对账时发现它们用的是三组分母完全不同的口径混用会得出错一个量级的判断。于是我写了个账本工具openweight_share_ledger.py把三组口径分开记只对同一分母的那一对做除法跨分母的比值直接拦下来。结论先放前面份额领先不等于收入领先把 78% 的调用量份额和 4% 的收入份额放进一句话比较是量级错误。所谓「开源模型开始收租」更准确地说是「使用权重换到了调用量但单位 token 的变现能力只有全模型层平均值的约 20%」。一、为什么这件事必须拆口径「国产开源模型份额领先」这句话里至少有三个不同的「份额」口径Atoken 调用量里国产开源模型占多少分母 国产 美国两者之和口径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 的变现系数。改成usage1或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实测输出。