A local model is a client-specific copy of the global model in a federated learning system that is trained exclusively on the device's private, local dataset. During a communication round, the client downloads the current global model, performs multiple local epochs of training on its own data, and computes a model delta (the parameter update) to send back to the server. This architecture ensures raw training data never leaves the client device, providing a foundational privacy guarantee.
Glossary
Local Model

What is a Local Model?
A core component in federated learning, the local model is the instance trained directly on a client's private data.
The local model's training is governed by the core Federated Averaging (FedAvg) algorithm. Challenges like statistical heterogeneity (non-IID data) can cause client drift, where local models diverge. Techniques such as FedProx add a proximal term to the local objective to constrain updates. After local training, only the compact model update is transmitted for secure aggregation, balancing collaborative learning with stringent data sovereignty requirements.
Key Characteristics of a Local Model
In federated learning, a local model is a client-specific instance of the global model. It is the core computational unit that performs learning directly on private, decentralized data.
Ephemeral Instance
A local model is a temporary copy of the global model downloaded by a client (e.g., a smartphone or edge device) at the start of a communication round. It exists only for the duration of local training. Its lifecycle is:
- Instantiated from the latest global model parameters.
- Trained for a specified number of local epochs.
- Used to compute an update (the model delta).
- Discarded after the update is sent, preserving client memory. The learned knowledge is captured solely in the transmitted update.
Data Sovereignty
The defining characteristic of a local model is that it trains exclusively on the client's private local dataset, which never leaves the device. This enforces a strict privacy-by-design architecture.
Key implications:
- Raw Data Isolation: Sensitive user data (e.g., personal messages, health metrics, on-device photos) is never transmitted or centralized.
- Regulatory Compliance: This architecture directly supports compliance with frameworks like GDPR and HIPAA by minimizing data movement.
- Trust Model: The server only ever sees mathematical updates (gradients or parameter deltas), not the underlying data, establishing a foundational trust boundary.
Optimization Anchor
The local model's objective is to minimize loss on its local data distribution. It performs multiple steps of stochastic gradient descent (SGD) or a variant, acting as a local optimizer. This creates a fundamental tension:
- Goal: Improve performance on the client's specific data.
- Constraint: Updates must also be useful for improving the shared global model.
Under statistical heterogeneity (non-IID data), this local optimization causes client drift, where models diverge. Algorithms like FedProx add a proximal term to the local loss to anchor updates closer to the global model.
Update Generator
The primary output of a local model is a model update (or delta). This is the mathematical difference between the model's parameters before and after local training.
Update Calculation: Δ_i = θ_local^(t+1) - θ_global^t
Where Δ_i is the update from client i, θ_global^t is the initial global model, and θ_local^(t+1) is the locally trained model.
This delta is then processed (e.g., compressed, clipped for differential privacy) and sent to the server for aggregation. The local model's role is complete once this transmission occurs.
System Heterogeneity Interface
Local models must operate within the highly variable constraints of edge devices, making them an interface for system heterogeneity.
Key variations they must accommodate:
- Compute Power: From powerful GPUs to microcontrollers.
- Memory: Limits model size and batch processing.
- Connectivity: Intermittent or slow networks affect download/upload of models and updates.
- Availability: Devices are only available for training when idle, plugged in, and on Wi-Fi.
Frameworks handle this via partial participation and straggler mitigation, where only a subset of available clients with capable local models complete a round.
Personalization Foundation
While the standard local model is transient, its architecture is the foundation for personalized federated learning. Techniques modify the local model's structure to create persistent, user-specific intelligence.
Common Approaches:
- FedPer: Keeps the final layers (the "head") of the model local and personal, while collaboratively training shared base layers.
- FedRep: Learns a shared representation globally, while clients train unique local heads.
- FedBN: Keeps Batch Normalization layer statistics local to each client, accounting for feature distribution shift without adding persistent parameters.
In these paradigms, the local model evolves from a temporary worker into a lasting, tailored asset.
Lifecycle in a Federated Averaging Round
This section details the role and lifecycle of the local model within a single communication round of the Federated Averaging (FedAvg) algorithm.
A local model is a client-specific instance of the global model downloaded at the start of a federated learning round. The client trains this model exclusively on its private, on-device dataset for a predetermined number of local epochs. This local training phase computes a model delta—the mathematical difference between the initial and final local parameters—which encapsulates the learned knowledge from that client's data.
After local training, the client transmits only the compact model delta to the central server for secure aggregation. The original local model and its private training data are never exposed. The server aggregates deltas from all participating clients, typically via weighted averaging, to update the global model. This cycle repeats, with each round refining the global model through decentralized, privacy-preserving collaboration.
Local Model vs. Global Model
A comparison of the two primary model instances in the federated learning paradigm, highlighting their distinct roles, locations, and lifecycle stages.
| Feature | Local Model | Global Model |
|---|---|---|
Primary Function | Performs local training on private client data | Represents the aggregated, collaborative knowledge from all clients |
Physical Location | Resides on the federated client device (e.g., phone, sensor, edge server) | Resides on the central coordinating server |
Lifecycle Stage | Ephemeral; instantiated, trained, and discarded per communication round | Persistent; evolves iteratively across all communication rounds |
Training Data | Exclusively the client's private, on-device dataset | Never directly accesses any raw client data; learns from aggregated updates |
Update Mechanism | Parameters are updated via local SGD over several epochs | Parameters are updated via weighted averaging of client model deltas |
Privacy Exposure | High risk; has direct access to raw, sensitive user data | Theoretically zero; only sees mathematical updates, not raw data |
Convergence Target | May diverge from global objective due to client drift (non-IID data) | The central optimization target; aims to minimize global loss |
Personalization | Can be the basis for personalized models (e.g., via FedPer, FedRep) | Is a generalist model; may underperform on individual client distributions |
Frequently Asked Questions
A local model is the client-side instance of a neural network in a federated learning system. These questions address its core function, lifecycle, and technical characteristics.
A local model is a complete, downloadable instance of the global neural network that a federated learning client trains exclusively on its own private, on-device dataset. It is the fundamental unit of computation in the federated paradigm, enabling decentralized training without data leaving the device. The client receives the latest global model parameters from the server, performs multiple local epochs of stochastic gradient descent on its local data, and produces a model delta—the difference between its updated parameters and the initial ones—which is sent back to the server for aggregation. This process preserves raw data privacy while allowing collective intelligence to emerge.
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
A local model operates within a broader ecosystem of federated learning concepts. These related terms define the algorithms, processes, and challenges that govern its training and aggregation.
Federated Averaging (FedAvg)
Federated Averaging (FedAvg) is the foundational iterative algorithm that orchestrates the training of a local model. The server coordinates multiple clients in a series of communication rounds, where each client trains its local model and sends back an update. The server aggregates these updates, typically via a weighted average, to form a new global model. FedAvg's efficiency stems from performing multiple local epochs of training per communication round, drastically reducing the required server-client exchanges compared to a naive federated SGD approach.
Global Model
The global model is the central, shared neural network whose parameters are maintained by the server. It is the target of the federated learning process. In each round:
- The server broadcasts the current global model to selected clients.
- Each client uses it to initialize their local model.
- After local training, client updates (model deltas) are sent back.
- The server performs update aggregation to produce a new, improved global model. The global model represents the collaborative knowledge learned from all participating devices' data, without that data ever leaving its source.
Client Drift
Client drift is a critical optimization challenge caused by statistical heterogeneity (non-IID data) across clients. It occurs when local models, trained on diverse data distributions, diverge from the global objective. This divergence hinders convergence and degrades final model performance. Mitigation strategies include:
- FedProx: Adds a proximal term to the local loss function to constrain updates.
- SCAFFOLD: Uses control variates to correct for update variance.
- Gradient Clipping: Caps update norms to limit the influence of outliers. Managing client drift is essential for stable federated training.
Update Aggregation
Update aggregation is the server-side process that combines the model deltas from participating clients to update the global model. The standard method is weighted averaging, where each client's update is scaled by the size of its local dataset. This ensures the global objective aligns with the overall data distribution. Advanced aggregation techniques include:
- FedOpt Framework: Applies adaptive optimizers (e.g., Adam) to aggregated updates.
- FedAvgM: Incorporates server-side momentum for accelerated convergence.
- Secure Aggregation: Cryptographically combines updates without revealing individual contributions.
Personalized Federated Learning
Personalized FL techniques adapt the federated paradigm to produce models tailored to individual clients' data, addressing the limitations of a single global model under high data heterogeneity. Key approaches that modify the local model paradigm include:
- FedPer: Keeps the final model layers (the "head") local and personal, while collaboratively learning the base layers.
- FedRep: Clients learn a shared representation (model body) but train unique local heads.
- FedBN: Localizes batch normalization statistics, allowing the model to adapt to local feature distribution shifts. These methods balance shared knowledge with local specialization.
Communication-Efficient FL
This suite of techniques reduces the bandwidth and frequency of communication between clients and the server, a major bottleneck. It directly impacts how local model updates are transmitted. Core methods include:
- Update Compression: Applying quantization (reducing numerical precision) and sparsification (sending only the largest values) to shrink update size.
- Partial Client Participation: Selecting only a subset of available clients per round.
- Local Epochs: Performing multiple local training passes per round amortizes communication cost.
- Straggler Mitigation: Using asynchronous protocols or deadlines to prevent slow clients from delaying aggregation.

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