Federated Learning Implementation: Train ML Models Without Data Transfer

We design and deploy artificial intelligence systems: from prototype to production-ready solutions. Our team combines expertise in machine learning, data engineering and MLOps to make AI work not in the lab, but in real business.
Showing 1 of 1All 1566 services
Federated Learning Implementation: Train ML Models Without Data Transfer
Complex
from 1 week to 3 months
Frequently Asked Questions

AI Development Areas

AI Solution Development Stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1318
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1226
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    926
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1160
  • image_logo-advance_0.webp
    B2B Advance company logo design
    620
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    894

Federated Learning Implementation: Train ML Models Without Data Transfer

A medical consortium of five hospitals wants to train a cancer detection model on X-rays. Transferring images is forbidden by GDPR and internal policies — fines for leaks reach 4% of annual turnover. We implement Federated Learning (FL) for such scenarios: each hospital trains the model locally, and the central server aggregates only weight updates. Data transfer savings reach 50–80%, and privacy is preserved.

Federated Learning is not just a technology but an architectural approach to distributed training. Data stays on devices (hospital servers, smartphones, industrial controllers), while the central node receives only gradient deltas. This ensures regulatory compliance (GDPR, CCPA) and unlocks scenarios where data physically cannot be transferred.

How Federated Learning Solves the Privacy Problem

In classic ML, data flows into a single repository — a risk. FL flips the process: the model goes to the data, not vice versa. Each client receives the current global model, fine-tunes on its samples, and returns updated weights. The server averages weights using FedAvg: ( w_{t+1} = \sum_i \frac{n_i}{n} w_i^t ), where ( n_i ) is the client’s dataset size. No raw example ever leaves the perimeter.

When FL Delivers Maximum Effect

Scenarios with strict privacy requirements: healthcare (diagnostics, genomics), finance (fraud detection, scoring), mobile devices (personalization). FL is especially effective when data is scarce or highly distributed — e.g., rare diseases where each hospital has only a few cases, but the joint model sees the entire population. In our projects, an FL model across 10 hospitals outperformed local models by 8% AUC (0.94 vs 0.87).

FedAvg — The Baseline Algorithm

Federated Averaging (McMahan et al., 2017) is the FL standard:

  1. Server initializes global model ( w_0 )
  2. Each round, a subset of clients is selected (typically 20–50%)
  3. Each client trains locally (3–10 epochs) and returns weight deltas
  4. Server aggregates weighted by dataset size: ( w_{t+1} = \sum_i \frac{n_i}{n} w_i^t )
Python implementation with Flower framework
import flwr as fl
import torch
from typing import List, Tuple, Dict
import numpy as np

class MedicalModelClient(fl.client.NumPyClient):
    def __init__(self, model, train_loader, val_loader):
        self.model = model
        self.train_loader = train_loader
        self.val_loader = val_loader

    def get_parameters(self, config) -> List[np.ndarray]:
        return [param.data.numpy() for param in self.model.parameters()]

    def set_parameters(self, parameters: List[np.ndarray]):
        for param, new_param in zip(self.model.parameters(), parameters):
            param.data = torch.tensor(new_param)

    def fit(self, parameters, config) -> Tuple[List[np.ndarray], int, Dict]:
        self.set_parameters(parameters)
        optimizer = torch.optim.SGD(self.model.parameters(), lr=config.get("lr", 0.01))
        local_epochs = config.get("local_epochs", 3)
        self.model.train()
        for epoch in range(local_epochs):
            for batch in self.train_loader:
                optimizer.zero_grad()
                loss = self.model(batch)
                loss.backward()
                optimizer.step()
        return self.get_parameters(config), len(self.train_loader.dataset), {}

    def evaluate(self, parameters, config) -> Tuple[float, int, Dict]:
        self.set_parameters(parameters)
        loss, accuracy = test(self.model, self.val_loader)
        return float(loss), len(self.val_loader.dataset), {"accuracy": float(accuracy)}

class FedAvgWithDP(fl.server.strategy.FedAvg):
    """FedAvg with Differential Privacy"""
    def aggregate_fit(self, server_round, results, failures):
        aggregated_params, aggregated_metrics = super().aggregate_fit(server_round, results, failures)
        if aggregated_params is not None:
            noise_multiplier = 0.1
            for param in fl.common.parameters_to_ndarrays(aggregated_params):
                noise = np.random.normal(0, noise_multiplier, param.shape)
                param += noise
        return aggregated_params, aggregated_metrics

strategy = FedAvgWithDP(
    min_fit_clients=5,
    min_evaluate_clients=3,
    min_available_clients=10,
    fraction_fit=0.5,
)

fl.server.start_server(
    server_address="0.0.0.0:8080",
    strategy=strategy,
    config=fl.server.ServerConfig(num_rounds=50)
)

Differential Privacy in FL

DP guarantees that from the global model, one cannot determine whether a specific client participated. We add Gaussian noise to aggregated weights with parameter ε (smaller ε means stronger protection). Implementation via Opacus:

from opacus import PrivacyEngine

privacy_engine = PrivacyEngine()
model, optimizer, train_loader = privacy_engine.make_private_with_epsilon(
    module=model,
    optimizer=optimizer,
    data_loader=train_loader,
    epochs=local_epochs,
    target_epsilon=5.0,
    target_delta=1e-5,
    max_grad_norm=1.0,
)

What's Included in a Turnkey FL System

Component Description Timeline
Data & Model Analysis Assess data distribution, choose architecture (CNN/Transformer) 3–5 days
FL Infrastructure Deployment Install Flower/PySyft, configure communication (gRPC, TLS) 2–4 days
Data Source Integration Connect to hospital PACS, banking APIs, IoT gateways 5–7 days
Privacy Setup DP with ε=5, Secure Aggregation, model audit 3–5 days
Testing & Optimization A/B test vs centralized training, tune hyperparams 5–8 days
Documentation & Training Model card, operator instructions, team training 2–3 days
Post-Launch Support Monitoring, retraining, version updates 1 month included

Typical FL Metrics

Metric Typical Value Target
Communication efficiency (rounds to target accuracy) 50–200 rounds <100 rounds
Accuracy gap (vs centralized) 1–5% <3%
Privacy budget (ε, δ)-DP (5, 1e-5) ε <5
Participation rate >95% >98%

Why FL Can Be Slower Than Centralized Training

Main delays: communication between clients and server (especially with thousands of devices), stragglers, data heterogeneity. Solutions:

  • Gradient compression (Top-k sparsification, 8-bit quantization) reduces traffic 10x
  • Asynchronous updates (FedAsync) — server doesn't wait for all clients
  • Client sampling — 20–50% clients per round is enough for convergence

Real-World Case Study

A medical consortium of 10 hospitals trained a cancer detection model on X-rays. Without FL, the best single hospital achieved AUC 0.87. With FL, AUC rose to 0.94 — an 8% gain without any transfer of patient data. The project required 4 weeks for integration and 50 training rounds.

Our team has been deploying FL since 2018, with over 20 projects in healthcare, finance, and industrial IoT. Contact us for a free project assessment — we'll discuss architecture and timelines. Schedule a consultation today.