从试验走向生产

推荐运行方式

对固定周期发布的天气产品，先用独立 GPU 批处理任务运行 Earth2Studio。调度器检查输入到齐，启动一次预测，校验输出并发布；网站只读取成功发布的结果。规模较小时，systemd timer 或已有作业调度器加一个受控 worker 足够，不必先引入 Kubernetes。

如果需要多人按需提交不同模型、区域或集合请求，可参考仓库 serve：它提供基于 FastAPI、Redis／RQ 和 worker 的异步服务结构。它是推理作业基础，不等于已经具备你的产品权限、数据发布事务与用户体系。服务说明

生产链路

观察初始资料
    ↓ 到齐且稳定
创建唯一任务 → 等待 GPU → 预测 → 科学校验
                                   ↓
                              编码和打包
                                   ↓
                         上传临时区 → 服务端校验
                                         ↓
                                  完整发布 → 网站读取

每个阶段都有明确状态、截止时间与失败原因。输入没到齐属于等待，网络失败可以重试，单位或坐标不明应停止发布。失败不能清空上次成功结果。

作业身份与幂等

一个任务的逻辑身份至少包含模型／权重版本、起报时间、初始资料身份、预报配置和随机种子。网络重试不应重复创建不同的业务起报；但权重、输入或处理规则改变，应当被识别为不同内容。

调度器要防止同一 GPU 上无上限地同时运行模型。并发成员数由实测峰值显存决定；顺序运行成员、并发保存少量结果，比一次把所有成员塞进显存更容易稳定。大输出分步落盘，不在内存堆积整个运行结果。

运行环境和目录

推荐将程序镜像、模型缓存、初始场缓存、任务工作目录与待上传目录分别管理。镜像内保存程序和依赖，不塞入原始资料、巨大权重或每天变化的预报文件。

• 固定基础镜像 digest、依赖锁、Earth2Studio tag 和模型权重 revision。
• 发布前预热权重并校验下载完整性；生产重启不能依赖临时下载成功。
• 作业使用唯一工作目录，完整产物通过完成标记或原子重命名交给上传器。
• 上传器使用仅有指定 dataset 提交权限的身份；推理进程不需要正式存储管理权限。
• 预测完成后由独立发布步骤负责可见性；半写的 Zarr 目录不能被网站发现。

失败怎样处理

Checkpoint 不是自动获得的可靠性：需要确认模型隐藏状态、随机数状态、输出游标及 IO 写入均可恢复。尤其是概率模型，不能只保存当前物理场就假定可重现原来的后续轨迹。工作流与 checkpoint

监控哪些指标

除了 CPU、GPU、显存和磁盘，还应记录输入资料迟到时长、预报产生时长、最新成功起报、各变量缺测率、上传积压、发布失败率以及不同阶段重试次数。日志关联 job ID 与 run ID，但不记录凭据、访问令牌或带签名的 URL。

为 meteo 业务制定的 SLA 应以“完整结果什么时候可被读取”为终点，而不是以最后一次 GPU 调用结束为终点。数据服务、身份服务和存储需要备份恢复演练；单台服务器上的多个容器不是多机容灾。

不建议第一次就做的事

同时部署所有模型；从零训练全球模型；把全球高分辨率多成员数据全部送到浏览器；让网站请求触发推理；用临近预报的区域模型替代全球中期模型；在没有验证初始场和统计定义时直接发布异常或事件概率。