Earth2Studio 评测：用几行 Python 统一调度 AI 天气模型

它解决什么问题，写给谁用

Earth2Studio 解决的问题很具体：AI 天气预测模型的接入成本。每个模型有自己的权重格式、输入变量和预处理逻辑，数据源又分 GFS、ERA5、IFS 等，输出格式还可能是 Zarr 或 NetCDF。没有统一层的话，换一个模型就要重写一半代码。这个框架把模型包装成一致的 Python 类，数据源和输出后端也做成可替换的接口。目标用户是研究人员、数据科学家和做气候应用的工程师，他们想快速跑通一个预报流程，而不是研究某个模型的内部实现。文档强调“快速上手”，几个示例都是十行以内的代码。

核心机制：模型、数据、IO 三件套

从 README 的示例能看出它的架构，核心是三个组件。模型类放在 earth2studio.models.px 下，比如 FCN3、AIFS、GraphCastOperational，每个都有 load_model 和 load_default_package 方法。数据源在 earth2studio.data 下，GFS 和 IFS 是两个示例。输出用 earth2studio.io 的 ZarrBackend。最后通过 earth2studio.run.deterministic 把三者串起来，传入起始时间、预报步数和这些对象。这个设计把数据流固定成“时间加模型加数据加输出”的管道，组件之间不互相依赖，所以可以随意替换。例如 GraphCast 的示例用了 GFS 数据，而 AIFS 示例用了 IFS 数据，说明同一套 run 函数能适配不同来源。

快速上手：三个真实示例的代码

安装和运行在 README 里有明确路径。它支持 Python 3.11 到 3.14，默认安装从 0.14.0 起面向 CUDA 13。快速开始的第一个示例是 FourCastNet3，代码如下：from earth2studio.models.px import FCN3；from earth2studio.data import GFS；from earth2studio.io import ZarrBackend；from earth2studio.run import deterministic as run；model = FCN3.load_model(FCN3.load_default_package())；data = GFS()；io = ZarrBackend("outputs/fcn3_forecast.zarr")；run(["2025-01-01T00:00:00"], 10, model, data, io)。AIFS 的示例把模型换成 AIFS，数据换成 IFS，步数改成 10。GraphCast 示例用 GraphCastOperational，步数是 4。注意每个模型需要单独安装依赖，README 提到“model-specific installations”在安装指南里。此外还有 agent 辅助安装，通过 npx skills add 添加 earth2studio-install 等技能，让 Claude 或 Codex 这类工具帮你配置环境。

模型库的广度与第三方许可证问题

README 声称拥有“最大的天气/气候 AI 模型动物园”，并列举了最新加入的模型：Microsoft Aurora v1.5、StormCast CONUS、StormScope NSRDB 等。模型覆盖确定性预报、集合预报和诊断模型。但这里有个关键限制，这些模型和数据集大多属于第三方。README 用 IMPORTANT 警告明确说，Earth2Studio 只是接口，模型的许可证归各自提供方所有，用户必须自行确认下载、使用和再分发的权利。这意味着框架本身是 Apache-2.0，但实际跑起来，每个模型和数据集都可能附带不同许可证。例如 GFS 数据来自 NOAA，AIFS 来自 ECMWF，使用条款并不统一。这个责任完全落在使用者身上，框架不替你处理。

数据源扩展：从云存储到 Icechunk

除了标准数据源，新版增加了 Dynamical.org 和 EarthMover 的数据源。Dynamical.org 提供从匿名 Icechunk 仓库读取的 AIFS、GFS、GEFS、HRRR、MRMS、ICON-EU、IFS-ENS 等数据。EarthMover 提供 ERA5 0.25 度再分析和 IFS 0.1 度预报数据。这些数据源通过 earth2studio.data 模块暴露，和模型一样可替换。设计上，数据源返回的是统一的张量接口，所以换数据源不需要改模型代码。但要注意，这些数据源依赖外部服务，比如 Icechunk 仓库或 BrightBand 的托管，可用性和访问速度取决于这些服务，不是框架能控制的。如果某个数据源停服，你的管道就会中断。

一个明显的局限：推理框架，不是训练框架

Earth2Studio 定位是“AI inference pipeline toolkit”，文档明说它是推理管道工具包。它不提供训练功能，训练配方在另一个仓库 PhysicsNeMo 里。这意味着如果你想微调模型或从零训练，这个框架帮不上忙。另外，run 函数是确定性的，虽然 README 提到 Aurora v1.5 有 ensemble 模型包装，但整体设计偏向跑预报，而不是做实验性的模型开发。另一个限制是模型依赖的安装可能很重，每个模型有特定依赖，比如 FourCastNet3 和 GraphCast 的依赖可能冲突，你需要用虚拟环境隔离。文档没有给出解决依赖冲突的具体方法，只提示看安装指南。

替代方案：直接调用模型库与物理约束工具

如果不想引入 Earth2Studio 的抽象层，可以直接使用模型各自的官方实现。例如 GraphCast 的原始仓库提供独立的 Python API，你需要自己处理数据下载和预处理。另一个替代是 NVIDIA 的 PhysicsNeMo，它提供训练和推理的底层工具，但学习曲线更陡。差异在于抽象层级：Earth2Studio 把数据、模型、IO 统一成 run 函数，直接调用则要你手动拼接每个环节。前者的好处是替换组件快，后者的好处是减少一层依赖，更容易调试。对于只跑一个模型的用户，直接调用可能更简单；对于要对比多个模型的用户，Earth2Studio 的交换成本更低。

维护成本与升级风险

Earth2Studio 的发布节奏很活跃，从 2026 年 5 月到 7 月连续发布 0.15.0、0.16.0、0.17.0，每月一版。这带来两个问题。一是 API 可能变化，比如 0.14.0 把默认安装改成 CUDA 13，升级旧环境时需要重新配置。二是模型包装需要跟上上游模型更新，如果某个模型更新了权重格式，框架必须发新版适配。README 提到 changelog 文件，说明维护者重视变更记录，但使用者仍需在升级时检查模型 API 是否变动。许可证方面，框架是 Apache-2.0，允许商用和修改，但第三方模型和数据集的许可证不受此保护。

编辑结论

Earth2Studio 适合需要快速对比多个 AI 天气模型、或希望以统一代码接入 GFS、ERA5 等数据源的研究者和工程团队。它不适合只需跑单个模型、且不想引入额外依赖层的用户，也不适合对第三方模型许可证没有把握的团队。采用前先核对目标模型的许可证，确认其数据源（如 GFS 或 IFS）在你所在地区的可访问性，并验证 CUDA 13 默认安装与现有环境的兼容性。该框架的价值在于组合与替换，而非单一模型的性能。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes