Federated Learning: Training a Model Without Ever Seeing the Data

Moving the Model, Not the Data

The default way to build a machine learning model is to collect data in one place and train on it there. Federated learning inverts that. Instead of moving data to the model, the model moves to the data. A copy of the model is sent out to wherever the data already lives (a phone, a hospital server, a factory sensor), it trains for a bit locally, and only the resulting weight updates travel back to a central server. The raw data never leaves the device it started on.

Google’s research team coined the term around 2016 while working on a very unglamorous problem: how do you improve the keyboard’s word predictions using what people actually type, without collecting what people actually type? That constraint, useful data that legally or practically cannot be centralized, is the reason federated learning exists at all. It shows up again and again: hospitals that cannot pool patient scans, banks that cannot share transaction histories, phones that generate more text and location data per day than any server farm could ethically ingest.

FedAvg in Five Steps

The algorithm behind most federated systems is Federated Averaging, or FedAvg, introduced by McMahan and colleagues in 2017. It runs in rounds, and each round follows roughly the same sequence:

1. The central server sends the current global model to a selected group of clients (a subset of devices or institutions, not necessarily all of them).
2. Each client trains that model for a few local epochs using only its own data.
3. Each client sends back the change in its model weights, not the data that produced them.
4. The server combines all the updates into a new global model, weighting each client’s contribution by how much data it trained on.
5. The updated global model gets sent out again for the next round.

In large consumer deployments like Gboard, this can run across millions of phones and thousands of rounds. In medical or financial settings, the numbers flip: a handful of institutions, each holding a large and valuable dataset. Researchers call the first setup cross-device and the second cross-silo, and the two have different bottlenecks. Cross-device systems worry about devices dropping offline mid-round. Cross-silo systems worry more about a single hospital’s data skewing the whole model.

Gboard’s Prediction Engine

The clearest production example is still Google’s own keyboard. Gboard’s next-word prediction, smart compose, and emoji suggestions are trained with federated learning directly on users’ phones, and the words someone actually types never get uploaded anywhere. What gets uploaded is a small model update reflecting how that local model changed after a bit of training on that person’s typing.

Google has kept refining the privacy side of this pipeline. A 2023 paper from the Gboard team describes pairing FedAvg with a technique called DP-FTRL, which gives formal differential privacy guarantees without needing to randomly sample clients in a specific way, combined with secure aggregation so the server can sum client updates without seeing any individual one in the clear. The team reported that, as of that work, every next-word prediction language model shipped in Gboard carries a formal DP guarantee, and that this is now a requirement for future launches, not an optional add-on.

Brain Scans That Never Leave the Hospital

Medical imaging is where the cross-silo version of federated learning has been tested hardest. The Federated Tumor Segmentation challenge, known as FeTS and run under MICCAI, trains models to outline glioma tumors in brain MRI scans using data that stays physically inside each participating hospital. The underlying dataset, based on BraTS, includes well over a thousand multi-modal MRI scans contributed by institutions across the globe, thirty-two of them in one recent benchmark, and the training itself runs on Intel’s OpenFL framework with a 3D U-Net segmentation model.

What makes FeTS interesting isn’t just the privacy angle, it’s that it exposed real engineering lessons. Work from the challenge found that letting the server adaptively weight contributions from different sites, rather than treating every hospital’s update identically, improved the final model. It also found that having only a fraction of institutions (roughly a fifth in some rounds) actively participate at any given step saved time and computing resources without hurting accuracy. That is not something you would predict from the theory alone. It came out of running the system on real institutional data.

The Non-IID Problem

FedAvg was built assuming, at least loosely, that each client’s local data looks like a small fair sample of the whole population. Real deployments almost never work that way. One hospital sees mostly one tumor subtype because of its patient population. One phone user types mostly in a language the global model underrepresents. Researchers call this statistical heterogeneity, or more casually, the non-IID problem, and it turns out to matter a lot. Studies have shown that plain FedAvg can converge slowly or fail to converge at all once client data gets sufficiently heterogeneous, a failure mode often described as client drift, where each local model wanders toward its own client’s quirks between rounds instead of staying aligned with the group.

