Edge Computing and Federated Learning: Private AI Training

Federated learning trains a shared AI model without collecting the data it learns from. Instead of sending your typing history, voice recordings, or patient scans to a central server, each device or hospital trains the model locally and sends back only a mathematical update. Google described the idea for Android keyboards in 2017, and Apple later applied it to Siri speaker recognition. This article explains how the loop works, where edge hardware fits in, what the privacy guarantees actually cover, and which attacks still work.

Key takeaways

• Federated learning moves the model to the data instead of the data to the model. Participants train locally and share updates, which a server averages into a better global model.
• Edge computing, meaning computation on phones, hospital machines, and local servers, supplies the hardware. Training usually waits until a phone is idle, charging, and on an unmetered network.
• Sharing updates is not the same as sharing nothing. Published attacks have reconstructed training images and text from gradients, so serious deployments add secure aggregation and differential privacy.
• Documented results exist: a 2020 study found federated brain tumor segmentation reached 99% of the quality of pooling the data, and a 2021 study across 20 institutions improved COVID-19 outcome prediction.
• The hardest open problems are statistical, not cryptographic: every participant's data looks different, and some participants may be malicious.

What federated learning replaces

Traditional machine learning follows a simple rule of gravity: pull all the data into one place, train a model there, then ship the model out. It works until the data cannot move. Hospitals are restricted by patient-privacy law and by their own ethics boards. Competing banks will not hand each other transaction logs. A billion phones generate more typing, voice, and photo data than anyone could, or should, upload.

Federated learning inverts the arrangement. A 2019 survey by Peter Kairouz and 58 co-authors defines it as a setting in which many clients, such as mobile devices or whole organizations, collaboratively train a model under the coordination of a central server, while the training data remains decentralized. The survey notes that this supports the principle of data minimization, the idea that you should collect only what you need.

Start with an analogy. Imagine five researchers, each with a private patient database, who want to produce one joint statistical model. Pooling the records into one spreadsheet would be a privacy disaster. Instead, each runs the same analysis on their own records and shares only summary numbers. A coordinator combines the summaries. Federated learning is that process automated for neural networks, repeated hundreds or thousands of times.

The second analogy works for the repetition: think of a class where each student practices at home and the teacher collects only the corrections each student made to a shared answer key, never the student's notebook. The teacher merges the corrections, issues a better answer key, and the cycle repeats.

The training loop, round by round

