企业官网建设流程全解析

简介：这份资源面向气象学研究者、AI 工程实践者与需要本地跑通气象大模型的学生，提供 Pangu、Fuxi、Fengwu、GraphCast、FourCastNet 等主流模型的本地部署项目代码，解决从环境搭建到预训练权重接入、ERA5 数据获取与预报运行的完整链路问题。压缩包共 2 个文件，以 html 与 inscode 为主，html 承载项目说明与部署指引，inscode 为可运行的代码入口，整体约 5KB，轻量便于快速查阅与二次整理。目前已有 138 人学习下载。读者可据此在 Ubuntu 18.04.6 LTS + Anaconda 3 + CUDA 11.8 + libcudnn 8 环境下复现部署流程，并参考 GPU 调用失败、版本不匹配等常见问题的排查思路，以及 Fengwu 等需手动安装模型的下载与配置指南，最终通过 CDS 访问 ERA5 数据驱动模型完成气象预报验证。

1. 本地部署气象大模型：从“跑不起来”到“跑得动”的那条分界线

很多人第一次听到“本地部署气象大模型”，脑子里浮现的是机房、A100 集群和一张吓人的显存账单。但真实情况是：只要模型选得对、量化做得狠、推理框架配得准，一台带 24GB 显存的消费级显卡机器，甚至一台 32GB 内存的 Mac，都能把 7B 级别的气象大模型跑出可用的推理速度。这件事的价值不在于“炫技”，而在于数据不出本地、推理不依赖外部接口、可以按自己的区域和变量做微调——对做气象服务、能源功率预测、农业灾害预警的团队来说，这是从“调别人接口”到“自己掌控链路”的分水岭。

这篇文章面向三类人：想在自己机器上跑通气象大模型但被环境卡住的工程师、需要把模型嵌进业务系统做批量推理的开发者、以及想评估“本地部署到底值不值得投入”的技术负责人。我会按“先搞清楚模型是什么 → 环境怎么搭 → 代码怎么跑 → 参数怎么调 → 坑在哪”的顺序讲，每一步都给可复现的命令和代码，不绕弯子。

2. 气象大模型到底在算什么：从 ERA5 到推理输出的链路拆解

2.1 气象大模型和普通 LLM 的本质区别

普通大语言模型处理的是 token 序列，输入输出都是离散符号；气象大模型处理的是网格化连续场，输入通常是多个气象变量在经纬度网格上的数值张量，输出是未来若干时刻的预测场。以常见的 Pangu-Weather、GraphCast、FengWu 这类模型为例，它们的输入维度一般是(batch, time, variable, lat, lon)或(batch, variable, lat, lon)，变量包括位势、温度、湿度、风速的 u/v 分量等，典型分辨率是 0.25°（约 721×1440 网格）或 1°（约 181×360 网格）。

这意味着两件事：第一，显存占用不只取决于参数量，还取决于网格分辨率和变量数；第二，推理不是“生成文本”，而是一次前向传播出一张场，所以延迟和吞吐的评估方式跟 LLM 完全不同。很多人拿 LLM 的经验去套，结果在数据预处理阶段就翻车了。

2.2 本地部署的三种典型形态

选型逻辑很简单：如果你只是验证模型效果，全精度跑一次就够；如果要嵌进业务做每天多次推理，量化是绕不开的。我一般建议先从 FP16 跑通，再根据显存余量决定要不要上量化。

2.3 数据预处理的三个关键步骤

气象大模型的输入不是随便一张图，而是需要严格对齐的网格数据。常见做法是：

import numpy as np import xarray as xr # 1. 读取 NetCDF 格式的再分析数据 ds = xr.open_dataset("era5_sample.nc") # 2. 选取模型需要的变量并按固定顺序排列 variables = ["z", "t", "u", "v", "q"] # 位势、温度、u风、v风、比湿 data = ds[variables].values # shape: (variable, lat, lon) # 3. 归一化：使用训练时统计的均值和标准差 mean = np.load("norm_mean.npy") # shape: (variable, 1, 1) std = np.load("norm_std.npy") normalized = (data - mean) / std # 4. 插值到模型要求的网格（如果原始分辨率不一致） # 常见做法是用双线性插值到 0.25° 或 1° print(normalized.shape) # 例如 (5, 721, 1440)

这段代码的逻辑是：先按模型训练时的变量顺序取数，再用训练集统计量做标准化，最后对齐网格。参数说明：variables的顺序必须和模型权重里的通道顺序一致，错了不会报错但结果全废；mean和std必须用模型作者提供的统计文件，自己算的会导致系统性偏差。

3. 本地环境搭建：从裸机到能跑推理的完整命令链

3.1 硬件与驱动的最低要求

先说结论：7B 级别气象大模型，FP16 推理最低 16GB 显存，推荐 24GB；INT8 量化后 8GB 显存可跑，但网格分辨率要降到 1°。CPU 推理不是不能跑，但 0.25° 网格下一次前向可能要几分钟，只适合验证。

驱动层面，NVIDIA 显卡需要 CUDA 11.8 以上，推荐 12.1。检查命令：

