Meta Replaces Manual Network Design With Automated Loom Engine

Physical Network Design at Scale | Brandon Premo and Richard Cziva from Meta — @Scale

@Scale

Meta eliminated human bottlenecks in AI data center expansion by deploying Loom, an end-to-end automation pipeline that cuts physical network design time from months to hours through joint device placement and fiber optimization.

AI-assisted summary of Physical Network Design at Scale | Brandon Premo and Richard Cziva from Meta — original source. Check the original for full context.

Source published:

Detailed notes

## Background Published on YouTube by @Scale on August 27, 2026, this talk features Brandon Premo and Richard Cziva from Meta presenting physical network design at scale. The page description outlines how Meta developed Loom, an automated pipeline incorporating Planogram for device placement and Fiber Design Automation for cabling, to accelerate network design from months to hours amid surging AI workloads.

## TL;DR Meta's presentation details Loom, an automated physical network design pipeline created to keep pace with unprecedented AI capacity demands across heterogeneous data centers. The authors explain how traditional manual placement and cabling bottlenecks are solved using Planogram—which balances fiber connectivity costs against failure domain isolation using lexicographic optimization (ILP, RL, and graph algorithms)—and an automated fiber design system. The talk concludes by highlighting key lessons learned, such as formalizing intuitive engineering rules into machine logic and eliminating legacy design habits, while outlining future directions for brownfield expansion and total fiber traceability.

## Atmosphere & style The session delivers an authoritative, deeply technical, and pragmatic tone characteristic of senior infrastructure engineers sharing hard-won production lessons. The narrative shifts smoothly from the tension of manual design bottlenecks to the systematic clarity offered by algorithmic optimization, evoking a sense of engineering rigor and modern innovation. Watching the presentation feels like an engaging, high-level masterclass in data center architecture, balancing mathematical exactness with honest reflections on organizational habits.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=4s) The massive scale and heterogeneous nature of AI workload capacity demands rendered traditional manual physical network design an operational bottleneck. - [01:41](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=101s) Meta developed Loom, an end-to-end automated physical network design pipeline that understands building layouts, maps logical topologies, and designs fiber cabling. - [02:28](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=148s) Logical topologies lack physical context, requiring explicit placement of thousands of devices onto data center floors, rows, and racks. - [04:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=282s) Physical device placement involves a fundamental trade-off between clustering devices for cheaper fiber vs. spreading devices across failure domains for fault tolerance. - [06:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=402s) Planogram utilizes multi-objective lexicographic optimization to strictly order competing goals like connectivity, failure survival, row similarity, and rack efficiency. - [08:08](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=488s) Greedy heuristic scripts fail at scale due to tangled physical constraints, combinatorial explosion, and conflicting design objectives. - [08:08](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=488s) Planogram solves complex placement by combining graph algorithms for problem decomposition, integer linear programming (ILP) for provable optimality, and reinforcement learning (RL) for scale. - [18:03](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1083s) Formalizing human domain expertise and intuitive design rules into precise mathematical optimization criteria was significantly harder than building the core software engines. - [18:03](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1083s) Automating the design pipeline exposed and eliminated wasteful legacy habits, such as reserving half-empty racks for vague future upgrades. - [18:59](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1139s) Loom and Planogram serve as Meta's production-grade physical network design pipeline, with future goals focusing on strand-level traceability, expanding constraint models, and supporting brownfield migrations.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=4s) AI Demand and the Limits of Manual Physical Network Design

AI workloads are fundamentally altering how data centers are constructed, driving an unprecedented demand to turn up massive amounts of network capacity far faster than legacy processes were ever built to support. Larger capacity builds inherently translate to larger physical networks, requiring significantly more network equipment and massive amounts of interconnecting fiber infrastructure. Adding to this scale challenge, modern capacity is not delivered in a uniform, cookie-cutter fashion; instead, it spans a highly heterogeneous mix of as-built data centers, leased facilities, and cloud infrastructure, where no two physical sites are identical.

The traditional approach to physical network infrastructure design was an artisanal, almost entirely manual process. For every single project, teams of human experts had to meticulously analyze the physical building, its power allocations, failure domain boundaries, and row and rack floor plans. They then had to select the appropriate network topology products and figure out how to physically map and design each component for that specific physical space. Because project counts scale directly with AI capacity demands, this expert-dependent model quickly became a bottleneck due to a severe shortage of specialized domain experts.

- Capacity demands require turning up unprecedented volume across heterogeneous environments (as-built data centers, lease sites, and cloud facilities). - The historical physical network design process was artisanal, manual, slow, and unscalable. - The severe shortage of domain experts relative to the skyrocketing number of AI infrastructure projects forced a transition to end-to-end automation.

[01:41](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=101s) Loom: End-to-End Automated Physical Network Design Pipeline

To eliminate this operational bottleneck, Meta built an automated physical network design pipeline (Loom) that understands the physical layout and structural properties of data center buildings. The pipeline automatically selects the proper network topology products for a project, maps the logical network onto the physical floor plan, and designs the complete fiber infrastructure required to connect every device together. The overall workflow relies heavily on two foundational automation components: **Planogram** for device placement and **Fiber Design Automation** for physical cabling.

- The automated pipeline captures the complete end-to-end workflow: building properties, product selection, logical-to-physical mapping, and fiber cabling design. - **Planogram** handles device placement across the physical floor plan subject to dimensional, power, and failure-domain constraints. - **Fiber Design Automation** generates the complete physical fiber infrastructure connecting all placed endpoints.

[02:28](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=148s) The Placement Challenge: Bridging Logical Topologies and Physical Reality

For decades, networking research and engineering have focused heavily on logical topology—how switch layers stack, how devices interconnect, and how traffic routes across them. However, a logical topology is merely a blueprint that cannot carry a single bit of live traffic on its own. Actual network traffic flows through physical fibers plugged into devices inside physical racks drawing power inside real data center rooms. Someone must take the logical blueprint and decide the exact row and rack location for thousands of individual devices.

Historically, mapping logical blueprints to physical floors was slow, manual, and highly inconsistent across different engineers and geographic regions. To illustrate the difficulty, consider a common building block design: a **megapod** consisting of leaf and spine switches in a Clos topology, sitting below an aggregation layer called the **axo-spine** (built from XSW switches organized into distinct planes). In this architecture, each plane connects to a single spine switch index across every megapod in the region (e.g., Plane 1 connects to SSW1 everywhere, Plane 2 to SSW2, and so on). These parallel planes never cross, creating two distinct structural consequences:

1. **Logical reach over physical proximity:** Connectivity is governed strictly by logical properties, meaning a plane must reach every corner of a data center building regardless of physical layout. 2. **Region-wide shared fate:** A plane represents a region-wide failure domain; taking down a single plane drops that specific slice of uplink capacity across every single megapod simultaneously.

- Logical topology design has decades of deep research, but physical floor placement was historically neglected and left to manual execution. - A **megapod** uses a Clos topology of leaf and spine switches; above it, the **axo-spine** layer uses XSW switches divided into parallel planes. - Plane connectivity is non-local and spans the entire building footprint, making physical device placement extremely complex.

[04:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=282s) The Architectural Collision: Clustering vs. Spreading

Placing a logical topology onto a physical floor plan requires two intertwined steps: racking the devices (grouping spine switches by megapod and axo-spine switches by plane) and allocating those racks to specific rows on the floor plan. Because connectivity must survive both steps, two fundamental engineering instincts violently collide during placement: the desire to cluster devices together versus the desire to spread them apart for fault tolerance.

This trade-off can be illustrated by two opposing physical placement options for axo-spine switches across failure domains:

- **Option 1: Clustering (Failure-Closed):** All switches for a given plane are packed into a single failure domain. This requires minimal fiber—often just a single trunk per plane—making it extremely simple and inexpensive. However, if that failure domain goes down, the entire plane is wiped out, completely severing that spine index across every megapod simultaneously. This creates a massive blast radius with "failure-closed" behavior. - **Option 2: Spreading (Failure-Open):** Switches for every plane are scattered across all available failure domains. Fiber requirements explode because every plane must reach every physical domain. However, losing a failure domain now only results in losing a minor slice of capacity across each plane. The network gracefully handles the loss via Equal-Cost Multi-Path (ECMP) shrinking, providing a highly preferred "failure-open" degradation.

- **Clustering:** Minimal fiber footprint, simple cabling, but maximal blast radius (a single failure domain loss takes down an entire logical plane). - **Spreading:** High fiber complexity and cost, but minimal blast radius (failures trigger an ECMP shrink rather than total plane loss). - Planogram explicitly models, ranks, and solves this trade-off between fiber cost and failure blast radius.

[06:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=402s) Multi-Objective Lexicographic Optimization in Planogram

Network engineers do not evaluate placement trade-offs using a single numeric score; instead, they operate on a ranked hierarchy of competing design objectives. Planogram models this using **lexicographic optimization**, where higher-ranked objectives are fully satisfied before lower-ranked objectives are evaluated. The system focuses on four core objectives:

1. **Connectivity:** Minimizes the number of rack pairs that must connect between adjacent layers, reducing inter-rack links to yield simpler and cheaper fiber infrastructure (the clustering instinct). 2. **Surviving Failures:** Spreads physical entities across failure domains so no single infrastructure failure exceeds the blast radius budget tolerated by network designers (the spreading counterweight). 3. **Row Similarity:** Keeps rack role layouts uniform from row to row, creating standardized floor plans that are easier to construct and operate. 4. **Rack Efficiency:** Packs equipment into the minimum number of physical racks to maximize the utilization of space and power budgets.

Rather than blending these goals into a single weighted mathematical score with arbitrary coefficients, lexicographic optimization enforces strict priority ordering. Changing the ranking alters the output to suit different deployment goals: a cost-sensitive project places connectivity at the top, while a resilience-critical site prioritizes failure spreading.

- Objectives are strictly ordered (lexicographic optimization) rather than combined into a single weighted score. - Changing objective hierarchy allows the exact same optimization engine to produce provably optimal designs for different business constraints (e.g., cost-optimized vs. resilience-optimized).

