NVIDIA FLARE 跨 Docker、Kubernetes 和 Slurm 扩展联邦学习

联邦学习（FL）项目通常从一个简单的设置开始：一个服务器、几个客户端，以及每个站点一个数据集。随着这些项目的发展，挑战从运行算法转变为运营共享基础设施。需要在作业需要时分配 GPU，多个研究必须保持隔离，每个参与组织必须保留对其自身数据、密钥和计算策略的控制。

当组织依赖不同的环境时，这种运营复杂性会增加。一个站点可能使用 Docker 主机，另一个可能运行 Kubernetes 集群，而一个研究中心可能使用 Slurm 调度其 GPU 工作负载。要求每个参与者采用相同的基础设施可能会将平台标准化变成协作的先决条件。

NVIDIA FLARE 通过将持久联邦与执行每个作业的进程分离来应对这一挑战。

FLARE 的两层架构将持久联邦服务与作业执行分离，允许同一联邦中的每个站点使用适合其基础设施的执行后端——例如，一个站点使用 Docker，另一个使用 Kubernetes，第三个使用 Slurm。每个站点保留对计算分配以及每个研究使用的数据集、镜像、密钥和调度策略的本地控制。

Docker 和 Kubernetes 部署支持在 NVIDIA FLARE 2.8 中可用。FLARE 2.9 增加了 Slurm 支持。

将联邦协调与作业执行分离

FLARE 部署有两个运营层。长期运行的服务器和客户端父进程维护联邦、验证连接并协调工作。独立的服务器和客户端作业工作器执行提交的 FL 作业。

这种分离实现了资源感知执行。父进程可以保持可用，而不占用训练所需的 GPU。当数据科学家提交作业时，每个父进程通过其配置的执行平台启动一个工作器。工作器接收作业，使用请求的资源，返回结果，并在工作完成后退出。

作业将资源意图与平台细节分开描述。作业可以请求 GPU、整个可调度的 CPU 单元和主机内存。每个站点的启动器将这些需求与本地研究配置结合，并将其转换为 Docker 容器、Kubernetes pod 或 Slurm 分配。

这些层共同保持联邦服务可用，同时作业工作器及其资源在每个站点按需创建。

图 1. 持久的 NVIDIA FLARE 父进程协调一个联邦，而瞬态作业工作器通过每个站点的原生运行时启动

使用 Docker、Kubernetes 和 Slurm 部署作业工作器

NVIDIA FLARE 与标准部署和调度系统集成。站点操作员选择与本地环境匹配的运行时，并继续负责其策略。

表 1. NVIDIA FLARE 部署运行时对比

用于单主机上容器化执行的 Docker

Docker 是工作站、实验室服务器、边缘系统或其他单主机环境的实用选择。持久化的 FLARE 服务器或客户端运行在由父镜像构建的父容器中。对于每个提交的作业，FLARE 会动态启动一个由作业镜像构建的独立作业容器。

父镜像包含 FLARE 运行时以及启动容器所需的组件。独立的作业镜像可以包含训练框架、模型代码和应用依赖。站点可以通过 NVIDIA Container Toolkit 向作业容器暴露所请求的 GPU，并使用 Docker 设置来满足共享内存、挂载、网络及其他主机特定需求。

将父镜像与作业镜像分离也使更新更加容易。基础设施所有者可以保持父环境稳定，而研究人员可以独立更新其训练环境，但须遵守站点的镜像和代码审批政策。

用于动态调度作业 Pod 的 Kubernetes

在 Kubernetes 中，Helm chart 将每个持久化的 FLARE 服务器或客户端安装为父 Pod。对于每个提交的作业，父 Pod 会创建一个独立的服务器或客户端作业 Pod。Kubernetes 调度器根据其 CPU、内存、GPU、存储和放置要求来放置该 Pod。

这种方法将 FLARE 作业与熟悉的 Kubernetes 能力连接起来。站点可以使用命名空间、服务账户、Secret、持久卷、节点选择器、容忍度和准入策略。例如，一项研究可以使用 Pod 模板选择 H100 节点，而另一项研究使用不同的节点池。

