Inferensys

Glossary

Horizontal Federated Learning

A federated learning topology where participating institutions share the same feature space but hold data on different, non-overlapping sample populations, enabling collaborative model training without centralizing sensitive records.
Data scientist building training data pipeline on laptop, data preprocessing visible, technical workspace.
DEFINITION

What is Horizontal Federated Learning?

Horizontal federated learning (HFL) is a decentralized machine learning paradigm where multiple parties share an identical feature space but hold data on different, non-overlapping sample populations, enabling collaborative model training without raw data exchange.

Horizontal Federated Learning, often called sample-partitioned federated learning, is the most common architectural pattern for institutional collaborations. In this setting, every participating client—such as different regional hospitals or genomic research consortia—collects the same types of data attributes (e.g., gene expression levels, clinical lab values) but for entirely distinct patient cohorts. The shared feature space allows a global model to be trained by averaging locally computed model updates or gradients, rather than centralizing sensitive records.

This topology directly addresses the data silo problem in healthcare and genomics, where privacy regulations like HIPAA and GDPR prohibit raw data pooling. The primary technical challenge in HFL is handling non-IID data distributions, where the statistical properties of local datasets diverge significantly, potentially degrading global model convergence. Advanced optimization strategies, including FedProx and personalized federated learning, are often deployed to mitigate this client drift and ensure robust performance across all participating nodes.

SAMPLE-PARTITIONED ARCHITECTURE

Key Characteristics of Horizontal Federated Learning

Horizontal federated learning (HFL) is the most common collaborative paradigm in genomic consortia, where institutions share the same feature space—identical sequencing assays and variant annotations—but hold data for non-overlapping patient populations. This architectural symmetry enables straightforward model aggregation without entity resolution.

01

Identical Feature Schema

All participating nodes must operate on a shared, pre-harmonized feature space. In genomics, this means identical variant calling pipelines, standardized reference genomes (e.g., GRCh38), and consistent annotation formats across institutions.

  • Each client's local dataset has the same columns, data types, and encoding
  • Enables direct weight averaging without feature translation layers
  • Requires rigorous phenotype harmonization before training begins
  • Common in multi-hospital GWAS consortia studying the same disease
02

Non-Overlapping Sample Populations

The defining characteristic of HFL is sample-space partitioning. Each institution contributes different patients or specimens, ensuring no single entity's records exist at multiple nodes. This is the natural topology for genomic biobanks.

  • Patient A exists only at Hospital 1; Patient B only at Hospital 2
  • Eliminates the need for entity resolution or private record linkage
  • Increases statistical power by pooling diverse populations
  • Introduces non-IID challenges when demographics or sequencing protocols differ across sites
03

Federated Averaging Compatibility

HFL is the native topology for the FedAvg algorithm, where each client trains a local copy of the model on its own samples, then transmits only weight updates to the aggregation server.

  • Local training: each hospital computes gradients on its private genomic data
  • Secure aggregation: the server computes a weighted mean of updates
  • Weights are proportional to local dataset size to account for sample imbalance
  • Converges reliably when local data distributions are approximately similar
04

Genomic Consortia Use Cases

HFL is the backbone of privacy-preserving collaborative genomics, enabling multi-institutional studies that would be impossible under centralized data-sharing agreements.

  • Federated GWAS: jointly computing variant-trait associations across biobanks
  • Polygenic risk score training: building more diverse, generalizable risk models
  • Variant pathogenicity classification: training classifiers on rare disease cohorts
  • Gene expression prediction: multi-center training of models like Enformer
  • Real-world example: the GA4GH community standards explicitly support HFL topologies for cross-institutional genomic queries
05

Privacy Guarantees & Threat Models

HFL provides a baseline privacy improvement by keeping raw sequence data local, but weight updates can still leak information about training samples through model inversion or membership inference attacks.

  • Defense layers: differential privacy noise injection on gradient updates
  • Secure aggregation prevents the server from inspecting individual contributions
  • Trusted execution environments protect computation at each node
  • Honest-but-curious server model is the standard threat assumption
  • Cryptographic guarantees require combining HFL with SMPC or homomorphic encryption
06

Distinction from Vertical Federated Learning

HFL contrasts sharply with vertical federated learning (VFL), where institutions hold different features about the same set of entities. Understanding this distinction is critical for architectural decisions.

  • HFL: same features, different samples → weight averaging works directly
  • VFL: different features, same samples → requires entity alignment and split neural networks
  • HFL is simpler to implement but requires feature-space standardization
  • VFL is common when one hospital has genomic data and another has imaging for the same patients
  • Hybrid federated transfer learning addresses scenarios fitting neither pure HFL nor VFL
HORIZONTAL FEDERATED LEARNING

Frequently Asked Questions

Clear, technical answers to the most common questions about horizontal federated learning architectures for genomic data consortia.

Horizontal federated learning (HFL) is a distributed machine learning paradigm where multiple organizations collaboratively train a shared global model while their local datasets share the same feature space but contain different, non-overlapping sample populations. In a genomic consortium, this means each hospital holds the same types of genomic features—such as gene expression values, variant calls, or DNA methylation levels—for entirely different patient cohorts. The process works by distributing a copy of the global model to each participating institution, training locally on private data, and transmitting only encrypted model updates (gradients or weights) to a central aggregation server. The server applies a federated averaging algorithm to combine these updates into an improved global model without ever accessing raw patient sequences. This architecture directly addresses the 'sample-partitioned' data silo problem common in healthcare, where institutions cannot legally pool patient genomes but desperately need larger, more diverse training populations to build robust diagnostic models.

ARCHITECTURAL COMPARISON

Horizontal vs. Vertical Federated Learning

A structural comparison of the two primary federated learning topologies based on how data is partitioned across participating organizations.

FeatureHorizontal FLVertical FL

Data Partitioning

Same features, different samples

Same samples, different features

Primary Use Case

Genomic consortia with same assays

Joint clinical-genomic studies

Entity Alignment Required

Model Architecture

Full local models, averaged globally

Split neural network per party

Privacy Mechanism

Secure aggregation of gradients

Entity resolution + split learning

Communication Pattern

Client-to-server gradient sync

Peer-to-peer intermediate activations

Scalability

High (many clients)

Low (typically 2-10 parties)

Genomic Example

Multiple biobanks with WGS data

Hospital A has DNA, Hospital B has EHR

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.