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.
Glossary
Horizontal Federated Learning

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.
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.
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.
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
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
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
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
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
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
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.
Horizontal vs. Vertical Federated Learning
A structural comparison of the two primary federated learning topologies based on how data is partitioned across participating organizations.
| Feature | Horizontal FL | Vertical 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 |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Master the core architectural and privacy-preserving concepts that enable horizontal federated learning for genomic consortia.
Federated Averaging (FedAvg)
The foundational optimization algorithm for horizontal federated learning. Each client trains a local model on its own genomic samples, and the central server aggregates these updates by computing a weighted average based on each client's dataset size. This ensures that larger, more statistically significant cohorts have proportionally greater influence on the global model without ever seeing the underlying DNA sequences.
Non-IID Data Challenge
A critical obstacle in genomic consortia where local datasets are not independently and identically distributed. Different hospitals may sequence patients with distinct ethnic backgrounds, disease subtypes, or using different sequencing machines. This distributional skew can cause naive federated averaging to diverge or fail to converge, requiring specialized optimization strategies like FedProx or SCAFFOLD to stabilize training.
Secure Aggregation
A cryptographic protocol that ensures the central server can only compute the sum of encrypted model updates from all participating institutions, without ever being able to inspect any single institution's contribution. This prevents an honest-but-curious server from reconstructing genomic features through gradient leakage attacks, providing a critical second layer of defense beyond raw data isolation.
Differential Privacy Guarantees
A mathematical framework that injects calibrated statistical noise into model updates before transmission. By clipping gradient norms and adding Gaussian noise, the system provides a provable (ε, δ)-differential privacy guarantee, ensuring that the final model's parameters are statistically indistinguishable whether or not any single patient's genome was included in the training cohort.
Cross-Silo Topology
The dominant architectural pattern for genomic federated learning, involving a small number of reliable, stateful institutional clients—such as major research hospitals or national biobanks—each possessing substantial on-premise GPU compute. Unlike cross-device FL with millions of unreliable smartphones, cross-silo genomic FL assumes persistent connectivity and allows for more complex synchronous training protocols.
Communication Efficiency
A primary bottleneck in horizontal FL where transmitting full model weights for a genomic foundation model with hundreds of millions of parameters can saturate institutional network links. Techniques like gradient compression, sparsification, and quantization reduce the bitrate of updates, while local SGD increases the number of local training steps between communication rounds to minimize overhead.

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.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us