NVIDIA FLARE 2.9 让联邦学习跨 Docker、Kubernetes 与 Slurm 混部：各站点保留自己的调度权 NEWS DETAIL

联邦学习项目往往从一个简单配置开始：一台服务器、几个客户端、每个站点一份数据集。项目规模上来之后，难点就从运行算法转向运营共享基础设施——需要在作业需要时分配 GPU，让多个研究彼此隔离，同时保证每个参与机构仍掌控自己的数据、密钥与算力策略。

复杂度还会随环境差异放大。一个站点可能用 Docker 主机，另一个跑 Kubernetes 集群，研究中心则用 Slurm 调度 GPU 负载。如果要求每个参与方采用同一套基础设施，平台标准化就会变成协作的前置条件，很多跨机构项目因此卡在起步阶段。

NVIDIA FLARE 的做法是把持久的联邦与执行作业的进程分开。一次 FLARE 部署包含两层：长期运行的 server 与 client 父进程负责维护联邦、认证连接、协调工作；独立的 server 与 client job worker 负责执行提交上来的联邦学习作业。这种分离带来资源感知的执行方式——父进程可以始终保持可用，却不占用训练所需的 GPU；数据科学家提交作业时，各站点的父进程通过其配置的执行平台拉起 worker，worker 取用所需资源、返回结果，完成工作后退出。

运行时支持的版本脉络很清晰：Docker 与 Kubernetes 部署支持在 NVIDIA FLARE 2.8 中提供，FLARE 2.9 增加了 Slurm 支持。Docker 适合工作站、实验室服务器、边缘系统等单主机环境，父进程跑在父容器里，每个作业动态启动独立的 job 容器，父镜像包含 FLARE 运行时与启动容器所需组件，job 镜像可单独放训练框架、模型代码与依赖，站点通过 NVIDIA Container Toolkit 把申请的 GPU 暴露给作业容器，因此基础设施可以保持父环境稳定、研究者独立更新训练环境。

Kubernetes 下，Helm chart 把持久的 FLARE server 或 client 装成 parent pod，每个提交的作业由父进程创建独立的 job pod，交给 Kubernetes 调度器按 CPU、内存、GPU、存储与放置要求调度。站点因此可以沿用熟悉的机制：命名空间、服务账号、Secret、持久卷、node selector、容忍与准入策略，例如一个研究用 pod 模板选 H100 节点，另一个研究用不同的节点池。Slurm 下，每个 server 或 client job worker 作为批处理作业提交，由 Slurm 选择计算节点并执行 GPU、CPU、内存、分区、账户、QoS 与时限约束，作业可申请单节点或多节点；launcher 支持裸执行（无沙箱）、Pyxis/Enroot 容器与 Apptainer 容器，Slurm 仍是资源权威，账户、关联、分区、QoS 规则、cgroup、文件系统权限与设备控制决定一次分配能用什么。

为了在共享基础设施上隔离研究，FLARE 用 study 作为同一部署内的逻辑多租户边界：每个 study 定义参与的客户端站点，以及可以为该 study 打开会话的管理员；作业可见性、客户端状态、提交目标与部署映射都限定在当前 study 内。边界一直延伸到站点侧——由站点拥有的 local/study_runtime.yaml 把 study 映射到本地可用资源，按运行时不同可定义数据集挂载、环境变量、由 Secret 支撑的环境变量与文件挂载、站点批准的默认作业镜像、Kubernetes pod 模板、Docker 运行时设置，以及 Slurm 的沙箱、分区、账户与 QoS 策略。数据科学家通过打开 study 作用域的会话来提交作业，作业不能自行选择任意本地数据集路径，也不能提供密钥值；FLARE server 在作业到达站点前校验 study 成员身份，站点运营者则掌握该 study 到本地资源的映射。安全上，FLARE 提供参与方认证、加密通信与授权，本地资源与工作负载策略由各站点执行平台落实，站点运营者负责主机与集群安全、审批镜像、密钥与访问控制，并验证所选运行时的工作负载隔离。