“风和”开放 1060 亿参数气象服务模型，预警体系仍在模型权重之外

2023 年 3 月 18 日，北京中国气象局总部开放日，参观者聚集在楼外。N509FZ 摄。[6] 风和出自该局公共气象服务中心，预定运行环境是一套机构级数据与预警链条，独立消费级聊天机器人不在其定位之内。[1][3]

2026 年 7 月 17 日，中国气象局在上海世界人工智能大会上发布风和（FengHe）模型检查点，并发起全球开源倡议。[1][2] 从检查点本身看，开放内容可以直接核验。官方模型卡声明采用 MIT 许可证；仓库收录配置文件、分词器文件和 43 个权重分片，其索引显示权重合计 213.7 GB。这些文件已经构成可加载运行的模型发布包。[1]

名称本身还划出了职责范围。风和是一款气象服务语言模型，位于大气预报模型下游。大气预报模型把观测资料转化为次日的气压、风场和降水场；到了风和这一层，任务转为获取权威预报与预警、针对特定受众作出解释、改写成通俗语言，并在需要时连接业务工具。

这项职责分工贯穿整次发布。截至 2026 年 7 月 22 日，检查点在技术上已有相当体量，配套服务体系仍依赖数据、工具、审核和发布权限，这些部分均未包含在权重中。[1]

这次实际发布了什么

风和基于 GLM-4.5-Air。模型卡将其描述为混合专家（MoE）因果语言模型，拥有 1060 亿总参数，每个 token 的激活参数约为 120 亿，共 46 层、128 个路由专家，并配有 128K token 上下文窗口。公开检查点的权重以 BF16 为主。附带示例覆盖 Transformers、vLLM 和 SGLang，其中 vLLM 与 SGLang 的方案均采用 8 路张量并行。[1]

公开的 8 路方案也给出了仅计算权重时的内存占用参照。将 213.7 GB 权重均匀分配到 8 个并行进程，在计入键值缓存、激活值、框架开销和分配不均之前，每个并行进程（rank）约需 26.7 GB 存放权重。最低配置尚无公开实测数据：模型卡没有公布延迟、吞吐量或内存测量结果，因此这些示例适合作为启动命令，容量规划仍需另行实测。[1]

比参数规模更能说明模型用途的是领域适配。公共气象服务中心称，训练中加入了超过 5000 万 token 的气象书籍、标准、预警译文、服务报告和新闻，随后又使用 49 万条人工标注、面向具体应用的指令样本。目标能力包括服务需求理解、服务内容生成、气象推理与决策支持，以及工具调用。[1]

官方时间线对这项训练规模给出了彼此冲突的数字。2025 年 9 月的备案报道写的是 5500 亿 token；2025 年 10 月的中国气象局回顾、2026 年 7 月的发布报道和当前模型卡则都写作约 5000 万 token。[1][2][3][5] 公开文件没有解释两组数字之间的差异，本文据此沿用已发布模型卡的表述；这项语料规模本身不足以证明训练过程可以复现。

这套训练安排以气象服务工作为目标。向港口运营人员解释台风预警，需要的语言和可给出的行动建议范围，都不同于回答小学生的天气问题。风和此次发布瞄准的，正是同一份天气信息面向不同受众时的改写与交付。

预报产品与服务产品分属两段流程

中国气象局于 2024 年启动风和研发，并在 2025 年将整个系统描述为“1+1+N”：一个领域语言模型、一个负责数据接入与工具使用的智能体平台，以及多个针对具体用途的应用。中国气象局列出的应用包括公众信息服务、预警发布、能源、旅游和交通。[3]

居中的“1”承担关键衔接。智能体平台调用上游系统和权威数据，天气事实由这些来源给出。2025 年的一份实施报告列出六类已接入数据：城市实况、城市预报、预警信号、生活指数、气候极值和全球城市预报。报告还称，风和可以调用中国气象局的“风雷”（FengLei）临近预报系统和“风清”（FengQing）中期预报系统。[5]

由此看，风和检查点提供的是语言能力，接入一套解释和编排预报产品的体系。常规天气模型估算未来的大气状态；风和接收其他系统产出的天气状态或预警，再结合用户与任务，把这些依据转化为简报、风险说明、工具请求或行动建议。独立的智能体平台负责实时连接和工作流。

中国气象局给出的自驾出行案例清楚展示了这次交接：一家人从上海驾车前往白洋淀时，系统可以把雷暴发生时间和积水风险对应到避让路线与室内备选活动。[5] 语言模型负责按受众组织表达，上游预报和风险数据负责给出事实。

这项分工同时划定了安全责任。回答再流畅，也无法证明降水输入仍在有效期内、预警区域选择正确，或当地主管部门已经发布警报。这些事实必须经由周边的数据与工具层进入系统。公开检查点可以协助撰写消息，输入是否可信仍要由外部系统确认。

模型已经开放，国家级服务体系仍在发布范围之外

