Transformers 5.23.0统一导出接口为什么不等于各后端性能相同？

Transformers 5.23.0统一了Python导出对象的使用方式，却没有把不同后端的性能和环境要求变成一样。ExportedModel承担调用、保存和重新加载的共同契约，实际执行仍交给Dynamo、ONNX Runtime、OpenVINO或ExecuTorch对应的运行时；旧配置和返回类型的变化，需要与性能宣传分开理解。

共同对象契约覆盖哪几个环节

环节	5.23.0的约定	不应推导的结论
导出	export返回ExportedModel	不能继续默认旧返回类型
调用	按原模型参数调用，保留同类输出	不代表每个模型和后端都无输入限制
保存与分享	可保存并上传Hub，支持仓库子目录	不代表产物与任意硬件都兼容
重新加载	通过后端自身运行时使用导出产物	不代表执行时回到同一个通用解释器

导出产物中的export.json记录配置、输入形状、包版本与输入输出名称。量化导出也采用相同保存和运行方式，但量化配置与对应后端能力仍属于实际运行条件。

接口统一为什么不等于图优化相同

ONNX配置的ort_fusions可以针对cpu、cuda、webgpu或dml，在导出时把图改写为ONNX Runtime的融合算子。OpenVINO导出则能利用其CPU融合内核处理注意力、RoPE、MoE专家及压缩权重。两者使用不同优化路径，不能仅凭相同ExportedModel接口就推断耗时相同。

相关性能对照绑定模型、输入数量与长度、硬件、精度和执行提供程序。它们不能换算为任意模型都会得到的固定加速比例，也不能当作本地环境已经验证的结果。

旧导出代码最明显的三处契约变化

第一，export()的结果是ExportedModel，而ONNX程序使用onnx_ir.Model。第二，OnnxConfig和OpenVINOConfig不再接受output_path，保存方向改为save_pretrained。第三，自定义后端通过register_backend注册。这些变化分别涉及对象类型、保存配置和扩展注册，不能只检查其中一处就认定旧工程完全兼容。

还有哪些独立兼容因素

专家并行的ep_router样式被移除，MXFP4 GPT-OSS专家进入ep_dispatch_experts路径。audio依赖缩减到torchaudio、soundfile、soxr，不再包含librosa与phonemizer；Wav2Vec2ProcessorWithLM以及pyctcdecode、kenlm语言模型解码被弃用。弃用与直接移除是不同状态，不能把两者混写。

模型新增包括Inkling2、JEV、LFM3、Dots 3 Note Preview、LFM3-VL、IQuestCoder和InternLM3。JEV及decision流水线仍实验，接口可能变化；IQuestCoder中使用不同架构的Loop检查点未受支持。架构支持、导出对象和后端优化是三层不同的兼容判断，不能用任何一层的支持声明代替另外两层。