Loading post…
NVIDIAElizabeth GoodmanExplainer
Scaling Federated Learning Across Docker, Kubernetes, and Slurm with NVIDIA FLARE
Summary
NVIDIA FLARE addresses the operational challenge of running federated learning across sites that use different infrastructure, including Docker, Kubernetes, and Slurm. Its two-layer architecture keeps long-running server and client parent processes available for authentication and coordination while launching transient job workers through each site’s native runtime. Jobs declare portable GPU, CPU, and host-memory requirements, which local launchers translate into Docker containers, Kubernetes pods, or Slurm allocations; studies add scoped membership and site-owned mappings for datasets, images, secrets, and scheduling policy. The result is a heterogeneous federation where organizations retain local resource authority, can allocate compute on demand, and run multiple studies without requiring one shared platform.
Context
The post describes how NVIDIA FLARE supports federated learning across sites with different execution environments while preserving local control over compute, data, secrets, images, and scheduling. It also explains how FLARE studies provide logical separation for multiple experiments within a shared deployment.
Approach / What changed
FLARE separates persistent federation services from transient job workers. Parent processes authenticate connections and coordinate work, while site-specific launchers translate portable resource requirements and study-owned runtime settings into Docker containers, Kubernetes pods, or Slurm allocations. Study-scoped sessions and local study_runtime.yaml mappings control participation, datasets, secrets, images, and scheduling policies.
Takeaways
Persistent FLARE parent processes remain available while job workers are created on demand, so federation services do not occupy training GPUs continuously.
The same resource_spec can express GPUs, whole CPU units, and memory; Docker, Kubernetes, and Slurm launchers translate those values into native runtime settings.
Studies limit membership and job visibility while mapping each study to site-owned datasets, images, secrets, and execution policies; separate deployments are recommended when PKI or failure isolation must differ.
FAQ
How does FLARE support Docker, Kubernetes, and Slurm in one federation?
Each site configures its own execution launcher while sharing persistent federation services. The launcher creates a Docker container, Kubernetes pod, or Slurm allocation for each job and applies the site’s local policies.
How are resource requirements made portable across execution platforms?
Jobs use resource_spec with num_of_gpus, num_of_cpus, and memory. Each launcher converts those values into native Docker, Kubernetes, or Slurm settings, while launcher_spec handles backend-specific topology and policy.
How does FLARE keep multiple studies separated?
A study-scoped session limits membership, job visibility, client status, submission targets, and deployment maps. The site’s study_runtime.yaml maps that study to approved datasets, images, secrets, and scheduling settings.
Source and freshness
- Source
- developer.nvidia.com
- Published
- Added to Yomu
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.