Hugging Face 的模型运行库新增了可同时接收文本、图像、音频和视频的 Meta 模型，以及无需允许外部代码即可加载的 InclusionAI 模型。将模型接入服务的开发者可以扩展输入类型，或简化此前依赖独立模型实现的加载流程。
1. 扩展输入与整合加载是不同的变化
2026年10月15日发布的 Transformers v5.20.0 发行说明将对这两个模型的支持列为新功能。这意味着库中新增了加载并使用这些模型的路径，并非宣布两个模型的速度都得到了提升。
Meta 的 Muse Spark Open 接收四种输入并生成文本。它针对多文件修改、调试和工具调用等编程任务进行了训练。例如，可用于将代码与截图或录屏一同输入的任务。
InclusionAI 的 Ling 3.0 Flash 是混合专家语言模型，会为每个输入片段选择部分计算网络。此次变更的核心在于，无需开启信任设置以执行外部仓库的模型代码，即可通过库内置的实现加载模型。
2. Ling 的加载与优化需分别核查
文档给出的模型类是 BailingHybridForCausalLM。使用示例展示了通过 AutoModelForCausalLM 加载已保存的模型、按对话格式构建输入，再生成回答的流程。
模型内部的部分计算包含仅依赖 PyTorch 即可运行的替代实现。这条路径可在不安装额外优化包的情况下执行相关计算。
安装 flash-linear-attention 和 causal-conv1d 后，在 NVIDIA GPU 的 CUDA 环境中会自动使用优化后的计算代码。这是可选的优化路径，并非加载模型的必要步骤。
3. Muse 也整合了输入准备流程
MuseSparkProcessor 将文本切分为模型输入单元 token 的处理、图像与视频及音频预处理、对话格式转换整合在一起。开发者可以将不同类型的输入组织为对话形式，再传给模型。
上下文窗口是模型一次可处理的输入范围，最大为 1,048,576 个 token。文本以及由图像、视频和音频生成的 token 共同占用这一范围，因此不能将该数值视为文本专用的可用空间。
据博客介绍，视频默认每秒提取 2 帧，最多提取 96 帧。保留更多帧可减少对事件之间信息的遗漏，但也会增加内存用量和生成回答前处理输入的时间。
4. 计算量减少不代表内存需求小
Muse 从每层的 256 个专家中选择 8 个，每个 token 激活全部 8160 亿参数中的 420 亿个。参数是模型通过训练确定的数值。
这种结构的优势在于只运行部分计算网络，但部署所需内存仍须容纳整个模型。博客称，BF16 权重文件约为 1.5TB。输入处理接口的整合，并不会消除运行大型模型的设备负担。
还需单独考虑用于保存先前输入计算结果的缓存。博客按 BF16 计算，每个 token 约需 250KB，填满最大上下文时约为 266GB。这是权重文件大小之外的额外开销。
5. 低精度权重与并行执行需单独检查
NVFP4 是以低精度保存权重、降低内存需求的格式。不过，模型开发文档要求使用兼容设备和单独的安装分支。文档中的安装示例如下。
pip install git+https://github.com/huggingface/transformers.git@finegrained-per-scheme-demo发行说明警告，将专家分配到多个设备上运行的专家并行推理存在速度下降问题。说明未提供下降幅度和测量条件。若部署时使用这条路径，就需要通过实际任务核查延迟。
此次支持的价值在于整合输入处理与模型加载，是否引入模型，应分别评估支持情况和实际部署资源。