仓库对模型文件的交代相当完整。它收录了以 BF16 为主的全部 43 个权重分片，以及架构配置、分词器、聊天模板、生成设置、模型卡和评测图片。模型卡与仓库元数据标注 MIT 许可，但仓库内没有一份包含完整条款的独立 LICENSE 文件。硬件充足的外部团队可以检查并部署这份检查点；开展法律尽调时，应记录上述文档差异。[1]

同一份文件清单也列明了发布范围之外的材料：领域语料库、49 万条指令样本、训练代码、MetsEval 题集、生产工具 schema、接入实时权威数据的连接器，以及气象服务所用的智能体应用。公开包足以复现模型推理，却无法复现风和的训练过程或整套国家级集成服务系统。[1][3]

这里关注的是实际采用范围，“真正开源”的语义争论不会改变这项范围。开发人员今天就能加载权重并向模型输入提示词；要建立可信的气象服务，仍需补齐数据来源与流转记录、时效与空间分辨率检查、工具调用失败处理、转交人工处理的规则，以及经授权的信息发布流程。

这一区分在国际应用中同样重要。7 月的发布活动把风和与“妈祖”（MAZU）早期预警方案相连，并介绍了面向全球用户的中英文天气查询与风险分析。[2] 模型可以跨地区部署，预警发布权仍由各地制度决定。每个国家和服务机构都有自己的信息源层级、警报术语、地理编码，以及信息发布权限规则。

把 MetsEval 视作方向性证据

模型卡使用 MetsEval-1k 评测风和。该套题共 1,076 道题，覆盖四个方面：服务需求理解、服务内容生成、推理与决策支持、工具调用。配套表格显示，风和的总分高于一组通用模型。[1]

这项结果可以指明方向：风和与其目标任务的匹配度较高。独立复现仍缺少必要条件。此次发布没有提供题集、提示词、评审器设计、各模型推理设置、采样策略、评分代码或逐题输出。缺少这些材料，表格便无法拆分领域知识、提示词效应、评审器偏好、测试泄漏或不同工具假设造成的影响。[1]

下一轮评测应沿着服务链继续推进，把回答质量与以下检查放在一起。生成的建议是否引用了正确的来源时间戳？工具返回过期数据或地理位置不匹配的数据时，模型能否停止作答？审核人员能否查明每项建议所依据的观测、预报、预警和规则？系统能否始终区分官方预警与模型生成的风险解读？

这些测试比判断行文是否像气象文本更难，也更接近真实系统出错时的代价。

治理要求进入系统架构

中国的 《人工智能气象应用服务办法》 自 2025 年 6 月 1 日起施行。办法要求提供者通过合法渠道获取标注相应气象数据身份标识的气象数据，对人工智能生成合成内容加注标识，建立信息溯源机制，提高准确性与可靠性，并实施全生命周期风险管理和控制。办法还规定，提供者不得向社会发布和传播非气象主管机构所属气象台站提供的公众气象预报、灾害性天气警报和气象灾害预警信号。[4]

这项规定将来源追溯写进了系统。生产环境中的风和还要在检索插件之外，保存气象数据由谁提供、覆盖什么范围、何时失效，并标明当前输出属于信息、建议、草稿还是经授权的预警。模型卡的使用声明同样划出权限界线，其中禁止生成虚假预警和误导性气象信息。[1][4]

对工程团队而言，审慎的集成方案会分成三条通道。对话通道可以解释官方信息，同时显示来源和时间。决策支持通道可以为有资质的审核人员起草定制建议。发布通道则继续接受有关主管部门的审批以及发布与传播管理。三条通道一旦混用，语言模型的流畅表达就会披上虚假的机构权威。

哪些补充材料能让发布更易审计和部署

风和已经满足模型文件的多数基础检查项：权重公开、MIT 许可声明清楚、兼容标准加载器、架构细节有明确名称，并提供模型卡。[1] 下一批证据应让周边交接环节也能接受同样程度的检查。

第一，团队可以发布 MetsEval 的提示词、题目、裁判说明和可重复运行的评测程序。第二，可以用一个参考智能体展示预报检索、预警查询、来源记录、工具故障和人工审批所需的一组 schema，同时把敏感生产系统留在公开范围之外。第三，部署配置可以报告推荐张量并行方案的内存占用、吞吐量和尾延迟，未来如有量化版本，也应给出相应数据。

最有价值的示例会是一条端到端记录：一份权威预报带着时间戳和地理范围进入系统；工具加入经过核验的预警与风险层；风和分别为通勤者、学校和应急管理人员起草不同版本；系统同时记录每项输出可由谁审批。这条记录能说明评测分数无法回答的问题：信息进入行动环节后，谁仍掌握发布权。

这次开放让国家气象服务机构使用的一份语言模型检查点可以迁移；完整服务体系仍依赖原有的数据、工具和权限安排。模型写得是否像预报员只是表层指标。更严格的检验，是每一句有用的话都能回溯到相应的预报、工具调用、规则和责任人，并说明它为何可以安全发布。

cronfeed.work