How federated learning works

Let's walk through federated learning with a healthcare example: several pathology labs want to collaborate on mammogram analysis to improve breast-cancer diagnosis.

Individual patient data is highly sensitive — it cannot be shared raw with other labs, nor moved out of each lab's own database. That constraint is exactly what makes this a good fit for federated learning. We can think of each lab as a client in the system.

Step 1 — Develop and train locally

• The labs collaboratively design a machine-learning model that diagnoses breast cancer from a mammogram.
• Each lab deploys that model locally and trains it on its own dataset.

Step 2 — Share parameters, not data

Once trained, a federated learning platform lets each client share its learned model parameters — never its raw data — with a central learner (Figure 1).

Figure 1: Parameter sharing from individual clients to the central learner

Step 3 — Federate into one model

The central learner combines all the individual parameter sets into a single model (Figure 2). This step merges what every client learned from its own data, converging it into one shared set of parameters.

Figure 2: The central federation process

Step 4 — Distribute the shared model

The federated parameters are sent back down to every client, which loads them into its local model (Figure 3). Each client thereby gains the learning of all the others, without ever touching their raw data. That completes one iteration.

Figure 3: Distributing the federated parameters back to clients

Step 5 — Repeat

The clients retrain on their local data and send their updated parameters back to the central learner (Figure 4). This continues for many iterations, improving the shared model each round.

Figure 4: The process repeats each iteration

The same loop, on BranchKey

The diagrams above are the general idea. Here is how one round maps onto the actual BranchKey entities and client-library calls:

• Each lab's training machine is a leaf. It trains its local model, then calls client.save_weights(...) and client.file_upload(...) to send its parameters.
• BranchKey holds the uploads until enough have arrived — the branch's files_per_aggregation setting — then the aggregator combines them using the branch's algorithm (average or maml).
• Every leaf is notified that an aggregation is ready and calls client.file_download(...) to fetch the shared model, then loads it back and trains again.

One turn of this loop is an aggregation; the whole session of many aggregations is a run that you start, pause, and stop. See Configuring a branch for the mechanics, and Your first federation for the loop in code.

Why it matters

Returning to our example, federated learning lets the different labs collaborate and improve their breast-cancer diagnosis using every case each of them sees — without ever sharing their raw data or interacting with each other directly. In practice this brings several advantages:

• Data security — data stays safe in its native location; only parameters travel.
• Privacy preservation — no raw data ever leaves the local environment.
• Concurrent processing — many sources train in parallel, speeding up learning across large, distributed datasets.
• Easy onboarding — a new participant starts from the latest shared model rather than training from scratch in isolation.
• Scalability — the approach handles large numbers of participating clients.

Where to go next

• What are model weights? — the numbers that actually travel
• Federated averaging, by hand — the maths of the combine step
• Configuring a branch — the algorithms and settings you control