10만 GPU 학습 패브릭은 Clos 토폴로지를 더 크게 그린다고 만들어지지 않습니다. 토폴로지는 포트 배정, 케이블 종단, IP 주소, 라우팅 인접 관계, 정책 매개변수, 제조사별 스위치 설정으로 변환되어야 합니다. 첫 패킷을 보내기 전에 이 산출물이 서로 일치해야 하며, 설계를 바꾼 뒤에는 무엇이 왜 달라졌는지와 새 상태가 네트워크의 불변조건을 지키는지를 확인해야 합니다.
Meta의 Matryoshka는 이 변환을 컴파일러 문제로 다룹니다[1]. 상위 수준의 네트워크 설계 의도를 모델 기반 작업 흐름에 넣습니다. 재사용 가능한 토폴로지 블록은 물리 구조와 논리 구조를 표현합니다. 데이터베이스는 의도한 네트워크를 구체적인 개체로 만들고, 범용 설정 계층은 제품과 무관한 의미를 스위치 제조사의 명령 문법에서 분리합니다. 실제 장비에 순차적으로 적용하기 전에 여러 경계에서 검증합니다.
운영 규모를 보면 이 소프트웨어가 아키텍처에서 차지하는 비중을 알 수 있습니다. Matryoshka는 6년 넘게 운영되었고 주요 코드 개정 네 번을 거쳤으며, 18개 유형에 걸친 약 900개 데이터센터 네트워크 설계를 지원했습니다. 최신 사례는 여섯 개 건물에 걸쳐 10만 개가 넘는 GPU를 연결합니다. 보고된 AI 환경에는 109개 클러스터 버전과 26개 스위치 역할이 있습니다. 이 규모에서 설정 생성은 단순 반복 업무가 아니라 패브릭의 실행 가능한 명세입니다.
토폴로지와 실제 스위치 사이에 빠진 계층
네트워크 연구는 논리 설계와 물리 배포를 나누어 설명하는 경우가 많습니다. 토폴로지 연구는 어떤 장비를 연결할지 정하고, 라우팅 연구는 트래픽을 어떻게 보낼지 정합니다. 배포 시스템은 재고와 케이블 상태를 기록합니다. 그러나 이 산출물 중 어느 하나도 모든 스위치가 실행할 완전한 설정을 만들지는 못합니다.
이 간극은 네트워크 구성이 다양할수록 커집니다. Meta는 70개가 넘는 지역에서 다섯 세대의 데이터센터 네트워크를 운영합니다. 보고된 구성에는 프런트엔드 네트워크, 패브릭 집선 네트워크, RoCE 학습 클러스터, 지역 패브릭, 특수 역할이 포함됩니다. 비중이 가장 큰 데이터센터 패킷 전달 환경은 47.3%이고, 패브릭 집선은 18.5%, RoCE 학습 클러스터는 12.2%입니다. 하나의 도구가 공통 개념을 표현하되 서로 다른 네트워크를 같은 것으로 취급해서는 안 됩니다.
수동 템플릿은 두 방향에서 무너집니다. 네트워크 유형마다 별도 템플릿을 두면 수정 사항과 정책이 서로 달라집니다. 모든 예외를 하나의 범용 템플릿에 넣으면 특정 설계의 변경이 관계없는 설계까지 건드립니다. 어려운 점은 문자열을 바꾸는 일이 아닙니다. 어떤 개념이 안정적이고, 무엇을 매개변수로 두며, 어느 동작을 제품별로 명시해야 하는지 정하는 일입니다.
Matryoshka는 이를 위해 중간 표현을 둡니다. 입력에는 완성된 명령줄이 아니라 설계 의도가 들어갑니다. 토폴로지 모델은 장비, 역할, 포트, 링크를 기술하고, 라우팅 정책 모델은 관계와 필요한 동작을 기술합니다. 컴파일러는 이를 데이터베이스 개체로 바꾼 뒤 범용 스위치 설정(Generic Switch Configuration, GSC)을 생성합니다. 제품 어댑터는 GSC를 제조사별 스위치 문법으로 변환합니다.
이 분리는 소프트웨어 컴파일러와 같은 실무적 이유를 갖습니다. 원본 설계 언어는 사람이 읽고 검토할 수 있어야 하며, 중간 상태는 같은 입력에서 같은 결과를 내야 합니다. 특정 제품의 차이가 모든 상위 모델로 새어 나오지 않아야 하고, 잘못된 설계는 실행 전에 거절해야 합니다. 네트워크 컴파일러에는 한 가지 의무가 더 있습니다. 대상이 기존 상태, 케이블 설비, 적용 순서에 따라 동작이 달라지는 물리 시스템이라는 점입니다.
재사용 블록은 차이를 지우지 않고 복잡도를 줄입니다
논문의 핵심 모델링 선택은 토폴로지 블록 라이브러리입니다. 블록은 조합 규칙이 정해진 장비와 링크 묶음입니다. 큰 네트워크는 모든 연결을 다시 적는 대신 이 단위를 조합합니다. 완전 연결과 Clos 구조를 재사용하고, 매개변수로 장비 수, 포트 배치, 네트워크 세대를 선택합니다.
재사용이 필요한 이유는 물리 구조와 논리 구조의 변화 속도가 다르기 때문입니다. 새 스위치가 포트 수와 배치를 바꾸더라도 역할 계층은 유지될 수 있습니다. 새 AI 클러스터는 랙 수나 건물 경계를 바꾸면서 레일 기반 통신 구조는 유지할 수 있습니다. 하나의 라우팅 정책이 여러 물리 변형에 적용되기도 합니다. 변화 축을 분리하면 한 요소를 바꿀 때 전체 명세를 다시 작성하지 않아도 됩니다.
FBNet 데이터베이스는 단순한 자산 목록이 아닙니다. Matryoshka는 원하는 상태를 계산하고 저장된 상태와 비교한 뒤 필요한 데이터베이스 트랜잭션을 적용합니다. 외래 키 관계는 구조 검증에 쓰입니다. 이렇게 구체화한 모델은 설정 생성과 네트워크 상태를 사용하는 다른 시스템이 함께 참조하는 기준이 됩니다.
전체 재컴파일은 의도적인 선택입니다. 증분 생성기는 요청된 변화만 처리하므로 빨라 보일 수 있습니다. 그러나 결과가 과거 작업 순서와 남아 있는 숨은 상태에 의존할 수 있습니다. Matryoshka는 모델에서 의도한 설정을 다시 생성하므로 같은 입력은 같은 출력을 내야 합니다. 이 결정성은 검토, 복구, 변경점 분석을 단순하게 만듭니다. 대신 데이터베이스 비교와 출력 생성의 비용을 제어해야 합니다.
설계 의도, 구체화된 토폴로지, 범용 동작, 제조사별 출력 가운데 어느 계층이 달라졌는지를 구분할 수 있다는 점도 중요합니다. 이들은 서로 다른 장애 영역입니다. 하나의 템플릿에 합치면 설정 차이가 생긴 원인을 찾기 어렵습니다.
10만 GPU 사례의 핵심은 규모보다 이질성입니다
Meta의 지역 AI 슈퍼클러스터는 여섯 건물에 걸쳐 있습니다. 다섯 건물은 AI 용량을 담고 한 건물은 스토리지를 제공합니다. 설계는 프런트엔드 트래픽과 학습용 백엔드 네트워크를 분리합니다. 학습 패브릭 안에서 스위치는 랙, 클러스터, 집선 역할을 맡습니다. 레일 기반 토폴로지는 같은 위치의 가속기를 계층적으로 연결해 집합통신이 예측 가능한 경로를 쓰도록 합니다.
건물 수는 데이터센터 경계가 물리적이라는 점을 드러냅니다. 광섬유 거리, 관로, 랙 전력, 냉각, 공사 일정, 장애 영역이 토폴로지를 제한합니다. 10만 GPU를 하나의 사각형으로 그린 논리도는 이 조건을 숨깁니다. Matryoshka는 지역 슈퍼클러스터와 이를 구성하는 건물 단위 네트워크의 관계를 표현해야 합니다.
클러스터 목록에는 109개 버전이 있습니다. 여러 가속기 세대, 네트워크 인터페이스 변형, 랙 설계, 케이블 구성이 섞입니다. 일부는 Top-of-Rack 스위치를 쓰고 다른 일부는 End-of-Row 방식을 씁니다. 공통 설계 의도 시스템은 이 요소의 안정적인 역할을 표현하면서 서로 다른 포트와 링크 배치를 보존해야 합니다.
AI 네트워크에는 26개 장비 역할이 있습니다. 역할은 단순 라벨이 아닙니다. 어떤 이웃이 허용되는지, 어느 라우팅 인접 관계가 필요한지, 어떤 정책과 설정 기능을 적용할지를 결정합니다. 장비에 잘못된 역할을 부여하면 문법상 정상인 설정으로도 동작이 틀린 네트워크를 만들 수 있습니다.
따라서 컴파일러는 계층 사이의 일관성을 책임집니다. 랙을 하나 추가하면 장비 목록, 포트 배정, 물리 연결, 주소, 라우팅 관계가 함께 달라집니다. 다섯 항목 중 네 개만 바꾸면 설계는 완성되지 않습니다. Matryoshka의 가치는 하나의 의도 변경을 정해진 작업 흐름으로 관련 산출물까지 전달하는 데 있습니다.
출력 정확성과 동작 정확성은 별도로 봐야 합니다
논문은 두 가지 성공률을 보고하며, 이 수치를 합치면 안 됩니다. 출력 검증은 생성된 설정이 검증 절차를 통과하는지를 봅니다. 최근 1년 동안 12,100건이 성공하고 589건이 실패해 통과율은 95.4%였습니다. 여기에서 실패는 검증 단계가 문제를 차단했다는 뜻이며 곧바로 운영 장애를 뜻하지 않습니다.
동작 검증은 생성 결과가 네트워크 설계 의도와 시스템 검사를 통과하는지를 봅니다. 2024년 10월 23일부터 측정 종료 시점까지 568건이 성공했고, 시스템 원인 실패는 46건, 시스템 외부 원인 실패는 25건이었습니다. 논문은 외부 원인 25건을 제외하고 성공률 96.4%를 제시합니다. 출력 검증과 분모가 다릅니다.
어느 수치도 무결함을 뜻하지 않습니다. 설정 컴파일러는 배포 전에 실패를 찾기 때문에 가치가 있습니다. 중요한 것은 어떤 결함이 검증을 빠져나갔는지, 진단에 얼마나 걸렸는지, 실패가 의도한 네트워크만 차단했는지입니다. 위험한 오류는 눈에 띄는 문법 오류가 아니라, 문법은 맞지만 여러 장비에 걸친 불변조건을 어기는 설정입니다.
독립된 검사를 겹치면 이 위험을 줄일 수 있습니다. 데이터베이스 스키마 검증은 개체 관계를 확인하고, 토폴로지 검사는 차수, 역할, 포트 제약을 확인합니다. 범용 설정 검사는 제조사 문법에 기대지 않고 라우팅과 정책 불변조건을 확인할 수 있습니다. 제조사별 설정 검증은 백엔드 고유 오류를 잡습니다. 이후 단계적 배포에서 실제 장비 동작과 의도한 모델을 대조합니다.
전체 재컴파일에도 빠른 상태 갱신이 필요합니다
결정성을 택했다고 성능이 중요하지 않은 것은 아닙니다. Meta는 보통 한 주에 800건에서 2,000건의 Matryoshka 작업을 수행하며, 2024년에 새 데이터센터 네트워크 유형 여덟 개를 추가했습니다. 생성이 느리면 정확성을 높이려 만든 도구가 배포 병목이 됩니다.
논문은 원하는 개체 그래프와 현재 그래프를 비교한 뒤 변화만 적용하는 데이터베이스 갱신 최적화를 설명합니다. 한 패브릭 집선 확장에서 트랜잭션 시간이 34.60분에서 46초로 줄어 97.80% 단축되었습니다. 그리드 이동은 34.84분에서 13.19초로 줄어 99.37% 단축되었습니다. 링크 288개 추가는 37초에서 3초로 줄어 91.9% 단축되었습니다. 스위치 88개와 수백 개 링크를 추가하는 작업도 200초에서 60초로 줄었습니다.
이는 FBNet 갱신 단계의 측정값입니다. 물리 네트워크 확장을 13초에 끝낸다는 뜻이 아닙니다. 설정 생성, 검토, 업로드, 장비 적용, 수렴, 변경 후 검증은 별도 단계입니다. 정확한 결론은 그래프를 인식하는 데이터베이스 트랜잭션이 전체 설계 의도를 다시 계산하는 작업 흐름에서 소프트웨어 병목 하나를 제거했다는 것입니다.
생성 시간 구성도 네트워크 유형에 따라 다릅니다. 어떤 작업에서는 GSC 생성과 업로드가 지배적이고 데이터베이스 조회와 컴파일은 작습니다. 따라서 최적화 대상은 작업과 네트워크 유형을 보고 정해야 합니다. 수천 개 장비의 출력을 백엔드가 직렬로 처리한다면 데이터베이스 쓰기만 빨라져도 전체 시간은 거의 줄지 않습니다.
운영자는 두 종류의 지연 백분위를 봐야 합니다. 대화형 설계에서는 엔지니어가 변경점을 검토할 수 있도록 피드백이 빨라야 합니다. 실제 배포에서는 일부 준비된 변경이 잠금과 검토 인력, 정비 시간을 점유하므로 꼬리 지연이 예측 가능해야 합니다. 중앙값만 보면 드문 네트워크 유형이나 큰 확장이 이상치가 되는지 알 수 없습니다.
공유 컴파일러는 공유 장애 범위를 만듭니다
중앙화는 중복 논리를 없애지만, 별도 도구 때문에 격리되어 있던 네트워크를 하나의 코드로 연결합니다. 논문은 2020년 변경 과정에서 패브릭 사이 연결에 쓰이는 IPv6 프리픽스를 모두 잘못 삭제한 사건을 설명합니다. 새 AI 백엔드 설계를 위해 넣은 변화가 기존 데이터센터 네트워크 논리에 영향을 준 사례도 제시합니다.
이 사건은 하나의 컴파일러를 쓰지 말아야 한다는 뜻이 아닙니다. 하나의 컴파일러를 안전하게 쓰기 위한 조건을 보여 줍니다. 공통 코드는 실제로 공통인 불변조건만 표현해야 합니다. 네트워크 유형별 동작은 명시적인 인터페이스 뒤에 두어야 합니다. 테스트 행렬에는 과거와 현재의 네트워크 세대가 모두 들어가야 하며, AI 패브릭 변경이 관계없는 프런트엔드와 지역 네트워크 출력을 바꾸지 않는지 확인해야 합니다.
출력 스냅숏 비교만으로는 충분하지 않습니다. 기대 스냅숏에 이미 잘못된 정책이 들어 있으면 동일한 오류를 보존합니다. 의미 검사는 필요한 모든 프리픽스에 도달할 수 있는지, 링크 하나가 끊겨도 중복 경로가 남는지, End-of-Row 변형이 올바른 포트를 연결하는지, 설정된 피어 수가 토폴로지 모델과 같은지를 물어야 합니다.
모델에는 버전 관리도 필요합니다. 데이터베이스 스키마 이전, 토폴로지 라이브러리 갱신, 범용 정책 변경, 제조사 백엔드 변경은 복구 경로가 서로 다릅니다. 생성물마다 컴파일러와 모델 버전을 기록해야 사건 당시 상태를 재현할 수 있습니다. 코드가 결정적으로 동작해도 실제 장비에 적용된 상태의 계보가 없으면 재현할 수 없습니다.
배포는 처음부터 점진적으로 설계해야 합니다. 먼저 쓰기 없이 생성하고 검증합니다. 그다음 의도한 변경점과 실제 네트워크를 비교합니다. 일부 장비에 시범 적용해 라우팅과 트래픽 불변조건을 확인한 뒤 장애 영역 단위로 넓힙니다. 중단 장치는 알려진 설정을 복원하거나 다음 건물로 넘어가기 전에 작업을 멈춰야 합니다. 컴파일은 계획을 반복 가능하게 만들고, 배포 제어기는 그 계획의 권한을 제한합니다.
컴파일러 인터페이스는 장비 구매 조건이 됩니다
스위치의 전달 용량이 충분하다고 바로 배포할 수 있는 것은 아닙니다. 범용 모델이 표현할 수 있고 제조사 백엔드가 출력할 수 있는 설정 의미를 제공해야 합니다. 지원하지 않는 정책 기능, 일관되지 않은 텔레메트리, 느린 적용, 약한 복구 기능은 명목상 호환되는 스위치의 통합 비용을 높입니다.
따라서 구매 과정에서 컴파일 계약을 확인해야 합니다. 포트와 분기 모드는 기계가 읽을 수 있습니까? 장비 없이 설정을 검증할 수 있습니까? 전체 설정을 원자적으로 교체할 수 있습니까, 아니면 명령을 순서대로 실행해야 합니까? 거부된 상태는 어떻게 보고합니까? 실행 중인 설정 버전을 식별할 수 있습니까? 여러 장비를 갱신하다 일부만 성공하면 어떤 상태가 됩니까?
토폴로지 유연성에도 소프트웨어 비용이 있습니다. 고포트 스위치가 물리 계층을 줄이더라도 새 역할, 포트 배치, 장애 모델을 컴파일러 라이브러리에 추가해야 합니다. 제조사 고유 기능이 한 경로를 개선하면서 백엔드 복잡도와 회귀 범위를 키울 수 있습니다. 장비 비교에는 가격과 대역폭뿐 아니라 모델링과 검증의 지속 비용을 포함해야 합니다.
광모듈과 케이블도 같은 원칙을 따릅니다. 논리 링크만 알고 커넥터, 거리, 매체 제약을 모르는 모델은 논리적으로 맞지만 만들 수 없는 설계를 생성할 수 있습니다. 컴파일러가 불가능한 배치를 거절할 수 있도록 물리 자산에 충분한 속성을 기록해야 합니다. 여러 건물을 연결할 때는 포트 번호뿐 아니라 거리와 패치 경계도 필요합니다.
도입 검증에서 무엇을 측정해야 합니까?
첫 번째는 재현성입니다. 같은 데이터베이스 스냅숏에서 같은 설계 의도를 두 번 컴파일합니다. 범용 출력과 제조사별 출력은 바이트 단위로 같거나, 명시적으로 제외한 메타데이터만 달라야 합니다. 이어서 매개변수 하나를 바꾸고 변경점이 의도한 네트워크와 역할 안에 머무는지 확인합니다.
두 번째는 불변조건 검사 범위입니다. 필요한 링크 제거, 주소 중복, 잘못된 역할 배정, 포트 용량 초과, 라우팅 프리픽스 삭제, 범용 모델이 표현하지 못하는 제조사 기능을 각각 넣습니다. 각 오류는 가장 이른 검증 단계에서 이해할 수 있는 설명과 함께 차단되어야 합니다.
세 번째는 규모별 시간입니다. 모델 구성, 데이터베이스 비교, 범용 설정 컴파일, 백엔드 변환, 업로드, 장비 적용, 동작 검증을 따로 측정합니다. 작은 랙 추가, 건물 확장, 많은 장비에 영향을 주는 정책 변경에서 중앙값과 꼬리 지연을 보고해야 합니다. 전체 시간 하나로는 다음 세대의 병목을 찾을 수 없습니다.
네 번째는 복구와 혼합 상태입니다. 일부 스위치만 새 설정을 적용한 시점에 배포를 끊습니다. 제어기가 버전 분리를 감지하고 위험한 진행을 막은 뒤 알려진 상태에 도달하는지 확인합니다. 장비 하나에 접속할 수 없거나 백엔드가 명령 하나만 거부하는 경우도 반복해야 합니다.
마지막은 조직 규모입니다. 두 팀이 공통 코드를 불필요하게 바꾸지 않고 서로 다른 네트워크 유형을 추가하게 합니다. 모델이 안정적인 추상화를 분명하게 만드는지, 템플릿 복잡도를 프로그래밍 언어로 옮겼을 뿐인지 검토해야 합니다. 하나의 정책을 여러 곳에서 서로 다르게 표현할 가능성을 줄여야 컴파일러가 성공한 것입니다.
Matryoshka의 장기적인 의미는 특정 토폴로지에 있지 않습니다. 초대형 네트워크 설계는 설계 의도에서 물리 설정까지 결정적이고 검증 가능한 경로를 가져야 완성된다는 주장에 있습니다. 10만 GPU 사례에서는 건물, 클러스터 버전, 장비 역할의 수가 사람이 한 번에 검토할 범위를 넘기 때문에 이 주장이 분명해집니다. 컴파일러는 일관성을 제공하지만, 컴파일러의 인터페이스와 불변조건, 배포 권한도 패브릭 장애 모델에 포함해야 합니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 독립적으로 작성한 편집 다이제스트입니다. 시스템 구조, 운영 규모, 검증 결과, 한계를 자체 문장으로 다시 설명했으며 원문의 문장, 표, 도판을 옮기지 않았습니다. 두 도판은 이 글을 위해 새로 만들었고, 첫 도판은 실제 제품 사진, 건물 평면도, 제조 도면이 아닌 개념적 하드웨어 도판입니다. 논문은 USENIX 발표 페이지에서 공개되어 있습니다. 저작권은 (c) 2026 저자에게 있으며, USENIX는 NSDI 논문별 저작권을 저자가 보유한다고 밝힙니다.