简介面向气象AI研究与开发者的本地部署方案包覆盖盘古、伏羲、风乌、GraphCast与FourCastNet等主流气象大模型从创建虚拟环境、安装依赖库、添加模型、下载预训练权重到接入输入数据均有清晰流程尤其适合需要独立完成环境搭建的算法工程师与科研人员。资源包为zip压缩格式共2个文件包含一个HTML说明文档与一个inscode配置工程压缩后仅5KB用于快速查看环境配置要点与运行代码片段。目前已有133人学习。虽然体积精简仍针对Ubuntu 18.04.6 LTS Anaconda 3 CUDA 11.8 libcudnn 8测试环境给出了GPU调用失败、版本不匹配等常见安装问题的排查思路并对需要手动安装的Fengwu模型提供了专门指南。读者按其中步骤操作可结合CDS获取ERA5再分析数据在本地完成气象预报验证适合已掌握Python与深度学习基础、希望独立部署和调参的研究人员。 在气象预测这个方向我踩过最大的坑就是“以为有台服务器就能跑模式”。传统数值预报比如WRF光编译依赖就能折腾两天跑一次全球预报还得排队等超算本地GPU根本扛不住。后来AI气象大模型出来以后情况完全变了——华为盘古、GraphCast、FourCastNet这些模型训练好的权重其实只有几百兆到几个GB推理一次十分钟内就能出结果。我这次把完整的气象大模型本地部署流程跑通顺带把踩过的坑、代码结构、模型选型都整理了一遍这篇就给想自己折腾“本地部署气象大模型”的人一份可以直接抄作业的参考。先划个重点这个项目适合谁一是搞农业、新能源、交通等行业应用的开发者想在本地拿到实时预报能力接自己的业务系统二是做科研验证的学生或研究员不想每次调参都去抢超算资源三是纯粹对大模型技术感兴趣想搞明白“气象大模型到底怎么落地”的人。整个流程不要求数学基础多好但得会基本的Python、命令行操作和一点点PyTorch常识。1. 项目概述为什么非要在本地跑气象大模型1.1 这个项目到底在解决什么问题传统气象预报的门槛不在“看不懂数据”而在“跑不动模式”。以WRF为例全球范围0.25度分辨率的模拟没有几十核CPU和几百GB内存根本转不起来就算配置达标一次72小时预报也得跑大半天。而气象大模型换了个思路——用海量再分析数据训练神经网络让模型学会大气演化的规律推理时只需要一次前向传播就能给出未来7到15天的预测。像GraphCast在单个TPU上10分钟就能算出10天全球预报这放到本地GPU上完全可行。我做这个项目的直接动机其实是农业场景的需求。农业大模型这个概念最近很热AI技术在作物生长过程中实时监测土壤、气象智能灌溉施肥已经是明确落地方向而这些功能全都依赖基础气象数据。如果每次都调第三方API数据延迟、费用、数据所有权都是问题。所以把气象大模型部署在本地让预测结果直接进入自己的决策系统这是性价比最高的路径。另一个痛点在于数据闭环。气象大模型本身预测结果是一堆栅格数据但如果配合大语言模型做结果解读就能自动生成“明天下午有暴雨建议推迟灌溉”这样的农事建议。我在项目里也把Dify和Ollama部署进来作为配套服务让生态完整一点。不过这部分是可选组件后面会讲。1.2 本地部署的“本地”到底划到哪很多人在部署前搞不清边界我建议先想清楚三个问题你本地是单张消费级显卡还是有多卡服务器你需要跑全球预报还是区域预报你要的是纯推理还是也要支持微调训练这个边界直接决定了选型和参数配置。如果只是做推理16GB显存就够用如果要微调那就要认真考虑显存分级策略否则数据并行、模型并行这些方案全都得安排上。我这次项目的定位是“单机可运行 支持推理 预留微调接口”所以选型都按这个标准来。目标是在一台带RTX 4080的本地服务器上跑通同时保证代码结构清晰方便后续扩展成服务接口给别人调用。2. 技术选型解析模型框架与配套组件怎么搭2.1 开源气象大模型选哪个更适合本地现在能拿到的开源气象大模型方案主流就那几个我直接做了个实测对比方便你选型模型空间分辨率预报时长权重大小本地部署难度备注盘古气象Pangu-Weather0.25°24小时到7天约100MB左右中精度高权重获取需要走申请流程GraphCast0.25°10天60步迭代约100-200MB低权重公开Google开源部署文档比较完整FourCastNet0.25°7天约300MB中基于Adaptive Fourier Neural Operator适合科研对比AIFSECMWF开源版0.25°15天较大高功能最全但依赖多配置繁琐第一次上手的话我强烈建议从GraphCast开始。原因是它的权重要求最简单、推理脚本官方就给好了踩坑少。但要注意它在迭代过程中每步都输出中间结果显存占用会波动设置批次的时候别太贪。盘古气象的精度确实更高尤其在中纬度地区的温度场上但申请权重需要填用途说明等着审批的过程就很烦人。如果机器配置一般比如只有一张8GB显存的卡也别慌。可以选择跑低分辨率版本把输入数据插值到1.5度再用虽然精度会降低但预报趋势基本保留做农业、能源行业的趋势分析完全够用。2.2 推理框架与开发环境怎么配模型选定之后配套环境就按官方要求来即可但有几个坑要提前避开。不要直接往系统Python里装包一定要建虚拟环境。用conda建环境Python版本选3.10PyTorch要装CUDA 12.1对应的版本。我建议的依赖版本清单大概是这样的python: 3.10 torch: 2.1.2cu121 numpy: 1.26.2 xarray: 2024.1.1 netCDF4: 1.6.5 dask: 2024.1.1 einops: 0.7.0 typing_extensions: 4.9.0 fastapi: 0.109.0 uvicorn: 0.27.0这里多提一句GraphCast官方仓库用的是graphs相关依赖需要单独安装dgl或者torch-geometric这步最容易出问题。很多人装上后一跑就报ImportError基本都是因为DGL版本和CUDA对不上。我的建议是直接安装dgl的CUDA预编译版本别用pip默认源里的CPU版本。2.3 项目代码的结构怎么组织项目代码这个事情很多人不重视觉得能跑就行。但等到想加功能、换模型的时候就知道痛苦了。我这次把项目代码组织成了下面这个结构weather-llm/ ├── configs/ # 配置文件目录 │ ├── graphcast.yaml │ └── pangu.yaml ├── data/ # 输入数据目录 │ ├── era5/ # ERA5再分析数据hPa层 │ └── gfs/ # GFS实时预报数据 ├── src/ # 核心代码 │ ├── data_loader.py # 数据读取与标准化 │ ├── model_inference.py # 模型推理封装 │ ├── postprocess.py # 结果后处理与可视化 │ └── server.py # FastAPI服务接口 ├── weights/ # 模型权重目录 ├── scripts/ # 一键部署脚本 │ ├── setup_env.sh │ └── download_weights.sh ├── requirements.txt └── README.md这套结构的核心思路是“配置与代码分离、数据与模型权重分离”。换模型时只需要改yaml配置文件不会动到核心代码。data_loader统一做标准化处理因为不同模型对输入数据的要做均值和方差归一化搞混了结果会非常离谱。3. 部署实操从环境准备到服务跑起来3.1 硬件检查与基础环境安装硬件这块没有太多讨价还价的余地。我实测下来CPU至少需要12核以上内存32GB起步推荐64GB——因为加载ERA5数据时通常要一次性读入多个气压层内存不够直接swap到死。磁盘建议SSD且预留200GB空间其中ERA5单日数据解压后大概2GB左右如果你要跑多天预报数据量累计得很快。GPU建议NVIDIA卡显存16GB以上支持CUDA。安装完驱动后先别急着跑模型用nvidia-smi确认驱动版本和CUDA版本再装PyTorch。装完以后务必要跑一次小张量计算来验证GPU是否真的被PyTorch识别到了import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) x torch.randn(3, 3).cuda()我第一次部署的时候用conda装完PyTorch后没验证结果跑了三个小时代码才发现调用的是CPU版本那速度慢到让人抓狂。这步验证两分钟就能做完一定不能省。3.2 拉取代码、装依赖、准备权重环境没问题后开始拉项目代码和准备模型权重。GraphCast官方仓库在GitHub上直接git clone即可。但要注意权重文件必须单独下载不会随仓库一起拉下来。我写了个下载脚本放在scripts/download_weights.sh里核心就是wget官方release里提供的checkpoint文件下载后放到weights/目录。盘古气象的权重是HDF5格式需要额外安装h5py这一点和GraphCast的npz格式不一样。依赖安装的时候有个细节官方requirements文件里锁定的版本比较老和Python 3.10会有冲突。我自己整理了一份适配过的requirements.txt大概如下pip install torch2.1.2cu121 torchvision0.16.2cu121 --index-url https://download.pytorch.org/whl/cu121 pip install dgl -f https://data.dgl.ai/wheels/cu121/repo.html pip install xarray netCDF4 dask einops typer fastapi uvicorn在装依赖这里我踩过最大的坑是DGL的CPU/GPU版本搞混。DGL默认pip包是CPU版本装上之后能导入但跑图神经网络那段代码直接报“kernel not compiled for GPU”非常坑。所以DGL一定要用CUDA对应的wheel源安装千万别偷懒用默认源。3.3 推理脚本与接口对接模型跑通推理是第一步真正能落地还要把它封装成服务。我用FastAPI写了一个简单的推理接口核心逻辑是把请求参数起始时间、预报天数、输出变量传给推理模块拿到结果后做后处理返回标准JSON或GeoTIFF。简化后的代码大概是这样的from fastapi import FastAPI, HTTPException from pydantic import BaseModel from src.model_inference import GraphCastInference app FastAPI(titleWeather LLM Local API) model GraphCastInference(config_pathconfigs/graphcast.yaml) class ForecastRequest(BaseModel): start_time: str # 2025-01-10T00:00:00 lead_days: int 10 # 预报天数 variables: list[str] [2m_temperature, total_precipitation] app.post(/forecast) def forecast(req: ForecastRequest): try: result model.predict(start_timereq.start_time, lead_daysreq.lead_days, variablesreq.variables) return {status: ok, data: result} except Exception as e: raise HTTPException(status_code500, detailstr(e)) app.get(/health) def health(): return {status: alive}启动服务就用uvicorn src.server:app --host 0.0.0.0 --port 8000。这样局域网内的业务系统就能直接调用预报能力了。如果有农业大模型平台把这里的接口接到自动灌溉的控制逻辑里就能实现“气象预测驱动的智能决策”这也是我后面打算继续做的方向。3.4 三条本地部署路线对比总结部署的过程中我测试了三种不同的方式各有优劣整理成下面这个表方便你按自己的情况选部署方式适用场景优点缺点纯Python脚本推理科研验证、批量跑实验灵活、调试方便、无服务开销每次跑都要手动加载模型FastAPI封装REST服务业务系统对接、多端调用接口标准、支持并发、便于集成需要额外维护服务进程集成Dify/Ollama工作流想做自然语言交互、自动生成预报解读能用LLM直接解读天气数据部署组件多、资源占用高如果你只是想先跑通验证效果选第一种如果要做应用集成直接用第二种如果想做得更智能比如让大语言模型自动解读预报结果再接入Dify编排工作流和Ollama部署本地对话模型那就上第三种。我目前是第二种和第三种混合用气象大模型输出数据Dify工作流负责把结构化数据转成自然语言建议。4. 常见问题与排查技巧实录4.1 显存不足和内存爆掉怎么处理这是本地部署气象大模型时最常遇到的问题我第一次跑GraphCast的时候就直接OOM了。排查下来主要是数据加载时把多个时间步全部读进内存一次性前向传播当然扛不住。解决办法有几个一是限制输入数据的时间范围不要一次读太多二是在推理代码里加with torch.no_grad()这个必须加不然梯度缓存会把显存直接吃满三是数据加载到GPU时用.float()如果是float64显存占用直接翻倍。如果机器配置实在太低还有一个终极方案用torch.cuda.amp.autocast()跑混合精度推理显存占用能砍掉大半。4.2 输入数据格式和来源的坑模型部署好了结果不对大概率是输入数据的问题。气象大模型要求的输入数据无论来源是什么最终都要处理成模型训练时用的格式。以GraphCast为例输入是特定气压层的多个变量组合数值必须经过mean和std标准化否则模型输出的值完全不可读。我第一次跑的时候直接用原始GFS数据塞进去出来的温度场数值跟实际差了二十度。数据来源上最常用的几个方案是ERA5再分析资料质量最好但实时性差、GFS实时预报免费且时效性好适合业务系统、以及本地气象站观测数据需要自己插值到网格。GFS数据是grib2格式要用cfgrib库读取这又是一个容易踩坑的地方conda装cfgrib需要先装eccodes。4.3 结果精度验证与调优模型跑通后验证精度是必须做的。我自己一般会拿历史某几天的GFS数据作为输入让模型预报未来几天的结果然后跟实际观测做对比计算RMSE和相关系数。如果模型在初始场附近的表现和ERA5对比偏差过大多半是标准化参数用错了。如果后期预报发散严重可以考虑调整推理时的迭代步长或者改用Ensemble策略跑多次取平均。另外预测结果的经纬网格和原始数据往往不一致xarray的interp函数可以用来重采样。视觉化检查时用matplotlib的contourf画个等值线图一眼就能看出预测场是否合理。这一步建议每次都跑一下比单纯看数值直观得多。4.4 最终效果与后续扩展方向整个项目跑通后我在本地RTX 4080上做了个基准测试GraphCast推理一个10天全球预报耗时约8分钟峰值显存占用约12GB。作为对比同样的任务如果跑WRF在同等硬件上至少需要6到8个小时这个差距是数量级的。盘古气象的推理速度更快7天预报大概3分钟出结果就是权重申请流程确实让人头疼。后续扩展方向我已经在着手两个事情。一个是把预报结果接入农业决策系统结合土壤墒情数据做智能灌溉和施肥建议把气象预测真正变成一个决策工具。另一个是接入Ollama部署一个本地大语言模型让模型不仅能给出“未来几天有强降雨”的数据结果还能用自然语言生成“建议暂停施肥注意排水”的操作建议。Dify这块我用它做工作流编排把数据解析、提示词模板、输出格式化串起来业务方只需要面对一个对话界面就能完成全部交互。最后再分享一个小经验本地部署气象大模型别一上来就追求最高的空间分辨率。先把推理链路完整跑通再逐步提高分辨率这个顺序能帮你省掉大量排查问题的时间。气象大模型最大的价值不是替代传统数值模式而是让你在可控成本内拥有一个实时、可定制、不与外部服务绑定的预报能力这比什么都重要。本文还有配套的精品资源点击获取