What is Federated Learning?
Federated Learning is a distributed machine learning approach in which clients train on local data and send model updates or other task-specific messages for aggregation into a shared model without pooling their raw datasets.
Quick Facts
| Specification | Official Specification |
|---|
How It Works
Run training as versioned communication rounds
In each round, the server selects eligible clients and sends one model version. Clients train locally under a declared optimizer, epoch limit, clipping rule, and data snapshot, then return updates plus the minimum metadata needed for aggregation. The server rejects stale or malformed updates, aggregates accepted contributions, evaluates the new model, and records lineage before the next round. A retry must not silently count one client's update twice.
Treat heterogeneity as a first-class constraint
The FedAvg paper identifies non-IID, unbalanced, massively distributed data and limited communication as defining conditions. Sample-weighted averaging optimizes a global example-weighted objective, but it can underperform for rare clients or diverge when local steps amplify drift. Evaluate global and per-client utility, participation bias, convergence, communication, energy, and failure rates rather than reporting one pooled accuracy.
Add privacy and integrity controls explicitly
Transport encryption does not hide an update from the coordinator. NIST's PPFL red-team problems demonstrate membership and reconstruction risks from client models or gradients. Secure Aggregation can hide individual updates inside a cohort sum; Differential Privacy can bound one declared contribution; robust aggregation and anomaly review address malicious updates. None of these controls alone proves consent, lawful use, fairness, or deletion.
Key Characteristics
- Keeps raw training records at clients while exchanging task-specific updates
- Coordinates repeated client selection, local training, aggregation, and redistribution
- Includes cross-device and cross-silo deployments with different trust assumptions
- Must handle non-IID data, unequal client sizes, stragglers, and intermittent availability
- Moves rather than eliminates privacy, integrity, and governance risks
- Requires per-client and system-level evaluation beyond one global metric
Common Use Cases
- Training keyboard or personalization models from on-device interactions
- Collaborating across hospitals without pooling raw patient records
- Building fraud models across institutions with separate data custody
- Learning from industrial or edge fleets with limited connectivity
- Evaluating privacy-preserving research across governed data silos
Example
Loading code...Frequently Asked Questions
How does Federated Learning work?
A coordinator distributes a model to selected clients. Each client trains on its local data and returns an update. The coordinator validates and aggregates accepted updates into a new global model, then repeats the process. Real systems also need client eligibility, version checks, failure recovery, evaluation, privacy controls, and auditable lineage.
Does Federated Learning guarantee privacy because data stays local?
No. Local retention reduces raw-data centralization, but model updates, participation metadata, checkpoints, and final models can reveal information. The guarantee depends on the threat model and controls such as Secure Aggregation, Differential Privacy, access control, retention, and privacy testing.
What is the difference between cross-device and cross-silo Federated Learning?
Cross-device FL typically coordinates many intermittently available consumer devices with small local datasets and severe communication limits. Cross-silo FL usually connects a smaller set of organizations with stable infrastructure, larger datasets, negotiated identities, and stronger governance. Their failure, trust, and aggregation assumptions differ.
Why does non-IID data matter in Federated Learning?
Clients often observe different populations, labels, time periods, or usage patterns, so each local objective can point in a different direction. Multiple local optimization steps may amplify this client drift. Teams should test convergence and utility per client or slice, not assume a pooled validation score represents every participant.
Is FedAvg enough for a production federated system?
No. FedAvg is an aggregation and optimization baseline. Production also requires authenticated participants, update validation, secure transport, privacy protection, poisoning defenses, model and dataset versioning, straggler handling, rollback, monitoring, and governance for purpose, consent, retention, and deletion.