Federated Learning Across Hospitals: GPU and Network Planning
Overview
Multi-site clinical AI has a structural problem: the models need data from many hospitals, and the hospitals cannot easily share patient data with each other. Federated learning addresses this by moving the model to the data instead of the data to the model — each site trains locally, only model updates are exchanged, and no patient record leaves its institution. For Indian hospital networks operating under DPDP, that is an attractive property. The cost, which is often understated, is that every participating site needs real GPU capacity and the whole system runs at the pace of its slowest participant.
Key takeaways
- Data never moves — each site trains locally and shares only model updates, which is the governance benefit.
- Every site needs GPU capacity, not just the coordinator; this is the cost most consortia underestimate.
- The slowest site sets the pace in synchronous federated training, so heterogeneous hardware is a real problem.
- Bandwidth is modest, reliability is not — update exchange is small but must complete every round.
- Data heterogeneity is the technical risk — different scanners, protocols and populations degrade naive averaging.
How the training loop works
A coordinator distributes the current global model to every participating site. Each site trains it for a defined number of steps on its local data, then returns the updated weights or the gradient delta. The coordinator aggregates those updates — typically a weighted average — into a new global model, and the cycle repeats. Patient data stays inside each hospital’s boundary throughout; only model parameters cross the network.
Two variants matter operationally. Synchronous federation waits for every site each round, which gives clean convergence but means one slow or offline site stalls the whole consortium. Asynchronous federation accepts updates as they arrive, which tolerates variable participation but complicates convergence. Most clinical consortia start synchronous for simplicity and move to asynchronous once site reliability proves uneven.
What each site must provide
| Requirement | Detail | Common gap |
|---|---|---|
| GPU capacity | Sufficient to train the model on local data per round | Smaller sites have none |
| Curated local dataset | Labelled, de-identified, consistent format | Labelling effort underestimated |
| Reliable network path | Outbound to coordinator each round | Hospital firewalls and change control |
| Local technical staff | To run and troubleshoot the client | No dedicated resource at small sites |
| Governance approval | Ethics and institutional sign-off | Slower than the technical work |
The first row is where consortia fail. Federated learning is often proposed precisely because smaller hospitals have valuable data, and those are the hospitals least likely to own GPU hardware or the staff to run it. A realistic programme budgets for equipping participant sites, not just the coordinating centre, and that capital cost frequently exceeds what the coordinating institution expected.
Network requirements are smaller than intuition suggests
A common misconception is that federated learning needs high-bandwidth links. It does not: what crosses the network each round is a set of model weights, typically hundreds of megabytes to a few gigabytes depending on model size, once per round rather than continuously. Compared with moving imaging datasets, this is trivial.
What does matter is reliability and predictability. A round cannot complete until every synchronous participant has returned its update, so an unreliable link at one site delays everyone, repeatedly, across hundreds of rounds. For Indian deployments spanning tier-2 and tier-3 city hospitals, the practical requirement is a dependable modest link rather than a fast unreliable one, plus resumable transfers so a dropped connection does not force a full round restart.
Data heterogeneity is the real technical problem
Hospitals differ in ways that matter to a model: scanner manufacturers and generations, acquisition protocols, contrast usage, patient demographics, disease prevalence and labelling conventions. Naive averaging of updates trained on very different local distributions can converge poorly or produce a global model worse than a good local one.
Mitigations exist and should be planned rather than discovered. Harmonising acquisition protocols and preprocessing across sites reduces the variation at source. Personalisation approaches keep a shared backbone with site-specific adaptation layers, which often outperforms a single global model. And per-site evaluation is essential: report performance at every site, not just the pooled average, because a model that helps large sites and harms small ones is a failure even with good aggregate numbers.
Governance comes before code
The technical setup is usually faster than the institutional agreement, and starting the former without the latter wastes effort. A workable federated programme needs, at minimum: a data-sharing agreement covering what is exchanged (model updates, not data) and what is not, ethics approval at each site, an agreed de-identification standard applied consistently, and a clear statement of who owns the resulting model and who may use it for what.
Under DPDP, the argument that no personal data crosses the boundary is strong but not automatic — model updates can in principle leak information about training data, and a serious programme addresses this explicitly through techniques such as secure aggregation or differential privacy, and documents the analysis. Penalties up to Rs 250 crore make that documentation worth doing properly. The wider residency and control framing is in DPDP-ready AI infrastructure planning.
When federation is worth it
Federated learning is the right choice when the data genuinely cannot be pooled and the model genuinely needs multi-site diversity. It is the wrong choice when a single institution has enough data, when the sites could lawfully share de-identified data and simply have not organised it, or when the consortium lacks the operational maturity to run a distributed system across institutions with different IT capabilities.
A pragmatic middle path many Indian networks adopt is centralised training on properly de-identified pooled data where consent and governance permit, reserving federation for the sites or data categories where pooling is genuinely blocked. That is less elegant but delivers a model faster, and it concentrates GPU investment in one place rather than requiring capability at every participant. The single-site infrastructure baseline is in healthcare AI infrastructure readiness in India, and the imaging-specific sizing in imaging foundation models.
Frequently asked questions
What is federated learning in healthcare?
A training approach where each hospital trains a shared model on its own data and returns only model updates to a coordinator, which aggregates them. Patient data never leaves the institution, which is why it appeals to networks operating under data protection constraints.
Does every hospital need a GPU?
Yes, and this is the cost most consortia underestimate. Local training happens at each site, so each participant needs capacity sufficient to train the model on its own data per round — including the smaller hospitals whose data motivated the project.
How much network bandwidth does it require?
Less than expected. Only model weights cross the network, typically hundreds of megabytes to a few gigabytes once per round. Reliability and resumable transfer matter far more than raw speed, because a synchronous round cannot complete until every site responds.
What is the main technical risk?
Data heterogeneity. Different scanners, protocols, populations and labelling conventions across sites can make naive update averaging converge poorly. Harmonise preprocessing, consider site-specific adaptation layers, and evaluate per site rather than only on the pooled average.
Is federated learning always the right answer?
No. It suits cases where data genuinely cannot be pooled and multi-site diversity is genuinely needed. Where consent and governance permit properly de-identified pooling, centralised training is faster to deliver and concentrates GPU investment in one place.
Ready to deploy?
Talk to an RDP architect about power, cooling and lead time.