现代视觉语言模型 (VLM)可以支持视觉问答、字幕和图像文本推理等任务。然而，在实践中，调整这些模型所需的数据可能会分布在无法集中其原始记录的机构或组织之间。
联合学习提供了一种跨这些数据本地站点协调训练的方法。对于 VLM 而言，挑战不仅仅在于编排。站点可能会提供不同的任务或模态组合，并且模型更新可能会大到足以让网络带宽和服务器内存捉见肘。
本文将重点介绍联邦多模态 AI 工作流的两个设计决策：应通过网络实现何种模型状态，以及应如何高效地进行传输和聚合？它展示了 NVIDIA FLARE 如何协调跨站点的联邦训练，以及如何通过外部化、张量流和磁盘支持的聚合来处理大型模型更新。
这些设计问题也适用于统一多模态模型 (UMM) ，这些模型支持共享架构中的多种模式和任务。FedUMM，通过 William & Mary 和 NVIDIA 合作开发的，提供了一个具体示例，即在冻结的多模态主干上联合轻量级适配器。
FedUMM 由 NVIDIA 学术资助计划提供支持，并在 TheWebConf 2026 的 FL+ FM 研讨会上获得了杰出学生论文奖。
为什么 VLM 难以联合？
在集中式视觉语言实验中，图像、描述、视觉问答示例和生成提示可以输入一个训练工作流。在联合设置中，这些示例分布在具有不同数据、任务组合和操作限制的站点之间。
这会产生两个工程问题。首先，站点可能会基于不同的任务或模态组合进行训练，因此工作流必须定义每个客户端的更新内容以及这些更新的组合方式。其次，在服务器内存中序列化、传输和保留完整模型更新的成本可能很高。
因此，第一个决定是联合对象。有些方法可以交换提取的知识，而不是模型权重。另一些则会冻结预训练主干，仅聚合轻量级可训练组件。CreamFL 展示了第一种方法，而 FedCLIP、FedPIA 和 FedUMM 则展示了第二种方法。当需要更大规模的更新时，系统还必须支持流式传输和内存高效聚合。
NVIDIA FLARE 是用于联邦学习和协作计算的开源、可扩展 Python SDK 和框架,可以支持参数高效型和全模型通信模式。
图 1 显示了常规工作流程。站点会在本地保留不同的图像、文本和提示词组合，而服务器则会协调训练并汇总经批准的模型更新。大型对象外部化、张量流和磁盘支持的聚合有助于管理更大的负载。
跨客户协调培训
每个 NVIDIA FLARE 作业都将全局协调与本地执行分离开来。服务器会安排对更新进行四舍五入和聚合，而每个客户端会根据其本地数据进行训练或评估。特定于站点的预处理、提示构建和批处理仍保留在客户端内部。
NVIDIA FLARE Recipe API 提供了一个简洁的起点。FedAvg recipe 将模型与客户端训练脚本配对。同样的方法可以在仿真中运行，也可以在实际调配的多站点部署中运行。
在实现模型之前，请定义客户端更新合同：哪些仍然是本地的，哪些可能会离开站点，每个客户端可以更新哪些模型组件，以及哪些指标会返回到服务器。当客户端更新不同的模型组件时，合同还应指定如何组合这些组件级更新。
高效移动和聚合大型模型更新
联邦 VLM 训练的一种常见基准方法是微调和聚合整个模型参数。这将导致大规模模型更新。随着许多客户端加入联合，它们会产生两种不同的内存压力：序列化和传输一次更新，以及在聚合期间在内存中保留多个客户端更新。NVIDIA FLARE 支持多种功能来应对这一挑战。
外化大型对象
NVIDIA FLARE 可以使用轻量级引用替换消息中的大型对象，并单独传输底层数据。这样可以使控制消息保持较小，并支持超过普通序列化消息限制的有效载荷。内置分解器涵盖 PyTorch 张量、NumPy 数组和常见的 FLARE 结构；自定义分解器仅适用于应用程序特定的对象类型。
流张量
对于 PyTorch 工作流，FLARE Tensor 下载器使用基于拉取的协议逐步流式传输张量。一次仅对请求的数据块进行序列化，从而减少模型分发期间的峰值内存。可以调整块大小，以平衡每个块的请求开销和内存开销。TensorFlow 工作流使用传统的序列化路径。
将聚合卸载到磁盘
流式传输可降低传输过程中的内存压力，但服务器可能仍需要在聚合过程中保留多个客户端更新。这会导致服务器的峰值内存随客户端数量呈线性增长。在 NVIDIA FLARE 2.8.0 中，张量磁盘卸载会将传入的 PyTorch FedAvg 更新写入临时 safetensors 文件，并根据需要进行加载，从而防止 CPU 内存线性增长。
这些机制补充了基于适配器的训练的有效载荷减少，从而实现了全模型训练、更大的适配器或与许多客户端的联邦学习。
有关测试的配置示例，请参阅 NVIDIA FLARE Recipe API、FLARE Tensor 下载器 和 Tensor 磁盘卸载文档。
使用 FedUMM 在冻结的 VLM 上联合轻量级适配器
FedUMM 提供了一个具体示例，用于在 NVIDIA FLARE 中最大限度地减少跨网络的内容。每个模拟客户端都保留了一个冻结的 BLIP 主干，并在本地训练 LoRA 适配器。NVIDIA FLARE 负责协调轮次，并仅汇总适配器更新。FedUMM 专为通用性而设计，具有适用于视觉、音频和文本的模态特定编码器，而其目前的实验侧重于视觉语言。
所报告的实验在多达 16 个客户端的 Dirichlet 控制异构下评估 VQA v2 和 GenEval。在对 8 个客户的比较中，与全模型 FedAvg 相比，仅使用适配器的联合可将每个客户的通信从每轮 28.6 GB 减少到 0.094 GB，并将 VQA v2 提高了 0.7 个百分点。在这两个基准测试中，八个客户端的性能仍占集中式参考的 97% 左右 (图 2) 。
评估使用模拟站点、合成分区和公共通用域基准。它并不建立临床表现或正式的隐私保证；它表明原始训练数据仍然是模拟联邦工作流程中的本地数据。
通过仅交换小型 LoRA 适配器，FedUMM 从源头上减轻了系统负担。并非每个 AI 工作流都能做到这一点。当客户端必须发送更大的更新时，张量流可降低传输过程中的内存压力；当服务器必须聚合来自许多客户端的更新时，磁盘支持的聚合会减少必须在内存中保留的数据量。
用于设计联合多模态 AI 工作流的清单
在设计联合多模态工作流时，请考虑每个客户端应贡献的内容，以及这些更新将如何在系统中进行。以下检查清单总结了平衡模型质量、通信成本和系统内存需求的关键决策。
- 定义更新合同：确定哪些内容保持本地状态、每个客户端发送哪些内容以及如何组合更新。
- 更大限度地减少负载：尽可能交换轻量级适配器，仅在任务需要时更新全模型。
- 选择更新的移动方式和聚合方式：使用外部化和张量流处理大型内存更新，以及在聚合多个更新超过服务器内存时在服务器上卸载磁盘。
- 端到端评估：测量模型质量以及通信、运行时、内存使用情况、数据异质性和故障。
开始构建联邦多模态 AI 工作流
首先，为您的工作流程定义更新合同：什么仍然是本地的，每个客户端可能返回的模型状态，以及哪些客户端应该为每个聚合做出贡献。使用 NVIDIA FLARE Recipe API 实施工作流，并在模拟中按照预期的客户端数量对其进行验证。
接下来，选择与瓶颈相匹配的负载处理机制。使用large-object externalization和 FLARE Tensor Downloader用于大型模型更新，以及在服务器端聚合内存受到约束时张量磁盘卸载。
如需了解基于适配器的具体示例，请阅读论文“FedUMM：A General Framework for Federated Learning with Unified Multimodal Models” (使用统一多模态模型进行联邦学习的通用框架)及其在NVIDIA FLARE 资源库中的实现。建立工作基准后，使用Auto-FL针对您自己的数据集和任务调整联邦实验。
如需了解更多信息，请与我们一起参加 NVIDIA Flare Day 2026，这是一项免费的在线活动，旨在探索联邦学习在各行各业中的前沿应用。
