Clients and the Server
Day 1 · Who participates in federated learning, and what each side is responsible for.
Hi learner, welcome to FedLab!
We’re glad you’re here. Let’s take this week one step at a time, starting with the idea of learning together while keeping data local.
What you’ll learn this week
This week we slow down and name every moving part of a federated system. You will learn exactly what clients and the server do, what happens during local training, what a communication round is, what a model update contains, how aggregation combines updates, and how all of it comes together in FedAvg. Day 7 is the weekly test.
Two roles, one system
Every federated learning system is built from two kinds of participants. Clients are the data owners: phones, laptops, hospital servers, or company branches that each hold their own local dataset. The server is the coordinator: it organizes training but never receives the clients' raw data.
The division of labor is strict. Clients do the learning — they train the model on their own data. The server does the organizing — it decides which clients participate in each round, sends them the current model, collects their updates, and combines those updates into an improved global model.
This separation is the whole point of FL. If the server needed the raw data, we would be back to centralized training. If clients never communicated, each would be stuck with a model trained only on its own small slice of the world.
Holds the shared model
1/4 · Share the global model
What a client actually is
A "client" is not always a person's phone. In cross-device FL, clients are millions of personal devices, each with a small, private dataset — think of a keyboard app learning from your typing. In cross-silo FL, clients are a handful of organizations, each with a large dataset — think of hospitals collaborating on a diagnosis model.
Clients differ in more than just data. They have different hardware, battery levels, network quality, and availability. A phone may go offline mid-round; a hospital server may be busy during the day. A real FL system must expect clients to be unreliable and design around it.
Clients also have no reason to fully trust each other or the server. Later weeks on security will ask what happens when a client lies about its update, or when the server tries to peek at what an update reveals. For now, just keep the roles clear.
What the server is responsible for
The server runs the training schedule: it picks a subset of available clients for each round, sends them the current global model, waits for their updates, and aggregates the results. It also decides when training is done.
Crucially, the server is the only participant with a global view — but its view is made of model updates, not data. It sees numbers that describe how each client's model changed, never the examples that caused the change.
Remember the simple picture: the server coordinates, clients compute, raw data stays put. Every topic this week zooms into one part of that picture.