Federated Averaging (FedAvg, McMahan et al. 2017) trains one shared model across devices that never upload their raw data. Each round, every client i starts from the current global weights wg, runs E local gradient steps on its own private objective Li, and only the resulting weight vector is sent back:
w_i ← w_g − η · ∇L_i(w_i), repeated E times (local SGD)
w_g ← Σ_i (n_i / N) · w_i (FedAvg aggregation)
Here each client's private loss is modeled as a simple quadratic bowl Li(w) = ‖w − ci‖² centered on that client's own data-optimal weights ci. When clients hold non-IID data, the ci are spread apart (the "skew" slider) — so local training pulls each client's weights toward a different point before the server ever sees them. This is real client drift: more local epochs E, a larger learning rate η, or more skew all push clients further from wg before averaging, which slows convergence and can bias FedAvg away from the true minimizer of the global objective (addressed in practice by methods like FedProx and SCAFFOLD).
The bowl-shaped surface is the global objective L(w) = Σ (ni/N) Li(w) — a weighted average of every client's bowl. Its true minimum is the sample-weighted mean of the client optima; switching to equal weighting moves that target, showing how FedAvg's ni/N weighting (not just plain averaging) determines which clients dominate the aggregated model.
- Non-IID skew — how far apart each client's local data optimum is from the others.
- Local epochs E — gradient steps each client takes before reporting back; more steps means more communication efficiency but more drift.
- Learning rate η — local step size; each local step contracts the distance to ci by a factor (1 − 2η).
- Sample-weighted vs equal — real FedAvg weights each client's update by ni/N (its share of total training examples); equal weighting lets a tiny client outvote a huge one.