Federated Averaging (FedAvg) is the foundational federated learning algorithm where selected clients independently perform multiple local stochastic gradient descent (SGD) steps on their private data partitions before transmitting only the resulting model deltas to a central server. The server then computes a new global model by taking a weighted average of these local updates, typically weighted by the number of local training samples, thereby preserving data locality.
Glossary
Federated Averaging (FedAvg)

What is Federated Averaging (FedAvg)?
The canonical algorithm for federated learning that combines local stochastic gradient descent on decentralized clients with periodic weighted averaging on a central server to produce a global model without centralizing raw data.
The core innovation of FedAvg is its ability to reduce communication rounds by increasing local computation, a trade-off parameterized by the number of local epochs E and batch size B. While highly effective on IID data, its convergence can suffer under non-IID distributions due to client drift, motivating more advanced algorithms like FedProx and SCAFFOLD that add regularization or control variates to correct for heterogeneous local objectives.
Key Characteristics of FedAvg
Federated Averaging (FedAvg) is the foundational algorithm that makes decentralized training practical by shifting computation to the edge and communicating only aggregated model updates. These characteristics define its operational profile.
Local Stochastic Gradient Descent (SGD)
The core mechanism of FedAvg is the execution of multiple local SGD steps on each client before communication occurs. Unlike traditional distributed training where gradients are exchanged after every batch, FedAvg allows clients to compute model deltas over several epochs on their local data. This significantly reduces the communication-to-computation ratio, as the number of synchronization rounds is decoupled from the number of local optimization steps. The local update rule follows: w_{t+1} = w_t - η∇F_k(w_t), where F_k is the local objective on client k.
Weighted Model Averaging
The server aggregates client updates using a weighted average proportional to the size of each client's local dataset. The global model update is computed as: w_{t+1} = Σ (n_k / n) * w^k_{t+1}, where n_k is the number of samples on client k and n is the total samples across all selected clients. This weighting scheme ensures that clients with more data exert proportionally greater influence on the global model, providing a statistically principled aggregation mechanism that converges to the centralized empirical risk minimizer under IID assumptions.
Client Drift Phenomenon
When local datasets are non-IID (heterogeneous), each client's local model drifts toward its own local optimum during multiple SGD steps. This client drift causes the averaged global model to diverge from the true global optimum, potentially slowing convergence or degrading final accuracy. The drift magnitude is proportional to the number of local epochs E and the degree of statistical heterogeneity. This is the primary challenge FedAvg faces in real-world deployments, motivating variants like FedProx and SCAFFOLD that add regularization or control variates to correct the drift.
Fractional Client Participation
FedAvg operates with a client fraction C (0 < C ≤ 1), selecting only a random subset of available clients per round. This partial participation is essential for scalability in cross-device settings with millions of clients, where waiting for all devices would be infeasible. The stochastic nature of client selection introduces additional variance into the aggregation, but also provides a regularization effect that can improve generalization. Typical values for C range from 0.1 to 0.5 in production deployments.
Communication Round Structure
Each FedAvg round follows a strict synchronous protocol:
- Step 1: Server broadcasts current global model
w_tto selected clients - Step 2: Clients initialize local model with
w_tand performElocal epochs of SGD - Step 3: Clients transmit their updated model weights
w^k_{t+1}back to the server - Step 4: Server computes the weighted average and updates the global model This synchronous barrier ensures consistent aggregation but makes the system vulnerable to stragglers—slow clients that delay the entire round.
Hyperparameter Sensitivity
FedAvg's performance is highly sensitive to three key hyperparameters:
- Local epochs
E: More epochs reduce communication but increase client drift. Values typically range from 1 to 20. - Local batch size
B: Affects gradient noise and convergence speed. Larger batches reduce variance but increase computation. - Client fraction
C: Controls the trade-off between round latency and update variance. Tuning these parameters requires balancing communication efficiency against convergence stability, with optimal values depending heavily on the degree of data heterogeneity across clients.
Frequently Asked Questions
Clear, technical answers to the most common questions about the foundational Federated Averaging (FedAvg) algorithm, its mechanisms, and its role in privacy-preserving collaborative machine learning.
Federated Averaging (FedAvg) is the foundational federated learning algorithm where a central server coordinates the training of a shared global model across decentralized clients holding local data. The process works in iterative communication rounds: the server sends the current global model to a selected subset of clients; each client performs multiple steps of stochastic gradient descent (SGD) on its private dataset to produce an updated local model; the clients transmit only these model updates—not the raw data—back to the server; and the server computes a new global model by taking a weighted average of the received updates, typically weighted by the number of local training samples. This algorithm, introduced by McMahan et al. in 2017, dramatically reduces communication overhead compared to naive Federated SGD by performing multiple local epochs before synchronization, making it practical for real-world deployments like mobile keyboard prediction and healthcare diagnostics.
FedAvg vs. Other Federated Optimization Algorithms
A feature-level comparison of Federated Averaging against other prominent federated optimization algorithms designed to handle statistical heterogeneity and client drift.
| Feature | FedAvg | FedProx | SCAFFOLD |
|---|---|---|---|
Core Mechanism | Weighted averaging of local SGD updates | Adds proximal term to local objective | Uses control variates to correct client drift |
Client Drift Correction | |||
Partial Participation Robustness | Degrades with high heterogeneity | Explicitly robust via proximal term | Robust via variance reduction |
Communication Overhead per Round | 1x model size | 1x model size | 2x model size (control variates) |
Convergence Rate on IID Data | Linear speedup | Comparable to FedAvg | Comparable to FedAvg |
Convergence Rate on Non-IID Data | Slower, may diverge | Stable, bounded divergence | Faster, asymptotically matches SGD |
Local Compute Overhead | Standard SGD steps | Standard SGD + proximal term | SGD + control variate update |
Server State Requirement | None beyond global model | None beyond global model | Maintains server control variate |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Federated Averaging (FedAvg) does not operate in isolation. Its performance and convergence are deeply influenced by the surrounding topology, the heterogeneity of client data, and the aggregation rules used to combine updates. The following concepts define the operational context for FedAvg in production healthcare networks.
Cross-Silo Federated Learning
The primary deployment topology for FedAvg in healthcare, where a small number of reliable institutional clients (e.g., hospitals) participate in all training rounds. Unlike cross-device settings with millions of unreliable smartphones, cross-silo assumes stateful clients with significant local compute and curated datasets. This topology allows FedAvg to run synchronous rounds without severe straggler issues, making it the default architecture for multi-institutional diagnostic model training.
Non-IID Data Distributions
The primary challenge to FedAvg convergence in real-world medical settings. Patient populations vary dramatically across hospitals—a rural clinic sees different disease prevalence than an urban research center. This statistical heterogeneity causes client drift, where local SGD steps pull models toward divergent local optima. FedAvg's weighted averaging partially mitigates this, but severe label distribution skew or concept shift requires algorithmic modifications like FedProx or SCAFFOLD to restore stability.
Secure Aggregation Protocols
A cryptographic layer that pairs with FedAvg's weighted averaging step to prevent the central server from inspecting individual client model updates. Using secure multi-party computation or homomorphic encryption, the server computes the weighted average of encrypted model deltas without ever seeing a single hospital's contribution in plaintext. This transforms FedAvg from a privacy-conscious protocol into a mathematically privacy-guaranteed one, essential for HIPAA and GDPR compliance in cross-border medical research.
Client Selection Strategies
The scheduling logic that determines which hospitals participate in each FedAvg communication round. Random selection is the baseline, but healthcare deployments often use bandwidth-aware scheduling to prioritize clients with available network capacity or data-quality-weighted selection to ensure representative clinical distributions. Poor client selection can introduce sampling bias that skews the global model toward over-represented patient demographics.
Differential Privacy Guarantees
A mathematical framework applied to FedAvg's weight updates before transmission. By clipping per-client model deltas and injecting calibrated Gaussian noise into the aggregated result, the central server can bound the information leakage about any single patient's record. This converts FedAvg's implicit privacy (data stays local) into explicit, provable privacy with a measurable epsilon budget, satisfying institutional review boards and regulatory auditors.
Federated Model Evaluation
The distributed auditing process that validates a FedAvg-trained global model without centralizing test data. Each hospital evaluates the model on its local holdout set and reports only aggregate metrics back to the server. This preserves patient data locality while enabling bias detection across demographic subgroups. Without federated evaluation, a model that appears accurate globally may silently fail on underrepresented populations at specific clinical sites.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us