nvidia-smi # 查看驱动版本和显存 nvcc --version # 查看 CUDA 版本

如果nvcc没输出，说明 CUDA Toolkit 没装或没进 PATH。常见做法是用 conda 装cudatoolkit，避免和系统驱动打架。

3.2 Python 环境与依赖安装

我一般用 conda 建独立环境，避免和系统 Python 混：

conda create -n weather-llm python=3.10 -y conda activate weather-llm # 安装 PyTorch（以 CUDA 12.1 为例） pip install torch==2.1.0 torchvision --index-url https://download.pytorch.org/whl/cu121 # 安装气象和推理相关依赖 pip install xarray netcdf4 numpy scipy pip install transformers accelerate # 如果模型基于 HF 生态 pip install onnxruntime-gpu # 如果走 ONNX 推理

参数说明：torch版本要和 CUDA 版本匹配，装错了会在torch.cuda.is_available()返回 False；xarray和netcdf4是读气象数据的标配，缺一个都会在open_dataset时报错。

3.3 模型权重下载与目录结构

权重文件通常几百 MB 到几 GB，建议单独放一个目录，不要混在代码仓库里：

mkdir -p models/weather-llm cd models/weather-llm # 假设权重已经通过合法渠道获取，放在当前目录 ls -lh # 典型文件：model.safetensors config.json norm_mean.npy norm_std.npy

目录结构建议：

project/ ├── models/ │ └── weather-llm/ │ ├── model.safetensors │ ├── config.json │ ├── norm_mean.npy │ └── norm_std.npy ├── data/ │ └── era5_sample.nc ├── infer.py └── requirements.txt

这样做的原因是：权重和代码分离，换模型时不用动代码；归一化统计文件和权重放一起，避免推理时找不到。

4. 推理代码实战：一个能跑通的最小示例与参数调优

4.1 加载模型与执行一次前向传播

下面是一个最小可运行示例，假设模型是 PyTorch 格式：

import torch import numpy as np import xarray as xr from model import WeatherModel # 假设模型定义在 model.py # 1. 设备选择 device = torch.device("cuda" if torch.cuda.is_available() else "cpu") print(f"Using device: {device}") # 2. 加载模型权重 model = WeatherModel.from_pretrained("models/weather-llm") model.to(device) model.eval() # 推理模式，关闭 dropout 和 batchnorm 更新 # 3. 准备输入 ds = xr.open_dataset("data/era5_sample.nc") variables = ["z", "t", "u", "v", "q"] data = ds[variables].values mean = np.load("models/weather-llm/norm_mean.npy") std = np.load("models/weather-llm/norm_std.npy") normalized = (data - mean) / std # 4. 转 tensor 并加 batch 维度 input_tensor = torch.from_numpy(normalized).float() input_tensor = input_tensor.unsqueeze(0).to(device) # (1, variable, lat, lon) # 5. 前向传播 with torch.no_grad(): # 关闭梯度，省显存 output = model(input_tensor) # 6. 反归一化 output_np = output.squeeze(0).cpu().numpy() output_denorm = output_np * std + mean print(f"Output shape: {output_denorm.shape}")

逻辑说明：model.eval()和torch.no_grad()是推理阶段的两个必做动作，前者关闭训练专用层，后者省掉梯度存储，显存能降 30% 以上。参数说明：unsqueeze(0)加的 batch 维度必须和模型期望一致，有些模型期望(batch, time, variable, lat, lon)，少一维会直接报 shape 错误。

4.2 显存不够时的三个调优手段

如果跑的时候报CUDA out of memory，按以下顺序试：

手段一：降低 batch size。气象大模型通常 batch=1 就够，如果已经是 1 还爆，说明输入网格太大。

手段二：混合精度推理。把float32换成float16：

model.half() # 模型转半精度 input_tensor = input_tensor.half() with torch.no_grad(): output = model(input_tensor)

注意：有些模型对半精度敏感，输出可能出现 NaN，这时候要回退到 FP32 或只对部分层做半精度。

手段三：分块推理。把大网格切成小块分别推理再拼接：

def chunked_inference(model, input_tensor, chunk_size=128): """按纬度分块推理，降低单次显存占用""" _, _, lat, lon = input_tensor.shape outputs = [] for i in range(0, lat, chunk_size): chunk = input_tensor[:, :, i:i+chunk_size, :] with torch.no_grad(): out = model(chunk) outputs.append(out) return torch.cat(outputs, dim=2)

参数说明：chunk_size越小显存越省，但边界处可能出现拼接痕迹，建议设成模型感受野的整数倍。

4.3 推理速度的评估与优化

评估指标不是“每秒多少 token”，而是单次前向耗时和吞吐（场/秒）。测量方法：

import time # 预热，避免第一次推理的初始化开销 with torch.no_grad(): _ = model(input_tensor) # 正式计时 torch.cuda.synchronize() start = time.time() for _ in range(10): with torch.no_grad(): _ = model(input_tensor) torch.cuda.synchronize() elapsed = (time.time() - start) / 10 print(f"Average inference time: {elapsed:.3f}s")

