美国国家海洋和大气管理局（NOAA）选择 Google Cloud 作为天气与气候业务超级计算系统（WCOSS）的主要高性能计算基础设施提供商。这不只是一次机房搬迁，而是业务级数值天气预测（Numerical Weather Prediction，NWP）从传统本地超算向云优先架构转型的重要案例。
天气预报系统必须在固定时间窗口内处理海量观测数据、运行紧密耦合的数值模拟，并及时生成可供预报员和公共安全机构使用的产品。因此，云端 HPC 能否成功，关键并不在于“能启动多少虚拟机”，而在于计算、网络、存储和作业调度能否作为一个整体稳定运行。
为什么天气模拟需要专门的 HPC 架构
数值天气预测会把大气划分为三维网格，在每个时间步中计算温度、气压、湿度、风场等变量的变化。网格越细、集合成员越多、预测周期越长，计算量和节点间通信量就越大。
这类负载通常具有三个鲜明特点：
- 高度并行：一个模型作业可能跨越大量 CPU 核心和计算节点。
- 通信密集：相邻网格之间需要频繁交换边界数据，MPI 集合通信也会不断同步全局状态。
- 时间约束严格：预报结果晚几个小时产生，即使数值精度很高，业务价值也会显著下降。
NOAA 采用由第五代 AMD EPYC 处理器驱动的 Google Cloud H4D 虚拟机，正是为了获得计算密集型模拟所需的处理能力和低延迟网络。这里的低延迟不是附加优化，而是决定多节点扩展效率的核心条件：如果每个时间步都要等待跨节点通信，再多 CPU 也可能被同步开销抵消。
评估此类平台时，不能只比较单节点基准成绩。更有意义的指标包括：
- 相同模型网格下的端到端运行时间；
- 从 1 个节点扩展到多个节点后的并行效率；
- MPI AllReduce、All-to-All 和邻域通信延迟；
- 检查点、初始场和预报产品的读写吞吐量；
- 连续业务周期中的作业成功率和完成时间波动。
从固定超算转向云优先，改变的不只是容量
传统超级计算系统通常按照多年后的峰值需求采购。硬件交付后，容量基本固定，新增模型、提高分辨率或扩大集合预报规模都要争夺同一批资源。云端 HPC 则允许团队按业务周期组织资源，并更快测试新的模型版本和计算配置。
这种弹性尤其适合研发与业务并行的场景。研究人员可以建立隔离的实验环境，验证新物理参数化方案或模型分辨率，而不必长期占用生产集群。通过验证的工作负载再进入严格受控的业务环境，有助于缩短科研成果转化为预报能力的周期。
不过，“云优先”不等于简单地按需创建实例。业务级气象平台仍然需要明确设计以下边界：
- 容量保障：关键预报周期不能完全依赖临时可用容量。
- 数据位置：输入数据、模型输出与计算节点距离过远会放大 I/O 延迟和传输成本。
- 环境可复现性：编译器、MPI、数学库和模型参数必须被版本化。
- 故障恢复：长时间模拟需要检查点机制，避免单个节点故障导致整轮重算。
- 成本治理：弹性资源必须配合预算、配额、标签和自动回收策略。
对 NOAA 而言，迁移的价值还来自长期积累的云端数据协作经验。双方此前已经围绕海量环境数据共享、实时野火跟踪、海洋保护和科研计算试点开展合作。这些项目降低了从单项实验进入核心业务系统时的组织和数据治理风险。
可以这样实践：先测量紧密耦合通信能力
在迁移真实天气模型之前，可以先用一个小型 MPI 基准测试验证集群的调度、主机发现和集合通信。下面的 Slurm 作业会在多个节点上编译并运行 OSU Micro-Benchmarks 的 osu_allreduce 测试。
运行前需要准备一个已安装 Slurm、C 编译器、git 和 OpenMPI 的 HPC 集群。将 --nodes、--ntasks-per-node 和 --partition 改成当前环境的配置：
#!/usr/bin/env bash
#SBATCH --job-name=mpi-allreduce
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=8
#SBATCH --partition=compute
#SBATCH --time=00:15:00
#SBATCH --output=mpi-allreduce-%j.log
set -euo pipefail
module load gcc
module load openmpi
WORKDIR="${SLURM_TMPDIR:-/tmp}/osu-${SLURM_JOB_ID}"
mkdir -p "$WORKDIR"
cd "$WORKDIR"
git clone --depth 1 https://github.com/forresti/osu-micro-benchmarks.git
cd osu-micro-benchmarks
./configure CC=mpicc CXX=mpicxx
make -j"$(nproc)"
BINARY="./c/mpi/collective/blocking/osu_allreduce"
TASKS="$((SLURM_NNODES * SLURM_NTASKS_PER_NODE))"
srun --mpi=pmix \
--nodes="$SLURM_NNODES" \
--ntasks="$TASKS" \
"$BINARY"
提交并查看结果：
sbatch mpi-allreduce.slurm
squeue --me
cat mpi-allreduce-<job-id>.log
不同 Slurm 与 MPI 组合使用的启动参数可能不同。如果集群没有配置 PMIx，可以根据平台文档调整 srun --mpi=pmix，或使用集群提供的 mpirun 启动方式。
这个测试不能代替真实天气模型基准，但能快速暴露几个基础问题：节点是否被正确分配、MPI 是否能跨节点启动、消息尺寸增大后延迟是否异常，以及多节点集合通信是否稳定。下一步应使用代表性的模型网格进行强扩展测试，记录节点数量、总核数、运行时间和并行效率：
并行效率 = 单节点运行时间 /（节点数 × 多节点运行时间）
如果节点数增加后运行时间下降很少，应进一步分析通信等待、负载不均衡、内存带宽和文件系统 I/O，而不是继续盲目扩容。
AI 预报模型与物理模型更可能形成组合系统
摘要还提到 NOAA 曾使用 Google DeepMind 和 Google Research 的 WeatherNext 模型支持飓风路径与强度预测，并探索由 Gemini for Government 支撑的智能体应用。这说明云平台的角色正在从承载传统数值模拟，扩展到连接数据处理、机器学习推理和业务工作流。
但 AI 模型不应被简单描述为物理模型的直接替代品。更现实的架构是让不同方法承担不同任务：
- 物理模型提供受方程约束、可持续校准的基础预报；
- AI 模型用于快速生成候选预报、偏差订正或集合后处理；
- 智能体协助检索数据、触发工作流和整理分析结果；
- 预报员继续负责解释不确定性并作出高影响决策。
涉及飓风、洪水和野火的系统属于高风险公共服务。上线 AI 能力时，应保存输入数据版本、模型版本、提示词、工具调用与输出结果，并建立人工复核和降级路径。一次成功案例能够证明潜力，但不能代替跨季节、跨区域和极端事件条件下的系统评估。
迁移时应盯住哪些指标
云端 HPC 的成败最终要由业务结果衡量，而不是由实例数量衡量。实施团队可以围绕下面的检查表推进：
- 用真实模型建立单节点和多节点性能基线；
- 测量完整预报周期，而不只测计算内核；
- 为关键时段建立容量预留和跨故障域策略；
- 将编译参数、依赖库、容器镜像和输入数据统一版本化；
- 为检查点、热数据和长期归档设计不同存储层；
- 对资源设置标签、预算告警、配额和自动清理规则；
- 在影子运行阶段并行比较新旧系统的结果、耗时与稳定性；
- 为 AI 输出建立可追溯记录、人工审核与回退机制。
NOAA 的转型表明，公共云已经开始承载对延迟、规模和可靠性要求极高的业务级数值天气预测。真正值得借鉴的并非单一虚拟机型号，而是把 HPC 计算、低延迟网络、环境数据和科研工作流放进同一套可扩展、可验证的运行体系。对于其他科研机构，稳妥路径仍然是从代表性基准和非关键工作负载开始，用数据证明扩展效率，再逐步进入有明确完成时限的核心业务。