Validation-Centric AI-Assisted GPU Porting of a 250,000+ Line Legacy Weather Simulation Code
Tetsuya Hoshino, Masaya Kato, Kazuhisa Tsuboki, Daichi Mukunoki, Takahiro Katagiri, Toshihiro Hanawa
cs.DC
2026-08-13
名古屋团队用 CLI AI 代理把 25 万行 CReSS 天气模拟按验证优先流程移植到 GH200,162 个核心全部过逐点数值校验,台风模拟提速 5.1 倍,还揪出 5 个浮点差异。
HPC 集群全面转向 GPU,但支撑气候与灾害研究的科学程序大多是几十万行的 Fortran 老代码,靠 MPI/OpenMP 并行,人工移植动辄以年计。麻烦在于这类程序不是普通遗留代码:CReSS 从 1998 年开发至今,可靠性来自二十多年与观测数据的反复比对。移植目标不是让 AI 重写一份新代码,是把已有实现搬到 GPU 上,同时不能丢掉积累多年的科学有效性。
难点具体在哪。AI 生成的改动必须与 CPU 原版行为核对,而有效输入产生于初始化、物理过程和配置分支,随机造数据测不出真实模拟状态下的行为。GPU 并行还会改变求值顺序和内部函数实现,CPU 与 GPU 逐位不一致是常态,开发者要判断每个差异是可接受的数值扰动还是移植 bug。天气模拟对这点尤其敏感,微小差异会随时间累积,最终翻转条件分支。
工作流分六阶段:代码元审查、profiling、抽核与 CPU 基准生成、核级 GPU 变换、集成、性能验证。AI 代理负责重复性产物生成,人类定验证标准、管规格、解读数值差异。三个关键设计:
核级过了还不够,集成后要跑完整 360 步,看最大最小扰动压力与开发者给定的参考值偏差是否都在 1e-4 以内。
| 指标 | 结果 | 参照 |
| 应用级加速 | 5.1×(每步 1.88s vs 9.51s) | 72 线程 Grace CPU 基线;H100 与 CPU 内存带宽比约 8× |
| 162 个核 | 全部过 dump 逐点校验 | 387 个 OpenMP 区中该台风场景实际执行的子集 |
| 数值差异 | 5 个核的单点差异 | 均为浮点/内部函数差异,非移植 bug |
| 显存带宽利用率 | 35–60% | 162 核逐个 Nsight profiling |
| 开发成本 | 约 100 GPU 节点时,三个月 | 人工移植通常按月到年规划 |
5 个差异里有 3 个是阈值敏感分支:bruntv.f90 里温度算出 233.16002 K(CPU)对 233.16000 K(GPU),恰好差在阈值 233.16 K 两侧,潜热修正项只在 GPU 上生效。disptke.f90 差 25 ulp,指向 exp/log/sqrt 的内部函数实现差异被相消放大。这些结论反馈给了 CReSS 开发者,单看应用级输出几乎不可能定位到这一层。
对维护大型科学代码的团队,这篇给出的可迁移经验有三条。验证优先的工作流把 AI 当加速器而非替代者,AI 做的是把人工做起来极贵的逐核 dump 校验自动化到可执行;编译器诊断当变量发现器,一行编译选项换来高成本失败的前移;流程规则和恢复策略写成规格文档持久化,AI 会话跨边界续跑时约束不丢。对照实验里,只用初始提示词的 5 次运行 3 次收敛,规格文档常驻的 5 次全收敛,再加「一次 dump 失败先批量检查同类变量再重跑」的规则,dump 执行次数从最多 7 次压到 1–3 次。
作者自己列得很清楚:快照式核校验只覆盖选定 dump 点的状态,不证明 162 个核的全部控制路径正确,集成阶段确实出现过基准漏掉某分支、快照没暴露、集成后才现形的案例;单个测试用例、单步、单 MPI 进程的最小 dump 就超 400 GB,扩场景必须有 dump 数据的生命周期管理;Unified Memory 加保守的核内局部修订换来了可验证性,显式数据管理、异步执行、核融合这些更激进的优化全留作未来工作,8× 的带宽比只兑现 5.1× 也部分源于此。另外 100 节点时是人类监督下的探索性时间,不能直接当无人值守的生产成本;失败模式基于 Claude Code Opus 4.5–4.6 观察得出,换模型未必复现,但「运行时状态重建、跨会话上下文、成本感知恢复」这三类成本本身不依赖具体模型。