天气预报这件事，大多数时候给人感觉是“够用就行”。但一旦进入台风季，问题就完全不同：路径偏 100 公里，受影响的城市名单、疏散范围、应急资源调配完全是两套方案。过去做一条热带气旋路径预报，传统数值预报模型要在超算上跑很长时间，而 AI 模型可以把推理时间压缩到秒级。DeepMind 的 WeatherNext 正是这一轮 AI 气象预报变革中非常有代表性的进展，它把“用 AI 做台风路径预测”从实验室研究推到了接近可用的业务形态。
这篇文章不打算复读新闻稿，而是围绕三件事展开：WeatherNext 到底是什么，它在热带气旋预报上为什么能被称为“突破”，以及如果你想在自己的环境里复现、评估甚至接入这类模型，会遇到哪些问题、应该避开哪些坑。
先给出一个明确判断：WeatherNext 真正的价值，与其说成是“AI 比传统预报更准”，不如说它把天气预报的生成方式带到了另一条技术路径上——推理成本大幅降低、集合预报可以大规模生成、全球覆盖能力更强。对开发者来说，这意味着一套完全不同的工程接入方式，也意味着要重新理解“预报产品”的验证、更新和风险控制流程。
1. WeatherNext 是什么：两个模型，一条主线
WeatherNext 是 Google DeepMind 推出的 AI 气象预报系列，官方资料里通常把它分成两个模块：WeatherNext Gen 和 WeatherNext Graph。
先看名字：Gen 是 generative 的缩写，意思是“生成式”；Graph 对应 graph neural network，也就是图神经网络。两个模块目标一致，但路线不同。
WeatherNext Graph 走的是确定性预报路线：给定过去几个时刻的全球气象场，直接输出未来某时刻的全球气象场。它的骨干结构是图神经网络，可以理解为把地球网格上的气象站点和它们之间的空间关系建成一张图，在图上做信息传递和状态更新。GraphCast 是 DeepMind 在这条路线上的前作，WeatherNext Graph 可以看作它的后续演化。
WeatherNext Gen 走的是生成式预报路线：它使用扩散模型，不是输出一个确定性的“最优预测”，而是生成多个可能的气象状态，构成一组集合预报。传统集合预报依赖物理模式的初始场扰动，成本很高；WeatherNext Gen 的做法是把“未来状态”看作一个条件生成问题，模型学习的是未来天气的分布。
用一个不太精确但容易理解的类比：Graph 像一位经验丰富的气象员，直接给你最可能的答案；Gen 像一组专家，每个人都给出自己的判断，最后你可以基于这一堆判断评估概率。
下表可以快速对比两个模块：
| 对比维度 | WeatherNext Graph | WeatherNext Gen |
|---|---|---|
| 模型类型 | 图神经网络 | 扩散模型 |
| 输出形式 | 单一确定性气象场 | 多个生成样本，构成集合 |
| 典型价值 | 快速获得高精度预测结果 | 支持概率预报和不确定性分析 |
| 更适合的场景 | 常规天气、气旋路径等确定性预测 | 极端事件风险评估、集合预报 |
| 推理成本 | 很低 | 比单一确定性模型高，但仍远低于传统集合 |
这两条线共同构成 WeatherNext 的核心能力：既能快速给出“最可能的预测”，也能通过生成多样本告诉你“预测有多不确定”。
2. 为什么说热带气旋预测是个硬骨头
要理解 WeatherNext 在气旋预测上的意义，得先知道传统方法在这个场景下的难处。
热带气旋的运动不是简单的“沿着大尺度气流走”。它受背景环流引导，又和自身强度、眼墙结构、海温、垂直风切变相互作用。不同尺度之间的耦合非常强：一个决定路径的引导气流，可能是几百公里尺度的天气系统；而气旋内部的台风眼变化，又是几公里甚至几百米尺度的过程。传统数值模式要把这些尺度都模拟出来，需要非常高的分辨率，计算量会急剧上升。
初始场敏感是另一个难题。气旋初期的位置、强度稍有偏差，路径预报就可能差出几百公里。传统做法是通过集合预报来应对这种不确定性：对初始场做一组扰动，跑几十个甚至上百个成员，然后统计路径集合。问题是每一个成员都是一次数值模拟，成本相当可观。真正在业务中，往往只能根据算力资源限制成员数量。
所以当 AI 气象模型出现时，最先被检验的场景之一就是热带气旋。原因很直接：第一，气旋路径本质上是从历史数据里能学到强统计规律的问题；第二，AI 推理成本低，可以快速生成大量样本，天然适合以集合方式补足不确定性的缺失；第三，全球再分析数据里保存了大量历史台风案例，训练数据相对丰富。
WeatherNext 相关报道的亮点正是落在这里：它的模型在热带气旋路径预测上表现突出，同时推理时间远低于传统模式。从工程视角看，这意味着你可以用很小的成本，在台风来临前快速跑完大量“what-if”场景，而不是等到超算队列排完才拿到一组结果。
但这里要泼一盆冷水：模型表现好，不等于它在任何年份、任何海域、任何强度层级的气旋上都能稳定超过传统业务模式。热带气旋样本本身存在长尾分布，强台风、快速增强这类极端案例出现频率低，AI 模型更容易在这些样本上出问题。这是后面选择工程方案时必须考虑的约束。
3. 核心原理：从物理方程到数据驱动的状态演化
传统数值天气预报（NWP）的逻辑，简单说就是用物理守恒方程描述大气运动，然后在网格上做数值求解。包括纳维-斯托克斯方程、热力学方程、辐射传输方程等。每一步求解都非常耗算力，而且网格越细，计算量增长越明显。
AI 气象模型的逻辑完全不同：不直接求解物理方程，而是学习“从过去一段天气状态到未来天气状态”的映射关系。
具体到 WeatherNext Graph，输入是过去若干个时刻的全球气象场，例如位势高度、温度、风速、湿度等变量在多个气压层上的分布。图神经网络把地球上不同位置的格点看作节点，节点之间有空间连接，通过在图上做一系列信息聚合和状态更新，模型逐步推出未来时刻的气象场。它的优势在于：图结构可以处理非均匀网格和跨区域依赖，某处气旋的发展往往和远方的高压脊、急流位置有关，传统网格卷积很难直接捕捉这种远距离联系，而图网络通过构造边可以做到。
WeatherNext Gen 则走另一条路：把预报问题建模为一个条件生成任务。它采用扩散模型——先让未来气象场逐步加噪变成随机噪声，训练时学习逆向去噪过程，推理时从一个随机噪声出发，在“过去气象场”的条件下逐步生成未来气象场。因为去噪过程带有随机性，每次生成结果都会略有不同，于是可以生成一组多样化的预测样本，形成集合。
这两个模型配合起来，解决了传统模式很难同时兼顾的问题：速度和不确定性。过去你可能要在“跑一个高精度确定性预报”和“跑几十个低精度集合成员”之间做取舍，而 WeatherNext 的 Graph 负责确定性快预测，Gen 负责大规模生成式集合。
还有一个工程上的点值得注意：这类模型通常使用 ERA5 等再分析资料训练，输入和输出都经过标准化处理。你在推理时不能直接把任意格式的观测数据丢进去，必须把输入组织成模型训练时相同的变量顺序、气压层、网格分辨率、归一化参数。很多新手复现时结果“画风不对”，问题就出在数据预处理和模型输入约定不一致。
4. AI 气象预报与传统数值预报：互补而不是替换
围绕 AI 气象预测，最常见的争论是：AI 模型会不会取代传统数值预报？
实际答案要复杂得多。
传统数值预报仍然承担着基础数据来源的角色。AI 模型的训练数据来自再分析资料，而再分析资料本身就是用传统模式把历史观测“同化”出来的。没有 NWP 长期积累的数据资产，就没有 AI 模型的训练原料。即便在推理阶段，很多 AI 模型的初始场也来自数值模式的短期预报结果，而不是直接使用原始观测。
AI 模型的真正优势体现在推理阶段的重构：一旦训练完成，它不需要在每次预测时都求解复杂方程组，而只是做一次大规模矩阵运算。这个差异让“低成本生成大量预报成员”变得可行。
那 AI 模型有什么短板？主要有三类：
一是物理一致性。AI 模型从数据中学规律，可能在统计上合理，但局部物理过程未必守恒。比如能量、质量在某些情况下可能出现不自然的偏差。这是生成式模型在气象领域要持续解决的问题。
二是极端事件外推能力。训练数据来自过去几十年，如果未来出现超过历史样本范围的气候状态，模型可能给出离谱结果。对于“五十年一遇”“百年一遇”的极端台风情景，AI 模型外推能力是存疑的。
三是可解释性。传统模式每一步都有物理量可以回溯，AI 模型的中间层很难直观解释。业务气象台要对外发布预警，必须能解释“为什么报这个路径”，这一点可能成为部署阻力。
所以更现实的工程方案是混合使用：用传统数值预报提供物理约束和初始场，用 AI 模型快速生成大集合、补充概率信息，再用人工经验做最终校准。说“替代”为时过早，说“互补”更稳妥，甚至可以说，AI 模型正在改变的是气象预报的生产链下半段：从“用算力换结果”转向“用历史数据换推理效率”。
5. 环境准备与数据获取
如果你想把类似模型跑起来，第一步不是写代码，而是确认三件事：机器、数据、模型权重。
硬件方面，这类模型的推理和训练都依赖 GPU。训练一个全球尺度气象模型需要 TPU/GPU 集群，个人基本不现实；但推理任务要轻很多，一张显存足够的 GPU 是可以跑的。如果只是理解流程，CPU 也能跑，只是慢。复现 WeatherNext 或 GraphCast 这类模型，内存和显存是主要瓶颈，因为图数据往往一次加载全量节点边信息。
Python 环境建议使用较新的稳定版本，依赖管理推荐 conda 或 venv。关键依赖一般包括 JAX 或 PyTorch、xarray、numpy、pandas 等，具体版本以保证模型权重兼容为准，不建议直接“最新版全装”，因为 JAX 生态和 CUDA 版本之间经常有隐性兼容要求。
数据方面，最常用的训练数据源是 ERA5 再分析资料。它由 ECMWF 提供，是目前公认的高质量全球气象再分析产品。获取 ERA5 需要注册并申请 CDS API 密钥，通过cdsapi库下载数据。需要注意数据许可和合规要求，只能把数据用于授权范围内的研究和开发。
模型权重方面，DeepMind 官方发布过 GraphCast 的开源实现和权重，WeatherNext 相关内容在官方博客、论文以及 HubeFace 等平台有发布入口。具体以官方渠道为准。很多第三方实现也能跑，但要特别留意权重版本和预处理逻辑是否匹配。
一次比较完整的复现流程通常包含这样的环境准备：
# 创建虚拟环境（示例，具体依赖以官方仓库 requirements 为准） conda create -n weathernext python=3.10 conda activate weathernext # 克隆官方或社区实现的开源仓库 git clone https://github.com/google-deepmind/graphcast.git cd graphcast # 安装依赖 pip install -r requirements.txt # 如果是 JAX 版本，确认 CUDA 与 jaxlib 版本匹配 python -c "import jax; print(jax.devices())"到这一步，你的环境基本就位。接下来才是真正的数据下载和模型加载。
6. 从模型下载到推理：最小实践示例
下面这段代码只用来演示通用流程，不是某个仓库的完整可运行脚本。模块名、函数签名、数据格式都以你选择的官方仓库为准。核心目的是让你理解一个 AI 气象模型的最小推理闭环长什么样。
第一步，下载历史气象数据。以 ERA5 单日数据为例，可以用 CDS API 申请：
# 安装 CDS API 客户端 pip install cdsapi # 提前在 ~/.cdsapirc 中配置 url 和 key # 然后运行下载脚本，脚本中定义变量层级、时间和区域范围 python download_era5.py下载脚本里需要注意：ERA5 数据按小时和气压层组织，变量种类多，一次全下载体积很大。做模型推理时，只需要模型输入层要求的那几个变量，不要贪多。
第二步，加载模型权重并做推理。以 GraphCast 类模型为例，调用逻辑大概是：
import xarray as xr import numpy as np # 1. 加载模型权重 model = load_weather_model("path/to/model_weights") # 具体函数名以官方仓库为准 # 2. 读取输入数据：过去若干个时刻的全球气象场 inputs = xr.open_dataset("path/to/input_era5.nc") # 需要做标准化：减去均值、除以标准差 inputs = preprocess(inputs) # 官方仓库会提供预处理函数 # 3. 推理，得到未来某个时刻的预测场 prediction = model.predict(inputs) # prediction 是包含温度、风、位势高度等多变量的数据结构这段代码的每一步都有坑。load_weather_model要正确处理模型配置和参数文件；preprocess要和训练时的标准化参数严格一致；model.predict要确认输入输出维度是否匹配。官方仓库一般会提供完整的run_demo.py入口，优先跑通 demo 再改自己的数据，性能问题排查会容易得多。
第三步，对气旋路径进行评估。假设你已经从预测场中提取了气旋中心位置序列，要和 IBTrACS 等最佳路径观测数据对比：
def haversine_distance(lat1, lon1, lat2, lon2): """计算两个经纬度点之间的大圆距离，单位 km""" lat1, lon1, lat2, lon2 = map(np.radians, [lat1, lon1, lat2, lon2]) dlon = lon2 - lon1 dlat = lat2 - lat1 a = np.sin(dlat / 2) ** 2 + np.cos(lat1) * np.cos(lat2) * np.sin(dlon / 2) ** 2 c = 2 * np.arcsin(np.sqrt(a)) return 6371.0 * c # pred_track: [(lat, lon), ...]，模型预测路径 # obs_track: [(lat, lon), ...]，观测/最佳路径 errors = [ haversine_distance(p[0], p[1], o[0], o[1]) for p, o in zip(pred_track, obs_track) ] mean_error_km = np.mean(errors) print(f"平均路径距离误差: {mean_error_km:.1f} km")路径误差是气旋预报里最直观的指标，但它不能代表全部。要全面评估，还要看强度误差、集合离散度、命中率等多个指标。
7. 运行验证：怎么判断模型输出是否合理
很多人在本地跑通模型后，第一反应是“我拿到了一堆数据，然后呢？”判断模型输出是否合理，可以从三个层次入手。
第一个层次是基本形态检查。把预测场的位势高度、温度或风速画成天气图，和对应时间的再分析资料做视觉对比。如果气象场出现明显的不连续、极端异常值、图像破碎，大概率是输入归一化不一致或权重版本错误。这个检查简单直接，能过滤大部分问题。
第二个层次是数值范围检查。计算预测场的全局统计量，例如全球平均温度、风速分布、位势高度范围，和真实气候态对比。如果模型输出的 500hPa 位势高度范围完全偏离气候值，说明模型输入出了问题，而不是模型本身差。
第三个层次是针对气旋任务的目标指标验证。如果你的目标场景是热带气旋路径预测，就不要只看全局天气图好不好看，而是要看具体的路径距离误差、集合路径离散度、对不同强度气旋的分层表现。把验证集按季节、海域、强度分组评估，很容易发现模型在哪类场景下会系统性偏弱。
举个简单例子：如果模型在强台风和快速增强个例上的路径误差显著大于平均水平，那在业务使用中就要人为提高对这类个例的警戒权重，不能简单把“平均误差小”当作结论。
运行失败时，排查顺序也有讲究。先看数据，再看模型，最后看环境。数据层面检查变量顺序、气压层、时间步长、标准化参数；模型层面检查权重版本和模型配置是否匹配；环境层面检查 CUDA、JAX 版本、显存是否足够。绝大多数第一次跑 AI 气象模型的报错，最后都回到“数据格式和模型预期不一致”这个问题上。
8. 常见问题与排查方法
以社区里复现 AI 气象模型最常遇到的问题为例，整理成一张排查表：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 启动即报内存或显存不足 | 图数据一次性加载过大，或网格分辨率设置过高 | 查看日志峰值内存，检查模型输入的网格大小 | 降低推理分辨率，或用批处理方式分块推理 |
| 输出全是 NaN 或极端值 | 输入数据标准化参数与训练时不匹配 | 对比输入数据和训练数据的均值、方差 | 使用官方提供的标准化文件重做预处理 |
| 模型权重加载失败 | 权重文件下载不完整，或 JAX/PyTorch 版本不兼容 | 检查文件完整性，对比官方要求的依赖版本 | 重新下载权重，建立固定版本环境 |
| 预测路径与真实路径系统性偏西/偏东 | 训练数据同化偏差，或区域气候特征差异 | 按海域和季节分层统计误差 | 引入区域性后处理校准，或融合多模型结果 |
| 集合成员之间差异太小 | 扩散模型采样步数不足，或温度参数偏低 | 检查采样配置，增加采样步数 | 调整采样参数，增加随机性 |
| 下载 ERA5 数据超时 | 数据量过大或服务端排队 | 缩小时间范围，拆成多个小任务下载 | 按日和层级拆分下载，合并后再处理 |
这些问题的共同特点是：不是你代码写得不对，而是模型运行的前置条件没有对齐。AI 气象模型的输入输出高度结构化，一旦某个变量顺序或归一化因子错了，结果会以不可控的方式变差，而且从输出结果上很难直接定位问题。所以建议从官方 demo 出发，先用一个小数据集验证整个流程，再去换自己的数据。
9. 工程落地与最佳实践：AI 预报不是替换传统数值预报
如果只是跑通 demo，这篇文章到一个段落就够了。但真正有工程价值的经验，是在把模型接入业务系统的时候总结出来的。这里给出几条比较通用的建议。
第一，不要直接用单一 AI 模型的输出做决策。推荐做法是混合预报：传统数值预报提供基准，AI 模型提供快速集合和替代情景。在气旋路径预报中，可以把数值模式的确定性路径、AI 模型的确定性路径、AI 模型生成的多成员集合路径放在一起做融合。多模型意见不一致的时候，往往意味着当前天气形势可预测性低，需要在预警文案里强调不确定性。
第二，务必建立回算校验机制。在把新模型加入业务前，先对过去 1 到 2 个台风季做完整回算，评估模型在不同海域、不同强度个例上的表现。业务预报员最怕的是“黑天鹅模型”：平均成绩好看，但在关键个例上给你一个完全错误的答案。回算是建立信任的唯一办法。
第三，关注模型的“保鲜期”。AI 气象模型依赖历史数据训练，气候状态会漂移，模型需要定期用新数据重新训练或微调。不要一套权重用很多年，至少要建立一个监控机制：当模型的业务误差开始系统性上升时，就该考虑升级版本。
第四，安全边界要明确。AI 模型可以用于科研和辅助预报，但在发布影响公共安全的预警时，必须有人工参与和官方流程背书。模型推理结果只是参考资料，不能自动生成对外预警。这个点听起来像套话，但在实际气象业务里是真正的红线。
第五，用工程手段管理模型版本和输入数据。把标准化参数、模型权重、配置文件、代码版本一起打包管理，保证任何一次推理都能追溯。否则半年后回看某个极端预报结果，你根本说不清当时用的是哪一版模型。
最后更新一下对后续方向的判断：接下来值得关注的不只是 DeepMind 这一家。ECMWF 的 AIFS、华为的盘古气象、微软的 ClimaX，再加上 WeatherNext，都在用不同的模型结构解决同一个问题。对开发者来说，真正的机会不在于复现某一个模型，而在于围绕“如何验证、如何融合、如何把不确定性落到业务决策”建立一套工程体系。这条路一旦走通，AI 气象预报的价值会比任何单点模型突破都大。
