天气预测领域正在从单纯依赖数值模式转向把机器学习、生成式模型和再分析数据结合起来。google-deepmind/weathernext 正是这样一个开源项目入口。面对这类仓库容易犯的错误是拿到代码就急着pip install却不清楚它解决的是“确定性预报”还是“概率集合预报”也不知道输入数据该用什么变量、什么空间分辨率。真正实用的做法是先定位项目在天气预测链路里的位置再按“环境、数据、推理、验证、排错”的顺序把整个流程跑通。下面用一条可复现的路径来拆解读完以后你不仅能理解这个项目的结构也能把同样的方法迁移到其他气象机器学习仓库。1. 先弄清楚 weathernext 属于哪一类天气预测项目1.1 天气预报模型的三条技术路线传统数值天气预报NWP通过求解大气运动方程从当前观测状态外推未来天气。它的物理约束强但计算成本很高而且需要复杂的资料同化系统。统计后处理则把模式输出和站点观测之间的关系用统计模型拟合常用于修正偏差、生成概率预报。第三条路线是纯数据驱动的机器学习天气预测用历史再分析资料作为输入让神经网络直接学习从当前大气状态到未来状态的映射。weathernext 这个名字可以拆成 “weather” 和 “next”指向的正是“从当前天气状态预测下一步状态”这个任务。DeepMind 近年在气象方向的开源工作大多属于第三条路线也就是用神经网络直接做中期预报或临近预报。因此遇到这个仓库时最合理的判断方向是它大概率是一个机器学习天气预测项目而不是一个传统 NWP 模式的包装。你可以通过仓库 README 里是否出现diffusion、graph neural network、ensemble、reamalysis这些关键词来确认。1.2 从仓库命名和目录结构判断项目类型打开 GitHub 仓库之后先不要下载代码。先看这几个关键位置README.md项目背景、数据来源、安装方式、模型输出格式。pyproject.toml 或 requirements.txt依赖框架和版本。configs/ 或 config.py训练和推理配置。scripts/训练、评估、推理入口。checkpoints/ 或 pretrained_weights/是否提供预训练权重。如果你的目录结构中出现多个config文件和以eval、predict结尾的脚本说明项目更重视“复现和评估”而不仅仅是模型代码演示。这种项目通常需要准备完整的天气数据输入而不是随便拿一张图片就能跑。weathernext 这类项目在结构上经常采用分模块方式weathernext/ ├── README.md ├── pyproject.toml ├── weathernext/ │ ├── data.py │ ├── model.py │ ├── train.py │ ├── eval.py │ └── utils.py ├── configs/ │ ├── pretrained.yaml │ └── training.yaml ├── scripts/ └── checkpoints/上面只是一个通用示意。实际仓库里模块名可能不同但阅读逻辑是通的data处理输入model定义网络train负责训练eval负责验证。先把这个映射建立起来后面阅读代码会快很多。1.3 核心技术方向生成式模型与集合预报天气预测天然存在不确定性所以只输出一条确定性预报并不够。业务预报需要知道“明天下午是否有 30% 的概率下雨”此时需要使用集合预报对初始状态做微小扰动或者让模型本身带有随机性生成多个未来状态再统计概率。weathernext 如果采用生成式方法很可能会用到扩散模型。扩散模型先学习从噪声数据逐步还原成真实天气场的过程推理时从随机噪声开始生成一组不同的预测样本。另一个常见结构是图神经网络把全球网格看成一张图相邻格点之间通过边传递信息。相比普通卷积网络图网络更容易处理球面网格和不均匀格点。理解这一点很重要因为它决定了验证方式。单一预测用 RMSE、MAE 评估集合预报则要额外看 CRPS、spread-skill 关系等指标。你不能用确定性预报的验证逻辑去评估一个生成式集合预报模型否则会得出“预报扰动太大、表现很差”的错误结论。2. 环境准备跑通 weathernext 前需要补齐哪些依赖2.1 硬件和运行环境大尺度天气网格通常包含经度、纬度、气压层和多个变量。例如 0.25 度分辨率的数据单张全球图就有 1440 x 721 个格点。如果输入包含多个时间步和多个变量单个样本的数据量很容易达到几十甚至上百兆。建议将学习环境与生产环境分开。学习阶段只需要把最小推理流程跑通一张 12GB 显存的显卡通常就够用生产环境则需要考虑多卡并行、分布式推理和容错机制。以下是一组常见配置参考项目学习环境生产环境GPU单张 12GB 以上多卡或 TPUCPU8 核以上32 核以上内存32GB128GB 或更多磁盘20GB 可用按数据量预留 TB 级空间深度学习框架与仓库锁定版本一致版本锁定并纳入镜像这里不是要给出精确的官方要求而是提醒你天气数据比常规图像数据大得多环境准备阶段最容易低估磁盘和内存需求。2.2 Python 环境与依赖安装安装依赖前先确认仓库使用的是 PyTorch、TensorFlow 还是 JAX。DeepMind 很多项目使用 JAX但 weathernext 不能凭名称判断。以 PyTorch 项目为例典型安装流程是conda create -n weathernext python3.10 conda activate weathernext pip install numpy pandas xarray dask netCDF4 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install -e .最后一步pip install -e .会把当前项目以可编辑模式安装方便源码改动后立即生效。不过要注意项目可能通过pyproject.toml声明额外依赖例如pip install -e .[all]其中[all]会安装包括可视化、测试、分布式训练在内的全部依赖。如果安装时网络条件有限建议先安装核心依赖跑通推理再补装可视化依赖。2.3 天气数据准备ERA5 与静态场文件机器学习天气预测通常使用再分析资料作为输入。ERA5 是常见的全球再分析数据集包含位势高度、温度、风场、比湿、海平面气压等变量。你可能会同时用到静态场数据例如地形高度、陆地掩膜、经纬度网格因为这些信息能帮助模型理解下垫面对大气运动的影响。读取这类数据时xarray 是核心工具import xarray as xr ds xr.open_dataset(data/era5_20250101_00.nc) print(ds)数据中通常包含维度time、level、latitude、longitude变量则可能包括z、t、u、v、q、msl。在送入模型前一般需要按时间排序统一缺失值用 NaN 或特定填充值表示检查经纬度是升序还是降序确认变量的单位是否需要转换如果原始数据没有给出明确版本落地前要先确认仓库 README 中要求的变量名和维度顺序。很多运行时报错并不是模型问题而是变量名对不上。2.4 环境检查清单在运行任何训练或推理脚本前花五分钟完成环境检查可以省掉大量排错时间Python 版本是否在仓库要求的范围内。CUDA 驱动和深度学习框架版本是否匹配。是否安装了 GPU 版本的 PyTorch 或 JAX。数据文件是否存在且权限可读。预训练权重是否下载到正确位置。临时目录空间是否足够存放中间结果。是否固定了随机种子并记录版本号。写环境检查清单时最好把每条对应的检查命令一起记录下来。比如用python -c import torch; print(torch.cuda.is_available())检查 GPU 是否可用用nvidia-smi查看显存占用。这样后续排查问题时能快速判断是环境问题还是业务代码问题。3. 从源码结构出发定位核心模块3.1 一个典型模型仓库的目录约定开源项目虽然风格各异但模块划分通常有规律可循。你不太需要从头读所有代码而是先画出一条数据流原始数据 - 预处理 - 模型输入 - 模型输出 - 后处理 - 评价指标。沿着这条数据流在仓库中找到对应的文件weathernext/ ├── weathernext/ │ ├── data.py # 数据读取、归一化、batch 化 │ ├── model.py # 网络结构 │ ├── losses.py # 训练损失函数 │ ├── metrics.py # RMSE、CRPS 等评估指标 │ └── plotting.py # 可视化辅助函数 ├── configs/ │ ├── data.yaml # 数据路径和预处理参数 │ └── model.yaml # 模型结构参数 └── scripts/ ├── train.py └── eval.py如果你发现仓库里的数据预处理函数很长不要意外。天气数据常常需要处理缺失值、极值、变量归一化和多层级累加这些逻辑比模型本身还复杂。3.2 找到推理入口推理入口通常不叫main.py而是predict.py、eval.py或者一个 Jupyter Notebook。如果你找到了预训练权重并希望用已有权重做预报重点看以下几个逻辑模型权重如何加载输入数据是否做了标准化输出是单一确定性结果还是多个集合成员结果如何从物理单位还原成摄氏度、米每秒等常规单位一个通用示例脚本如下import xarray as xr from weathernext import load_model, run_inference model load_model(checkpoints/weathernext_pretrained) input_ds xr.open_dataset(data/input_20250101.nc) forecast run_inference(model, input_ds)这里只是说明代码阅读思路。实际项目里的 API 可能完全不同你需要以仓库 README 或源码注释为准。重要的是理解推理脚本应该接收一个包含气象变量的xarray.Dataset或 NumPy 数组并输出一个具有时间、空间维度的预测结果。3.3 配置文件中必须读懂的参数模型仓库通常用 YAML 或 JSON 保存配置。以一份典型的推理配置为例data: path: ./data/era5_20250101.nc variables: [u10, v10, t2m, msl] time_start: 2025-01-01T00:00:00 num_steps: 10 model: checkpoint: ./checkpoints/pretrained.ckpt ensemble_members: 50 output: path: ./output/forecast.nc save_raw: true seed: 42这些参数每一项都可能在运行时产生重大影响num_steps要预测多少个未来时间步决定预报时效。ensemble_members生成多少个集合成员成员数越多概率估计越稳定但推理成本线性增加。seed随机种子直接影响扩散采样结果复现实验时必须固定。save_raw是否保存未经后处理的原始输出。建议打开便于排查标准化还原是否正确。读到配置时不要当成普通文件跳过。把每个参数和模型输入输出对应起来遇到问题就能更快发现是配置错误还是代码错误。4. 运行与验证从“代码能跑”到“结果可信”4.1 先跑通最小推理再谈复现第一次运行天气模型不建议直接做完整年份回算。先准备一条最小数据只包含少数时间步跑通一次推理确认输出形状和值域合理。假设模型的输入是[batch, time, level, lat, lon]输出是[batch, time, lat, lon]。你可以用一段小代码检查import numpy as np fake_input np.random.randn(1, 10, 13, 721, 1440).astype(np.float32) forecast model(fake_input) print(forecast.shape)如果用真实输入跑则要额外检查时间维是否正确推进print(forecast.coords[time]) print(forecast[t2m].values.mean())如果 mean 值接近正常气温量级说明单位还原大概率正确如果出现几千或几亿的值就要检查标准化逆变换是否遗漏。这一阶段不要急着评估指标目标是让每个中间变量都可视化或打印出来确认形状和量级没有问题。4.2 确定性预报和集合预报的验证方式不同模型类型要使用不同指标。确定性预报的常用指标包括 RMSE 和 MAE集合预报则更关注概率分布的合理性。CRPS 是集合预报中的常用指标它同时衡量预测分布的锐度与可靠性。可以先用一个极简例子理解 CRPS。比如真实温度为 20 度模型 A 给出的集合成员全部在 19 到 21 度之间模型 B 给出的集合成员在 -10 到 50 度之间。虽然二者均值可能都接近 20 度但显然模型 A 的集合更有用CRPS 会给出更低的分值。在评估天气模型时还需要看集合扩散集合成员之间的离散度不能太小否则会出现 overconfidence也不能太大否则预报没有技能。通常用 spread-skill 图来判断。4.3 可视化与误差分析数值指标之外可视化能帮助你快速发现空间上的系统偏差。比如模型是否在青藏高原区域出现明显冷偏差是否在海岸线附近有异常极值。一个常见的地图可视化示例如下import matplotlib.pyplot as plt import xarray as xr forecast xr.open_dataset(output/forecast.nc) temp forecast[t2m].isel(time0) plt.figure(figsize(10, 5)) temp.plot() plt.title(2m temperature forecast) plt.savefig(output/forecast_t2m.png, dpi150)如果安装了 cartopy还能叠加海岸线、国界等地理信息。可视化不是最终目标而是误差分析的手段。对比预测场、真实场和残差场才能判断模型在哪些区域失效。4.4 学习环境与生产环境的差异学习环境里能跑通不代表生产环境能稳定运行。生产环境需要考虑的问题更多关注点学习环境生产环境数据读取本地文件对象存储或数据平台临时文件随便存放独立的临时卷用完清理监控打印日志指标上报、告警随机种子固定便于复现固定但隔离每次实验依赖手动安装容器镜像锁定回滚不需要模型版本和权重版本需要记录如果只是做研究复现重点放在固定随机种子和记录依赖版本。如果要把 weathernext 变成对外服务还要额外考虑输入数据校验、推理超时、并发请求排队、输出异常检测等模块。5. 常见问题排查5.1 显存不足与 CUDNN 错误现象是运行时出现CUDA out of memory或cudnn_status_alloc_failed。常见原因有三个单样本输入过大、batch size 过大、模型中间激活值占用太多显存。天气输入的网格很大1440 x 721 的全球场在深网络中间层的显存消耗会快速膨胀。排查顺序是先调小 batch size再减小分辨率最后考虑混合精度或梯度检查点。如果用 PyTorch可以在代码入口加入torch.backends.cudnn.benchmark False torch.backends.cuda.matmul.allow_tf32 True这只能缓解部分问题。更稳妥的做法是打印模型推理时每一层的显存占用找到真正的大块占用节点。5.2 数据格点与模型输入不匹配常见报错是形状不一致比如模型期望维度顺序是[time, level, lat, lon]但读取的数据顺序是[time, lat, lon, level]。检查方式分三步打印数据维度print(ds.dims)打印数据坐标范围print(ds.latitude.values.min(), ds.latitude.values.max())打印变量名print(list(ds.data_vars))如果经纬度是降序而模型按升序处理结果会在地理空间上直接翻转这种错误很难通过数值指标发现。建议在数据预处理阶段统一坐标系并写一个断言assert ds[latitude][0] ds[latitude][-1] # 确认降序如果项目要求升序则用ds ds.sortby(latitude)调整。5.3 结果为 NaN 或发散预测结果出现 NaN 通常不是随机问题而是输入数据、损失计算或标准化环节存在确定性缺陷。优先检查输入数据是否包含 NaNimport numpy as np print(np.isnan(input_data.values).sum())如果输入正常再检查标准化过程是否出现除以零的情况比如某个变量的长期标准差为 0。天气数据里某些格点可能完全被陆地或海洋覆盖导致变量方差极小除以接近 0 的标准差后就会出现大数溢出。推荐在损失函数和推理逻辑里加入显式保护x np.nan_to_num(x, nan0.0, posinf1e10, neginf-1e10)但这只是兜底不能替代根因排查。应该在预处理阶段用有效的 mask 去掉无效格点。5.4 复现结果与 README 不一致这是最让人头疼的问题。明明按 README 做了结果仍然对不上。按以下顺序排查排查项检查方式可能原因随机种子是否设置相同 seed扩散采样随机性数据版本是否使用同一套 ERA5 文件数据更新导致差异权重版本checkpoint 文件名和哈希下载到旧权重依赖版本requirements 是否锁定框架版本差异硬件差异GPU 是否影响浮点运算不同硬件浮点结果不一致为了提升可复现性建议在运行日志中记录代码 commit、依赖版本、数据文件路径和校验和。没有这些信息一旦结果对不上很难判断是哪个环节变了。5.5 优先级排错清单遇到问题不要凭感觉改代码。按照以下顺序排查输入数据是否完整、变量名是否正确。配置文件路径是否正确checkpoint 是否真能加载。数据维度顺序和坐标方向是否匹配。标准化和逆变换是否对称。设备是否一致GPU 是否被科学计算框架正确识别。依赖版本是否与仓库锁定版本一致。错误堆栈中是否包含具体模块名去对应文件查看。这条清单适用于大多数天气机器学习项目也适用于其他开源 AI 项目。6. 最佳实践与扩展方向6.1 复现开源天气模型的通用检查清单每次复现 weathernext 或类似仓库建议按下面清单执行创建独立的 conda 或 venv 环境不要污染系统 Python。用pip freeze environment.lock锁定依赖。记录数据文件路径、下载时间和文件大小。固定随机种子并把种子写进配置文件。先跑一次最小推理再跑完整评估。保存模型输出为 netCDF而不是只保存图像。对比输出前先统一经纬度单位、时间单位和变量单位。这套清单同样适用于你未来的天气预测项目。只要每次实验都留下足够信息即使一个月后回看也能知道当时跑的是哪套数据和代码。6.2 工程化建议数据版本、日志、缓存与异常处理天气项目的核心不只是模型还包括数据管线。建议把数据版本化管理不只记录data_20250101.nc这个文件名还要记录文件哈希和来源。因为再分析数据会持续更新不同批次可能不同直接影响复现结果。日志方面建议在每个关键阶段输出一行结构化日志[2025-01-01 12:00:00] load data: data/era5_20250101.nc, shape... [2025-01-01 12:00:10] normalize data: min..., max... [2025-01-01 12:00:30] inference start, devicecuda:0 [2025-01-01 12:00:40] inference done, forecast shape...缓存方面预处理后的标准化数据可能很大。如果每次都重新处理会拖慢实验迭代。建议把预处理结果缓存为中间格式并只重建缓存失效的部分。例如如果你的输入数据每天更新可以按天缓存归一化结果模型代码更新时则清空模型相关缓存。6.3 从复现到下游定制任务weathernext 提供的预测能力可以服务于很多下游任务。最常见的方向包括可再生能源功率预测根据未来风场、温度、云量预测风电场和光伏电站出力。极端天气事件检测在预测结果中识别高温热浪、强降水和寒潮过程。农业风险预警结合土壤和作物生长阶段用温度、降水预测评估霜冻和干旱风险。城市内涝预判把降水预报接入水文模型预测城市积水风险。做下游定制时不要重新训练整个大模型。更稳妥的做法是先把预训练模型当成特征提取器用它的输出作为下游模型的输入。这样既能保留物理规律信息又能适应本地数据分布。如果你的最终目标是做研究建议先从小区域和少量变量开始。把 weathernext 的推理流程跑通记录一个真实案例的输出再逐步调整输入变量和输出变量。天气模型最怕一上来就追求完整全球预报那样会让调参和排错变得非常困难。先把一条链路走通再横向扩展才是效率最高的路线。