[08:08](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=488s) Why Greedy Heuristics Fail: Planogram's Internal Architecture

When faced with physical placement, the initial engineering instinct is often to write simple greedy bin-packing scripts. However, greedy heuristics consistently fail for physical data center placement due to three core complexities:

- **Tangled Constraints:** Power limits, physical rack space, maximum cable lengths, and port compatibility are tightly coupled; fixing one constraint almost always violates another. - **Combinatorial Explosion:** Thousands of network entities, multiple valid logical topologies, and diverse physical floor plans create a massive search space that simple heuristics cannot navigate effectively. - **Conflicting Objectives:** Scripts hardcode arbitrary winners between competing goals (e.g., cheap fiber vs. failure domain isolation, or dense packing vs. row uniformity), producing sub-optimal designs.

To overcome these limits, **Planogram** operates as an orchestrator combining three distinct computational engines:

- **Graph Algorithms:** Perform an initial pass to decompose the massive placement problem into smaller, tractable sub-problems. - **Integer Linear Program (ILP):** Serves as the primary heavy lifter, delivering a provably optimal placement design for a given lexicographic ranking. - **Reinforcement Learning (RL):** Adds scale and generates a diverse family of near-optimal design variants rather than a single static solution.

The output of Planogram is a precise physical topology where every single network entity is assigned to an exact row and rack coordinate on the data center floor, providing the machine-readable foundation needed to automate fiber design.

- Inputs to Planogram: Logical topology (LNTG), Data Center Stencil (floor plan, power/space budgets, failure boundaries), and ranked Objectives. - Output: Precise physical placement mapping every switch and device to an exact row and rack location. - Engine combination: Graph pass for tractability, ILP for provable optimality, and RL for scale and solution variety.

<ElicitationsGroup message="Explore related network automation topics or technical details:"> <Elicitation label="Explain Fiber Design Automation and channel schematics" query="How does Meta's Fiber Design Automation work, and what are channel schematics?"/> <Elicitation label="Summarize the real-world results and performance metrics of Loom" query="What are the real-world deployment scale and performance metrics achieved by Meta's Loom pipeline?"/> </ElicitationsGroup>

[18:03](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1083s) Key Lessons: Formalizing Objectives and Exposing Habits

Automating Meta's physical network design pipeline produced far better plans rather than simply generating them faster, but the journey revealed several unexpected challenges. The primary obstacle was not the technical buildout of the automation engines themselves, but rather the organization and formalization of domain knowledge. Translating human expertise into machine logic proved complex: an expert engineer could state an objective like "stretch things out for resilience" in five seconds, but turning that intuitive concept into precise, rankable mathematical criteria required months of effort.

Furthermore, introducing automation forced the team to confront legacy design rules that were actually just ingrained habits. For instance, past manual designs consistently left racks half-filled under the assumption of preserving "future upgradability." When questioned during the automation push, no functional justification remained—it was simply a tradition quietly wasting valuable data center space. Once explicit optimization objectives were defined, these unexamined habits had nowhere left to hide.

* Automating physical network design shifts focus from speed alone to producing higher-quality, optimized plans. * Knowledge organization was significantly harder than building the automation framework itself. * Formalizing intuitive rules (e.g., resilience spacing) into precise algorithmic objectives took months. * Questioning legacy habits eliminated wasteful practices, such as leaving racks half-empty for unspecified future upgrades.

[18:59](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1139s) Production Deployment at Meta and Future Horizons

The Planogram (device placement) and fiber design automation tools represent the first comprehensive work bringing physical layout, placement, and cabling automation to the @Scale community. The system operates end-to-end: high-level logical intent is fed into the pipeline, and a complete, build-ready region design comes out. Neither component is a mere research prototype—together, they form the default, production-grade physical design pipeline at Meta today.

Looking to the future, the team is pursuing three main directions. First, they are establishing end-to-end traceability from top-level intent down to every individual installed fiber strand. Second, they are expanding the system's constraint engine to incorporate additional physical infrastructure limits, including power delivery, cooling capacity, and structural loads. Finally, while the system currently handles greenfield new builds, development is underway to support brownfield designs—enabling complex, live network migrations in existing production regions. Physical design deserves to be automated, optimized, and studied as a first-class problem in an era where AI workloads are rapidly reshaping data center architecture.

* The end-to-end physical network design pipeline is fully deployed in production as Meta's default workflow. * Future effort #1: Achieving total traceability from logical intent down to the installed fiber strand. * Future effort #2: Incorporating advanced structural, power, and cooling constraints. * Future effort #3: Expanding capabilities from greenfield builds to brownfield network migrations in active production regions. * "AI is rewriting how we build data centers faster than any manual process can keep up."

<ElicitationsGroup message="Explore related aspects of Meta's data center automation:"> <Elicitation label="Explain how Planogram optimizes rack device placement" query="Explain how Meta's Planogram system optimizes rack device placement and handles physical failure domains."/> <Elicitation label="Detail Meta's automated fiber design architecture" query="Detailed breakdown of how Meta's fiber design component automates cabling and connectivity patterns."/> </ElicitationsGroup>

## Notable quotes > [00:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=4s) AI workloads are fundamentally altering how data centers are constructed, driving an unprecedented demand to turn up massive amounts of network capacity far faster than legacy processes were ever built to support.

> [00:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=4s) For every single project, teams of human experts had to meticulously analyze the physical building, its power allocations, failure domain boundaries, and row and rack floor plans.

> [00:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=4s) Because project counts scale directly with AI capacity demands, this expert-dependent model quickly became a bottleneck due to a severe shortage of specialized domain experts.

> [01:41](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=101s) Planogram handles device placement across the physical floor plan subject to dimensional, power, and failure-domain constraints.

> [02:28](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=148s) Logical topology design has decades of deep research, but physical floor placement was historically neglected and left to manual execution.

> [02:28](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=148s) Plane connectivity is non-local and spans the entire building footprint, making physical device placement extremely complex.

> [04:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=282s) Because connectivity must survive both steps, two fundamental engineering instincts violently collide during placement: the desire to cluster devices together versus the desire to spread them apart for fault tolerance.

> [06:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=402s) Rather than blending these goals into a single weighted mathematical score with arbitrary coefficients, lexicographic optimization enforces strict priority ordering.

> [08:08](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=488s) Tangled Constraints: Power limits, physical rack space, maximum cable lengths, and port compatibility are tightly coupled; fixing one constraint almost always violates another.

> [18:03](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1083s) Translating human expertise into machine logic proved complex: an expert engineer could state an objective like "stretch things out for resilience" in five seconds, but turning that intuitive concept into precise, rankable mathematical criteria required months of effort.

> [18:03](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1083s) When questioned during the automation push, no functional justification remained—it was simply a tradition quietly wasting valuable data center space.

> [18:59](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1139s) AI is rewriting how we build data centers faster than any manual process can keep up.

## Mentioned Brandon Premo, Richard Cziva, Meta, YouTube, @Scale, Loom, Planogram, Fiber Design Automation, Clos topology, ECMP, Integer Linear Program (ILP), Reinforcement Learning (RL)

