《Applied Computing and Geosciences》：Interoperability in Earth Observation deep learning: A cross-language and cross-framework evaluation
开放神经网络交换（ONNX）被广泛宣传为一种独立于框架的深度学习模型可移植性解决方案，但对于地球观测（EO）工作流而言，其在不同语言、框架与部署环境中的可靠性，仍缺乏系统性证据。本文提出了一种用于评估EO深度学习模型ONNX推理可移植性的八步评估协议，并在已文档化的软件条件下通过两个案例研究加以展示。对于TempCNN作物类型分类器，无论是从PyTorch还是Flux导出，原生推理与ONNX推理之间的偏差均控制在10?6均方根误差（RMSE）以内；并且在CUDAExecutionProvider下，Python、R与Julia三种运行时环境中的跨运行时输出达到逐位一致（bitwise-identical）。对于ConvLSTM降水临近预报模型，研究人员测试了三条转换路径：基于PyTorch后端的Keras 3路径（KPT）通过了全部八个协议步骤，包括直接计算得到的RMSEport=2.81×10?7；另外两条路径则需要额外变通方案，或者在原生回导入时受阻。研究结果表明，在所测试配置下，ONNX的可移植性具有架构依赖性。由常见算子构成的静态卷积模型可以实现干净迁移，而具有显式时间循环的循环模型则暴露出不同失效模式，因而需要依据工具链开展专门验证。该协议当前经验证的适用范围覆盖这两类架构及相应软件条件；对于其他模型家族，其表现仍需通过重新应用该协议加以确认。
本文发表于《Applied Computing and Geosciences》，聚焦地球观测（Earth Observation, EO）深度学习模型在跨语言、跨框架环境中的互操作性问题，核心讨论开放神经网络交换（Open Neural Network Exchange, ONNX）能否作为EO模型的通用推理交换格式。研究背景在于，随着Sentinel等开放卫星计划、数据立方（data cube）基础设施以及openEO、STAC、STAC-MLM等标准的发展，EO数据与元数据层面的互操作性已有显著进展，但模型执行层面的互操作性仍然薄弱。现实中，训练好的深度学习模型通常绑定于特定框架、版本与编程语言，这与大规模生产部署、联邦平台共享及受数据治理约束的本地离线运行需求之间形成明显矛盾。尤其是在EO场景中，模型往往需要面向海量像元、多时相序列和高频更新任务进行推理，因此“模型能否跨环境稳定运行”是工程上的关键问题，而非纯理论问题。
研究人员正是在这一背景下开展工作。论文围绕两个互补问题展开：其一，固定ONNX制品在Python、R、Julia三种主流空间数据科学语言中的运行时可移植性；其二，含显式时间循环的循环神经网络在不同导出工具链中的跨框架可移植性边界。为此，研究人员提出了一套八步评估协议，依次检查导出成功、图结构有效性、运行时兼容性、输出层数值保真度、层级保真度、任务指标保持性、回导入可行性以及版本与opset约束记录。论文的主要意义在于，将“成功导出”“可稳定推理”“可双向转换”“可重复部署”这些经常被混用的概念严格区分，并通过实证展示：导出成功并不等于可移植，图结构合法也不等于推理忠实，ONNX的表现高度依赖模型计算图是否包含动态控制流。
方法上，研究人员选择了两个具有代表性的EO时空深度学习架构作为案例。第一个案例是TempCNN时间卷积网络，用于BreizhCrops数据集上的Sentinel-2作物类型分类。该模型完全由静态卷积、批归一化（Batch Normalization, BN）、激活、展平和全连接层构成，没有循环状态，是ONNX导出的理想测试对象。第二个案例是ConvLSTM，用于荷兰KNMI雷达降水序列的临近预报，该模型含显式时间展开与循环状态传递，能够暴露ONNX在动态控制流表示方面的困难。通过这两个架构，论文形成了“静态图模型”与“循环时序模型”的鲜明对照。
用于开展研究的关键技术方法主要包括三部分。首先，研究人员构建了统一的八步ONNX可移植性评估协议，并以onnx.checker.check_model、Netron、RMSE
port、MAE
port、层级激活偏差分析和回导入测试作为核心评估工具。其次，在TempCNN实验中，样本来自法国布列塔尼BreizhCrops基准数据集，Python作为统一预处理环境，随后分别在PyTorch、R torch与Julia Flux中实现结构等价模型，并比较同一ONNX制品在Python、R、Julia ONNX Runtime中的推理一致性。再次，在ConvLSTM实验中，样本来自荷兰皇家气象研究所（KNMI）RAD: NL25-RAD-2.5雷达数据，研究人员设置KTF、KPT与PT三条导出路径，对动态控制流、opset兼容性、重导入能力与数值稳定性进行逐项验证。
在研究结果部分，论文以多个小节系统呈现证据。
5.1.1. Training behavior and native model performance
研究人员首先比较了TempCNN在三种语言生态中的原生训练表现。结果表明，Python/PyTorch、R torch与Julia/Flux三种实现均能够顺利收敛，但聚合精度、加权F1与Cohen’s κ并不完全相同。这些差异被明确归因于后端实现、张量布局和默认初始化策略差异，而不是ONNX可移植性本身。作者借此强调：跨语言原生模型间的训练差异，不应与固定ONNX制品的推理一致性混淆。
5.1.2. Per-class performance
在FRH04独立测试区的分类任务中，不同类别的F1分数整体相近，但向日葵、坚果等极少样本类别接近零分。研究人员指出，这反映的是标注稀缺和光谱可分性不足，而不是移植失败。因此这些类别不应用于判断可移植性优劣。该分析体现出论文对数据集偏倚与方法学解释边界的严格控制。
5.1.3. ONNX export and structural validation
对于TempCNN，PyTorch与Flux均能成功导出ONNX模型，且通过图结构校验。R torch则无法在测试条件下提供自洽的原生导出路径，只能作为推理消费者参与。Netron可视化显示，PyTorch与Flux导出的图在输入转置、展平策略以及输出头结构上存在明显差异，例如Flux图包含Transpose及显式LogSoftmax节点，而PyTorch图以Gemm结束。但这些结构差异并未影响最终推理结果。研究人员据此指出，图拓扑相似性不能替代数值保真度评估，结构检查与推理一致性检查必须分离。
5.1.4. Numerical fidelity at output level
这是TempCNN部分最关键的结论之一。对于相同训练权重的“原生推理—ONNX推理”比较，PyTorch与Flux的RMSE
port均处于10
?6量级；而同一ONNX制品在Python、R、Julia三种运行环境中的ONNX Runtime输出差异低于10
?12，达到逐位一致。论文进一步解释，三种语言环境实际共享同一C++ ONNX Runtime引擎，并在CUDAExecutionProvider下执行相同序列化计算图，因此在给定硬件配置下可获得完全一致输出。这一结果强有力地支持了静态卷积EO模型在跨语言运行时中的高可移植性。
5.1.5. Layer-wise numerical fidelity
研究人员进一步比较中间层激活，检验最终输出接近是否只是下游误差抵消的结果。TempCNN各层均值与方差偏差处于10
?6至10
?5%量级，且不表现为随深度单调累积。由此可见，ONNX并未在中间层引入系统性表示漂移，满足协议中关于层级保真度的要求。
5.1.6. Spatial prediction consistency
在空间预测图层面，原生PyTorch与ONNX Runtime推理生成的作物类型图在视觉上不可区分，说明输出层数值一致性已经转化为业务上等价的空间制图结果。对于EO应用而言，这意味着ONNX不仅在统计指标层面保真，也能保持实际地图产品的一致性。
5.1.7. Cross-framework re-import assessment
在回导入测试中，PyTorch导出的ONNX模型可被Flux重新导入，Flux导出的ONNX模型也可被PyTorch通过onnx2torch重新导入，且重导入后模型推理结果与原始模型一致。这一结果表明，对于由标准静态算子构成的卷积时序分类模型，ONNX不仅是单向部署格式，还可以作为真正的双向交换格式。
5.1.8. Cross-language runtime summary
基于上述证据，研究人员总结：一旦TempCNN的有效ONNX制品生成成功，其在Python、R和Julia中的推理行为极其稳定，且具备双向回导入能力。不过语言间导出能力并不对称——Python与Julia可导出，R不能原生导出，这暴露出当前EO工具生态的结构性缺口。
5.2.1. Forecast quality by lead time
在ConvLSTM降水临近预报实验中，KTF与KPT在全部18个预报时效上的RMSE曲线高度接近，而原生PyTorch路径（PT）在t+5 min和t+90 min处表现出边界性升高。研究人员强调，这些结果只能被理解为具体实现管线的综合表现，不能归因于单一框架优劣，因为三条路径在后端、接口层和归一化默认设置上同时不同。
5.2.2. Training and validation behavior
三种ConvLSTM实现均在25个epoch内收敛。KTF与KPT在平均任务RMSE上极为接近，显示当Keras 3接口保持一致时，后端切换未显著改变整体预测质量。PT虽具有最低验证损失，却呈现最高平均任务RMSE，提示验证损失与长时距预报质量并不完全一致。这一观察为后续分析其内部表示差异埋下伏笔。
5.2.3. ONNX export outcomes and version compatibility
这是ConvLSTM部分的核心。研究人员归纳出四类失败模式。第一类是动态控制流问题：KTF使用的tf.while_loop无法直接映射到静态ONNX有向无环图，导致直接导出失败，只能借助SavedModel→tf2onnx的变通路径。第二类是算子覆盖缺口：PT虽然可以通过torch.onnx.export静态展开导出，但后续转TensorFlow需固定在opset 11，opset 13和17会因onnx-tf版本中的算子实现缺失而失败。第三类是回导入失败：KTF经tf2onnx生成的ONNX Loop算子无法被onnx2torch支持，因此只能单向部署。第四类是布局不兼容：PT导出的通道优先（NCDHW）布局不能被onnx2tf处理，且缺少维度语义标注（dimension denotation）进一步放大了转换失败风险。相比之下，KPT在测试条件下避开了上述四类问题，顺利通过所有八步评估，是该研究中ConvLSTM最成功的导出路径。
5.2.4. Intermediate activation divergence
中间激活分析揭示了更细微的差异。KPT相对于KTF在深层递归块中出现了数十个百分点级别的均值和方差偏差，最高达到L4层均值+32.2%、方差+83.7%。但这种偏差并不呈单调累积模式，且最终被Conv3D解码器吸收，输出层RMSE
port仍低至2.81×10
?7。因此KPT在协议第5步属于“模式通过但幅度需备注”的情形。PT则表现出更严重的偏移：从L1开始均值和方差就与KTF基线存在数百至数千百分比的差异，并在前几层呈广义递增趋势，符合误差累积的失败特征，故在层级保真度上不通过。研究人员认为，造成这种差异的原因无法由当前设计完全分离，但界面层行为与归一化默认参数差异是最可能的解释。
5.2.5. Output predictions at selected horizons
在t+5和t+45 min时，三条ConvLSTM路径的空间预测图相近；到t+90 min时，PT模型的降水结构明显更弥散，与其末端时效RMSE升高一致。这表明内部表示差异最终会在长时距预测阶段体现为空间结构上的退化。
5.3. Comparative overview
综合两项案例，论文得出最关键的总括性结论：ONNX可移植性不是框架属性，而是架构属性。静态卷积型TempCNN在导出、推理、跨语言执行和回导入方面均表现优异；含显式时间循环的ConvLSTM则暴露出动态控制流、算子覆盖、布局和回导入障碍等多类问题。KPT之所以成功，不是因为某个框架“更好”，而是因为其导出路径以静态展开方式构造出可兼容的计算图。由此，研究人员将“计算图是否包含动态控制流”确立为实践中最优先的诊断问题。
讨论部分进一步提炼了方法论与实践启示。对于TempCNN案例，研究人员指出三点：第一，图结构拓扑差异并不能预测推理是否一致，因此必须进行输出层和中间层定量核查；第二，跨运行时等价性依赖于特定执行提供器（execution provider），本文结论仅在CUDAExecutionProvider与测试GPU上得到验证，对CPU环境仍需独立复核；第三，R调用ONNX Runtime并非原生绑定，而是通过reticulate代理Python C++后端，因此R更适合作为推理消费端，而非独立部署端或导出端。对于ConvLSTM案例，论文提出清晰的失败分类学：导出成功与可回导入并非同义，动态控制流、算子缺失、回导入阻塞和布局不兼容构成诊断 recurrent EO 模型ONNX可移植性的四大类别。对于实际部署，作者强调版本记录不可或缺，framework、converter、runtime、opset乃至onnxsim这类图简化工具版本都应随制品共同发布；同时，R生态尚缺乏原生ONNX导出通道，这是一个现实且结构性的工具缺口。
论文结论部分可译述如下：研究的核心发现是，ONNX的可移植性具有架构依赖性，而仅凭导出成功无法揭示这一点。真正决定模型能否顺利迁移的，并非其训练所用框架，而是其计算图是否包含动态控制流。本文提出的八步评估协议将这一差异转化为可复现的诊断流程，明确区分了导出成功、推理保真与回导入可行性。对于测试的静态卷积架构，在文档化软件条件下，ONNX表现为可靠的推理交换格式：来自PyTorch和Flux的制品均能以10
?6量级RMSE重现原生推理，并在Python、R、Julia三种运行环境下实现逐位一致输出，且支持双向回导入。对于ConvLSTM，决定性结论则是结构性的：Keras 3-on-PyTorch路径通过了全部八步，而TensorFlow路径与原生PyTorch路径至少各有一步失败，且这些失败均源于显式时间循环所引入的动态控制流问题。因而，对任何循环型EO模型而言，在尝试导出之前，首要诊断问题都应是其计算图是否包含动态控制流。总体而言，八步协议的价值正在于提醒实践者：导出成功不等于可移植，只有逐步完成结构、数值、任务与版本层面的验证，ONNX制品才真正具备可信的部署价值。
