Transformers 5.23.0的新模型支持、JEV实验接口与Loop检查点有哪些边界？

Transformers 5.23.0新增模型支持时，也保留了实验功能和架构变体的边界。JEV及decision流水线仍属实验；IQuest-Coder-V1常规模型可以加载，名称含Loop的检查点却不受支持。与此同时，导出对象改为ExportedModel，音频依赖和部分并行接口有兼容变化，不能把“支持新模型”理解成全部旧工程无需调整。

多模态模型新增了哪些接入对象

Inkling2支持来自Thinking Machines Lab的Inkling 2 Small，它接受文本和图像输入并生成文本。Dots 3 Note Preview支持原生文本、图像、视频和音频输入，并支持BF16与FP8推理。LFM3是混合短卷积与注意力的模型家族，LFM3-VL则结合视觉编码器、投影层与LFM3语言模型处理图像和视频。

这些描述区分了模型家族的输入与结构，并不是它们在所有任务上的效果排名。库提供架构支持，也不意味着任意硬件具备相同内存、精度和运行时条件。

为什么同一家族仍有不支持的检查点

IQuest-Coder-V1提供7B、14B和40B等规模及base、instruct、thinking变体，常规架构与Llama一致，自动类利用LlamaModel或LlamaForCausalLM加载，配置类则为IQuestCoderConfig。但Loop检查点使用不同架构，不在支持范围内。模型名称相近不能替代架构兼容判断。

InternLM3同样通过Llama实现加载，保留专用配置类。其配置中的qkv_bias及bias分别映射到注意力与MLP偏置，并要求两者一致。可加载的模型架构与配置约束需要一起理解。

JEV为什么不宜当作稳定决策接口

JEV是对单Token标签评分的决策头，支持通过实验decision流水线或decide调用。JEV与decision流水线的API、配置和行为都可能在后续开发中改变，因此不能仅凭加入5.23.0就把它们当成固定不变的生产契约。

模型支持与导出后端是两个维度

5.23.0的export()现在返回ExportedModel，可按原模型的参数调用并保留同类输出；统一接口覆盖Dynamo、ONNX Runtime、OpenVINO和ExecuTorch。导出对象能保存、上传Hub并在对应后端运行时加载。export.json还记录输入形状、配置、包版本及输入输出名称。

统一对象不代表所有模型自动支持每个后端，更不代表更换后端后无需确认实际输入约束。OnnxConfig和OpenVINOConfig的output_path已移除，保存方向改为save_pretrained，自定义后端使用register_backend。

哪些已有环境仍可能需要迁移

audio可选依赖缩减为torchaudio、soundfile、soxr，移除librosa和phonemizer；Wav2Vec2ProcessorWithLM及pyctcdecode、kenlm语言模型解码被弃用。ep_router专家并行样式也被移除，MXFP4 GPT-OSS专家改用ep_dispatch_experts路径。这些变化与是否使用新模型没有直接等价关系，旧任务也可能依赖相关接口。

理解5.23.0时，模型架构、检查点变体、实验API和后端产物需要分别对应。性能展示则带有具体硬件、模型和输入条件，不能把单个演示结果推及全部模型。