[Source](https://www.youtube.com/watch?v=TS1d05vl9aQ)

中文简报

Meta以自动化Loom引擎取代人工网络设计 Meta通过部署端到端自动化流水线Loom消除AI数据中心扩建中的人工瓶颈，借助设备协同放置与光纤优化，将物理网络设计耗时从数月缩短至数小时。 Meta的演讲详细介绍了Loom，这是一个为应对异构数据中心前所未有的AI容量需求而打造的自动化物理网络设计流水线。作者阐述了如何通过自动化光纤设计系统以及Planogram来解决传统人工放置与布线的瓶颈；Planogram利用字典序优化（结合ILP、RL和图算法）在光纤连接成本与故障域隔离之间取得平衡。演讲最后强调了关键经验教训，例如将直观的工程规则形式化为机器逻辑并摒弃传统设计习惯，同时概述了针对棕地扩建和全光纤可追溯性的未来发展方向。 面对 AI 工作负载激增带来的巨大容量需求，Meta 开发了端到端物理网络设计管道 Loom，整合设备放置（Planogram）与光纤连接设计，将网络设计周期从数月压缩至数小时。 (1:41) 物理设备放置面临着核心设计权衡：将设备集中放置虽能显著降低光纤成本，但会放大单点故障的爆炸半径；而跨故障域分散设备虽增加光纤用量，却能通过 ECMP 缩容实现高容错的平滑降级。 (4:42) 针对物理约束交错与组合爆炸难题，Planogram 摒弃了效果欠佳的贪心算法，通过融合图算法分解、整数线性规划（ILP）与强化学习（RL），并采用多目标词典序优化计算出可证明的最优物理拓扑。 (8:08) 该系统目前已作为 Meta 内部的默认工作流全面投入生产运行，未来研发重点包括实现到单根光纤维度的全链路追溯，并拓展至在役生产环境的棕地（brownfield）网络迁移。 (18:59)

Reading summary

Brandon Premo and Richard Cziva from Meta explain that surging AI capacity demands rendered manual physical network design unsustainable, prompting Meta to deploy Loom—an automated pipeline that mathematically optimizes the mapping of logical network topologies onto physical data center infrastructure. Manual Network Design Bottlenecks Under AI Scaling (0:04) Escalating AI workloads require deploying unprecedented network capacity across heterogeneous environments, including custom-built data centers, leased sites, and cloud facilities. Historically, mapping network topologies to physical rooms was an artisanal, manual process: engineering teams examined floor plans, power allocations, failure domains, and rack footprints for each individual project. Because project volume scales directly with AI infrastructure demands, a shortage of specialized physical design experts turned this manual process into a severe operational bottleneck. To resolve this, Meta built Loom, an end-to-end automated pipeline comprising Planogram for physical device placement and Fiber Design Automation for cabling generation. The Tension Between Clustering and Failure Spreading (4:42) While logical architectures like Clos-based megapods and axo-spine switch aggregation planes are well-researched, translating them onto physical data center floors introduces conflicting engineering trade-offs. In Meta's architecture, axo-spine switches are segmented into parallel planes that link to specific spine switch indices across every regional megapod. Consequently, a plane functions as a region-wide failure domain that spans the physical facility. When placing these devices into physical racks and rows, engineers must balance two opposing instincts: clustering versus spreading. Placing all switches for an axo-spine plane into a single failure domain minimizes inter-rack fiber runs and cabling costs, but losing that domain wipes out the entire plane in a disruptive 'failure-closed' event. Conversely, scattering switches across multiple failure domains inflates fiber requirements, but allows the network to gracefully absorb domain losses through Equal-Cost Multi-Path (ECMP) capacity shrinking, achieving a 'failure-open' design. Lexicographic Optimization and Planogram's Computational Architecture (6:42) Simple greedy bin-packing scripts fail at physical placement because physical rack space, power caps, cable distance limits, and port configurations form tightly coupled, combinatorial constraints. Planogram addresses this by rejecting weighted-score balancing in favor of lexicographic multi-objective optimization, which evaluates strictly ranked engineering goals sequentially. The system prioritizes four core criteria: minimizing inter-rack connectivity to curb fiber complexity, enforcing failure domain spreading to limit blast radiuses, maintaining row-to-row similarity for operational uniformity, and maximizing rack packing efficiency to conserve space and power budgets. Planogram executes this by orchestrating graph decomposition algorithms to break problems into manageable segments, an Integer Linear Program (ILP) to calculate provably optimal placements for a given ranking, and Reinforcement Learning (RL) to generate alternative near-optimal variants. Formalizing Engineering Heuristics into Production Pipelines (18:03) According to the presenters, Meta's biggest challenge was not constructing the optimization software, but formalizing intuitive human rules into rigorous mathematical constraints. Converting casual engineering guidelines—such as spacing switches out for resilience—into programmable formulas took months of effort. The formalization process also eliminated long-standing operational habits that lacked functional rationale, such as routinely leaving racks half-empty under vague expectations of future hardware upgrades. Today, Loom operates as Meta's default production workflow for greenfield builds, generating build-ready region layouts from high-level logical intent. Meta has fully deployed Planogram and its automated fiber design tools in production, yet current implementations focus primarily on greenfield builds; ongoing engineering efforts center on expanding the constraint engine to encompass deeper cooling and structural limits, enabling brownfield migrations in active regions, and establishing end-to-end traceability to individual installed fiber strands.

精炼阅读摘要

Meta 工程师 Brandon Premo 与 Richard Cziva 指出，AI 算力爆发引发的数据中心规模激增与场地异构性，使得传统依赖人工经验的物理网络设计难以为继；为此 Meta 研发了端到端自动化流水线 Loom，通过形式化多目标优化与混合计算架构，将抽象逻辑拓扑精确转化为可施工的物理机架布局与光纤拓扑。 AI需求激增倒逼物理网络设计自动化 (0:04) AI 计算工作负载从根本上重塑了数据中心的建设形态，不仅要求以前所未有的速度提供海量网络容量，还要求网络部署能够兼容自建机房、租赁机房以及云基础设施等高度异构的物理环境。过去数十年来，物理网络基础设施设计一直是一种高度依赖专家经验的“手艺活”：专业团队必须针对每个项目逐一手工测算建筑结构、电力分配、故障域边界以及机架平面图，再选择相应产品并完成映射。然而，AI 项目数量的几何级增长与专业领域专家的极度稀缺发生直接冲突，人工模式迅速演变为阻碍基础设施交付的核心瓶颈。 为了消除这一扩展限制，Meta 研发了名为 Loom 的端到端自动化物理网络设计流水线。该系统深入理解数据中心建筑物的物理布局与结构属性，能够自动选择网络拓扑产品，将逻辑拓扑映射到机房物理平面，并完成连接全部设备所需的光纤布线设计。整个流水线主要由两大核心系统驱动：负责在多重物理约束下放置网络设备的 Planogram，以及负责自动化生成物理光纤布线拓扑的 Fiber Design Automation 工具。 逻辑映射与集聚抗灾的架构权衡 (2:28) 网络工程与研究历来聚焦于交换机分层、设备互连与流量调度的逻辑拓扑，但逻辑蓝图本身无法传输任何流量，最终必须具体落实到真实机房内特定机柜的物理交换机与线缆中。在 Meta 的典型架构中，由 Leaf 和 Spine 交换机组成的 Clos 架构 Megapod 向上连接至聚合层 axo-spine；axo-spine 交换机被划分为若干相互独立的平行平面，每个平面跨越整个机房连接所有 Megapod 的对应编号 Spine 交换机。由于这些平行平面从不交叉，平面的物理连通需求必须跨越整个机房，同时单一平面的损坏会同时削减所有 Megapod 的上行容量，形成了区域级的共享命运。 在将逻辑蓝图映射到物理空间时，“设备集聚”与“故障分散”两种工程本能产生了激烈碰撞。若采取集聚方案（故障关闭），将同一平面的所有交换机集中放置于单一故障域内，光纤用量极少且布线简单，但一旦该故障域失效，整个逻辑平面将被全盘摧毁，爆炸半径极大；若采取分散方案（故障开放），将各平面的交换机分散部署在所有故障域中，虽然光纤数量与布线复杂度急剧增加，但单一故障域下线只会损失各平面的微小容量，网络能够通过等价多路径路由（ECMP）平滑降级。自动化系统必须在光纤成本与容错爆炸半径之间取得精确平衡。 字典序多目标优化与混合计算架构 (6:42) 数据中心物理网络设计存在供电限制、机架空间、最大线缆长度及端口兼容性交织在一起的强约束，加之数以千计的设备实体，使得传统的贪心启发式脚本极易陷入死局或硬编码出次优解。Meta 的 Planogram 系统放弃了单一加权评分函数，改用“字典序多目标优化”（Lexicographic Optimization），严格按照工程优先级顺序对目标进行求解：排在首位的高优先级目标必须被完全满足，系统才会进一步优化次级目标。其核心目标层级包括：最小化相邻层间机架互连对数量以降低光纤成本（连通性）、跨故障域分散设备以限制爆炸半径（容错生存）、保持各行机柜角色排列一致（机架排一致性），以及在空间与电力限额内紧凑部署以最大化空间利用（机柜效率）。 在底层计算实现上，Planogram 构建了结合三种引擎的协同架构：首先利用图算法将大规模全局放置问题分解为可计算的子问题；接着以整数线性规划（ILP）作为主要运算核心，在给定的字典序优先级下求取具备数学证明的最优解；最后引入强化学习（RL）算法扩充求解规模，并生成多样化的近似最优方案，从而输出包含精确行号与机架坐标的物理拓扑，为后续光纤自动化设计提供机器可读的数据基准。 隐形设计惯性破除与全生产流程落地 (18:03) Meta 团队在工程推进中发现，构建自动化引擎本身的技术难度反而是次要的，真正的瓶颈在于领域知识的形式化与规范化。资深工程师可以凭借直觉在数秒内提出“为了抗灾需要将设备分散”的设计规则，但将其拆解并转化为严谨、可排序的机器数学优化目标，耗费了团队数月的研究与反复校准。 此外，全面推行自动化设计迫使工程团队重新审视许多长期固化的习惯性做法。例如，在传统手工设计中，工程师习惯让机柜保持半空状态，理由是“便于未来升级”；但在自动化优化的严格审视下，该做法被证明缺乏功能层面的实质支撑，只是一种白白浪费机房昂贵空间与电力配额的陈规。当设计目标被精确数学化后，无依据的经验主义被彻底破除，大幅提升了数据中心的实际构建质量。 目前，Loom 流水线已作为 Meta 的标准生产级系统全面投产，实现了从顶层逻辑意图输入到直接输出可施工网络设计的端到端自动化。不过，演讲者指出当前系统主要服务于新建（greenfield）数据中心；未来研究团队将重点攻克三个方向：建立从逻辑意图到每根已安装光纤的端到端可追溯性，将供电分配、冷却负载与建筑承重等更多物理基础设施边界纳入约束求解器，以及扩展流水线能力以支持生产环境中正在运行机房的带电网络迁移（brownfield）。

Detailed notes — zh

## Background 本视频由 @Scale 频道于 2026 年 9 月 3 日发布在 YouTube 上，主讲人为来自 Meta 的 Brandon Premo 与 Richard Cziva。视频简介指出，面对 AI 工作负载对数据中心网络容量指数级增长的需求，Meta 开发了名为 Loom 的端到端物理网络自动化与优化系统，通过设备放置引擎 Planogram 与光纤自动化设计组件，将网络物理设计周期从数月缩减至数小时。 ## TL;DR 演讲系统介绍了 Meta 为应对大规模 AI 数据中心建设挑战而研发的物理网络自动化设计系统 Loom。面对逻辑拓扑蓝图与物理机房约束深度脱节、光纤数量激增的困境，Loom 拆解为两大核心引擎：上游的 Planogram 结合图算法降维、词典序整数线性规划（ILP）与强化学习，求解兼顾故障隔离与光纤成本的设备机架排布；下游的光纤自动化设计则通过通道原理图抽象与端到端软件建模，自动化完成高密度线缆聚合、路径多样性验证、极性检测及物料清单生成。目前该流水线已 100% 承接 Meta 新建数据中心设计，落地支撑超过 1 GW 算力规模与 20 余栋建筑，将方案产出周期从数月缩短至数天，并从根源上杜绝了人工经验的随意性与隐性错误。 ## Atmosphere & style 整场演讲充满硬核、务实且条理极其清晰的顶尖工程质感，两位讲者在算法架构与微观布线工程之间自如切换、衔接流畅。内容从真实数据中心机房的混乱与手工痛点切入，逐步收敛至数学上可严谨证明的最优解体系，给听众带来层层拆解复杂工程难题的智力快感。尤其在结尾回顾工程经验时，讲者以极具启发性的口吻揭示了将专家隐性知识形式化过程中的艰难拉扯，以及自动化如何刺破“伪装成设计规则的陈规陋习”，兼具极高的方法论深度与实战感染力。 ## Bulletin - [00:54](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=54s) Meta 推出端到端物理网络自动化设计系统 Loom，通过设备放置引擎 Planogram 与光纤布线引擎，将超大规模 AI 数据中心的物理网络设计周期从数月大幅缩减至数天。 - [06:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=402s) Planogram 摒弃了经验加权打分与贪心装箱脚本，引入词典序多目标优化，并协调图算法、整数线性规划（ILP）与强化学习（RL）求解数学上可证明最优的物理机架排布。 - [13:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=784s) 系统通过“通道原理图”将物理多样性与布线模式形式化为规则集，实现对数百万光纤芯线的全路径软件建模，在设计阶段提前验证极性并直接输出施工物料清单（BOM）。 - [16:05](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=965s) Loom 已在 Meta 100% 投入生产落地，支撑了 4 个数据中心区域、20 多栋建筑及超过 1 GW 的计算容量，将全量设计规则的合规校验耗时缩减至 1 分钟以内。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=4s) AI 工作负载驱动网络设备与光纤体量爆炸式增长，自建、租赁与云设施的高度异构性使得缺乏通用设计模板，传统手工设计成为算力交付的核心瓶颈。 - [02:28](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=148s) 网络界过去长期深耕逻辑蓝图与拓扑路由算法，但抽象逻辑并不承载比特，如何严谨、可复现地将蓝图映射到物理空间与电力约束上长期处于断层状态。 - [03:31](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=211s) 在 Megapod 与 XL-Spine 构成的典型两层架构中，汇聚平面完全按逻辑索引对称辐射至机房每个物理角落，各平面构成了跨区域的命运共享体。 - [04:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=282s) 物理落地面临聚集与打散的经典博弈：聚集放置光纤成本极低但会导致整平面瘫痪的闭锁型故障；打散放置光纤成本高昂但能通过 ECMP 弹性收缩实现开放型故障隔离。 - [06:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=402s) Planogram 采用词典序优化替代人为设定权重的打分公式，按业务设定的严格优先级顺序依次对连接性、容灾抗毁、机行一致性和机架利用率进行数学求解。 - [08:08](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=488s) 传统贪心装箱算法在物理摆放中彻底失效，根源在于交织缠绕的物理硬约束、组合爆炸的超大解空间以及低成本与高容灾之间的互斥拉扯。 - [09:14](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=554s) Planogram 系统架构融合了负责降维解耦的图算法、负责全局最优解的整数线性规划（ILP），以及负责大规模解空间探索的强化学习（RL）组件。 - [11:11](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=671s) 光纤物理互连通过跳线、分支缆、主干缆及混编缆等产品组合实现分层聚合，有效化解了端到端点对点拉线带来的物理空间吞噬与超长距离施工难题。 - [13:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=784s) “通道原理图”将专家的多路径多样性布线规则提炼为形式化约束，确保互斥路径端到端不共享任何无源设备，解耦了互联意图与具体建筑平面。 - [14:27](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=867s) 端到端软件模型对数百万芯线与接头进行全生命周期追踪，可在设计期自动完成光学兼容性与极性校验，并无缝导出施工机架物料清单与作业手册。 - [16:05](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=965s) 生产实践证明自动化不仅大幅加速了初始规划与变更重新分配，更通过确定性规则与空间/电力联合前置建模，排除了大量现场施工阶段才暴露的隐蔽缺陷。 - [18:12](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1092s) 系统研发的最大工程阻碍在于将领域专家的口头隐性经验严格形式化为数学目标，这一过程也倒逼团队剔除了盲目预留半满机架等工程陋习。 - [18:12](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1092s) Loom 正从绿地新建向棕地在线改造延伸，未来将支持存量在线数据中心的带电割接与网络迁移，并纳入液冷散热及建筑承重等更深层的物理约束。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=4s) AI 浪潮下的数据中心网络物理设计挑战 人工智能（AI）正在重塑数据中心的构建方式，对容量交付提出了前所未有的海量需求。这种极速增长的容量，必须以远超传统流程预设能力的速度完成设计与落地。建设规模越大，意味着网络规模更庞大、设备数量激增，连接所有设备所需的光纤基础设施也呈现指数级膨胀。 更严峻的是，现代数据中心呈现出极高的异构性，容量交付形式涵盖自建数据中心（as-built data centers）、租赁站点（lease sites）以及各类云基础设施（cloud infrastructure），“没有任何两个站点是完全相同的”。面对交付周期缩短、光纤数量激增、缺乏通用标准设计模板的三重挤压，工程师必须在没有退路的情况下解决高度定制化的大规模部署问题。 - **规模与形式**：AI 工作负载驱动网络设备与光纤体量爆炸式增长，形态涵盖自建、租用和云端混合设施。 - **异构性痛点**：缺乏一劳永逸的标准设计（no standard design to fall back on），每个站点的物理条件都独一无二。 --- ### [00:54](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=54s) 传统手工设计的困境与 Loom 自动化流水线 以往的物理网络基础设施设计近乎一种“手工匠人式的过程（artisanal process）”。每开启一个新项目，都需要一组资深专家深入研读物理建筑结构、供电与故障域规划、机架和行排列（row and rack layout）。专家们必须在复杂的现场物理约束下，挑选适用的网络拓扑产品，并逐个机柜、逐条光纤手动映射和设计。这种依赖专家人工决策的模式不仅耗时漫长，而且无法横向扩展，直接卡死了数据中心算力交付的节奏。项目数量随 AI 算力需求急剧攀升，但资深专家资源始终极其有限。 为了打破这种瓶颈，Meta 研发了名为 Loom 的端到端自动化物理网络设计流水线。该系统深入感知建筑的物理空间属性与硬件约束，自动匹配拓扑产品，将逻辑拓扑映射到物理平面图上，并完成端到端光纤连接设计。这套自动化体系的核心由两个关键子组件驱动： 1. **Planogram**：负责网络设备在物理平面图上的布局规划组件。 2. **光纤自动化设计（Fiber Design Automation）**：负责生成端到端光纤互联拓扑的布线组件。 ```mermaid flowchart TD accTitle: Loom 物理网络自动化设计流程 accDescr: 展示 Loom 系统从物理与逻辑输入到设备布局与光纤生成的整体流水线架构 subgraph Inputs["设计输入要素"] A["物理建筑条件与约束<br/>(供电/行机架/故障域)"] B["逻辑拓扑规范<br/>(LNTG 蓝图)"] end subgraph LoomPipeline["Loom 自动化流水线"] C["设备摆放规划引擎<br/>(Planogram)"] D["光纤布线自动化引擎<br/>(Fiber Design)"] end subgraph Outputs["最终交付成果"] E["物理机架定位图<br/>(Physical Placement)"] F["端到端光纤连接方案<br/>(Fiber Plant Design)"] end A --> C B --> C C --> E E --> D B --> D D --> F ``` --- ### [02:28](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=148s) 逻辑蓝图与物理现实的脱节 过去数十年间，网络领域的研究重心高度聚焦在逻辑拓扑上——诸如交换机网络分层、互联拓扑演变以及跨层路由算法。这些工作虽然极其扎实且不可或缺，任何构建都必须始于逻辑拓扑，但“逻辑拓扑并不承载任何一个比特的实际流量，它只是一张设计蓝图”。真正的网络流量流动在机房特定机柜内的光纤之中，消耗着真实机房的电力与空间。 必须有人将这张理论图纸落实到物理现实中，为成千上万台交换机决定它们究竟安置在机房的哪一行、哪一列机架上。现实中，这半截将蓝图映射到物理实体的流程长期依赖人工，不仅进度滞后，而且因工程师个人的经验偏好和地理区域的不同而呈现极大的随意性与不一致性。 - **逻辑拓扑的局限**：只规定设备间的抽象连接关系，无法解决供电、发热、线缆长度及机柜空间等物理现实约束。 - **物理映射断层**：学术界和工业界在逻辑蓝图层面投入了数十年研发，却极少系统化研究如何将其严谨、可复现地映射到物理机房中。 --- ### [03:31](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=211s) 典型逻辑拓扑架构：Megapod 与 Aggregation 层 以 Meta 频繁部署的典型网络拓扑为例：其底层基础模块是“Megapod”，由叶交换机（Leaf Switch）与脊交换机（Spine Switch / SSW）构成标准的 Clos 拓扑结构。在 Megapod 之上设立汇聚层，称为“Axospine（或 XL-Spine）”，由大量汇聚交换机（XSW）按平面对称组织而成（Planes）。 其互联模式具有极强的逻辑规律：某一个特定平面仅连接到一个特定的脊交换机索引（Spine index），且覆盖区域内所有 Megapod 中该相同索引的交换机。例如，Plane 1 连接所有 Megapod 的 SSW1，Plane 2 连接所有 Megapod 的 SSW2，依此类推。这些平面之间完全平行且永不交叉。当一个平面被激活点亮时，它会呈扇形辐射到整个网络拓扑中。这导致了两个关键后果： 1. **连接性取决于逻辑属性，而非空间临近度**：无论物理机柜如何摆放，一个平面都必须延伸触达机房建筑的每一个物理角落。 2. **平面构成跨区域的命运共享体（Shared Fate）**：一旦某个平面整体瘫痪，区域内每一个 Megapod 都会在同一时刻失去相应的一份上行链路算力。 --- ### [04:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=282s) 物理落地中的核心矛盾：聚集还是打散？ 将逻辑拓扑落到物理平面图（Floor Plan）包含两个不可分割且同步交织的步骤：第一步是将设备装入机架（如将 Megapod 的脊交换机按单元打包入柜，XL-Spine 按平面装柜）；第二步是将各机架分配放置到数据中心平面的具体行排列（Rows）中。在完成映射后，必须保证逻辑连接完整无误，即每个平面仍然必须穿透整个建筑，稳固连接到各个 Megapod 的指定脊交换机索引。 由于这两个步骤紧密交织，设计时立刻会遭遇两种本能诉求的剧烈碰撞——“是将同类设备集中放置，还是分散规避风险？”这一经典物理设计博弈集中体现为以下两极： ```mermaid flowchart TD accTitle: 物理放置策略权衡：聚集 vs 打散 accDescr: 对比聚集（Clustering）和打散（Spreading）在光纤消耗、故障影响和模式上的根本区别 subgraph Option1["选项一：聚集放置 (Clustering)"] A1["单平面汇聚至单物理故障域"] --> B1["光纤成本极低<br/>(极简主干 Trunk)"] A1 --> C1["爆炸半径极大<br/>(故障域失效导致整个平面瘫痪)"] C1 --> D1["失效模式: Closed Failure<br/>(区域所有 Megapod 缺失同索引上行)"] end subgraph Option2["选项二：打散放置 (Spreading)"] A2["单平面分散穿插至各故障域"] --> B2["光纤成本暴增<br/>(布线错综复杂)"] A2 --> C2["爆炸半径受控<br/>(单故障域仅损失局部切片)"] C2 --> D2["失效模式: ECMP Shrink<br/>(弹性降级，Open Failure 首选方案)"] end ``` - **聚集策略（Clustering）**：将一个平面的所有交换机集中放置于单个故障域内。优点是光纤连接极其经济简洁，只需单根主干缆即可；致命缺点是故障半径极大，一旦该故障域断电或毁坏，整个逻辑平面随之毁灭，所有 Megapod 同时断崖式减产，构成系统设计必须极力避免的“闭锁型故障（closed failure）”。 - **打散策略（Spreading）**：将每个平面的设备均匀分散到所有物理故障域中。此时光纤走线复杂度爆炸，成本剧增；但换来了极强的弹性：当任意一个物理域宕机时，没有任何 Megapod 会陷入绝境，各平面仅损失一小段容量切片，网络通过 ECMP（等价多路径路由）平滑收缩，形成更易容忍的“开放型故障（open failure）”。 --- ### [06:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=402s) 词典序多目标优化：打破传统加权打分 面对相互冲突的设计考量，网络规划工程师从不给出单一的量化公式，而是给出一份排序优先级列表。Planogram 将物理放置的复杂需求提炼为四大核心目标： 1. **连接性（Connectivity）**：尽量减少相邻网络层级之间需要建立物理互联的机架对数。机架间物理链路越少，光纤布线越简单便宜（契合聚集诉求）。 2. **容灾抗毁（Surviving Failures）**：将逻辑实体分散至不同故障域，确保任何单一物理故障导致的爆炸半径不超过设计预算（抗衡聚集诉求）。 3. **机行一致性（Row Similarity）**：保持不同机架行之间的排布规则统一。整齐划一的设计便于施工建造与后期日常运维。 4. **机架利用效率（Rack Efficiency）**：以最少数量的物理机架紧凑容纳所有设备，极致榨取电力与空间预算。 为了严谨求解，Planogram 彻底摒弃了人为设定“魔法权重系数（magic coefficients）”并加权打分的传统做法，而是采用严格的**词典序优化（Lexicographic Optimization）**： - 优先无条件全力满足最高优先级目标； - 在最高优先级目标达成最优解的前提集合内，再最大化求解次级目标； - 依次类推向下求解后续目标。 这种排序完全可根据业务场景灵活替换：针对成本敏感型机房，连接性（即光纤成本）可被置于首位；而对于高可用核心节点，故障分散度则直接升至首位。同一个底层引擎，无论如何排序都能导出数学上可证明的最佳设计方案。 --- ### [08:08](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=488s) 算法探索：为何贪心装箱算法会失败 许多初涉物理网络布局的工程师，第一反应往往是将其视作经典的装箱问题（Bin Packing Problem），试图编写一套贪心启发式脚本来解决。然而，实践证明纯贪心脚本在此类场景中彻底失效，根源在于三层壁垒： 1. **硬约束深度交织缠绕（Tangled Constraints）**：供电配额、空间槽位、跳线最大长度限制、接口硬件兼容性等环环相扣。强行修复其中一个约束，往往会导致另一个维度直接崩溃。 2. **解空间超大规模爆炸（Combinatorial Explosion）**：面对数千个物理实体，存在海量合法的逻辑拓扑变体与物理落地组合。规模之大超出了任何单一启发式搜索能处理的范畴；这类算法即便能吐出可行解，质量也极其低劣。 3. **互斥目标的动态拉扯（Compromising Objectives）**：廉价光纤与故障隔离天然相克，紧凑堆叠与行排一致性往往背道而驰。硬编码的贪心脚本只能偏袒一方，根本无法达成系统级动态平衡。 --- ### [09:14](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=554s) Planogram 系统架构与引擎分解 针对上述难题构建的 Planogram 系统，对外定义了清晰的输入与输出契约： - **三项核心输入**： 1. **逻辑网络拓扑（Logical Network Topology）**：以图结构定义组件层级关系。 2. **数据中心模版（DC Stencil）**：精确描述物理机房平面、机柜空间、供电预算及物理故障域边界。 3. **目标优先级规范（Objectives）**：定义评估优劣的词典序排序列表。 - **最终输出**：确定性的物理网络拓扑，每个交换机实体均精准指派到具体的行与机架点位。 ```mermaid flowchart LR accTitle: Planogram 系统架构组件 accDescr: 展示 Planogram 接收三类输入并由图算法、ILP 和 RL 三大引擎协同求解机架分配 subgraph Inputs["输入三要素"] I1["逻辑拓扑规范"] I2["机房 Stencil<br/>(空间/供电/故障域)"] I3["词典序多目标排序"] end subgraph PlanogramBox["Planogram 编排系统"] G["图算法通道 (Graph Pass)<br/>[降维解耦，保证计算可行性]"] ILP["整数线性规划 (ILP)<br/>[词典序求解，保证全局最优]"] RL["强化学习组件 (RL)<br/>[规模扩展，探索近优解空间]"] G --> ILP G --> RL end Inputs --> PlanogramBox PlanogramBox --> Output["高精度物理机架映射<br/>(Machine-Readable Map)"] ``` 在系统内部，Planogram 并非单一算法，而是协调两大核心引擎的编排体系： - **图算法通道（Graph Pass）**：负责将庞大复杂的整网物理问题解耦降维成多个可计算的子模块，奠定计算可行性（Tractability）。 - **整数线性规划（ILP）**：系统的基石算法（Heavy Lifter），在图降维的基础上，负责在指定排序下给出具备**数学可证明最优性（Provably Optimal）**的排布解。 - **强化学习组件（Reinforcement Learning）**：补充 ILP 面对极大尺度求解时的算力短板，通过高并发探索提供一整族接近最优（Near-Optimal）的多样化候选变体。 该系统输出的不再是一张模糊图纸，而是一份机器可读的微观机房点位映射表（Machine-Readable Map）。正是这一精确到物理机柜的布局成果，为下游光纤自动化设计（Fiber Design Automation）的全面自动化展开铺平了道路。 ### [11:11](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=671s) 从逻辑拓扑到物理光纤：跨越尺度的线缆聚合挑战 在 Planogram 完成设备节点的物理摆放后，整个站点的网络设计进入了光纤物理互连的具象化阶段。此时，图模型中的每一条逻辑连接都已拥有明确的物理端点坐标，而这些需要互联的设备广泛散布在数据中心的不同机架行、不同房间乃至跨越不同的建筑单体。随着拓扑规模膨胀，逻辑上点对点的端到端链路数量呈现指数级激增，物理空间迅速被线缆吞没。在超大规模数据中心中，直接在机架对之间拉设点对点光缆无论在物理空间还是拉线距离上都是完全不可行的，必须引入更高效的布线分层聚合机制。 为了解决空间拥挤与长距拉线的矛盾，Meta 依赖一系列标准化的线缆产品组合构建层次化的线缆平面。最基础的跳线（Patch cord）仅提供单对光纤的点对点连接，适用于极小范围的单链路互联；对于海量的跨机架与跨建筑连接，系统通过汇聚策略将离散链路集中至统一聚合点，接入使用高密度接头的主干光缆（Trunk cables）。在主干光缆的两端，分支光缆（Breakout cables）负责将单路光纤对打包进主干或从主干中解绑分离；针对某些拓扑对特定光纤映射关系的严苛要求，系统则通过混编光缆（Shuffle cables）重新分配同一光缆连接器内部的光纤配线。自动化系统将这些线缆形态按拓扑特征组合串联，实现了灵活可靠的物理拓扑铺设。 ```mermaid flowchart LR accTitle: Cable Plane Aggregation Flow accDescr: Illustration of patch, breakout, trunk, and shuffle cables chaining across network racks. subgraph SrcRack["源端机架 (Building A)"] DevA["网络设备"] -->|"跳线 (Patch Cord)"| BO_A["分支光缆 (Breakout)"] end subgraph Backbone["物理主干与混编"] BO_A -->|"高密度连接"| Trunk["主干光缆 (Trunk Cable)"] Trunk --> Shuffle["混编光缆 (Shuffle Cable)"] end subgraph DstRack["目的端机架 (Building B)"] Shuffle --> BO_B["分支光缆 (Breakout)"] BO_B -->|"物理终端接入"| DevB["网络设备"] end ``` ### [13:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=784s) 严苛的多路径多样性约束与通道原理图（Channel Schematic） 对于超大规模网络而言，单纯打通一条物理链路远远不够。拓扑结构中的每个连接层级都附带明确的容错能力与多样性（Diversity）约束，往往要求同一逻辑连接组必须分散在多条物理隔离的链路上。Brandon Premo 强调，这里所谓的多样性是指真正的全链路完全隔离——"确保每条路径在端到端范围内不共享任何公共组件、布线或无源基础设施"，唯有如此，在单点故障或常规设备维护时，其余存活路径才能不受影响地维持服务连续性。 过去，哪类线缆产品应该如何串接、多样性路径在何处分流完全依赖资深设计工程师的脑力沉淀与手工绘制。为了将专家经验转化为机器可读的算法，团队深入梳理了工程师所运用的布线模式与物理规则，提炼出一套能支撑全系网络拓扑的最小规则集，并将其形式化为“通道原理图”（Channel Schematic）。如果说 LNTG（Logical Network Topology Graph）定义了“连接什么”（What has to connect），通道原理图则定义了“如何去连接”（How）。它是光纤设计自动化引擎必须遵从的指令集与约束框架，具备强大的抽象能力，能够无缝施加于任何不同的机房布局与建筑平面图之上。 - 物理多样性要求路径间实现端到端的零元器件、零线缆、零无源设备共享。 - 通道原理图解耦了拓扑互联意图与具体建筑平面，统一了物理连接模式。 - 规则集覆盖从行内互联、跨行互联、跨机房互联到跨建筑远距链路的全场景。 ### [14:27](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=867s) 全链路软件建模、极性验证与自动化物料清单（BOM） 当通道原理图与物理平面图相结合时，端到端光纤设计的落地流程被完全激活。系统以 LNTG 中的电路清单为驱动源，解析机房平面图并自动判定适宜作为汇聚节点的机架位置，随后依据光纤在建筑内实际经过的物理走向将光纤束归类打包装配。通过全生命周期的软件模型，系统完整映射了数以百万计的光纤芯线、每个接头以及每一段无源连接，使任何一条从 A 楼机架出发、辗转经过复杂跳接最终抵达 B 楼目标机架的链路都能在软件中完成端到端的全路径追踪。 这种在设计阶段的软件级端到端追踪带来了显著的工程质量飞跃。系统能够在软件内部运行规则引擎，自动化校验所有相连光学元件的兼容性，并确认全路径的设计极性（Polarity）是否正确无误。过去在现场施工上电阶段才会暴露的极性颠倒或接口不匹配错误，如今在设计初期就被完全拦截。更进一步，系统能够直接基于该模型输出数百万根芯线维度的线缆物料清单（BOM）与分机架安装施工手册（Rack-by-rack runbooks），大幅抵消物料采购长交付周期带来的工期风险，实现从设计意图到施工人员手中的零手工二次介入。 ### [16:05](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=965s) 规模化落地成果：不仅是更快，更是更优的设计 Richard Cziva 重新接过话筒，针对这一自动化系统究竟是“纸上谈兵的科研原型”还是“真实生产系统”给出了确凿的数据：Meta 当前所有新建数据中心的网络设计均已百分之百通过该自动化流水线完成。系统上线以来，已成功构建 4 个全新数据中心区域（Regions）、20 多栋数据中心建筑，支撑管理着超过 1 GW 的计算容量，并在设计过程中快速评估了超过 100 种网络设计变体。自动化带来了量级上的提速： - **初始设备与光纤分配**：耗时从过去的数月缩短至短短几天； - **设计变更与重新分配**：从数周缩减至一到两天； - **设计规则合规性验证**：从人工审查所需的数天彻底压缩至 1 分钟以内。 面对“快速做出的糟糕设计仍然是糟糕设计”的质疑，Richard 从三个维度证明自动化不仅带来了速度，更交付了远超手工水平的卓越设计： 1. **可靠性（Reliability）**：每处布局都严格受自动化规则拦截，每根光纤都具备端到端追踪验证； 2. **可行性（Feasibility）**：提前在算法中加载真实的电力与物理空间约束模型，成功排除了多处传统手工模式直到接近部署时才能察觉的隐蔽不可行缺陷； 3. **一致性（Consistency）**：相同的设计输入永远生成一致的设计方案，彻底杜绝了过去“两个工程师在两个不同区域用两种截然不同方式解决同一问题”的割裂局面。在定制 UI 中，工程师能够同时直观校验设备放置与光纤路径，保证高质量方案落地。 | 评估维度 | 传统手工设计模式 | Loom 自动化设计体系 | |:--- |:--- |:--- | | **初始方案产出周期** | 数月（Months） | 数天（Few days） | | **变更重新分配周期** | 数周（Weeks） | 1~2 天（Couple of days） | | **全量设计验证耗时** | 数天（Days） | 1 分钟以内（Under a minute） | | **设计方案一致性** | 因人而异、因地而异 | 严格确定性，输入一致则输出一致 | | **不可行缺陷捕获阶段** | 施工部署现场甚至上电阶段 | 设计早期（通过空间与电力联合前置建模拦截） | ### [18:12](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1092s) 核心工程启示与未来演进：棕地迁移与 AI 数据中心新范式 回顾整个系统的演进历程，Richard 感慨这是他“最希望自己的年轻后辈能看到的一页总结”。研发过程中最大的阻碍并非算法编写本身，而是领域隐性知识的形式化与组织化。团队总结了两个最深刻的工程教训：其一，**目标口头陈述极为容易，但形式化与量化极其困难**。领域专家可以在五秒钟内随口说出“为了保证弹性，尽量把连接分散开”，但要将其转化为计算机能够优化和排序的严格数学目标，团队耗费了数月时间；其二，**自动化强迫团队直面那些“伪装成设计规则的工程习惯”**。过去在手工设计中，工程师习惯让机架处于半满状态以备“未来扩容”，但当算法追问其背后的硬性约束时，大家才发现并没有科学依据，这只是披着传统外衣、悄悄浪费机房宝贵空间的盲目习惯。一旦设计目标被明晰形式化，这些无意义的习惯便无处遁形。 面向未来，虽然 Loom 已经成为 Meta 内部不可替代的默认设计中枢，团队仍在持续拓展其能力边界。后续的演进方向包括：打通从“设计意图”到“现场已铺设物理纤芯”的真正端到端全链路跟踪；纳入更精细的物理基础设施约束，如更严苛的电力边界、液冷与风冷散热极限以及建筑承重结构限制；最后也是最关键的一步，从目前的绿地新建（Greenfield）全面迈向棕地改造（Brownfield），为已有在线运行数据中心提供复杂的带电网络割接与迁移支持。面对 AI 工作负载对数据中心底层网络架构带来的剧烈重塑，物理网络设计已被证明是一个值得被自动化、最优化并作为一等公民对待的核心系统工程。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=4s) 没有任何两个站点是完全相同的 > [00:54](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=54s) 手工匠人式的过程（artisanal process） > [02:28](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=148s) 逻辑拓扑并不承载任何一个比特的实际流量，它只是一张设计蓝图 > [04:42](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=282s) 是将同类设备集中放置，还是分散规避风险？ > [13:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=784s) 确保每条路径在端到端范围内不共享任何公共组件、布线或无源基础设施 — Brandon Premo > [13:04](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=784s) 连接什么（What has to connect）……如何去连接（How） — Brandon Premo > [16:05](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=965s) 快速做出的糟糕设计仍然是糟糕设计 — Richard Cziva > [18:12](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1092s) 目标口头陈述极为容易，但形式化与量化极其困难 — Richard Cziva > [18:12](https://www.youtube.com/watch?v=TS1d05vl9aQ&t=1092s) 自动化强迫团队直面那些“伪装成设计规则的工程习惯” — Richard Cziva ## Mentioned Brandon Premo, Richard Cziva, Meta, @Scale, Loom, Planogram, Megapod, Axospine, XL-Spine, LNTG (Logical Network Topology Graph), Clos, ECMP, ILP (Integer Linear Programming), RL (Reinforcement Learning), Channel Schematic ## Video description Physical network design—deciding how thousands of network devices and millions of fibers are distributed across data centers, racks, and failure domains—has traditionally been a manual, time-consuming process performed by design engineers. Yet we are seeing exponentially increasing demand to fulfill the capacity required by AI workloads. At Meta, we developed Loom, a system to automate and optimize the end-to-end physical network design pipeline. Loom orchestrates two core components: a device placement component (Planogram) which places network devices across the physical floorplan subject to dimensional and failure-domain constraints; and a fiber design component, which generates end-to-end fiber connectivity satisfying the variety of connectivity patterns driven by physical constraints. Together, these components accelerate end-to-end physical network design from months to hours, allowing us to produce more complex and efficient designs with fewer resources. Learn more about the @Scale conference here: https://atscaleconference.com/ [Source](https://www.youtube.com/watch?v=TS1d05vl9aQ)

Source quotes

[0:04] 没有任何两个站点是完全相同的 [0:54] 手工匠人式的过程（artisanal process） [2:28] 逻辑拓扑并不承载任何一个比特的实际流量，它只是一张设计蓝图 [4:42] 是将同类设备集中放置，还是分散规避风险？ [13:04] Brandon Premo: 确保每条路径在端到端范围内不共享任何公共组件、布线或无源基础设施 [13:04] Brandon Premo: 连接什么（What has to connect）……如何去连接（How） [16:05] Richard Cziva: 快速做出的糟糕设计仍然是糟糕设计 [18:12] Richard Cziva: 目标口头陈述极为容易，但形式化与量化极其困难 [18:12] Richard Cziva: 自动化强迫团队直面那些“伪装成设计规则的工程习惯”

Source quotes

[0:04] AI workloads are fundamentally altering how data centers are constructed, driving an unprecedented demand to turn up massive amounts of network capacity far faster than legacy processes were ever built to support. [0:04] For every single project, teams of human experts had to meticulously analyze the physical building, its power allocations, failure domain boundaries, and row and rack floor plans. [0:04] Because project counts scale directly with AI capacity demands, this expert-dependent model quickly became a bottleneck due to a severe shortage of specialized domain experts. [1:41] Planogram handles device placement across the physical floor plan subject to dimensional, power, and failure-domain constraints. [2:28] Logical topology design has decades of deep research, but physical floor placement was historically neglected and left to manual execution. [2:28] Plane connectivity is non-local and spans the entire building footprint, making physical device placement extremely complex. [4:42] Because connectivity must survive both steps, two fundamental engineering instincts violently collide during placement: the desire to cluster devices together versus the desire to spread them apart for fault tolerance. [6:42] Rather than blending these goals into a single weighted mathematical score with arbitrary coefficients, lexicographic optimization enforces strict priority ordering. [8:08] Tangled Constraints: Power limits, physical rack space, maximum cable lengths, and port compatibility are tightly coupled; fixing one constraint almost always violates another. [18:03] Translating human expertise into machine logic proved complex: an expert engineer could state an objective like "stretch things out for resilience" in five seconds, but turning that intuitive concept into precise, rankable mathematical criteria required months of effort. [18:03] When questioned during the automation push, no functional justification remained—it was simply a tradition quietly wasting valuable data center space. [18:59] AI is rewriting how we build data centers faster than any manual process can keep up.

Original transcript

[0:04] Hey everyone and thanks for being here [0:06] today. As we all know, AI is rewriting [0:09] how we build data centers. AI is driving [0:12] the demand to turn up more capacity than [0:14] ever before. And that capacity has to be [0:18] designed and delivered faster than our [0:20] existing processes were ever intended to [0:22] support. Larger builds mean larger [0:24] networks, more network equipment and [0:27] more fiber infrastructure needed to [0:29] connect everything together. And beyond [0:31] just the scale, the capacity is coming [0:33] in many different forms. It's a [0:35] heterogeneous mix of asbuilt data [0:37] centers, lease sites, and cloud [0:40] infrastructure. [0:42] No two are exactly the same. [0:45] So, we're facing turning up more [0:46] capacity in less time, requiring far [0:49] more fiber and no standard design to [0:51] fall back on. [0:54] Let me start by going over the old way [0:56] of doing things. Physical network [0:58] infrastructure design was an almost [1:01] entirely manual artisal process. For [1:04] every project, we had a group of experts [1:06] had to understand the building itself, [1:08] the power and failure domain design, and [1:11] the row and rack layout. They then had [1:13] to decide which network topology [1:15] products to deploy in that building and [1:17] solve how to physically map and design [1:19] each one for that specific space. This [1:22] is slow does not scale and became a [1:25] blocker to turn up capacity. Project [1:28] count scales with AI capacity demand. [1:31] There are simply too many projects and [1:33] not enough experts. So it became clear [1:36] that we needed to change how we do [1:38] things. [1:41] So we turned to automation. We looked at [1:43] the problem end to end and built an [1:45] automated design pipeline that [1:47] understands the physical design and [1:50] properties of data center buildings. [1:52] Selects the network topology products to [1:54] deploy for that project. Maps the [1:57] logical network onto the physical floor [1:59] plan and designs the fiber [2:00] infrastructure needed to connect [2:02] everything together. For this talk we [2:04] want to highlight two components of this [2:06] pipeline. The first one is called [2:08] planagram. The second one is our fiber [2:11] design automation. [2:14] My colleague Richard will go over [2:16] planagram. I'll be back to discuss fiber [2:19] design automation [2:21] and then Richard will be back to close [2:23] us out with lessons learned and what's [2:24] next. So now I'll hand it off to my [2:27] colleague Richard. [2:28] >> Thanks Brandon. Let me take you inside a [2:30] placement problem and show what makes it [2:33] hard. I will illustrate that with a [2:35] specific example. [2:38] So first here is what motivated the [2:40] project. Our field has spent decades on [2:43] the logical topology. How layer stack, [2:46] how switches interconnect and how we [2:48] route across them. That work is deep and [2:50] it matters. Every network we build [2:53] starts from a logical topology. But a [2:55] logical topology doesn't serve a single [2:57] bit of traffic. It's just a blueprint. [3:01] Traffic runs on fibers in racks drawing [3:04] power in a real room. [3:06] Someone has to take the blueprint and [3:08] decide for thousands of devices which [3:10] row and which rack each one goes in. And [3:13] as Brandon said, it has been almost [3:16] entirely manual, expert-driven, slow, [3:19] inconsistent from engineer to engineer [3:21] and region to region. Decades of [3:24] research on the blueprint, but very [3:26] little on the half that meets physical [3:28] reality. [3:31] So here is a concrete example of a [3:33] logical network. I picked this one [3:35] specifically because it's a design we [3:37] have been allocating many times and it's [3:40] an example of we keep coming back on the [3:42] next few slides. So here a building [3:45] block is a megapod a set of leaf and [3:47] spine switches in a close topology. [3:50] Above them is an aggregation layer we [3:52] call the axospine built from XSW [3:55] organized into planes. And now the [3:58] connectivity pattern. A plane connects [4:00] to a single spine index and to the same [4:03] index in every megapod in the region. [4:06] Plane one serves SSW1 everywhere. Plane [4:09] 2 SSW2 and so on. They are parallel and [4:13] they never cross. Watch one light up. [4:16] One plane fanning out across the entire [4:18] topology. There are two consequences [4:21] here. Connectivity is biological [4:24] property not by proximity. A plane has [4:26] to reach every corner of the building no [4:28] matter how you lay it out. And the plane [4:31] is a regionwide shared fate. You lose it [4:34] and every megaput loses the same slice [4:36] of uplink at the same moment. That's a [4:39] logical topology. [4:42] So how does a logical topology land on [4:44] the floor? There are really two steps [4:46] here and they happen together. First we [4:49] rack the devices. [4:52] Spine switches ragged by megapod. Excel [4:54] spine switches are ragged by plane. Then [4:57] those racks are allocated to rows on the [4:59] floor plan. [5:01] The thing to watch out is that [5:02] connectivity survives both steps. A [5:05] plane still reaches the same spine index [5:07] in every megapod. No matter how it's [5:09] racked up. There it is. One plane staged [5:13] clear across the building. And these two [5:16] steps are inseparable, which is exactly [5:18] why it gets hard because two instincts [5:21] spreading things out and grouping them [5:23] together are about to collide. [5:27] Here is that collision in a single [5:29] screen. Our job here is to place [5:32] accessine switches into failure domains. [5:34] There are two honest options side by [5:36] side. First on the left, option one we [5:39] call clustering. Here we can put the [5:42] whole plane into one domain. Look how [5:44] little fiber that takes. One trunk per [5:47] plane. It's really simple. But let's [5:49] simulate losing a failure domain and the [5:52] entire plane is gone. The spine index is [5:56] cut off in every megapod at once. [5:59] Minimal fiber, maximal blast radius. [6:02] We call this failure closed failure that [6:05] we would like to avoid. Now let's look [6:07] at option two on the right. We call it [6:09] spreading. Here we scatter every plane [6:11] across all the failure domains. Now the [6:14] fiber explodes. Every plane has to reach [6:16] everywhere. But let's kill a domain and [6:19] nobody is isolated. Each plane just [6:21] loses a slice. Then this becomes an ECMP [6:25] shrink and open failure which is [6:27] preferred over what we have seen in [6:28] option one. So two physical allocations [6:32] of the same logical topology with very [6:35] different properties. That tradeoff is [6:37] what panagram makes explicit and ranked [6:40] and then solves it. [6:42] So really how do our engineers set this [6:44] dial? They never hand you a number. They [6:47] hand you a ranked list. And it comes [6:49] down to a handful of objectives out of [6:51] which we are calling out four. First [6:54] connectivity. This objective minimizes [6:57] the rack pairs that have to connect [6:59] between adjacent layers. Fewer rectorack [7:02] links simpler and cheaper fiber. That's [7:05] the clustering instinct. Second, [7:07] surviving failures spreading entities [7:10] across failure domains. So no single [7:12] failure blows past the budget that ini [7:15] designers will tolerate. That's the [7:16] counterweight. Row similarity. Here we [7:20] keep rack rolls consistent from row to [7:22] row. Uniform design is easier to build [7:25] and easier to operate. Rack efficiency. [7:28] We pack into the fewest number of racks [7:30] and get the most of your space and [7:32] power. [7:34] Now the crucial part. These are not [7:36] blended into one weighted score with [7:38] magic coefficients. They are strictly [7:40] ranked. We satisfy the first goal fully [7:43] and do the best in that we can for the [7:46] second, third, and so on objectives. [7:49] That is what's called lexographic [7:51] optimization. [7:53] And that ordering is a choice. [7:55] Costsensitive deployment ranks [7:57] connectivity on top. A resilience [7:59] critical one puts failure spreading [8:01] first. [8:03] same engine, approvably best design [8:05] either way. [8:08] So when engineers here, let's place [8:10] devices on a floor plan, the first [8:12] instinct is always the same. This is [8:14] bean packing. Let's just write a greedy [8:16] script. And we thought so too. It [8:18] doesn't work for three reasons I'm [8:20] describing here. First, the constraints [8:23] are tangled. Power, space, cable length, [8:26] compatibility. You fix one and you break [8:28] another. Second, the scale. There are [8:31] thousands of entities, multiple valid [8:33] logical topologies, multiple valid [8:35] physical layouts. The combinations [8:38] explode past any single heristic search [8:40] can reasonably solve. They will give you [8:43] an answer, but it just won't be a good [8:45] one. Third, the one that you really can [8:48] script around that objectives each [8:51] other. Cheaper fiber versus surviving [8:54] failures then packing versus uniformity. [8:57] A script would hardcode a winner. But [8:59] the real problem has to balance. So the [9:02] question is how do we design custom data [9:05] center networks rapidly, repeatedly, [9:08] provably well balancing objectives that [9:11] pull against each other. [9:14] So that's the problem. And here's the [9:16] system from outside in. We call it plan. [9:19] It takes three inputs. First the logical [9:22] topology. Second, the DC stencil that [9:25] describes our floor plan, rack space and [9:27] power budgets as well as our failure [9:30] domain boundaries. And the third one, [9:32] the objectives. They define what good [9:35] means. The rank list we just walked [9:37] through. The output is a physical [9:40] topology where every entity is assigned [9:42] to a specific row and rack position. So [9:45] really what's in the box? Plan is an [9:47] orchestrator over two core engines. The [9:50] heavy lifter is an integer program which [9:52] gives us provably optimal design for a [9:55] given ranking. A row IOP over such large [9:58] problem would choke. So we also do a [10:00] graph pass where we reduce the problem [10:02] into tractable smaller problems. Then a [10:06] reinforcement learning component adds [10:07] what ILP can't. It's scale and the whole [10:10] family of near optimal variants instead [10:12] of a single answerer. Graph algorithms [10:15] are for tractability. ILP is for [10:17] optimality and reinforcement learning is [10:19] for scale and variety. I won't take you [10:22] down to the details of these, but there [10:24] is a blog post and our sitcom paper if [10:26] you want it. What I do want you to see [10:29] is what this output unlocks. Every [10:31] device spin to an exact rack. A precise [10:34] machine readable map is the thing that [10:37] finally makes the fiber automatable. And [10:39] now Brendan will go into details of [10:41] that. [10:42] >> Thank you, Richard. After planagram has [10:45] completed, we have a solved data center [10:47] floor plan. Every network device and [10:49] rack in the design topology has been [10:51] given a home, a real physical rack [10:54] position on the data center floor. Now [10:57] we have to design the fiber plant that [10:58] connects them. [11:01] To build the connections, we'll use the [11:02] same logical topology graph that Richard [11:04] used in planagram, the LNTG. The LNTG is [11:08] the logical design, every device and [11:11] every connection between them. For every [11:13] connection in the graph, we now know the [11:15] physical location of each endpoint. [11:18] Planagram placed the nodes. Now we [11:20] materialize the logical edges into [11:22] designed physical fiber connections. [11:26] The devices that need to connect [11:27] together have been distributed across [11:29] the entire site. Some of the needed [11:32] connections will be within the same row. [11:34] Others will be cross row in the same [11:36] room. Others will be across different [11:38] rooms or even across different [11:40] buildings. [11:42] Every one of these is a point-to-point [11:43] connection that the topology requires [11:47] and as they accumulate the picture gets [11:48] crowded very quickly. It is not [11:51] physically feasible to run cables [11:53] directly between each rack pair. The [11:55] distances are too long and the number of [11:57] cables is too great. So, we need a [11:59] better way to organize the cabling for [12:01] our design. [12:05] Fortunately, when it comes to cable [12:06] plane design, we have a range of cable [12:09] products at our disposal. The simplest [12:11] is the patch cord. It's a pointto-point [12:13] single fight or pair cable, one cable [12:16] per link. This is the type of cable we [12:18] just watched on the previous slide. It's [12:20] useful but insufficient for our use [12:21] case. So instead of giving every [12:24] individual connection its own cable, we [12:26] need to do aggregation. We bring [12:28] individual connections to a common [12:29] aggregation point and we carry them [12:31] together in cables that use highdensity [12:33] connectors that we call these trunk [12:35] cables. Breakout cables do the grouping [12:38] at each end. They take individual [12:40] connections and group their fiber pairs [12:42] into the trunk and then split them back [12:44] out on the far side. Shuffle cables are [12:47] used to redistribute fiber between [12:49] connectors of the same cable, enabling [12:51] very specific fiber mappings that [12:53] certain designs require. We chain these [12:56] cable products together in different [12:57] patterns and combinations to build the [13:00] connectivity a design needs. [13:04] That gives us connectivity. But [13:06] connectivity is not the only [13:07] requirement. Sometimes finding one path [13:09] is not enough. Each connection layer in [13:12] the topology has its own fault tolerance [13:14] and diversity requirements. So we may be [13:16] required to spread connections over [13:19] multiple physical diverse paths. And [13:22] diverse here means really diverse. We [13:24] have to ensure that each path does not [13:26] share any common components, cabling or [13:29] passive infrastructure end to end. That [13:31] way if anything happens such as a [13:33] failure or maintenance, the connections [13:35] on the remaining paths stay functional. [13:38] So, how do we know which projects to [13:40] chain together and where the diversity [13:42] has to go? That knowledge lived with our [13:45] design engineers, the experts who had [13:47] been doing this work by hand. We sat [13:49] down with them, worked through the [13:51] critical fiber design patterns and rules [13:53] they were applying, and we codified [13:55] them. Then we distilled those patterns [13:57] down to the core essential set needed to [13:59] support our catalog of network [14:01] topologies. What you are looking at we [14:03] call a channel schematic. The LNTG tells [14:06] us what has to connect. The channel [14:08] schematic tells us how. It is both the [14:11] instruction set the fiber design [14:13] automation follows as well as the [14:15] constraint that has to work with it. And [14:17] this is the important property. With [14:19] these design rules in hand, we can apply [14:21] them to a project regardless of its [14:23] physical floor plan and layout. [14:27] Putting it all together, we need to [14:29] apply the channel schematic and design [14:31] rules to the physical floor plan. The [14:34] circuits in the L&TG drive the fiber [14:36] design buildout end to end. Following [14:38] our design patterns, we analyze the [14:40] floor plan and identify the racks to use [14:42] as aggregation points. We bundle fibers [14:45] together based on the path they will [14:46] take through the building. And we use [14:48] the chain of cable product types laid [14:50] out in our channel schematic to build [14:53] out our endto-end connectivity. [14:57] Because the entire fiber plant is [14:59] modeled, every cable, every connector, [15:01] every passive connection means each [15:03] connection can be traced end to end in [15:05] software. We follow a link out of a rack [15:08] in building A through the series of all [15:10] the cables and connections needed to [15:13] reach its destination rack in building B [15:15] and confirm it terminates where the [15:17] logical topology requires. We run this [15:19] against every connection in the design. [15:21] We assure every connected component is [15:23] compatible and can verify the design [15:26] polarity is correct. That means we can [15:28] assert the cable model is correct early [15:31] during the design phase rather than [15:33] discovering errors later during [15:35] installation and turnup. [15:38] The result is a materialized fiber plant [15:40] model. Millions of strands fully [15:42] identified. We use that model to [15:45] generate the cabling billing materials [15:47] automatically. Producing it this early [15:49] in the design process helps offset [15:51] material lead times and we're able to [15:53] produce rackbyrack installation [15:55] instructions to hand off to our site [15:57] teams for building and turning up our [16:00] data center networks. No manual rework [16:02] anywhere in the pipeline. Now Richard, [16:05] back to you. Thanks Brandon. Now you [16:08] have seen the problem, the system, and [16:10] how the fiber design falls out of it. [16:12] Which leads us to the obvious question. [16:14] Is this real or is this just a research [16:16] prototype? Here is the answer. Every new [16:19] data center network design goes through [16:21] this pipeline. Now, we have already [16:23] created four new regions, 20 plus [16:26] buildings, and actively manage over 1 GB [16:29] of compute capacity with this pipeline. [16:32] We've also created over 100 design [16:34] variants, evaluating different options. [16:37] And what made it stick, this automation [16:39] really speeds things up. What took us [16:41] months before, for example, the initial [16:44] allocation of devices and fiber now [16:46] takes only a few days. What took us [16:49] weeks, for example, reallocation of [16:52] devices and fiber now only takes us a [16:54] couple of days. And finally, we can now [16:58] validate designs in under a minute [17:00] instead of days. [17:04] So, it's fast and it's everywhere, but [17:06] speed really is an easy claim. A bad [17:08] design produced quickly is still a bad [17:10] design. So what I would like to defend [17:13] is that these designs are better than [17:15] what we build by hand. I'll give you [17:17] three ways. First, reliability. [17:21] Every design is checked against the [17:23] validated placement rules and every [17:25] fiber is traced end to end. Second, [17:28] feasibility. Because we frontload real [17:31] power in space modeling, we caught an [17:33] infeasibility we wouldn't have found by [17:36] hand until nearly at deployment. And [17:39] also consistency. Same input will always [17:42] produce the same design every time. No [17:45] more two engineers, two regions solving [17:47] the same problem two different ways as [17:49] Brandon was alluding to this earlier. [17:52] Now look at the right. This is real [17:54] output. In the custom UI, our designers [17:57] are able to validate both placement and [17:59] fiber at the same time. So, our [18:03] automation is producing better plans, [18:05] not just doing it faster. And getting [18:07] here taught us things we did not expect. [18:12] This is the slide I would most want my [18:14] younger son to see. We were sure that [18:16] the hard part would be the automation, [18:19] but it wasn't. It was really the [18:21] organization of the knowledge. two [18:23] lessons specifically to call out. First, [18:27] objectives are far easier to state than [18:29] to formalize. An expert would say stress [18:32] things out for resilience in 5 seconds, [18:35] but making them precise and rankable [18:37] took us months. Two, automation forced [18:40] us to confront rules that were really [18:42] habits. Designs kept half filling racks [18:45] for future upgradability before, but [18:47] then we asked why, and there was no [18:49] reason. It was tradition quietly wasting [18:52] space. [18:53] Once the objective was explicit, this [18:56] habit had nowhere left to hide. [18:59] To sum up, plan and fiber automation [19:02] are, as far as we know, the first work [19:04] to bring physical design, placement, and [19:06] cabling to this community. Logical [19:09] intent goes in and the build ready [19:11] region comes out. And neither is a [19:13] prototype. Together they are default at [19:16] Meta. Today, what's next is on the [19:19] right. We are working on traceability [19:21] end to end from intent to installed [19:23] strand. Also, we are constantly adding [19:26] new infrastructure constraints, [19:28] additional power, cooling, structural [19:30] limits. And finally, brownfield design. [19:34] While we today only work on Grimfield [19:36] new builds, we are looking to support [19:38] complex network migrations for already [19:41] existing and production regions. Which [19:44] lends us back where we opened. AI is [19:47] rewriting how we build data centers [19:49] faster than any manual process can keep [19:51] up. Physical design deserves to be [19:54] automated, optimized, and studied as a [19:57] first class problem. And with that, I [19:59] would like to thank you for your [20:00] attention.