What Is Federated Learning?

Federated learning is a way of training a machine learning model across many separate devices or data silos — phones, hospitals, banks — without any of their raw data ever leaving its original location. Instead of pooling everyone’s data into one central dataset the way traditional training does, each participant trains the shared model locally on its own data and sends back only the resulting model updates, which get combined into an improved shared model. The data stays put; only the learning travels.

Why keep the data in place at all

Centralized training assumes you can gather all your training data in one place. That assumption breaks down for a lot of real use cases: a hospital usually can’t legally ship patient records off-site, a bank doesn’t want to hand transaction data to a third party, and a phone manufacturer can’t casually upload everyone’s private keyboard typing history to a central server just to improve autocomplete. Privacy regulation, competitive sensitivity, and sheer data volume (uploading every phone’s full sensor history isn’t practical) all push toward training where the data already sits, rather than moving the data to a central training pipeline.

Federated learning was popularized by Google’s work on improving keyboard prediction directly on Android phones — millions of phones, each with data far too sensitive and voluminous to centralize, each contributing to a shared model none of them could have trained alone.

How the training loop works

A typical federated learning round follows a repeatable pattern:

1. A central server sends the current version of a shared model out to a selected set of participating devices or nodes.
2. Each device trains that model locally, for a limited number of steps, using only its own local data. No raw data is transmitted.
3. Each device sends back its updated model parameters (or the difference between the original and updated parameters) — not the training data itself.
4. The server aggregates all the received updates, commonly by averaging them, to produce a new, improved version of the shared model.
5. The cycle repeats with the improved model, over many rounds, until performance converges.

This aggregation step is doing real work: because different devices have different (and often quite unrepresentative) local data — a phone’s typing patterns reflect one person’s vocabulary, not a general population — the aggregation algorithm has to combine updates in a way that produces a model that generalizes well, rather than one dominated by whichever device happened to train the most or the loudest.

What actually gets protected, and what doesn’t

Federated learning removes raw data from the transmission path, which is a real and meaningful privacy improvement over centralizing everything. But model updates themselves can still leak information about the data used to produce them — research has repeatedly shown that gradients or parameter updates can, in some cases, be used to partially reconstruct properties of the underlying training examples. That’s why federated learning in security-sensitive deployments is often combined with additional protections rather than relied on alone:

• Differential privacy — adding calibrated statistical noise to updates before they’re sent, so no individual data point can be reliably inferred from the aggregate, at some cost to model accuracy.
• Secure aggregation — cryptographic protocols that let the server compute the sum or average of many devices’ updates without ever seeing any individual device’s update in isolation.
• Encryption in transit and at rest — the model updates themselves still need standard protection while moving between devices and the server, the same as any other network traffic; see encryption at rest vs in transit for that distinction.

Federated learning vs centralized training vs transfer learning

	Centralized training	Federated learning	Transfer learning / fine-tuning
Where raw data lives	Moved to a central location	Stays on the local device/silo	Already centralized, typically a pretrained model adapted further
What’s transmitted	Raw data	Model updates only	N/A — training happens in one place
Privacy profile	Weakest — full data exposure to the trainer	Stronger — raw data never leaves origin	Depends entirely on the source of the pretrained model and the fine-tuning data
Typical use case	Most large-scale model training, including most LLM pretraining	Mobile keyboards, cross-hospital medical models, cross-bank fraud detection	Adapting an existing pretrained model to a narrower task, see fine-tuning
Coordination complexity	Low	High — device availability, connectivity, and stragglers all matter	Low to moderate

The practical tradeoffs

Federated learning isn’t free. Devices vary wildly in compute power, connectivity, and how much local data they hold, so training rounds have to tolerate slow or dropped participants gracefully rather than waiting on the weakest link. Local data is often non-IID — not independently and identically distributed the way centralized training data usually is curated to be — which can make convergence slower and less stable than centralized training on a well-mixed dataset. And it adds real infrastructure complexity: coordinating rounds across thousands or millions of intermittently-connected devices is a harder engineering problem than running a training job on a fixed cluster you fully control.

The takeaway

Federated learning trains a shared model by moving the learning to the data instead of moving the data to the learning — each participant trains locally and shares back only model updates, which get aggregated into an improved shared model. That structure is a genuine privacy improvement over centralizing raw data, though it isn’t privacy by itself; deployments handling sensitive data typically pair it with differential privacy or secure aggregation, and accept added coordination complexity as the cost of keeping the data where it started.