Matryoshka: How Meta Automates Hyperscale Data Center Networks
Matryoshka Realizing Hyperscale Data Center Network Design for the AI Era
Modern AI training clusters can contain tens or even hundreds of thousands of GPUs, but the computational infrastructure is only one part of the problem. Connecting those GPUs requires data center networks that are enormous, heterogeneous, and continuously evolving.
Designing a topology is relatively easy compared with turning that design into working configurations across thousands of physical switches.
Meta’s NSDI 2026 paper, Matryoshka: Realizing Hyperscale Data Center Network Design for the AI Era, describes a production-grade system built to solve exactly this problem.
Matryoshka has reportedly operated inside Meta for six years and serves as the network design and configuration system behind nearly 900 data center networks. It has also supported infrastructure for a 100,000-GPU AI supercluster.
Its core purpose is straightforward:
Translate high-level network intent into validated, deployable switch configurations at hyperscale.
The system combines modular topology construction, hierarchical IP allocation, routing generation, vendor abstraction, deterministic compilation, validation, and incremental deployment into a unified pipeline.
🌐 The Three Problems of Hyperscale AI Networking #
Data center network bandwidth has grown rapidly over the past decade, with bandwidth requirements roughly doubling every 12 to 15 months. Generative AI has accelerated that trend even further.
At hyperscale, network engineering is no longer simply about choosing a topology. Engineers must coordinate:
- Physical cabling
- Switch hardware
- IP address allocation
- Routing policies
- Port mappings
- Device configurations
- Configuration validation
- Production deployment
- Live network upgrades
Historically, the industry has been fragmented around this workflow.
Research often focuses on topology design and network hardware, while other systems concentrate on verifying configurations after deployment. The critical middle layer—turning a high-level network blueprint into concrete device configurations—has often depended on experienced engineers and collections of custom scripts.
Meta identified three fundamental challenges.
1. Hyperscale #
Meta operates data centers across more than 70 regions, with individual facilities containing hundreds or thousands of switches.
AI networks can require tens of thousands of GPUs to communicate at high bandwidth. The number of devices varies substantially between network types, making manual configuration generation impractical.
Automation therefore needs to operate efficiently across entire fleets rather than individual devices.
2. Rapid Network Iteration #
Modern infrastructure must support both greenfield deployments and brownfield upgrades.
Greenfield projects build new AI clusters from the ground up. Brownfield projects modify existing production facilities while traffic remains online.
Typical changes can include:
- Replacing switches
- Increasing link speeds
- Migrating workloads
- Expanding network fabrics
- Introducing new device roles
- Changing topology structures
The challenge is not merely making the change work. The network must remain operational while ensuring that unrelated configurations are not accidentally modified.
Matryoshka reportedly processes approximately 800 to 2,000 network change operations per week.
3. Hardware and Software Heterogeneity #
Meta operates multiple categories of infrastructure networks, from general-purpose front-end systems to specialized AI backend networks.
The hardware ecosystem is equally diverse.
Networks can include Meta-designed white-box switches running FBOSS as well as third-party switching platforms. AI infrastructure must also accommodate different accelerator architectures, including NVIDIA GPUs and Meta’s MTIA systems.
Different vendors expose different configuration languages, capabilities, and operational models.
A network automation platform that embeds vendor-specific assumptions throughout its codebase quickly becomes difficult to maintain.
Matryoshka addresses this by separating network intent from hardware-specific configuration generation.
🪆 The Matryoshka Design Philosophy #
The system’s name reflects its central architectural idea: complex networks can be constructed from reusable layers of smaller components, much like Russian nesting dolls.
Two principles are particularly important.
Modular Topology Building Blocks #
Instead of hard-coding every network individually, Matryoshka constructs networks from reusable topology primitives.
Clos networks, full meshes, and other structures can be composed into larger systems while preserving common underlying logic.
This allows a new network architecture to reuse existing building blocks rather than requiring an entirely new implementation.
Stateless Deterministic Compilation #
Matryoshka does not maintain its own operational network state.
Instead, authoritative state is stored in Meta’s FBNet network database. Whenever configurations are generated, Matryoshka recompiles the network from its current high-level intent.
This makes the compilation process deterministic and reproducible.
The same principle is particularly valuable for brownfield upgrades. Rather than relying on what a previous execution happened to produce, the system can determine the desired configuration from the source of truth and calculate the difference against the existing network model.
That gives live upgrades many of the same properties as greenfield deployments.
🧱 From Network Intent to Physical Switch Configuration #
The Matryoshka pipeline can be summarized as:
Intent → Modeling → Topology → IP Allocation → Routing → Generic Configuration → Vendor Translation → Validation → Database Commit → Deployment
The important distinction is that engineers do not begin by writing switch commands.
They describe what the network should accomplish.
The system then compiles that intent into the low-level configuration required by the physical infrastructure.
📝 Intent Modeling: Describe Objectives, Not Commands #
Engineers define network specifications using Thrift-based Network Spec documents.
These specifications describe high-level properties such as:
- Switch entities
- Device roles
- Hardware models
- Lifecycle states
- Topology relationships
- Port mappings
- IP allocation blocks
- BGP neighbor groups
- Routing policies
For example, an engineer can define how devices should be connected without manually specifying every individual switch command required to establish those connections.
Changes are also subjected to automated testing, peer review, and version control, providing an auditable history of network modifications.
🔗 Topology Generation Uses Reusable Primitives #
Matryoshka separates network topology into two levels.
Abstract topology describes logical relationships between devices using logical interfaces.
Concrete topology maps those logical relationships onto the physical ports of actual switches.
This distinction is important because abstract topology can be reused across different hardware configurations.
Matryoshka decomposes data center networks into four fundamental primitives:
- Complete Bipartite Graph
- Ring
- Fully Connected Mesh
- Cyclic Bipartite Graph
These primitives can be combined and stacked to construct larger architectures, including conventional Clos networks and specialized AI networking designs.
Abstract Topology Comes Before Physical Mapping #
The system first generates the logical network structure.
It then applies port-mapping templates to translate logical connections into physical switch ports.
This produces the concrete topology required for actual cabling and deployment.
Separating these layers reduces hardware-specific coupling and makes it easier to introduce new network architectures.
🗺️ Hierarchical IP Address Allocation #
IP planning is another part of the process that Matryoshka automates.
The system separates addresses into two broad categories:
- Infrastructure prefixes: Used for control-plane communication, loopbacks, and interconnect interfaces.
- Service prefixes: Used for application traffic, dynamic cluster addresses, and virtual IPs.
Large address blocks are recursively divided into smaller subnets for devices and interfaces.
This hierarchical approach provides predictable allocation while preserving IP stability where possible during network upgrades.
Stable addressing is particularly important for brownfield environments because unnecessary address changes can introduce additional operational complexity.
🛣️ Automated Routing Configuration #
Meta uses OpenR for intra-domain routing and BGP for inter-domain and policy-driven routing.
Matryoshka provides reusable BGP neighbor-group templates based on device roles while accepting routing policies as external inputs.
From those inputs, the system can automatically construct:
- BGP sessions
- Neighbor relationships
- Route filtering policies
- Corresponding device configurations
This again moves network engineering away from manually assembling device-level commands.
⚙️ Generic Configuration Creates Hardware Abstraction #
Once topology, IP allocation, and routing information have been generated, Matryoshka produces a Generic Switch Configuration (GSC).
The GSC is intentionally platform-agnostic.
It is then translated into the native configuration language required by the target switch hardware and operating system.
This architecture creates a clean abstraction boundary:
Network Intent → GSC → Vendor-Specific Configuration
Adding support for a new hardware platform therefore primarily requires a new translation layer rather than modifications throughout the entire network design system.
For a hyperscale operator with a constantly changing hardware fleet, this isolation can significantly reduce maintenance complexity.
✅ Validation and Incremental Deployment #
Matryoshka performs multiple levels of validation before changes reach production.
The generated network model is checked for semantic correctness, while resulting configurations undergo syntax and platform-specific validation.
The system then compares the desired configuration against the FBNet source of truth to determine what actually changed.
Only those differences are committed and deployed.
This incremental approach became particularly important in the second major version of the system.
Incremental Updates Reduced Commit Time by Up to 99% #
Earlier versions of Matryoshka rebuilt the full network dataset during updates.
Version 2 introduced incremental database updates, calculating differences and modifying only affected entries.
For large networks, this dramatically reduced commit latency and made brownfield changes significantly more efficient.
The system can therefore treat a small network modification as a small transactional update rather than reconstructing an entire hyperscale network model.
🤖 Building Meta’s 100,000-GPU AI Supercluster #
One of the strongest demonstrations of Matryoshka’s capabilities is Meta’s 100,000-GPU AI supercluster.
The infrastructure combines both existing data center facilities and newly constructed AI buildings.
The network is divided into two major systems.
Front-End Network #
The Front-End (FE) network provides conventional infrastructure services such as:
- Data ingestion
- Model checkpointing
- Logging
- General service traffic
Back-End AI Network #
The Back-End (BE) network is dedicated to distributed AI training.
It uses RoCEv2 RDMA and is optimized for:
- High throughput
- Low latency
- Lossless communication
- Distributed GPU workloads
Each AI training rack connects to both the FE and BE networks.
Within the backend network, an AI Zone serves as a reusable infrastructure building block. Rack-level training switches connect GPUs to cluster-level training switches, providing non-blocking communication within the zone.
Aggregation training switches then connect different AI Zones through a full-mesh architecture.
🏗️ Brownfield and Greenfield Deployment #
The 100,000-GPU environment demonstrates both sides of Matryoshka’s deployment model.
Retrofitting Existing Data Centers #
Three existing front-end buildings were converted to support AI infrastructure.
Matryoshka modified high-level network specifications to expand an existing RoCE storage cluster into AI Zones while migrating storage workloads elsewhere and increasing Fabric Aggregation bandwidth.
Because the system compiles desired state deterministically and calculates changes against the existing model, the migration could be performed without unnecessarily modifying unrelated production configurations.
Building New AI Facilities #
Two additional AI buildings were constructed as greenfield deployments.
Although the backend AI network uses specialized topology and hardware, many of its foundational concepts overlap with conventional data center networking.
Matryoshka was able to reuse existing specification templates and topology logic while adding AI-specific requirements.
This reuse is one of the major benefits of the system’s modular architecture.
🧪 Supporting Experimental AI Network Topologies #
AI networking does not stand still.
As distributed training architectures evolve, the network topology itself may need to change to optimize collective communication and data movement.
Meta is therefore experimenting with architectures beyond the standard AI Zone model.
Rail-Optimized Topology #
The rail-optimized design connects GPUs occupying the same ordinal position across different nodes to the same leaf switch.
The goal is to improve all-reduce collective communication and reduce latency for distributed training workloads.
Distributed Scheduled Fabric #
The Distributed Scheduled Fabric (DSF) takes another approach.
Packets are divided into smaller cells that can be forwarded more granularly to improve load balancing.
This architecture introduces routing-neighbor models and IP allocation requirements that differ substantially from conventional data center networks.
Matryoshka’s modularity allows these experiments to be incorporated by changing topology, port-mapping, and routing modules instead of rebuilding the entire automation pipeline.
📈 Production Results at Meta #
The paper provides production measurements demonstrating the system’s behavior at scale.
Configuration Correctness #
GSC validation achieves a reported 95.4% pass rate, with invalid configurations intercepted before reaching production switches.
End-to-end behavioral testing reaches a reported 96.4% success rate, catching logical issues during automated testing.
The remaining failures can involve hardware bugs or human input errors, but the system is designed to prevent detected issues from reaching production.
Database Update Performance #
Incremental updates produced substantial improvements over full database rebuilds.
Adding 88 switches and hundreds of links to a Fabric Aggregation network reduced commit time from approximately 200 seconds to 60 seconds, a reduction of about 70%.
For a larger Fabric expansion operation, commit time dropped from 34.6 minutes to 46 seconds, representing a roughly 97.8% reduction.
After the incremental update architecture was deployed in 2022, large database-update latency spikes reportedly became rare.
Near-Linear Scaling #
Matryoshka’s execution time scales approximately linearly with switch count.
At large scales, Generic Switch Configuration generation becomes the primary CPU bottleneck, accounting for roughly 90% of CPU time in GSC serialization and deserialization.
Despite this bottleneck, the system can handle networks containing thousands of switches.
🌎 Six Years of Hyperscale Evolution #
The scale of Matryoshka’s production deployment illustrates how the system evolved alongside Meta’s infrastructure.
Between 2020 and 2025:
- Data center network types increased from 2 to 18
- Deployed network instances grew from 18 to nearly 900
The system therefore had to support not just a larger number of devices, but an increasingly diverse collection of network architectures.
That distinction is important.
Hyperscale network automation is not simply a scaling problem. It is a scale + heterogeneity + change-management problem.
🔮 The Bigger Lesson for AI Infrastructure #
Much of the discussion around AI networking focuses on switch ASICs, topology designs, congestion control, RDMA, and bandwidth.
Matryoshka highlights another layer that is just as important: the software infrastructure required to turn those architectural ideas into reliable production networks.
The system creates a bridge between abstract design and physical infrastructure:
Network Intent → Model → Topology → IP/Routing → Generic Configuration → Vendor Configuration → Validation → Deployment
Three properties stand out.
Intent-driven compilation replaces large amounts of manual configuration work.
Stateless deterministic generation makes greenfield deployment and brownfield upgrades more predictable.
Modular topology and hardware abstractions allow the same toolchain to evolve as AI architectures and switch platforms change.
As AI clusters grow from thousands to tens or hundreds of thousands of accelerators, manually managing the underlying network becomes increasingly unrealistic.
The future of hyperscale networking therefore depends not only on better hardware and better topologies, but also on software systems capable of continuously compiling, validating, and deploying those designs at production scale.
Matryoshka demonstrates what that layer can look like in practice—and why network design automation is becoming a foundational component of modern AI infrastructure.