Inferensys

Glossary

Horizontal Federated Learning

A federated learning paradigm where collaborating parties hold data with the same feature space but different sample spaces, representing the most common and straightforward data partitioning scenario.
Data engineer managing feature store on laptop, feature definitions visible, casual data engineering session.
DEFINITION

What is Horizontal Federated Learning?

Horizontal Federated Learning (HFL) is a decentralized machine learning paradigm where multiple parties collaborate to train a shared model while their local datasets share the same feature space but contain different, non-overlapping sample populations.

Horizontal Federated Learning, often called sample-partitioned federated learning, is the most common architectural pattern in privacy-preserving machine learning. In this scenario, collaborating institutions—such as regional hospitals—hold data with identical schema and feature columns (e.g., lab results, vital signs) but for entirely distinct patient populations. The feature space overlap allows a global model to be trained by averaging locally computed model updates, typically using the Federated Averaging (FedAvg) algorithm, without any raw patient data leaving its origin site.

This paradigm directly addresses the Non-IID Data challenge, as the statistical distribution of labels and features often varies significantly across the different sample spaces. HFL is foundational to Cross-Silo Federated Learning in healthcare, enabling multi-site biomarker discovery and diagnostic model training. It contrasts sharply with Vertical Federated Learning, where parties hold different features about the same entities, and Federated Transfer Learning, which handles mismatched feature and sample spaces simultaneously.

SAMPLE-PARTITIONED COLLABORATION

Key Characteristics of Horizontal Federated Learning

Horizontal Federated Learning (HFL) is the most prevalent and straightforward federated topology, defined by a shared feature space across clients with non-overlapping sample populations. This architecture enables competing hospitals or regional banks to collaboratively train robust models without exposing raw records.

01

Shared Feature Schema

The fundamental prerequisite for HFL is feature space alignment. All participating clients must agree on a common data schema—identical column names, data types, and preprocessing pipelines. In healthcare, this means standardizing to common data models like OMOP or FHIR.

  • Schema agreement is negotiated before training begins
  • Requires robust data normalization across sites
  • Mismatched features cause silent training failures
02

Sample-Partitioned Topology

Data is partitioned horizontally—each client holds different rows (samples) but identical columns (features). Think of it as splitting a massive spreadsheet by rows across institutions.

  • Hospital A has patients 1-10,000; Hospital B has patients 10,001-20,000
  • Both hold the same lab values, demographics, and imaging features
  • No single institution sees the full patient population
03

Federated Averaging (FedAvg) Core

HFL typically employs the FedAvg algorithm as its aggregation backbone. Local models train on-site, then transmit only model weights—not data—to a central aggregation server.

  • Local training: Each client computes weight updates on private data
  • Secure aggregation: Server averages weights, often weighted by local dataset size
  • Global distribution: Updated global model is redistributed for the next round
04

Non-IID Data Challenge

The primary engineering hurdle in HFL is statistical heterogeneity. Real-world client data is rarely independent and identically distributed (IID). Hospital populations differ in demographics, disease prevalence, and equipment calibration.

  • Label distribution skew: One hospital may have 40% diabetic patients, another 10%
  • Feature distribution skew: Different MRI scanner vendors produce varying pixel intensities
  • Algorithms like FedProx add proximal terms to stabilize convergence under non-IID conditions
05

Privacy Guarantees

HFL provides a baseline privacy improvement over centralized data lakes, but raw weight updates can still leak information through gradient inversion attacks. Production deployments layer additional protections.

  • Differential Privacy: Noise injected into weight updates before transmission
  • Secure Aggregation: Server only sees the summed update, never individual contributions
  • Trusted Execution Environments: Hardware-enforced isolation for aggregation logic
06

Cross-Silo vs. Cross-Device

HFL deployments fall into two distinct operational profiles based on client characteristics.

Cross-Silo:

  • Small number of reliable institutional clients (2-50 hospitals)
  • Clients participate in every training round
  • Large compute resources available per client

Cross-Device:

  • Massive scale (millions of smartphones)
  • Intermittent availability, high dropout rates
  • Requires lightweight model architectures and asynchronous aggregation
HORIZONTAL FEDERATED LEARNING

Frequently Asked Questions

Clear, technically precise answers to the most common questions about the horizontal federated learning paradigm, where institutions share the same feature space but hold data on different patient populations.

Horizontal federated learning (HFL) is a distributed machine learning paradigm where collaborating parties hold data with identical feature schemas but non-overlapping sample spaces—meaning every hospital records the same lab tests and vitals, but treats entirely different patients. The process works by distributing a copy of the global model to each client, training locally on private data, and transmitting only encrypted model updates (gradients or weights) to a central aggregation server. The server fuses these updates using algorithms like Federated Averaging (FedAvg) to produce an improved global model without ever accessing raw patient records. This architecture is the most straightforward and widely deployed federated topology because it requires no entity alignment or feature engineering across sites, making it ideal for multi-hospital biomarker discovery consortia where each institution has independently collected the same standardized clinical assays.

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.