FedProx, proposed as a direct response, adds a regularization term that penalizes local updates for straying too far from the shared global model, which helps stabilize training under heterogeneity. It is not a complete fix. Newer work keeps proposing alternatives: clustering clients with similar data before aggregating, weighting updates by how well they align with the overall gradient direction, sampling clients more deliberately. None of this is fully solved, which is worth knowing if anyone frames federated learning as a plug-and-play technique. It has real optimization problems that centralized training simply does not run into.

Is Federated Actually Private?

The pitch for federated learning leans hard on privacy, and it’s easy to hear «the data never leaves the device» and assume the problem is solved. It isn’t. The model updates themselves can leak information about the data that produced them, sometimes in surprising detail.

The foundational demonstration of this is a 2019 paper by Zhu and colleagues, Deep Leakage from Gradients, which showed that in small networks, an attacker with access to a single gradient update could reconstruct the original training image with near pixel-level accuracy, no auxiliary data needed. A more recent and more concerning example targeted Gboard directly. A 2023 study from Trinity College Dublin ran new attacks against the actual next-word prediction model used in the production app and found that the words a person typed could be recovered with high accuracy, including full sentence order, and that standard countermeasures like training on mini-batches or adding local noise did not stop it.

This is why serious federated systems layer in more than just «don’t centralize the data.» Differential privacy bounds how much any single user’s data can influence the shared model and adds calibrated noise to make individual contributions statistically hard to isolate. Secure aggregation is a cryptographic protocol that lets the server compute the sum of client updates without ever seeing any individual client’s update unencrypted. Neither of these is automatic. They have to be deliberately engineered in, and Gboard’s own team treats formal DP guarantees as something they had to build toward over several years, not something federated learning gave them for free.

Regulation, Money, and the Push Toward FL

Part of why federated learning is getting more attention now, rather than staying a research curiosity, is that data protection law increasingly makes centralizing sensitive data a liability rather than a convenience. Rules like GDPR and HIPAA push organizations toward architectures that minimize how much personal data moves or gets pooled in the first place, and federated learning fits that requirement structurally rather than as an afterthought.

The commercial numbers reflect this shift. Market research estimates put the federated learning market at roughly $0.33 billion in 2025, growing to about $0.46 billion in 2026, and projects it reaching close to $1.77 billion by 2030, a compound annual growth rate near 40 percent. The drivers cited are the ones you’d expect: tighter privacy expectations, wider AI adoption generally, and the growing number of edge and IoT devices that generate data faster than anyone could reasonably centralize it.

Federated Fine-Tuning for LLMs

The newest frontier is applying federated learning to large language models, and it runs into an immediate practical wall: a phone cannot fine-tune a multi-billion parameter model in full. The fix researchers have converged on is pairing federated training with parameter-efficient fine-tuning methods, most commonly LoRA (low-rank adaptation), where each device trains only a small set of additional parameters layered on top of a frozen base model, and only that small adapter gets shared and aggregated instead of the whole network.

Work like the heterogeneous LoRA approach for on-device foundation models, and separate methods like FedBiOT that let a large model be fine-tuned collaboratively without ever moving the full model to any single client, are early attempts at making this practical on real hardware. The appeal is obvious: a personalized assistant that adapts to how someone actually writes, without that writing ever leaving their device, while still benefiting from a model trained across many users. The catch is that everything covered above, statistical heterogeneity across devices, the risk that gradients leak information, comes along for the ride, just at the scale of a much bigger and more expressive model.

The Real Trade-off

Federated learning is often described as free privacy, and that framing undersells what’s actually happening. It’s a shift in where the risk sits, not a removal of risk. In exchange for not centralizing raw data, you take on a distributed system with unreliable clients, uneven data, and communication costs that a single dataset in one place never had, and you take on an attack surface, the model updates themselves, that has to be actively defended rather than assumed safe.

That trade is genuinely worth making in plenty of cases. Hospitals really cannot pool patient scans across borders, and a billion phones really cannot upload everything users type. But it is a trade, and the next stretch of federated learning research, particularly around fine-tuning language models on-device, is largely going to be spent paying down the same debts that Gboard and FeTS already ran into: how to handle clients whose data doesn’t look like anyone else’s, and how to stop the model updates from quietly giving away what they were trained on.

By: Max Johnson B.