PyTorch 可用于构建联邦多模态人工智能工作流，解决分布式数据带来的挑战。

为简化这些复杂流程，NVIDIA FLARE 通过用轻量级引用替代大对象并独立传输数据，实现了大消息负载的外部化。Flare Tensor Downloader 通过增量张量流进一步优化了模型分发，降低了峰值内存需求。

阅读 NVIDIA 最新技术博客，了解如何通过外部化、张量流和磁盘支持聚合来协调多站点联邦训练并管理大型模型更新。

博客链接：https://bit.ly/4y5J6TW

使用 NVIDIA FLARE 构建联邦多模态人工智能工作流

来源：https://developer.nvidia.com/blog/building-federated-multimodal-ai-workflows-with-nvidia-flare/ 现代视觉语言模型 (VLMs) (https://www.nvidia.com/en-us/glossary/vision-language-models/) 可支持视觉问答、图像描述生成和图文推理等任务。然而在实践中，适配这些模型所需的数据可能分散在无法集中原始记录的不同机构或组织中。

联邦学习 (https://nvflare.readthedocs.io/en/2.4/fl_introduction.html) 提供了一种协调这些数据本地站点间训练的方法。对于 VLMs，挑战不仅在于编排协调。不同站点可能贡献不同的任务或模态组合，而模型更新可能足够大，以至于会给网络带宽和服务器内存带来压力。

本文重点探讨联邦多模态人工智能工作流的两个设计决策：哪些模型状态应跨网络传输，以及应如何高效传输和聚合这些状态。文章展示了 NVIDIA FLARE (https://github.com/NVIDIA/NVFlare) 如何协调跨站点的联邦训练，并通过外部化、张量流和磁盘支持聚合处理大型模型更新。

这些设计问题同样适用于统一多模态模型 (UMMs)——在共享架构内支持多种模态和任务的模型。由威廉与玛丽学院和 NVIDIA 合作开发的 FedUMM (https://arxiv.org/abs/2601.15390) 提供了一个具体实例：通过在冻结的多模态骨干网络上联邦化轻量级适配器来实现这一目标。

FedUMM 受 NVIDIA 学术资助计划 (https://www.nvidia.com/en-us/industries/higher-education-research/academic-grant-program/) 支持，并在 TheWebConf 2026 的 FL@FM 研讨会 (https://federated-learning.org/fl@fm-www-2026/) 上获得优秀学生论文奖。

**为何 VLMs 难以联邦化？**https://developer.nvidia.com/blog/building-federated-multimodal-ai-workflows-with-nvidia-flare/#why_are_vlms_difficult_to_federate

在集中式视觉语言实验中，图像、描述文本、视觉问答示例和生成提示词可以馈送到单一训练流程中。而在联邦环境中，这些示例分布在具有不同数据、任务组合和运行约束的多个站点中。

这带来了两个工程问题。首先，站点可能基于不同的任务或模态组合进行训练，因此工作流必须定义每个客户端更新的内容以及如何组合这些更新。其次，完整的模型更新序列化、传输和保存在服务器内存中的成本很高。

因此，第一个决策是联邦化什么内容。一些方法交换蒸馏知识而非模型权重。另一些方法则冻结预训练骨干网络，仅聚合轻量化的可训练组件。CreamFL (https://arxiv.org/abs/2302.08888) 阐释了第一种方法，而 FedCLIP (https://arxiv.org/abs/2302.13485)、FedPIA (https://arxiv.org/abs/2412.14424) 和 FedUMM (https://arxiv.org/abs/2601.15390) 阐释了第二种方法。当需要更大的更新时，系统还必须支持流式传输和内存高效聚合。

NVIDIA FLARE 是一个用于联邦学习和协作计算的开源、可扩展 Python SDK 与框架，能够支持参数高效和完整模型的通信模式。

图 1 展示了通用工作流。站点将不同组合的图像、文本和提示词保持在本地，而服务器负责协调训练并聚合经批准的模型更新。大对象外部化、张量流和磁盘支持聚合有助于管理更大的负载。

联邦多模态人工智能工作流示意图。图顶部是 NVIDIA FLARE 服务器，负责协调轮次和聚合更新。灰色箭头将全局模型下发至站点；绿色箭头将更新（适配器、张量和指标）回传，并标注为流式传输、外部化和磁盘卸载。一条虚线数据本地边界将服务器与三个站点隔开。站点 A 持有图像和报告，站点 B 仅持有图像，站点 C 持有报告和实验室数据；每个站点缺失的模态绘制为空白虚线框。图 1. 使用 NVIDIA FLARE 的联邦多模态人工智能工作流

协调跨客户端训练https://developer.nvidia.com/blog/building-federated-multimodal-ai-workflows-with-nvidia-flare/#coordinating_training_across_clients_

每个 NVIDIA FLARE 任务都将全局协调与本地执行分离。服务器调度轮次并聚合更新，而每个客户端则基于其本地数据进行训练或评估。特定于站点的预处理、提示词构建和批处理仍保留在客户端内部。

NVIDIA FLARE Recipe API (https://nvflare.readthedocs.io/en/main/user_guide/data_scientist_guide/recipe_api.html) 提供了简洁的起点。FedAvg (https://nvflare.readthedocs.io/en/main/apidocs/nvflare.recipe.fedavg.html#nvflare.recipe.fedavg.FedAvgRecipe) 配方将模型与客户端训练脚本配对。相同的配方可在仿真或真实配置的多站点部署中运行。

在实现模型之前，需定义客户端更新契约：哪些内容保留在本地，哪些内容可以离开站点，每个客户端可以更新模型的哪些组件，以及哪些指标返回给服务器。当客户端更新不同的模型组件时，契约还应指定如何组合这些组件级别的更新。

高效移动和聚合大型模型更新https://developer.nvidia.com/blog/building-federated-multimodal-ai-workflows-with-nvidia-flare/#moving_and_aggregating_large_model_updates_efficiently

联邦 VLM 训练的一个常见基线方法是微调和聚合整个模型参数。这将导致大型模型更新。随着许多客户端加入联邦，它们会产生两种不同的内存压力：序列化和传输单个更新，以及在聚合期间将多个客户端更新保存在内存中。NVIDIA FLARE 支持多项功能来应对这一挑战。

外部化大对象https://developer.nvidia.com/blog/building-federated-multimodal-ai-workflows-with-nvidia-flare/#externalize_large_objects

NVIDIA FLARE 可以用轻量级引用替代消息中的大对象，并单独传输底层数据。这使得控制消息保持小巧，并支持超过常规序列化消息限制的负载。内置分解器涵盖 PyTorch 张量、NumPy 数组和常见的 FLARE 结构；仅针对特定应用的对象类型才需要自定义分解器。

流式传输张量https://developer.nvidia.com/blog/building-federated-multimodal-ai-workflows-with-nvidia-flare/#stream_tensors

对于 PyTorch 工作流，FLARE Tensor Downloader (https://nvflare.readthedocs.io/en/main/programming_guide/tensor_downloader.html) 使用基于拉取的协议增量流式传输张量。一次仅序列化请求的块，从而降低了模型分发期间的峰值内存。可以调整块大小以平衡请求开销与每个块的内存占用。TensorFlow 工作流使用传统的序列化路径。

将聚合卸载到磁盘https://developer.nvidia.com/blog/building-federated-multimodal-ai-workflows-with-nvidia-flare/#offload_aggregation_to_disk

流式传输降低了传输期间的内存压力，但服务器在聚合期间可能仍需保存多个客户端更新。这导致服务器的峰值内存随客户端数量线性增长。在 NVIDIA FLARE 2.8.0 中，tensor disk offload (https://nvflare.readthedocs.io/en/main/design/tensor_disk_offload.html) 将传入的 PyTorch FedAvg 更新写入临时的 safetensors 文件，并按需加载，从而防止了 CPU 内存的线性增长。

这些机制与基于适配器的训练所带来的负载减少相辅相成，使得完整模型训练、更大的适配器或与众多客户端的联邦学习成为可能。

有关经过测试的配置示例，请参阅 NVIDIA FLARE Recipe API (https://nvflare.readthedocs.io/en/main/user_guide/data_scientist_guide/recipe_api.html)、FLARE Tensor Downloader (https://nvflare.readthedocs.io/en/main/programming_guide/tensor_downloader.html) 和 tensor disk offload 文档 (https://nvflare.readthedocs.io/en/main/design/tensor_disk_offload.html)。

使用 FedUMM 在冻结的 VLM 上联邦化轻量级适配器https://developer.nvidia.com/blog/building-federated-multimodal-ai-workflows-with-nvidia-flare/#federating_lightweight_adapters_over_a_frozen_vlm_with_fedumm

FedUMM (https://arxiv.org/abs/2601.15390) 提供了一个具体实例，展示了如何最小化在 NVIDIA FLARE 中跨网络传输的内容。每个模拟客户端保留一个冻结的 BLIP 骨干网络 (https://huggingface.co/BLIP3o)，并在本地训练 LoRA 适配器。NVIDIA FLARE 协调训练轮次，并仅聚合适配器更新。FedUMM 通过针对视觉、音频和文本的模态特定编码器设计实现通用性，但其当前实验专注于视觉-语言任务。

报告的实验在狄利克雷控制的异质性下，对多达 16 个客户端评估了 VQA v2 (https://huggingface.co/datasets/HuggingFaceM4/VQAv2) 和 GenEval (https://arxiv.org/abs/2310.11513)。在八客户端的比较中，仅适配器联邦将每客户端每轮通信量从 28.6 GB 减少到 0.094 GB，并且相比完整模型 FedAvg，在 VQA v2 上提升了 0.7 个点。在八个客户端时，两个基准上的性能均保持在集中式参考的约 97%（图 2）。

FedUMM 示意图（左→右）：客户端持有冻结的 BLIP3o 模块（绿色 LoRA 适配器）和共享对齐 token；最多显示 16 个客户端，数据保留在站点内。绿色箭头向右发送适配器/token 更新（0.094 GB/轮），灰色箭头返回平均后的适配器。FLARE 服务器按模态（视觉、文本、对齐）平均适配器。底部注释：0.094 GB/轮，占 28.6 GB 负载的 0.3%，以及相比完整模型 FedAvg 在 VQA v2 上 +0.7。图 2. FedUMM 在冻结的 BLIP3o 骨干网络上训练 LoRA 适配器，并仅聚合可训练组件

该评估使用模拟站点、合成分区和公开的通用领域基准。它并未确立临床性能或正式隐私保证；它表明在模拟的联邦工作流中，原始训练数据保留在本地。

FedUMM 通过仅交换小型 LoRA 适配器从源头降低了系统负担。并非每个 AI 工作流都能做到这一点。当客户端必须发送更大的更新时，张量流降低了传输期间的内存压力；当服务器必须聚合来自多个客户端的更新时，磁盘支持的聚合减少了需要保存在内存中的数据量。

设计联邦多模态人工智能工作流的清单https://developer.nvidia.com/blog/building-federated-multimodal-ai-workflows-with-nvidia-flare/#checklist_for_designing_federated_multimodal_ai_workflows

在设计联邦多模态工作流时，需要考虑每个客户端应贡献什么内容，以及这些更新将如何在系统中移动。以下清单总结了平衡模型质量、通信成本和系统内存需求的关键决策。

• 定义更新契约： 决定什么内容保留在本地，每个客户端发送什么内容，以及如何组合这些更新。
• 最小化负载： 尽可能交换轻量级适配器，仅在任务需要时才交换完整模型更新。
• 选择更新移动和聚合的方式： 对于较大的内存更新，使用外部化和张量流；当聚合多个更新可能超出服务器内存时，在服务器端使用磁盘卸载。
• 评估端到端： 衡量模型质量以及通信、运行时、内存使用、数据异构性和故障情况。

开始构建联邦多模态人工智能工作流https://developer.nvidia.com/blog/building-federated-multimodal-ai-workflows-with-nvidia-flare/#get_started_building_federated_multimodal_ai_workflows%C2%A0

首先为您的工作流定义更新契约：哪些内容保留在本地，每个客户端可以返回哪些模型状态，以及哪些客户端应参与每次聚合。使用 NVIDIA FLARE Recipe API (https://nvflare.readthedocs.io/en/main/user_guide/data_scientist_guide/recipe_api.html) 实现工作流，并在预期的客户端数量下通过仿真进行验证。

其次，选择与您瓶颈匹配的负载处理机制。对于大型模型更新，使用大对象外部化 (https://nvflare.readthedocs.io/en/main/programming_guide/decomposer_for_large_object.html) 和 FLARE Tensor Downloader (https://nvflare.readthedocs.io/en/main/programming_guide/tensor_downloader.html)；当服务器端聚合内存成为限制时，配合张量磁盘卸载使用。

对于基于适配器的具体示例，请参阅论文《FedUMM: A General Framework for Federated Learning with Unified Multimodal Models》(https://arxiv.org/abs/2601.15390) 及其在 NVIDIA FLARE 仓库 (https://github.com/NVIDIA/NVFlare/tree/main/research/fedumm) 中的实现。建立工作基准后，使用 Auto-FL (https://developer.nvidia.com/blog/accelerating-federated-learning-research-with-ai-agents-and-nvidia-flare-auto-fl/#how_to_adapt_auto-fl_to_your_datasets_and_tasks) 为您自己的数据集和任务调整和优化联邦实验。

如需了解更多，请参加 NVIDIA Flare Day 2026 (https://events.nvidia.com/flare-day-2026)，这是一个免费的在线活动，探讨联邦学习在各行各业的尖端应用。