이 논문의 첫머리에 나오는 산수는 내용을 그대로 옮길 가치가 있다. 2017년에서 2022년 사이 플래그십 GPU의 부동소수점 처리량은 4× 늘었다(V100에서 H100). 같은 기간 프런티어 모델이 요구하는 연산은 1500× 늘었다(BERT-base에서 GPT-3). 중국의 사업자에게 이 격차는 더 벌어진다. 그곳에서 합법적으로 살 수 있는 가속기는 플래그십을 일부러 깎아 낸 파생품이기 때문이다. 14억 활성 사용자에게 1조 파라미터가 넘는 자체 모델을 서비스하는 텐센트는 이 산수가 허락하는 유일한 결론을 끌어낸다. 칩당 성능이 선택지에 없다면, 모자란 배수는 데이터센터가 규모로 공급해야 한다. 텐센트가 난징대, 하버드, 밀라노 공대와 함께 SIGCOMM 2025에 발표한 Astral은 그렇게 나온 인프라다[1]. GPU 51만 2천 장을 위해 설계된 패브릭이고, 18개월의 점진적 구축 끝에 현재 두 개 Pod에 12만 8천 장이 가동 중이다. 논문은 한 편 안에 세 편이 들어 있는 구성인데(네트워크 아키텍처, 모니터링 시스템, 성능 예보기), 각 시스템이 앞 시스템에 들어간 투자를 지키기 위해 존재하므로 그 순서대로 읽는다.
아래는 논지를 우리 표현으로 재구성한 것이다.
모든 랭크를 제 레일 위에 붙드는 패브릭
Astral의 호스트 구성은 평범하다. NVLink급 호스트 내 네트워크 뒤에 GPU 8장, 2×200 Gbps NIC 8장이 있고 NIC 하나가 GPU 하나를 전담하므로, 가속기마다 전용 400 Gbps RDMA가 붙고 서버 한 대가 패브릭에 3.2 Tbps를 내민다. 흥미로운 결정은 한 계층 위에서 시작된다. 요즘 집합 통신 라이브러리는 호스트 간 트래픽을 같은 랭크의 GPU들(“같은 레일”)끼리 오가도록 라우팅하고, 이 최적화가 켜져 있으면 트래픽 대부분이 레일 안에 머문다는 것을 Astral의 프로덕션 통계가 확인해 준다. 그래서 이 아키텍처는 2계층에서 같은 레일의 ToR 스위치들을 묶는다. GPU 1,024장짜리 블록이 이중화된 ToR 16대에 물리고(NIC의 두 포트는 서로 다른 ToR에 꽂혀서 스위치나 광모듈 하나가 죽어도 서버가 고립되지 않는다), 여러 블록의 같은 레일 ToR들이 64대 단위의 애그리게이션 스위치 그룹으로 모인다. 그 결과가 6만 4천 GPU짜리 Pod다. 이 안에서는 같은 랭크의 GPU 어느 둘이라도, 레일당 최대 8천 장까지, 코어 계층을 아예 거치지 않고 서로 닿는다. 레일을 가로지르는 트래픽에도 그룹당 64대의 코어 스위치를 지나는 길이 남아 있는데, 이 점이 메타의 rail-only 제안과 Astral을 가른다. rail-only에서는 레일 간 통신이 호스트 내부 인터커넥트로 우회해야 한다.
두 번째 결정이 돈이 드는 쪽이다. 모든 계층에서 집계 대역폭을 동일하게, 즉 51.2 Tbps 스위치 3개 계층 어디에도 과약정(oversubscription)을 두지 않는다. 메타, 바이트댄스, 알리바바는 모두 애그리게이션과 코어 사이를 과약정한다[2][3][4]. 3계층까지 올라오는 트래픽이 적다는 관찰에 기댄 선택이다. 텐센트가 따라가지 않은 이유는 논문의 측정이 설명한다. GPU 1천 장짜리 all-to-all 작업을 Pod 하나 대신 32개에 쪼개면 집합 통신 처리량의 19~37%를 잃고, 3계층 과약정은 all-to-all 처리량의 최대 52%, 학습 전체 성능의 3%를 앗아간다. 3%가 큰 숫자인 이유는 계산과 겹치고 남는 통신 시간이 전체의 15% 남짓뿐이기 때문이다. 민감도는 아키텍처를 탄다. 밀집 트랜스포머가 미는 데이터 병렬 AllReduce와 파이프라인 점대점 트래픽은 레일 안에 머물지만, 전문가 혼합(MoE) 모델이 미는 전문가 병렬 all-to-all은 그렇지 않은데, 업계가 가는 방향이 MoE다. 할당량이 예측 불가능하게 쪼개지고 늘어나는 고객들에게 GPU를 빌려주는 회사에게, 균일한 대역폭은 성능 기능이라기보다 상품 보증에 가깝다. 기계의 어느 부분을 떼어 줘도 다른 부분과 똑같이 동작한다는 보증이다. 부하 분산은 ECMP를 유지하되 2단계 보수 루프를 붙였다. 흐름마다 UDP 소스 포트를 골라 경로를 고르게 흩고, 그래도 스위치의 ECN 카운터가 혼잡을 보고하면 중앙 컨트롤러가 스위치와 같은 해시 함수를 시뮬레이션으로 돌려 문제 흐름들의 소스 포트를 다시 배정한다.
네트워크 아래에는 51만 2천 GPU 설계가 강제로 치르게 하는 물리학 비용이 있다. GPU가 들어오면 서버 한 대의 소비 전력이 8×(1 kWh에서 8 kWh) 뛰므로, Astral은 교류(AC)+UPS 조합을 분산형 고압 직류(HVDC) 시스템으로 바꿨다. 랙 한 줄마다 배치된 유닛이 배터리를 직접 충전하고, LLM 학습이 일으키는 20~30%의 용량 요동을 흡수하며, 반복(iteration)마다 GPU가 TDP를 넘는 순간을 위해 개별 랙이 정격의 30%까지 추가 전력을 끌어 쓸 수 있게 한다. 2024년에는 지붕 태양광과 풍력이 에너지의 22%를 댔다. 냉각도 2단계로 진화했다. 공기 흐름을 수직(측면 흡기 대신 아래에서 위로)으로 바꿔 랙 간 온도 편차를 1도에서 0.11도로 줄였고, 가장 뜨거운 부품은 콜드 플레이트가 맡되 공랭 계통과 하나의 1차 냉원을 공유하게 했다. 액랭과 공랭의 적정 비율이 워크로드에 따라 달라지는데 시설의 수명은 10년 가까이 되므로, 비율을 조절할 수 있어야 했기 때문이다. 평균으로 치면 Astral의 PUE는 텐센트의 기존 데이터센터보다 16.34% 개선됐다. 사업의 성격을 드러내는 운영 디테일 하나. GPU 전력 곡선에는 하루 단위의 밀물과 썰물이 있어서 사용자가 깨어 있는 낮에 높고 추론이 잠드는 밤(대략 22시~8시)에 내려가는데, 전력 회사와는 정액 계약이므로 텐센트는 야간 학습 임대료를 할인해 그 골짜기를 채운다.
결함을 따라 스택을 내려가는 모니터링
두 번째 시스템은 첫 번째 시스템이 고장 나기 때문에 존재한다. Astral의 프로덕션 분류는 원인을 묻기 전에 겉모습부터 정리한다. 장애의 66%는 즉시 죽는 fail-stop, 4%는 시작조차 못 하는 fail-on-start이고, 나머지 30%가 비싼 종류다. 멈춘 채 침묵하는 fail-hang(17%)과 느려진 채 굴러가는 fail-slow(13%)는 에러 메시지를 전혀 내지 않는다. 원인 쪽에서는 호스트 환경·설정 문제가 32%로 선두이고 NIC 오류(15%), 사용자 코드(14%), 스위치 설정 오류(14%)가 뒤를 잇는다. 사건 대부분이 학습 작업 안이 아니라 그 전 또는 옆에서 태어난다는 뜻이다. 진단이 어려운 이유는 증상과 원인의 대응이 다대다이기 때문이다. GPU 결함과 네트워크 결함이 똑같은 NCCL 타임아웃을 만들고, 멈춤은 아무것도 만들지 않는다.
Astral의 답은 개별 센서보다 센서들 사이의 이음매가 돋보이는 모니터링 스택이다. 애플리케이션 계층은 반복마다 모든 NCCL 연산자의 시작과 종료를 추적해, 누가 계산 중이고 누가 통신 중이며 누가 멈췄는지를 호스트 단위로 보여 준다. 전송 계층은 RDMA 오류 이벤트와 함께, 더 특이하게는 큐 페어(QP)별 처리량을 밀리초 해상도로 잡는다. RDMA 요청의 첫 패킷만 걸러 헤더의 전송 길이를 읽는 방식인데, 초 단위 평균으로는 병든 흐름과 건강한 흐름이 아예 구분되지 않는 사례를 논문이 보여 준다. 네트워크 계층은 sFlow 샘플링으로 흐름의 스위치별 경로를 복원하고 INT를 실은 핑으로 홉마다 지연을 잰다. 물리 계층은 스위치 카운터(PFC, ECN, 드롭)와 호스트 내부 상태를 모은다. 계층을 잇는 열쇠가 의도된 설계다. 작업의 통신 그룹은 QP로, QP는 5-튜플로, 5-튜플은 경로 데이터베이스로, 경로는 물리 장비로 이어진다. 탐지는 호스트 간 수평 비교로 임계값에 거의 기대지 않고(집단에서 벗어난 노드가 용의자이고, 기대값은 아래에서 설명할 예보기가 공급한다), 진단은 그 이음매들을 타고 아래로 내려간다. 프로덕션의 fail-slow 하나가 전체 경로를 보여 준다. NCCL 타임라인이 광범위한 통신 지연을 알리고, 밀리초 QP 속도가 링크 대역폭의 절반에 못 미치는 흐름들을 찾아내고, 홉별 텔레메트리가 한 경로에서 0.6, 179, 266마이크로초의 지연을 재고, 스위치 카운터가 애그리게이션-ToR 하향 링크의 PFC 정지 폭풍을 드러내며, 최종 원인은 ECMP가 비효율적인 상류 경로로 흐름을 밀어 넣은 것으로 확정된다. 배치 1년 후 장애 위치 특정에 걸리는 평균 시간(MTTLF)이 며칠에서 몇 분으로 줄었다. fail-stop은 12×, fail-hang은 25×, fail-slow는 약 5× 빨라졌다.
이 시스템이 못 하는 일에 대해서도 실전 기록은 솔직하다. 8천 GPU에서 난 fail-hang 하나는 어디에도 비정상 로그를 남기지 않았다. 규모를 줄이면 증상이 사라져 이분 탐색 격리도 통하지 않았고, 수십 명의 전문가가 한 번에 한 시간씩 걸리는 일괄 교체를 26시간 동안 반복한 끝에, 유지보수 기록과의 대조로 특정 NVIDIA 드라이버 버전이 범인으로 밝혀졌다. 장비 한 대의 고장 난 PCIe 링크 하나는 당시 모니터에 보이지 않는 채로 PFC 폭풍을 일으켜 클러스터의 모든 임차 고객의 학습 효율을 절반으로 깎았고, 물리 계층 PCIe 감시는 그 뒤에 추가됐다. 장애의 32%가 호스트 환경·설정에서 나오는 만큼 오프라인 도구도 제 몫을 한다. MAC 주소와 슬롯 ID를 의도된 토폴로지와 대조하는 배선 검증기(초기 구축 때 현장 인력이 51만 2천 포트 설계의 배선을 반복해서 틀렸다), 그리고 혼잡 제어 파라미터, 드라이버 버전, NCCL 빌드가 제각각인 채 들어오는 임대 서버를 인도 전에 걸러내는 설정 점검이다.
Seer: 몇 초 만에 나오는, 0.3% 오차의 예보
세 번째 시스템은 앞의 두 시스템 모두가 기준 답안을 필요로 하기 때문에 존재한다. Astral Seer는 학습·추론 작업의 실행 타임라인을 연산자 단위로 예보한다. 이 하드웨어와 이 네트워크에서 이번 반복은 연산자별로 얼마가 걸려야 정상인가라는 물음의 답이다. 기존 패킷 수준 시뮬레이터는 속도에서 탈락했다. GPU 1천 장 작업의 반복 한 번을 ASTRA-sim은 48코어 서버에서 하루 걸려 계산했고 SimAI도 몇 시간이 필요했다. 반대편의 연산자 수준 도구들은 패킷 수준 현상을 아예 무시한다. Seer는 그 사이를 가른다. 연산자 의존성 그래프는 PyTorch 프로파일러 트레이스를 Chakra로 변환해 얻거나, 아직 존재하지 않는 연산자를 모델링하고 싶은 연구자가 JSON 템플릿으로 직접 쓴다. 실행 시간은 순진한 공식(텐서 크기 나누기 이론 대역폭)에서 출발한 뒤 프로덕션 데이터로 보정된다. 연산 강도와 실측 FLOPS, 메모리 트래픽과 실측 HBM 처리량, 메시지 크기와 실측 네트워크 처리량을 각각 다항식으로 맞추는 방식이라, 패킷 수준의 현실이 시뮬레이션 대신 보정(calibration)을 통해 들어온다. 여기서는 임대 사업이라는 조건이 오히려 이점이 된다. 다양한 구성의 고객이 많으니 보정 데이터도 저절로 쌓인다. 결과물은 몇 초 만에 타임라인을 내놓고, 사내 Hunyuan 밀집 모델에서는 테스트베드 반복 시간과의 편차가 0.3%에 들어온다. 약점도 숨기지 않는다. MoE 모델은 전문가 라우팅이 데이터에 좌우되고 일부 연산자가 아직 미보정이라 예보가 더 어긋난다.
두 사례 연구가 이 도구의 밥값을 보여 준다. GPU 수급 때문에 여러 데이터센터에 걸쳐 학습해야 할 때 어느 병렬화를 경계 너머로 보낼 것인가라는 물음에, Seer는 통념(트래픽이 가장 가벼운 파이프라인 병렬)을 뒤집는다. 데이터 병렬 트래픽은 덩치가 커도 빈도가 낮고 겹치기 쉬워 여러 구성에서 PP를 이기고, ZeRO 방식의 샤딩된 DP만은 어떤 경우에도 링크 너머로 늘여서는 안 되는 쪽이며, 사이트 간 대역폭 과약정이 대략 16:1을 넘기 전까지는 효율이 버틴다. 호스트 내 도메인을 얼마나 키울 가치가 있는가라는 물음에는, 스케일업 논쟁이 보통 정성적으로 주장하는 것을 Seer가 정량화한다. MoE 학습·추론은 더 큰 NVSwitch 도메인에서 크게 이득을 보고, 밀집 모델은 훨씬 덜 본다.
우리가 읽어낸 것
같은 SIGCOMM에 실린 InfiniteHBD[7]와 겹쳐 읽으면 Astral은 설계 공간의 반대편 극점이다. 한 논문은 스위치를 트랜시버 속으로 줄여 값싼 전용 링을 만들고, 다른 논문은 돈으로 살 수 있는 가장 균일하고 스위치가 많은 패브릭을 세워 임대 함대에 나쁜 구석이 없게 만든다. 둘은 워크로드의 차이만큼이나 사업의 차이에 대한 답이라는 데 유의할 필요가 있다. 모든 계층의 대역폭을 같게 하겠다는 Astral의 고집은 임차 고객의 작업이 예측 불가능하게 쪼개질 때에만 본전을 뽑는데, 그것이 바로 클라우드라는 조건이다. 논문의 모니터링 절반은 ByteRobust와 자연스러운 짝을 이룬다. 바이트댄스는 결함이 의심된 다음(빠르게 축출하고 진단은 오프라인으로)을 최적화하고, 텐센트는 의심 그 자체(결함이 번지수를 갖게 될 때까지 모든 계층의 텔레메트리를 잇는 일)를 최적화한다. 완결된 운영에는 명백히 둘 다 필요하다. 우리는 저평가되기 쉬운 기여가 Seer라고 본다. 모델링이 대단해서가 아니라(일부러 단순하다) 루프 안에서의 위치 때문이다. 같은 보정된 예보 하나가 모니터링의 이상 판정 기준을 정하고, 데이터센터 간 대역폭 문제의 값을 매기고, 다음 호스트 내 도메인의 크기를 정한다. 단서는 운영자 논문의 통례를 따른다. 모든 숫자는 한 함대에서 자체 보고된 것이고, 51만 2천은 설계 용량이며 배치된 것은 12만 8천 장이고, 같은 레일에 거는 승부는 집합 통신 라이브러리가 앞으로도 트래픽을 레일 안에 붙들어 준다는 전제에 기댄다. 논란의 여지 없이 이 논문이 기록한 것은, FLOPS 경쟁에서 배제된 회사도 시스템 경쟁에서는 겨룰 수 있다는 것, 그리고 그러려면 스위치 ASIC의 해시 함수부터 냉각 공기가 부는 방향까지 함께 설계된 스택이 필요하다는 사실이다.
출처와 저작권 안내
이 글은 Silicon and Systems가 작성한 편집 요약으로, 아래에 인용한 논문의 논지를 우리 표현으로 재서술한 것이다. 원문의 문장, 도판, 표는 이 글에 재사용하지 않았으며, 이 페이지의 도판은 모두 이 요약을 위해 새로 제작했다. 논문은 SIGCOMM 2025에서 발표되었고, 확정본은 Proceedings of the ACM SIGCOMM 2025 Conference에 실려 있다. (c) 2025 the authors, publication rights licensed to ACM.