The algorithm that made the idea practical is Federated Averaging, or FedAvg, introduced by H. Brendan McMahan and colleagues in a paper first posted in February 2016. Their abstract reports that it needs 10 to 100 times fewer communication rounds than a naive federated version of stochastic gradient descent (the standard training method, which nudges a model's weights a little after each batch of examples). That mattered because communication, not computation, is the bottleneck when the clients are phones.

One round looks like this:

1. Selection. A server picks a subset of available clients, perhaps a few hundred phones out of millions.
2. Broadcast. The server sends each selected client the current global model.
3. Local training. Each client trains the model for a few passes over its own data. The data never leaves the device.
4. Upload. Each client sends back its updated weights, or the difference from the model it received. (A "gradient" is the direction in which a model's weights should change to reduce error; an update is a bundle of such changes.)
5. Aggregation. The server averages the updates, weighting each by how much data the client used, and produces a new global model.

Then the loop repeats with a fresh set of clients. Because each round averages the work of many participants, one person's idiosyncratic data has a limited effect on any single round.

Cross-device versus cross-silo

The Kairouz survey distinguishes two settings that look similar but behave very differently.

Feature	Cross-device	Cross-silo
Typical participants	Phones, wearables, vehicles	Hospitals, banks, research labs
Number of participants	Very large	Small (a handful to a few dozen)
Availability	Intermittent: devices drop out mid-round	Usually reliable and always on
Hardware	Limited battery, memory, and bandwidth	Servers or workstations
Main concern	Scale, dropouts, communication cost	Legal agreements, data heterogeneity, auditing
Example	Gboard next-word prediction	Multi-hospital tumor segmentation

Most public discussion focuses on the cross-device case, but most medical and financial work is cross-silo, where a few well-resourced participants have large, high-quality datasets and strong incentives to keep them private.

Where edge computing fits

Edge computing means doing computation close to where data is produced, on the phone, the sensor, or the hospital's own servers, rather than in a distant data center. For inference, the edge removes round-trip delay. For federated learning, it is the entire point, because the edge is where the data lives. For more on how models run on phones, see how edge AI works on your phone.

Training on a phone has costs that a data center never faces. Google's 2017 description of its Gboard system says training runs only when the phone is idle, charging, and connected to a free wireless network, so it does not affect the user's experience. The phone runs a miniature version of TensorFlow to do the work. Participants also appear and disappear unpredictably, which is why a 2019 Google paper on running federated learning at production scale, built on TensorFlow, devotes most of its pages to system design rather than algorithms.

Shrinking the model also helps. Compression techniques that reduce numerical precision make on-device training and uploads cheaper; the LLM quantization explainer covers the same idea applied to language models. Google's 2017 post reports that update compression using random rotations and quantization can reduce upload costs by up to another 100 times on top of FedAvg's savings.

Why not train everything on the device? A model trained only on one person's data sees a tiny, narrow sample. Federated learning lets millions of narrow samples add up to a broad one, which is why it beats purely local training for anything that benefits from variety.

Google's Gboard: the first large public deployment

Google's research blog introduced the approach on April 6, 2017, describing how Gboard, the Android keyboard, could improve query suggestions without uploading what people type. The phone stores context and whether you tapped a suggestion, trains locally, and sends a small update. The server combines many updates into a consensus change.

A November 2018 paper by Andrew Hard and eight co-authors then compared two ways of training a recurrent neural network for next-word prediction: standard server-based training on logged data and federated averaging on client devices. The federated model reached better prediction recall. The authors argued that the result shows on-device training is practical for language models and can use a higher-quality dataset, since it learns from what people actually type.

The 2017 post is also candid about limits. It notes that federated learning does not suit every problem, for example training on carefully labeled examples such as dog breeds, and that data already stored in the cloud, such as Gmail spam filtering, may not need it.

Privacy was tightened over time. Google's February 2022 post describes training a Spanish-language Gboard model of about 1.3 million parameters using an algorithm called DP-FTRL, with a formal user-level differential privacy guarantee. The post states the guarantee as zero-concentrated differential privacy with parameter ρ = 0.81 rather than as an epsilon value. "User-level" matters: it treats all the data on one device as a single person, which is a stronger promise than protecting each individual sentence.

Apple: on-device learning plus differential privacy

Apple's public record involves two separate techniques that are easy to confuse. The first is local differential privacy, which Apple introduced with iOS 10 for features such as emoji and QuickType suggestions. Each device adds noise to its own data before anything leaves it, so even Apple's servers see only randomized reports. That is stronger than central differential privacy, where a trusted server collects raw data and adds noise later, but it needs more noise for the same level of protection, which costs accuracy.

The second is federated learning proper. At the NeurIPS conference on December 8, 2019, Apple's head of privacy, Julien Freudiger, said Apple uses federated learning to personalize Siri's speaker recognition so that it responds to the owner's "Hey Siri" and ignores people nearby. Each device trains its own copy of the model on local audio, and only updated parameters go to a server to be merged into a master model. Apple pairs this with differential privacy, a combination it introduced with iOS 13, according to MIT Technology Review's report of the talk. The same techniques also support QuickType personalization and the Found In Apps feature.

A third Apple effort is often mislabeled as federated learning but is not. Apple's April 2025 research post describes using differential privacy with devices whose owners opt in to share Device Analytics: for Genmoji, devices are polled on whether they have seen a prompt fragment and answer with a noisy signal, so popular prompts surface while rare ones stay hidden. For text features, Apple generates synthetic emails, sends their embeddings to opted-in devices, and each device reports only which synthetic variant is closest. The post does not mention federated learning. It is a way to learn aggregate trends, not to train a shared model on device data.

Hospitals: training across institutions that cannot share records

Healthcare is where cross-silo federated learning has the strongest case. Patient data is governed by laws such as HIPAA in the United States and GDPR in Europe, and by hospital policy. Sharing raw scans across institutions can take years of legal work. Federated learning offers a technical alternative: send the model, not the patients.

Three studies illustrate the range.

Brain tumor segmentation (2020). Micah Sheller and colleagues, publishing in Scientific Reports on July 28, 2020, simulated a federation of 10 institutions using brain scans from the BraTS 2017 challenge, with the task of separating tumor from healthy tissue in MRI. Their global validation Dice score (a measure of overlap between the model's outline and the expert outline, where 1.0 is perfect) was 0.857 for federated learning and 0.862 for centrally pooled data. The abstract summarizes that as 99% of the model quality of data sharing. The cost was time: federated training needed roughly 2.26 times as many epochs. The paper also tested "institutional incremental learning," where institutions train the model one after another, and found it suffers from catastrophic forgetting, with the model biased toward the last institution it saw.

COVID-19 outcomes (2021). The EXAM study, by Ittai Dayan and colleagues in Nature Medicine (volume 27, 2021), trained a model across 20 institutions worldwide to predict a COVID-19 patient's future oxygen requirement from vital signs, laboratory values, and chest X-rays. The model reached an average area under the curve above 0.92 for predicting outcomes 24 and 72 hours after emergency-room presentation, with a 16% improvement in average AUC and a 38% improvement in generalizability compared with models trained at single sites.

Swarm Learning (2021). Stefanie Warnat-Herresthal and colleagues, in Nature (volume 594, 2021), proposed a variant that drops the central coordinator and uses Bitcoin.">blockchain-based peer-to-peer coordination. They tested it on COVID-19, tuberculosis, leukemia, and lung disease, using more than 16,400 blood transcriptomes from 127 clinical studies and more than 95,000 chest X-ray images. Swarm classifiers outperformed those built at individual sites. The authors describe Swarm Learning as going beyond federated learning because there is no single server to trust.

NVIDIA FLARE is one open-source toolkit used for this kind of work. NVIDIA describes it as a domain-agnostic SDK that includes built-in workflows for FedAvg, FedOpt, and FedProx, secure provisioning with SSL, an admin console, and support for PyTorch, TensorFlow, and NumPy. A caution: all three studies report research results. A model that works in a study is not a medical device, and clinical deployment requires validation and regulatory review that federated training does not replace. For the broader picture of AI in clinical settings, see AI in healthcare: diagnosis and treatment.

Why sharing updates is not automatically private

Early descriptions of federated learning sometimes implied that because raw data never moves, privacy is solved. Research since has shown that is too optimistic. Updates are computed from the data, and in some cases the data can be recovered from them.

In 2019, Ligeng Zhu, Zhijian Liu, and Song Han published "Deep Leakage from Gradients." They showed that private training data can be recovered from shared gradients, reporting pixel-wise accurate image reconstructions and token-wise matching for text. Among the defenses they discussed, gradient pruning was the most effective. A 2020 follow-up, iDLG by Bo Zhao, Konda Reddy Mopuri, and Hakan Bilen, showed that gradients leak the ground-truth labels of training examples for models trained with cross-entropy loss on one-hot labels, which makes the reconstruction attack more reliable.

These attacks are most effective when the attacker sees one client's update in isolation. That is where the layered defenses come in.

Defense	What it does	What it costs
Secure aggregation	Cryptography lets the server decrypt only the sum of many updates, not any individual one	Extra communication and more complex dropout handling
Differential privacy	Adds calibrated noise so one person's data barely changes the result	Lower model accuracy, more rounds to converge
Gradient compression or pruning	Sends only the largest or quantized parts of an update	Some accuracy loss; reduces leakage as a side effect
Homomorphic encryption or multi-party computation	Computes on encrypted values	Large computational overhead, used for high-stakes cases
Larger batches and more local steps	Mixes many examples into each update	Can interact with non-IID data (see below)

Google's 2017 post describes secure aggregation, then still being built for production, as a cryptographic protocol that lets the server decrypt only the average update, and only after hundreds or thousands of users have participated, so no individual phone's update can be inspected before averaging.

Differential privacy deserves a plain explanation. The idea, formalized by Cynthia Dwork, Frank McSherry, Kobbi Nissim, and Adam Smith in 2006, is that an algorithm's output should barely change whether or not any single person's data was included. The parameter epsilon bounds that change: a smaller epsilon is a stronger guarantee, and requires more noise. There is no universal "safe" epsilon, and the number alone says little without knowing what is being protected (one example or an entire user) and how many times the data is used. Google's 2022 Gboard post is a useful illustration, since it reports a user-level guarantee in the ρ form and warns that the earlier DP-FedAvg approach lacked a meaningful formal guarantee because the amplification it relied on is hard to verify in a real cross-device system.

Poisoning and backdoors: the attacker inside the federation

Privacy attacks target what the server can see. Poisoning attacks target what the federation produces.

In "How To Backdoor Federated Learning," Eugene Bagdasaryan and colleagues showed that any participant can insert a hidden backdoor into the joint model, for example making an image classifier assign an attacker-chosen label to images with a particular feature, or making a word predictor complete certain sentences with an attacker-chosen word. Their model-replacement technique let an attacker selected in a single round make the global model reach 100% accuracy on the backdoor task, and their "constrain-and-scale" approach was designed to evade anomaly detection.

Defenses exist, but they are hard to combine with privacy. Secure aggregation hides individual updates from the server, which also hides malicious ones. Robust aggregation rules try to discard outliers: Krum, proposed by Peva Blanchard and colleagues at NeurIPS 2017, was described by its authors as the first provably Byzantine-resilient aggregation rule for distributed stochastic gradient descent, in a setting where plain averaging fails with even one faulty participant. Krum was designed for distributed training generally, not specifically for federated learning with non-identical data, which is part of why the field keeps producing new defenses.

No single defense is known to stop all attacks, and that threat models differ between a hospital consortium (few, known participants) and a phone fleet (millions of anonymous ones). The site's piece on machine learning in cybersecurity covers how anomaly detection works in related settings.

The non-IID problem: everyone's data looks different

The hardest technical issue in federated learning is not privacy. It is that clients rarely have the same kind of data. One person types in Spanish and another in Korean. One hospital scans older patients on one brand of machine, another scans children on a different brand. Statisticians call data from different participants non-IID, short for not independent and identically distributed.

When each client trains for several steps on its own skewed data, its update pulls the model toward that client's local optimum. Averaging the updates then produces a worse compromise than training on pooled data would. The 2019 SCAFFOLD paper by Sai Praneeth Karimireddy and co-authors analyzes this as "client drift" and proposes control variates, a variance-reduction technique, to correct for it. The 2018 FedProx paper by Tian Li and co-authors adds a term to each client's objective that penalizes straying too far from the global model, and reports that in highly heterogeneous settings it improved absolute test accuracy by 22% on average over FedAvg.

Both results are the authors' own, on benchmark datasets chosen for the research, so treat the headline figures as evidence that the problem is real and tractable rather than as guarantees for your data. Overfitting to a participant's own data is an old machine-learning problem; the overfitting and underfitting explainer covers the basics of why it hurts.

Costs and trade-offs

Federated learning is not free, and it is not always the right tool. The table compares it with the alternatives.

Approach	Where data goes	Model quality	Privacy exposure	Main drawback
Centralized training	One server or cloud	Usually the best baseline	Highest: raw data pooled	Legal, security, and bandwidth barriers
Federated learning	Stays on clients; updates go to a server	Close to centralized in several studies (for example 99% in the BraTS study)	Lower, but updates can leak without extra defenses	Slower convergence, system complexity, non-IID data
Local-only training	Stays on one device	Limited by a small, narrow dataset	Lowest	Cannot learn from anyone else
Differentially private centralized training	One server, with noise added	Lower than non-private	Formal guarantee on outputs	Server still sees raw data

Federated learning also changes the engineering work. Teams must handle clients that disappear mid-round, models that must fit on small hardware, versioning across thousands of device types, and debugging when you cannot look at the data that caused a bug. In a cross-silo setting there are governance questions too: who owns the resulting model, who can audit it, and what happens if a participant leaves and asks for its contribution to be erased.

Common misconceptions

"Federated learning means the data is private." It means the raw data is not centralized. Whether the output is private depends on the defenses added, as the gradient-leakage research shows.

"Federated learning is only for phones." Several of the best-documented results are cross-silo hospital studies with 10 to 20 participants.

"It always matches centralized training." Some studies come close, such as 99% in the BraTS experiment, but others show a gap, and non-IID data can widen it.

"It replaces encryption." Encryption protects data in transit and at rest, but the server that trains on decrypted data still sees it. Federated learning avoids that exposure by never sending the data. The two are complementary, as covered in how encryption works.

"It is the same as on-device AI." On-device inference runs an already-trained model locally. Federated learning is about training. The two often appear together, which is why they are confused.

Frequently asked questions

Q: How is federated learning different from encrypting data before sending it to a server? A: Encryption protects data while it travels, but the server decrypts it to train, so the server ends up holding the raw data. In federated learning the raw data never leaves the device. The server receives model updates, which are derived summaries. Those updates can still leak information, which is why they are usually protected with secure aggregation and differential privacy.

Q: Can federated learning handle non-IID data? A: Partially. FedAvg can converge poorly when clients' data differ sharply. Methods such as FedProx, which penalizes drifting from the global model, and SCAFFOLD, which corrects client drift with control variates, address the problem. FedProx's authors report a 22% average absolute accuracy gain in highly heterogeneous settings, but results depend on the data and benchmark.

Q: What does differential privacy guarantee in federated learning? A: It bounds how much any one person's data can change the result. Smaller epsilon means stronger privacy and more noise. A guarantee only means something relative to what it protects: Google's Gboard work uses user-level privacy, treating all the data on a device as one person, which is stronger than protecting a single example.

Q: How much bandwidth does federated training use? A: It depends on model size and compression. Google's 2017 post reports that FedAvg needs 10 to 100 times less communication than a naive federated version of SGD, and that compression can cut upload cost by up to another 100 times. Google also restricts Gboard training to phones that are charging, idle, and on a free wireless connection.

Q: Does federated learning work only with neural networks? A: No. The idea applies to any model trained by iterative optimization, and researchers have developed federated versions of methods such as gradient-boosted trees and clustering. In practice, most deployments use neural networks because they gain the most from training on large, varied data.

Q: Is Apple's differential privacy the same as federated learning? A: No. Local differential privacy randomizes data on the device before it is sent, so servers see only noisy reports. Federated learning trains a shared model on device data and returns updates. Apple uses both, but its April 2025 work on Genmoji prompts and synthetic emails uses differential privacy without federated model training.

Q: Has federated learning been used for medical AI? A: Yes, in research. Studies have federated brain tumor segmentation across 10 institutions (a simulated federation), COVID-19 outcome prediction across 20 institutions, and Swarm Learning on blood transcriptomes and chest X-rays. These are research results, not approved clinical products.

The takeaway

Federated learning changes where trust has to live. In centralized machine learning, everyone trusts one server with everything. In federated learning, participants trust a protocol: that the server only sees aggregates, that noise bounds what any individual's data reveals, and that bad participants can be detected. Each layer works, and each has a cost in accuracy, speed, or complexity. The most reliable evidence is also the most modest: close-to-centralized quality in brain scans, better generalization across 20 hospitals, and keyboards and voice assistants that improve without uploading what you say. The fair conclusion is that federated learning is a strong tool when data cannot move, and a poor choice when it can.

Sources

• McMahan et al., "Communication-Efficient Learning of Deep Networks from Decentralized Data" (arXiv)
• Hard et al., "Federated Learning for Mobile Keyboard Prediction" (arXiv)
• Kairouz et al., "Advances and Open Problems in Federated Learning" (arXiv)
• Bonawitz et al., "Towards Federated Learning at Scale: System Design" (arXiv)
• Google Research: Federated Learning, collaborative machine learning without centralized training data (2017)
• Google Research: Federated learning with formal differential privacy guarantees (2022)
• Sheller et al., Federated learning in medicine (Scientific Reports, 2020)
• Zhu, Liu, Han, "Deep Leakage from Gradients" (arXiv)
• Zhao, Mopuri, Bilen, "iDLG: Improved Deep Leakage from Gradients" (arXiv)
• Bagdasaryan et al., "How To Backdoor Federated Learning" (arXiv)
• Li et al., "Federated Optimization in Heterogeneous Networks" (FedProx, arXiv)
• Karimireddy et al., "SCAFFOLD" (arXiv)
• MIT Technology Review: Apple's AI personalizes Siri with federated learning (2019)
• Apple Machine Learning Research: Understanding Aggregate Trends for Apple Intelligence Using Differential Privacy (2025)
• NVIDIA FLARE
• Blanchard et al., Machine Learning with Adversaries: Byzantine Tolerant Gradient Descent (NeurIPS 2017)

---

Read next:

• Quantum Computing and Machine Learning: Real Applications Emerging Now
• Machine Learning in Cybersecurity: How AI Detects Intrusions Before Humans Can
• Reinforcement Learning for Robotics: Teaching Machines to Move Through the World
• How AI Models Are Trained: The Full Pipeline Explained