torch.cuda.synchronize()是必须的，否则测的是 CPU 下发命令的时间，不是 GPU 实际计算时间。优化方向：开torch.backends.cudnn.benchmark = True让 cuDNN 自动选最快卷积算法，对固定输入尺寸的推理通常有 10%～20% 提升。

5. 避坑指南：本地部署气象大模型最常见的五个翻车现场

5.1 现象：推理结果全是 NaN

原因：多半是输入数据里本身有 NaN，或者归一化时用了错误的统计量导致数值溢出。气象数据在海洋、极地等区域常有缺测值，直接送进模型就会污染整张输出场。

解决：预处理阶段做缺测填充，常用做法是用邻近网格均值或气候态值填补：

data = np.nan_to_num(data, nan=0.0) # 简单粗暴但有效 # 或者更精细：用 xarray 的 interpolate_na ds = ds.interpolate_na(dim="lat", method="linear")

5.2 现象：显存够但跑得极慢

原因：数据在 CPU 和 GPU 之间反复拷贝，或者没开no_grad导致显存被梯度占满，触发显存交换。

解决：确认torch.no_grad()已加；数据一次性搬到 GPU，不要在循环里反复.to(device)；用nvidia-smi -l 1观察显存和 GPU 利用率，如果利用率长期低于 30%，说明瓶颈在数据加载。

5.3 现象：换一台机器结果对不上

原因：CUDA 版本、PyTorch 版本、甚至 cuDNN 版本不同，会导致浮点运算顺序差异，累积后输出有微小偏差。如果偏差很大，多半是归一化统计文件没一起拷过去。

解决：把norm_mean.npy、norm_std.npy、config.json和权重一起纳入版本管理；在requirements.txt里锁死版本号：

torch==2.1.0 numpy==1.24.3 xarray==2023.1.0

5.4 现象：INT8 量化后精度崩了

原因：气象场的动态范围比图像大，直接用图像量化的校准集会导致某些变量（如位势）的量化误差过大。

解决：校准集要用真实气象数据，且覆盖不同季节和区域；对动态范围大的变量单独做 per-channel 量化，不要全局量化。

5.5 现象：模型加载报 key 不匹配

原因：权重文件里的参数名和代码里的模型定义对不上，常见于从不同框架转换过来的权重。

解决：打印权重文件的 key 列表和模型的 state_dict key 列表做对比：

state_dict = torch.load("model.safetensors") print(list(state_dict.keys())[:10]) print(list(model.state_dict().keys())[:10])

差异通常出在前缀（module.）或命名风格（驼峰 vs 下划线），写个映射函数批量改 key 即可。

6. 进阶技巧：让本地气象大模型真正嵌进业务链路

跑通一次推理只是起点，真正要嵌进业务，得解决三件事：批量推理的调度、输出格式的标准化、以及和下游系统的对接。

先说批量调度。业务场景往往要一次跑未来 10 天、每天 4 个时次，共 40 次推理。串行跑太慢，但并行又会爆显存。我的做法是用一个简单的生产者-消费者队列，控制同时推理的批次数：

from concurrent.futures import ThreadPoolExecutor import torch def batch_inference(model, inputs, max_concurrent=2): """控制并发数的批量推理""" results = [] with ThreadPoolExecutor(max_workers=max_concurrent) as executor: futures = [executor.submit(single_infer, model, inp) for inp in inputs] for f in futures: results.append(f.result()) return results def single_infer(model, input_tensor): with torch.no_grad(): return model(input_tensor).cpu().numpy()

max_concurrent要根据显存设，24GB 卡跑 0.25° 网格通常只能并发 2 个，设大了直接 OOM。

再说输出标准化。模型输出是 numpy 数组，但下游系统可能要 NetCDF、GRIB 或 JSON。我一般统一转成 xarray Dataset，带上经纬度和时间坐标，这样下游无论要什么格式都能再转：

import xarray as xr def to_dataset(output_np, lat, lon, variable_names): """把推理输出转成带坐标的 Dataset""" ds = xr.Dataset( {var: (["lat", "lon"], output_np[i]) for i, var in enumerate(variable_names)}, coords={"lat": lat, "lon": lon} ) return ds

最后是验证方法。本地部署最怕“跑出来了但不知道对不对”，我的习惯是拿模型输出和再分析数据做对比，算 RMSE 和 ACC（距平相关系数）：

如果 ACC 低于 0.8，先别怀疑模型，回头查归一化和网格对齐——这两个地方出问题的概率远大于模型本身。

一个血泪经验：本地部署气象大模型，最耗时间的从来不是写推理代码，而是数据预处理和格式对齐。我见过太多人卡在“输入 shape 对不上”上耗一整天。所以我的习惯是，每接一个新模型，先写一个check_shapes.py，把输入输出维度、变量顺序、归一化统计量全部打印出来核对一遍，再写正式推理代码。这个习惯帮我省下的时间，比任何调优技巧都多。

希望帮到你。

本文还有配套的精品资源，点击获取