平台运维人员为其集群配置存储类、镜像仓库凭据、网络策略、GPU 启用和基于角色的访问控制（RBAC）。FLARE 使用这些服务来启动作业 Pod 并监控其状态。

用于调度 GPU 和多节点分配的 Slurm

许多大学、研究中心和企业计算环境使用 Slurm 来共享 GPU 集群。FLARE Slurm 启动器将每个服务器或客户端作业工作进程作为批处理作业提交。Slurm 选择计算节点，并强制执行所请求的 GPU、CPU、内存、分区、账户、服务质量（QoS）和时间限制。

作业可以请求单个节点或多个节点。FLARE 提交分配、监控其状态、传播完成或失败信息，并在需要时取消它。该启动器支持裸执行（无沙箱）、Pyxis/Enroot 容器和 Apptainer 容器。

Slurm 仍然是资源权威。其账户、关联、分区、QoS 规则、cgroups、文件系统权限和设备控制决定了分配可以使用什么。这保留了集群管理员已用于非联邦工作负载的运维模型。

NVIDIA FLARE 提供参与者身份验证、安全通信和授权，而每个站点的执行平台则强制执行本地资源和工作负载策略。站点运营人员配置主机和集群安全、已批准的镜像、密钥和访问控制，并针对所选运行时验证工作负载隔离。

通过研究（studies）分离研究工作

共享基础设施引入了另一个问题：多个团队如何在不混淆其用户、作业或数据的情况下运行联邦学习（FL）研究？

FLARE 研究在单个部署内提供了一个逻辑上的多租户边界。每个研究定义了其参与的客户端站点以及可以为该研究打开会话的管理员用户。研究感知操作将作业可见性、客户端状态、提交目标和部署映射限制在活动研究内。

研究边界在每个参与站点继续存在。站点拥有的 local/study_runtime.yaml

文件将研究映射到它可以在本地使用的资源。根据运行时的不同，此配置可以定义：

• 数据集挂载
• 环境变量
• 基于密钥的环境变量和文件挂载
• 站点批准的默认作业镜像
• Kubernetes pod 模板
• Docker 运行时设置
• Slurm 沙箱、分区、账户和 QoS 策略

数据科学家通过打开研究范围的会话来选择研究，从该会话提交的作业继承研究上下文。作业不能选择任意的本地数据集路径或提供密钥值。FLARE 服务器在作业到达站点之前验证研究成员资格，而站点运营人员控制从该研究到本地资源的映射。

以下简化的 Kubernetes 示例将病理学研究映射到站点拥有的数据卷和数据库凭据。配置包含对 Secret 的引用，而不是它们的值。

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/<study>/<dataset>

。

secret_env

条目在 Pod 规范中变为 Kubernetes 的 secretKeyRef

引用。Kubernetes 在启动 Pod 时从 pathology-db

Secret 中注入 username

和 password

值。这样，凭据值保留在站点的密钥存储中，同时为研究工作进程提供其所需的环境。

图 2. Kubernetes 启动器在创建作业 Pod 之前，将活动研究解析为站点拥有的运行时默认值

研究适用于共享同一 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

条目将一个资源配置应用于每个目标站点，包括服务器。命名的客户端或服务器条目仅提供不同的值。在此示例中，两家医院都继承一个 GPU、四个 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 将四个 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 管理本地资源。

使用 launcher_spec

进行后端特定的拓扑和策略，例如 Slurm 节点布局或运行时特定的镜像。研究运行时配置为每个站点提供经批准的本地默认值，用于镜像、数据集、密钥和执行策略。

这实现了什么

联邦学习基础设施不需要在参与者之间统一。FLARE 将持久联邦服务与动态启动的作业工作进程分离，以便每个站点可以使用 Docker、Kubernetes 或 Slurm。研究添加范围成员资格和站点拥有的数据、密钥、镜像和调度策略映射。

这些能力共同使一个联邦能够跨越本地系统和云，而无需强制每个组织使用同一平台。站点可以在作业需要时分配 GPU 和其他资源，继续使用其既定的操作控制，并在独立治理的数据上运行多个研究。异构基础设施成为联邦设计的一部分，而不是扩展它的障碍。

要开始使用，请探索 NVIDIA FLARE 文档 和 NVIDIA FLARE GitHub 仓库。