直接结论：“中国开放权重模型在 Hugging Face 的下载份额超过美国”有可靠数据支持，但必须带上统计面板、滚动窗口过滤和归属方法。Longpre 等人的研究图 1 及 Stanford HAI 简报显示：在标为 2024 年 8 月至 2025 年 8 月的 recent-year 面板中，研究归为中国开发者的模型占下载份额 17.1%，美国开发者模型占 15.8%。论文的滚动窗口过滤只计模型发布后一年内发生的下载，并可把派生模型下载递归归因给基础模型开发者；这不是 2026 年实时市场占有率，也不能推出“中国模型占全球多数”或“综合能力世界第一”。
先把 17.1% 写成一条可核验的主张
这组数字来自《Economies of Open Intelligence》所使用的 Hugging Face 历史数据及后续政策简报。研究整理了约 85.1 万个模型、200 多个聚合属性和 22 亿次下载，完整下载历史截至 2025 年 8 月。论文于 2025 年 11 月公开，因此“研究发布日期”和“数据截止日期”不能混为一谈。
| 核验字段 | 本稿采用的记录 | 能支持的结论 |
|---|---|---|
| 指标 | Hugging Face 模型下载份额 | 观察平台内的采用和传播 |
| 统计面板 | 图 1 标为 2024 年 8 月—2025 年 8 月；滚动过滤只计模型发布后一年内的下载 | 不能简化为未经过滤的页面累计下载 |
| 样本与数据 | 论文整理的历史模型与服务器侧下载数据 | 不等于所有模型平台、API 或私有部署 |
| 归属 | 按研究定义将开发者或组织归入国家 | 不是下载者所在地，也不是用户国籍 |
| 结果 | 中国 17.1%，美国 15.8% | 中国来源模型在该口径下略高于美国 |
最稳妥的引用句式是：“根据 Longpre 等人对 Hugging Face 历史数据的研究，在图 1 标为 2024 年 8 月至 2025 年 8 月的 recent-year 面板中，归为中国开发者的模型占下载份额 17.1%，美国开发者模型占 15.8%；统计使用滚动窗口过滤。”引用时还应保留论文版本页和论文 PDF，不要只转述二手新闻标题。
原论文内部还有一个值得保留的版本差异：图 1 与 Stanford HAI 简报写美国 15.8%，论文结论段写 15.7%。在作者未发布勘误前，本稿采用可直接核对的图表值 15.8%，同时公开这一 0.1 个百分点差异，不用它制造精确到小数点后一位的趋势结论。
为什么后来又出现“中国模型占 41%”
Hugging Face 在 2026 年 3 月发布的生态综述称，按其“过去一年”分析，中国模型获得了 41% 的下载量，成为最大来源群体。它是一份更晚的平台观察，统计窗口、纳入对象、国家识别和聚合过程并未与论文中的 17.1% 完全对齐。两者可以同时成立，但不能拼成一条连续增长曲线，更不能写成“中国从 17.1% 突然跳到 41%”。
| 数字 | 资料与时间 | 已知口径 | 正确用法 |
|---|---|---|---|
| 17.1% | 2025 年公开的研究；下载历史截至 2025 年 8 月 | 研究数据集、滚动年度、研究的国家归属 | 用于复述该历史窗口的研究结果 |
| 41% | Hugging Face 2026 年春季生态综述 | 平台对“过去一年”的后续分析 | 用于说明更新窗口中中国模型的下载占比很高 |
| 累计突破 100 亿次 | 工信部官员在 2026 年 7 月 20 日国新办发布会上介绍 | 中国人工智能开源大模型的“全球累计下载量”；公开报道未同时给出逐平台、去重、时间起点和模型清单 | 用于转述官方发布的累计规模，不能换算成 Hugging Face 份额或独立用户数 |
| 不可直接计算 | 三组资料之间 | 没有公开的同口径时间序列或统一累计口径 | 不能据此计算增速、百分点变化或预测未来份额 |
“累计下载量突破 100 亿次”为什么也不能和 17.1% 直接换算
2026 年 7 月 20 日，工信部总工程师王卫明在国新办发布会上介绍，中国人工智能开源大模型全球累计下载量突破 100 亿次。人民网对发布会的报道可以确认这句官方表述，但公开报道没有同时提供逐平台分项、统计起点、模型清单、派生模型归因、重复请求处理或独立下载者数量。因此，这个数字适合说明累计传播规模，不足以复算本文的 17.1%，也不能证明有 100 亿名用户。
三组数字回答的是不同问题：17.1% 是特定历史面板中的份额，41% 是 Hugging Face 后续生态综述的另一版本，100 亿次则是官方发布的全球累计下载量。百分比需要明确分母，累计值需要明确起点和计数规则；在底层明细没有公开对齐前，把三者拼成“从 17.1% 增至 41%，累计用户 100 亿”属于方法错误。
遇到两个不同份额时怎样判断能否比较
比较两个百分比前，应先做“版本差异卡”，而不是先做减法。只有时间窗口定义、平台范围、仓库样本、下载计数、国家归属、派生模型处理、未知样本和分母都一致，才可能把两个点放进同一时间序列。只要其中一项未知，就应把它们写成两个独立观察，不能计算“增长了多少倍”或“提高了多少个百分点”。
| 对齐项 | 必须回答的问题 | 不一致时怎样写 |
|---|---|---|
| 时间窗口 | 自然年、过去 12 个月还是模型发布后一年 | 分别标注窗口，不画连续趋势线 |
| 平台范围 | 只含 Hugging Face 还是包含 API、镜像和私有部署 | 限定为平台内观察 |
| 样本门槛 | 是否排除低下载、私有、删除或缺失仓库 | 披露纳入数量与排除规则 |
| 下载定义 | 页面累计值、请求日志还是去重下载 | 不用同一个“下载量”词掩盖差异 |
| 国家归属 | 按组织、总部、作者机构还是基础模型来源 | 保留跨国和未知类别 |
| 派生关系 | 微调、量化和合并模型是否递归归因 | 分别报告直接份额与归因份额 |
| 分母 | 其他地区、个人开发者和未知是否保留 | 同时公布分母与未知占比 |
| 精度 | 原始值还是四舍五入后的展示值 | 避免用 0.1 的差异制造确定趋势 |
以本文两组数字为例，17.1% 来自论文图表中明确描述的方法面板，41%来自平台后续生态综述。现有公开材料不足以证明两者使用完全相同的样本和聚合代码，因此最稳妥的结论是“两个不同版本都显示中国来源开放模型的下载采用度较高”，而不是“份额在几个月内从 17.1% 增长到 41%”。如果未来作者或平台公开同口径时间序列，应新增一张版本记录，再计算变化；不能回头覆盖历史引用。
Hugging Face 2026 年春季综述还指出，独立或非机构开发者在 2025 年获得的下载份额上升到 39%。这进一步说明“公司所属国家”和“社区开发者来源”会改变分母与分类，不能把所有模型简单塞进中美二分法。
Hugging Face 的一次“下载”究竟是什么
下载量不是注册用户数。根据 Hugging Face 的模型下载统计文档，平台在服务器侧选择能够代表模型加载的查询文件计数；默认可能是 config.json，不同库也可能使用 pytorch_model.bin、adapter_config.json 等文件。对这些文件的 GET 和 HEAD 请求都会计入。GGUF 等格式有自己的规则，完整克隆仓库在特定情形下还可能重复计数。
| 可能发生的动作 | 下载数可能怎样变化 | 为何不能等同独立用户 |
|---|---|---|
| 同一开发者在多台机器部署 | 多次请求并累计 | 一个人或一个团队产生多次下载 |
| CI/CD 反复构建镜像 | 可能持续拉取查询文件 | 自动化任务不是新增用户 |
| 企业缓存后供多人使用 | 外部下载可能只有一次 | 一次下载可服务许多内部用户 |
| 仓库包含多个 GGUF 文件 | 下载多个文件可能分别计数 | 格式选择会改变统计结果 |
| 私有镜像或离线复制 | 后续使用通常不回传平台 | 真实使用量可能高于平台请求量 |
因此，下载量最适合回答“模型在该平台被获取和部署得有多活跃”，不适合独立回答“有多少人使用”“产生多少收入”或“在生产环境调用多少次”。需要独立下载者、排除 CI/CD 或更细粒度去重时，必须使用请求级日志和额外规则，而不是直接读取公开累计数字。
一份可复现的下载份额快照需要什么
如果团队要自行更新份额，不能只在模型榜单上抄下几个累计数字。最低可复现包应保存查询时间与时区、仓库清单、每个仓库的开发组织与国家归属依据、基础模型和派生模型关系、下载计数窗口、缺失值处理、去重代码以及最终分母。原始快照应只读保存，清洗后的表格与绘图脚本则使用版本控制；修订归属时生成新版本，不覆盖旧结果。
还要预先决定如何处理被删除或改名的仓库、组织迁移、重复镜像、同一模型的多种量化格式和无法归属的个人账号。若研究使用平台内部去重数据，公开复现者通常无法用页面累计值完全还原结果，此时应明确写成“方法复核”而不是声称逐项复算成功。最有价值的透明度不是给出更多小数位，而是让读者知道每个数字从哪个快照、经过哪些规则得到。
对外发布时建议同时提供三层材料：正文只保留结论和边界；方法附录记录字段、规则与异常；机器可读表格保存分子、分母和版本。这样后续出现 41% 或其他新数字时，可以逐项比较口径，而不是把不同报告的标题拼接成趋势。
怎样从仓库快照计算下载份额
最基础的份额公式是“目标组在同一窗口、同一计数规则下的下载数 ÷ 全部纳入样本的下载数”。真正困难的不是除法，而是确定哪些仓库属于目标组、哪些下载进入窗口、派生模型是否回归基础模型，以及未知归属是否保留在分母中。任何一项规则变化，都可能让结果发生显著变化。
| 计算步骤 | 必须冻结的输入 | 最低检查 | 错误做法 |
|---|---|---|---|
| 定义分析窗口 | 起止时间、时区、数据截止时间 | 所有仓库使用同一窗口 | 把累计下载与最近一年下载混算 |
| 建立仓库清单 | 仓库 ID、组织、创建时间、基础模型关系 | 记录删除、改名与镜像 | 只抄排行榜前几十名 |
| 确定归属 | 组织与国家映射、跨国和未知规则 | 人工复核高下载仓库 | 根据用户名、语言或服务器位置猜测 |
| 处理派生模型 | 直接归属或递归归因规则 | 避免同一下载同时计入两组 | 结果出来后再选择更好看的算法 |
| 应用下载过滤 | 查询文件、去重、最低下载量与滚动窗口 | 分子、分母使用同一规则 | 用公开累计值假装复现内部请求日志 |
| 输出结果 | 分子、分母、份额、未知占比和版本 | 保留未四舍五入值与代码 | 只发布一个百分比截图 |
如果使用公开接口更新当前仓库清单，可参考 Hugging Face Hub 的仓库搜索指南记录筛选、排序、分页和返回字段。但公开 API 能帮助冻结仓库元数据，不等于能够重建论文使用的全部服务端下载日志、去重结果与历史归属。复现报告必须明确标注“完全复算”“近似复算”或“只复核方法”中的哪一种。
一张结果表至少要公布什么
| 字段 | 例子 | 为什么重要 |
|---|---|---|
| snapshot_id | 2025-08-31-v1 | 让同一快照能够重复读取 |
| window | 2024-08 至 2025-08 | 区分累计值、自然年和滚动年度 |
| attribution_rule | 开发者归属/递归基础模型归因 | 解释派生仓库落到哪一组 |
| numerator | 目标组合格下载数 | 百分比必须有可审计分子 |
| denominator | 全部合格下载数 | 防止把未知、社区或其他地区悄悄删除 |
| unknown_share | 无法可靠归属比例 | 显示分类不确定性而不是强行补齐 |
| code_commit | 分析脚本提交哈希 | 让规则修改可追踪和回滚 |
国家归属不是下载者所在国家
17.1% 描述的是模型来源侧归属，而不是中国网民贡献了 17.1% 的下载。国家标签可以依据公司总部、主要研发组织、仓库所有者或论文作者机构建立；跨国团队、个人账号和社区派生模型则可能没有唯一答案。严谨的分析应公开归属表，并允许“跨国”“未知”或“无法可靠判定”。
| 边界案例 | 可采用的处理 | 常见误读 |
|---|---|---|
| 中国公司在海外组织账号发布 | 按开发组织而非账号域名归属 | 把托管位置当作模型来源 |
| 海外开发者微调 Qwen | 区分基础模型来源与派生仓库作者 | 所有 Qwen 派生模型都算中国开发者 |
| 跨国研究团队共同训练 | 标记跨国或按预先公开规则处理 | 任选一名作者国籍决定全部归属 |
| 组织信息不完整 | 保留未知，不强行补齐 | 根据用户名或语言猜测国家 |
这也解释了为什么 17.1% 与 15.8% 相加不是 100%：研究还包含其他国家和地区的开发者、跨国组织、无法可靠归属的仓库以及不同类型的社区项目。Stanford HAI 的中国开放权重生态简报适合核对这组份额与政策背景，但引用者仍应回到原论文确认方法。
Qwen 为什么会成为关键变量
Qwen 提供不同参数规模、语言、代码和多模态模型，并形成大量微调、量化与适配仓库。完整的尺寸覆盖、持续迭代和主流推理框架适配，让同一模型家族可以服务端侧、工作站和数据中心。Hugging Face 对中国生态的后续观察也显示，DeepSeek、Qwen 等组织在全球社区有很高关注度。
但“Qwen 派生模型超过多少万个”必须注明查询方法和日期。只统计明确的 base_model 关系、统计名称或标签包含 Qwen 的仓库、以及把所有量化文件都视为独立模型，会得到不同结果。实时数量可在Qwen 官方组织页和Hugging Face 模型列表查询，但当天页面不能替代冻结的历史数据。
想继续梳理基础模型、微调、量化和开放权重之间的关系，可从站内的AI 概念专题进入已完成复核的解释页；需要查找模型平台和工具入口时，可使用AI 工具导航。无论从哪个入口下载，都要回到具体仓库的模型卡、许可证和提交版本，不能只凭平台或榜单名称判断可用性。
生态热度怎样转成自己的模型候选集
下载份额适合作为“值得进一步看”的发现信号，不适合作为自动采购规则。团队可以先用下载、衍生仓库和文档活跃度发现候选，再按任务质量、许可证、硬件、推理服务和维护状态逐层淘汰。需要托管 API 时，可用Cohere 模型与产品栈选型指南对照服务边界；关注推理延迟与吞吐时，可参考Groq LPU 推理架构指南；计划训练或大规模微调时，可阅读Megatron Core 分布式训练指南核对并行与显存约束。三类方案回答的问题不同，不能用同一下载榜替代。
| 筛选阶段 | 要回答的问题 | 可使用的证据 | 淘汰条件 |
|---|---|---|---|
| 生态发现 | 哪些模型家族值得进入长名单 | 下载趋势、派生仓库、文档与社区活跃度 | 仓库失效、来源不明或版本无人维护 |
| 权利审查 | 能否用于目标业务与再分发 | 许可证全文、模型卡、数据与出口限制 | 关键用途不允许或义务无法履行 |
| 离线质量 | 是否解决真实中文任务 | 冻结测试集、基线、盲评与失败样本 | 关键字段错误或低于现有方案 |
| 系统性能 | 目标硬件能否稳定运行 | 显存峰值、吞吐、P95 延迟和并发 | 超出成本、时延或稳定性预算 |
| 上线治理 | 错误发生时能否发现和回滚 | 日志、版本、权限、人工接管与回滚演练 | 无法追踪版本或高风险动作不能撤回 |
例如，同一模型家族的基础权重、指令微调、量化版和社区合并版可能共同推高下载量，但它们的许可证、上下文长度、推理精度、远程代码和内存需求并不相同。选型记录必须落到完整仓库名、提交哈希与文件哈希；“我们使用 Qwen”或“我们选择热门国产模型”都不足以支持复现、漏洞响应和回滚。
下载份额为什么不是能力排行榜
下载量会同时受到性能、参数大小、许可证、量化版本、教程数量、中文支持、框架适配、缓存更新和自动部署影响。研究者对 Hugging Face 的另一项大规模分析发现，模型下载高度集中，大量仓库几乎没有下载；详情可核对Hugging Face 模型开发研究。因此，少数热门家族足以显著改变国家份额。
这组数据支持的稳健结论是：中国开放权重模型在全球开发者生态中的采用度显著上升，并在研究窗口内的 Hugging Face 下载份额上略高于美国来源模型。它不支持“整体 AI 能力全面领先”“美国模型失去用户”或“Qwen 在每项任务都最佳”等延伸判断。
开放权重也不自动等于开源
能够下载权重，只说明取得了模型参数，不保证训练数据、训练代码、评测过程和完整许可权利都开放。开放源代码促进会的开放源代码 AI 定义要求用户拥有使用、研究、修改和分享系统所需的充分信息；而OECD 关于 AI 开放性的报告也强调开放存在多个组件和层次。
许可证字段存在也不代表可以无条件商用。Hugging Face 的模型卡文档建议披露模型用途、限制、训练信息、数据集和评测结果，并允许在元数据中声明标准或自定义许可证。选型者仍需打开许可证全文，核对地域、规模、用途、再分发和衍生模型义务。
开发者如何把“热门”变成可复现选型
| 验收项 | 最低证据 | 不通过时的动作 |
|---|---|---|
| 版本身份 | 仓库、提交哈希、权重哈希、下载日期 | 固定版本后重新测试 |
| 许可证 | 许可证全文与业务用途逐条映射 | 法务确认或换用限制更清楚的模型 |
| 模型卡 | 用途、限制、训练信息、评测与基础模型关系 | 把缺失信息列为供应链风险 |
| 任务质量 | 自有中文测试集、基线、评分规则和失败样本 | 不得用公开下载排名替代验收 |
| 部署成本 | 显存、吞吐、首 Token 延迟、并发与单位请求成本 | 尝试量化、缩小模型或更换推理栈 |
| 安全边界 | 远程代码、依赖、序列化格式和镜像来源审计 | 隔离运行，禁止未审查远程代码 |
| 上线表现 | 成功率、人工接管率、投诉、漂移和回滚记录 | 降级或回滚，不以下载量辩护 |
选型时先使用本节表格定义任务、权利、版本和硬件约束，再用已完成编辑复核的训练与优化器基础理解微调差异。对于会调用工具或自动执行动作的生产系统，还应参考AI 智能体治理指南设置权限、审批、追踪和回滚。真正的选型结论应来自自己的版本、硬件和数据，而不是某一天的下载榜。
读者可以怎样复核这篇文章
- 从论文版本页记录标题、作者、公开日期和版本号，再下载 PDF 保存。
- 在方法与附录中确认数据截止日期、样本范围、去重和国家归属规则。
- 用 Stanford 简报交叉核对 17.1% 与 15.8%，但不让简报替代原始方法。
- 单独阅读 Hugging Face 2026 年综述，标记其“过去一年”和 41% 为另一个统计版本。
- 检查平台下载计数文档，确认请求、查询文件和 GGUF 等格式的计数边界。
- 若要更新数字，建立新快照并同时公布查询日期、代码、分母和归属表，不覆盖历史值。
看到开放模型份额新闻时的八个红旗
- 只有百分比，没有分子和分母：读者无法判断是全部下载、热门仓库，还是经过过滤的窗口。
- 只写“最新”，不写数据截止日：报告发布日期可能比统计窗口晚数月，不能当作实时值。
- 把模型来源写成用户所在地：开发组织归属和下载者所在国家是两个指标。
- 把平台下载写成市场占有率：私有镜像、API 调用、本地复制和其他平台可能都不在分母内。
- 把下载次数写成独立用户：自动构建、多机部署与重复拉取都可能增加计数。
- 把派生仓库全部算给基础模型：递归归因需要明确规则，不能在标题里悄悄完成。
- 把开放权重直接写成完整开源：仍要检查许可证、数据说明、训练代码和修改再分发权利。
- 用下载榜直接宣布能力第一：任务质量、中文边界、显存、吞吐、安全和维护状态必须独立测试。
若一篇报道同时出现以上两项以上问题，应回到论文、平台方法文档和冻结快照重新核验；在证据补齐前，把结论降级为“待确认的生态观察”，不要继续扩写成产品推荐、投资判断或国家能力排名。
常见问题
中国模型已经占全球下载量的大多数吗？
不能这样说。17.1% 不是多数；41% 也只来自 Hugging Face 后续特定分析，不等于所有平台、API、私有镜像和离线部署的全球份额。
下载一次等于一个用户吗？
不等于。同一用户、服务器或自动化流程可以多次触发请求；一次外部下载也可能经企业缓存服务许多内部用户。下载量是平台活动指标，不是独立用户数。
17.1% 与 41% 哪一个才是真的？
两者分别描述不同资料和窗口。没有对齐样本、时间、归属、分母和去重规则前，不应判断哪一个“更真”，也不能用它们计算增长率。
开放模型与开源软件完全相同吗？
不一定。模型可能开放权重，但训练数据、训练代码或许可权利并不完整开放。本文优先使用“开放权重模型”，避免把所有可下载模型笼统称为开源软件。
编辑复核与纠错记录
本文由兰塞 AI 编辑流程于 2026 年 7 月 23 日完成发布前增量复核。旧稿中的“2026 年 3 月 25 日新报告”“两个月完成反超”“平均每日 110 万次”和“欧美用户流失”等无可靠来源表述已删除；前一版把 17.1%/15.8% 归因于 ATOM 的错误已从正文和首图中一并纠正。本文补充滚动窗口过滤、递归模型归因、原论文美国份额 15.7%/15.8% 的内部差异，以及 17.1% 与 41% 的版本对照、下载计数、国家归属、开放性边界和可复现选型清单；本次又加入工信部发布的“全球累计下载量突破 100 亿次”，并明确公开资料尚不足以把累计值换算成 Hugging Face 份额、独立用户数或同口径增速。本站的来源、更新与纠错原则见关于本站与编辑规范。
