联邦学习项目通常始于简单的架构：一台服务器、几个客户端，每个站点对应一份数据集。但随着项目规模扩大，挑战会从运行算法转变为运营共享基础设施。GPU 需要按需分配，多个研究项目必须保持隔离，每个参与机构还必须掌控自己的数据、密钥和计算策略。
当各参与机构依赖不同的运行环境时，这种运营复杂度会进一步加剧。有的站点使用 Docker 主机，有的运行 Kubernetes 集群，某研究中心可能用 Slurm 调度 GPU 任务。若要求所有参与方统一采用相同的基础设施，平台标准化反而会成为协作的前提门槛。
NVIDIA FLARE 通过将持久化的联邦体系与每个任务的执行进程分离，解决了这一难题。
FLARE 的双层架构将持久化联邦服务与任务执行分开，使同一联邦中的每个站点都能选用适合自身基础设施的执行后端——例如某站点用 Docker，另一站点用 Kubernetes，第三个站点用 Slurm。每个站点都能保留对计算资源分配的本地控制权，以及各研究项目所用数据集、镜像、密钥和调度策略的自主权。
NVIDIA FLARE 2.8 已支持 Docker 和 Kubernetes 部署。FLARE 2.9 新增了 Slurm 支持。
将联邦协调与任务执行分离
一个 FLARE 部署包含两个运行层级。长期运行的服务器与客户端父进程负责维护联邦、认证连接并协调工作；独立的服务器与客户端任务工作进程则负责执行提交的联邦学习任务。
这种分离机制实现了资源感知型执行。父进程无需占用训练所需的 GPU 便可保持可用状态。当数据科学家提交任务时，每个父进程会通过其配置的执行平台启动一个工作进程。该工作进程接收任务、使用所需资源、返回结果，并在工作完成后退出。
任务描述会将资源诉求与平台细节区分开来。一个任务可以申请 GPU、可调度的整数 CPU 单元以及主机内存。每个站点的启动器会将这些需求与本地研究配置结合，并转换为 Docker 容器、Kubernetes Pod 或 Slurm 分配请求。
这两个层级共同确保了联邦服务始终可用，同时任务工作进程及其所需资源可在各站点按需创建。
使用 Docker、Kubernetes 和 Slurm 部署任务工作进程
NVIDIA FLARE 与标准部署和调度系统集成。站点运营方可选择匹配本地环境的运行时，并负责相应的策略管理。
Docker：单主机容器化执行
对于工作站、实验室服务器、边缘系统或其他单主机环境，Docker 是实用之选。持久化的 FLARE 服务器或客户端运行在基于父镜像构建的父容器中。对于每个提交的任务，FLARE 会动态启动一个基于任务镜像构建的独立任务容器。
父镜像包含 FLARE 运行时以及启动容器所需的组件。独立的任务镜像可包含训练框架、模型代码和应用依赖项。各站点可通过 NVIDIA Container Toolkit 向任务容器暴露所需 GPU，并使用 Docker 设置来配置共享内存、挂载、网络及其他特定于主机的需求。
将父镜像与任务镜像分离也简化了更新流程。基础设施管理方可保持父环境的稳定性，而研究人员可根据站点的镜像与代码审批策略，独立更新其训练环境。
Kubernetes：动态调度任务 Pod
在 Kubernetes 环境中，Helm Chart 会将每个持久化的 FLARE 服务器或客户端安装为父 Pod。对于每个提交的任务，父 Pod 会创建一个独立的服务器或客户端任务 Pod。Kubernetes 调度器会根据其 CPU、内存、GPU、存储和放置需求来安排该 Pod。
这种方式将 FLARE 任务与人们熟悉的 Kubernetes 能力结合起来。站点可使用命名空间、服务账户、Secrets、持久化卷、节点选择器、容忍度以及准入策略。例如，某项研究可通过 Pod 模板选择 H100 节点，而另一项研究则使用不同的节点池。
平台运营方为其集群配置存储类、镜像仓库凭证、网络策略、GPU 启用以及基于角色的访问控制（RBAC）。FLARE 借助这些服务来启动和监控任务 Pod。
Slurm：面向计划性 GPU 与多节点分配
许多大学、研究中心以及企业计算环境使用 Slurm 来共享 GPU 集群。FLARE 的 Slurm 启动器会将每个服务器或客户端任务工作进程作为批处理任务提交。Slurm 负责选择计算节点，并强制执行所请求的 GPU、CPU、内存、分区、账户、服务质量（QoS）以及时间限制。
任务可以请求单节点或多节点资源。FLARE 负责提交分配请求、监控其状态、传递完成或失败信息，并在需要时取消分配。该启动器支持裸执行（无沙箱）、Pyxis/Enroot 容器以及 Apptainer 容器。
Slurm 仍是资源管理的权威方。其账户、关联关系、分区、QoS 规则、cgroups、文件系统权限以及设备控制共同决定了一次分配可使用的资源范围，这保留了集群管理员已习惯使用的、针对非联邦工作负载的运营模式。
NVIDIA FLARE 负责提供参与方认证、安全通信与授权，而每个站点的执行平台则负责强制执行本地资源与工作负载策略。站点运营方需配置主机与集群安全策略、审批通过的镜像、密钥以及访问控制，并针对所选运行时验证工作负载隔离性。
用研究项目实现隔离
共享基础设施带来了另一个问题：多个团队如何在不混淆用户、任务或数据的情况下运行各自的联邦学习研究？
FLARE 的研究项目机制在同一部署内提供了逻辑上的多租户边界。每个研究项目定义了其参与的客户端站点，以及可为该研究开启会话的管理员用户。具备研究感知能力的操作会将任务可见性、客户端状态、提交目标以及部署映射限定在当前活跃的研究项目范围内。
这种研究边界会延伸至每个参与站点。站点自有的 local/study_runtime.yaml 文件将某项研究映射到其在本地可使用的资源。根据运行时的不同，该配置可定义：
数据集挂载
环境变量
由密钥支持的环境变量与文件挂载
站点审批通过的默认任务镜像
Kubernetes Pod 模板
Docker 运行时设置
Slurm 沙箱、分区、账户及 QoS 策略
数据科学家通过开启一个限定于特定研究的会话来选择研究项目，从该会话提交的任务将继承该研究的上下文。这些任务无法自行选择任意的本地数据集路径，也无法提供密钥值。FLARE 服务器会在任务到达站点之前验证研究成员资格，而站点运营方则控制该研究到本地资源的映射关系。
以下是一个精简的 Kubernetes 示例，展示了将一项病理学研究映射到站点自有的数据卷和数据库凭证。该配置仅包含对 Secrets 的引用，而非其实际值。
format_version: 2 studies: pathology: container: image: registry.example.com/pathology-trainer:1.0 datasets: slides: source: pathology-data-pvc mode: ro secret_env: DB_USER: {source: pathology-db, key: username} DB_PASSWORD: {source: pathology-db, key: password}
当从病理学研究会话提交的任务到达该站点时，Kubernetes 启动器会选取匹配的 studies.pathology 配置项。启动器将该研究镜像作为本地默认镜像，并以只读方式将 pathology-data-pvc 卷挂载到任务容器内的 /data/pathology/slides 路径。该挂载路径由研究名称与数据集名称共同派生，格式为 /data/<研究名>/<数据集名>。
secret_env 中的条目会转换为 Pod 规范中的 Kubernetes secretKeyRef 引用。Kubernetes 会在启动 Pod 时，从 pathology-db 这一 Secret 中注入用户名和密码值。这样一来，凭证值始终保存在站点自己的密钥存储中，同时也为研究工作进程提供了所需的运行环境。
研究项目机制适用于共享同一 FLARE 服务器和公钥基础设施（PKI）、但需要在不同实验之间实现逻辑隔离的机构。若某机构需要独立的 PKI、独立的基础设施管理员，或需要独立的故障影响范围，则应使用单独的 FLARE 部署。
整合异构基础设施构建联邦体系
在上文图 1 所示的联邦体系中，一项病理学研究连接了两家医院和一所大学，使用 GPU 工作进程处理各站点审批通过的镜像和数据集。而一项结果分析研究仅包含两家医院，使用 CPU 工作进程分析结构化临床数据。
这两项研究共享该联邦的持久化服务。研究成员资格决定了哪些站点参与其中，而每个站点的研究配置则为其工作进程提供数据集、镜像、密钥和调度设置。研究人员从相应的研究会话中提交任务，本地启动器则应用这些设置。
提交任务
FLARE 2.9 支持在任务 meta.json 文件的 resource_spec 中设置可移植的 GPU、CPU 及主机内存需求。可移植的键包括 num_of_gpus、num_of_cpus 和 memory。CPU 值代表可调度的整数 CPU 单元，内存则使用带有 Mi、Gi 或 Ti 单位的正整数值。
@default 条目会将同一套资源配置应用于所有目标站点，包括服务器本身。而具名的客户端或服务器条目仅需提供有差异的数值。在下面的示例中，两家医院都继承了 1 个 GPU、4 个 CPU 单元和 64 GiB 内存的配置。大学站点覆盖了 GPU 数量设置，服务器则将 GPU 数量覆盖为零，二者均继承了相同的 CPU 与内存需求。
{ "resource_spec": { "@default": { "num_of_gpus": 1, "num_of_cpus": 4, "memory": "64Gi" }, "server": {"num_of_gpus": 0}, "university": {"num_of_gpus": 8} } }
每个启动器都会将解析后的数值转换为原生设置。Docker 会将 4 个 CPU 单元转换为 nano_cpus=4000000000，将 64 GiB 转换为以字节为单位的 mem_limit，并应用相应的 GPU 设备请求。Kubernetes 会设置对应的 CPU 和内存请求与限制值，并添加 GPU 请求。Slurm 则会生成 --cpus-per-task=4、--mem=65536M 以及相应的 GPU --gres 参数值。
数据科学家开启一个限定于特定研究的会话，并将任务一次性提交给 FLARE 服务器，服务器随后将其部署给该研究的所有参与方。在每个站点，配置好的启动器会应用该研究的本地运行时默认设置并创建工作进程。FLARE 负责协调联邦工作流并汇报任务状态，而 Docker、Kubernetes 和 Slurm 则各自管理本地资源。
对于特定后端的拓扑结构与策略（例如 Slurm 节点布局或运行时专用镜像），可使用 launcher_spec 进行配置。研究运行时配置则为每个站点提供了经审批的本地默认设置，涵盖镜像、数据集、密钥及执行策略。
这一方案带来了什么
联邦学习基础设施无需在所有参与方之间保持一致。FLARE 将持久化的联邦服务与动态启动的任务工作进程分离开来，使每个站点都能自由选用 Docker、Kubernetes 或 Slurm。而研究项目机制则增加了限定范围的成员资格，以及站点自主掌控的数据、密钥、镜像和调度策略映射。
这些能力结合在一起，使得一个联邦体系能够横跨本地部署系统与云环境，而无需强迫所有机构采用统一平台。各站点可在任务需要时分配 GPU 等资源，继续沿用其既有的运营管控方式，并在独立治理的数据基础上运行多项研究。异构基础设施由此成为联邦体系设计的一部分，而非阻碍其扩展的障碍。
如需入门，可查阅 NVIDIA FLARE 官方文档及 NVIDIA FLARE 的 GitHub 代码仓库。
Q&A
Q1：NVIDIA FLARE 支持哪些部署方式？
A：NVIDIA FLARE 支持 Docker、Kubernetes 和 Slurm 三种部署方式。其中 Docker 和 Kubernetes 部署支持已在 FLARE 2.8 中提供，Slurm 支持则由 FLARE 2.9 新增，使不同站点可根据自身基础设施选择合适的执行后端。
Q2：FLARE 的研究项目机制有什么作用？
A：FLARE 的研究项目机制提供了一种逻辑上的多租户边界，让多个团队能在同一联邦部署中运行各自的研究而不互相干扰。每项研究定义了参与站点及可访问的管理员用户，并通过站点自有配置文件映射到本地数据集、镜像、密钥和调度策略。
Q3：FLARE 如何实现联邦服务与任务执行的分离？
A：FLARE 采用双层架构，长期运行的服务器与客户端父进程负责维护联邦、认证连接和协调工作，而独立的任务工作进程则负责执行具体任务。父进程无需占用 GPU 即可保持可用，任务提交后才会按需创建工作进程并分配资源。
