2025년 이후 산업계가 발표한 AI 인프라 논문을 가속기, 네트워크, 스케줄러처럼 장치별로 나누어 읽으면 서로 다른 최적화 사례로 보입니다. 그러나 시설 한도에서 시작해 모델 작업이 끝나는 지점까지 한 경로로 연결하면 공통된 변화가 드러납니다. 이제 최적화의 단위는 GPU 서버 한 대가 아닙니다. 전력, 열, 데이터, 대기열, 동기화, 장애가 작업 완료를 막는 모든 지점을 포함한 데이터센터 전체입니다.
이 글은 2025년 1월부터 2026년 8월 28일까지 공개된 1차 논문 가운데 9편을 살펴봅니다. Meta, Google, DeepSeek, Huawei Cloud, NVIDIA, Microsoft, Alibaba, ByteDance가 실제 운영 환경이나 산업계 규모의 시험 결과를 공개한 연구를 골랐습니다. 인용 횟수 순위도 아니고 관련 논문의 전체 목록도 아닙니다. 운영 주체가 분명하고, 메커니즘과 수치가 있으며, 결과를 적용할 때 알아야 할 한계까지 확인할 수 있는 연구를 선정했습니다.
이 논문들을 관통하는 결론은 데이터센터가 프로그래밍 가능한 런타임으로 바뀌고 있다는 것입니다. 런타임은 상태를 관찰하고, 다음 상황을 예측하며, 실행할 조치를 선택한 뒤 서비스 목표를 지켰는지 다시 확인합니다. 2025~2026년의 시스템은 이 루프를 150 MW 전력 한도, 미래 냉각 용량, 연산 패브릭 대역폭, 스토리지 배치, KV 캐시 지역성, 에이전트 워크플로, 강화학습 단계, GPU 단편화, 복구 상태까지 확장했습니다. 제어 주기는 마이크로초부터 20년까지 다르지만 구조는 같습니다.
첫 번째 제어 평면은 건물입니다
Meta가 2026년에 공개한 GB200 약 8만3천 장의 구축 사례는 장비가 도착하기 6~12개월 전부터 시작합니다. 건물 다섯 동에 배정된 전력은 총 150 MW입니다. GPU의 최대 설정인 1,200 W로 계획하면 약 7만4천 장이 들어갑니다. 960 W로 낮추면 계획상 약 8만6천 장, 네트워크와 실제 배치 조건을 반영하면 약 8만3천 장을 설치할 수 있습니다. GPU 한 장은 느려지지만 1,200 W 계획보다 클러스터 총 처리량이 약 11% 높습니다. 구축 후 실측 여유를 확인해 상한을 1,020 W로 올리고, 작업 단위 런타임 제어를 더하면 시설 전력을 늘리지 않고 총 처리량을 약 14% 높일 수 있습니다[1].
다른 시설이 가져갈 것은 960 W라는 설정값이 아닙니다. 랙 전원공급장치의 텔레메트리는 상위 전력 패널의 계측값보다 부하를 높게 잡았고, 캠퍼스 전체에 여유가 있어도 일부 주배전반에는 전력이 거의 남지 않았습니다. Meta는 고정된 구매 예산이던 전력을 계층별로 측정하고 스케줄링하는 자원으로 바꿨습니다. Power Smoother는 동기식 작업에서 반복되는 전력의 골을 줄이고, Dimmer는 7초 평균을 기준으로 같은 작업의 랭크를 함께 조절합니다. GPU 한 장만 늦추면 나머지 장비가 새로 생긴 지연 작업자를 기다리며 전력을 쓰기 때문에, 제어 수단이 작업 구조를 알아야 합니다.
Google의 Prometheus는 같은 제어 루프를 더 긴 시간대로 넓힙니다. 30개 데이터센터에서 과거 25년의 기상 관측과 미래 20년의 기후 전망을 결합했습니다. 필요한 냉각 용량은 평균 11%, 최악의 경우 48% 늘어납니다. Prometheus는 이를 20년 시설 계획, 2년 장비 계획, 2주 운영 예측으로 나눕니다[2]. 이 결과는 소프트웨어로 냉각 설비를 대체할 수 있다는 뜻이 아닙니다. 10 MW 작업을 옮기려면 가상머신 약 20만 개와 메모리 3.2 PB를 이동해야 하며, 평가한 시설 대부분은 부하의 20% 미만만 다른 곳으로 보낼 수 있었습니다. 소프트웨어는 단기 대응 수단이고 물리적 냉각 용량은 여전히 바닥을 정합니다.
두 논문을 함께 읽으면 이용률을 묻는 방식부터 달라집니다. GPU가 바쁜지가 아니라 다음 전력과 냉각 용량 1단위를 해당 랙에 필요한 시점까지 공급할 수 있는지를 봐야 합니다. 배전 계층, 순간 전력 변화, 기상 위험, 작업 이전 비용을 빼놓은 플릿 대시보드는 클러스터를 보여주지 않습니다. 장치 재고의 일부만 보여줍니다.
데이터 이동이 명시적인 API가 됩니다
DeepSeek-V3는 다음 경계를 드러냅니다. 파라미터 6,710억 개 모델을 H800 GPU 2,048장에서 학습했으며, H800의 NVLink 대역폭은 H100의 900 GB/s보다 낮은 400 GB/s입니다. DeepSeek의 분석에서 통신은 모델 설계를 마친 뒤 지불하는 부가 비용이 아닙니다. 전문가 병렬화, 통신 커널, 노드 배치, 하드웨어 토폴로지가 함께 모델 구조의 경제성을 정합니다[3]. DeepEP는 GPU 16~128장 구성에서 GPU당 40 GB/s가 넘는 대역폭을 보고하지만, 통신 처리를 위해 최대 20개의 스트리밍 멀티프로세서를 예약하기도 합니다. 연산량은 해당 연산을 깨우는 데이터를 제시간에 배치한 뒤에만 실제 처리량이 됩니다.
Huawei Cloud의 AITURBO는 스토리지 경계에서 같은 변화를 만듭니다. 한 지역 데이터센터에서 AI 작업이 클라우드 스토리지 대역폭의 10% 이상을 사용했습니다. AITURBO는 그룹 I/O API를 추가해 수천 개의 개별 파일 요청이 하나의 집합 연산임을 스토리지 계층에 알려줍니다. 중복 전송을 제거하고 호스트 DRAM을 임시 공간으로 쓰며, 연산 패브릭을 이용해 데이터를 여러 가속기로 전파합니다. 실제 학습 환경에서 체크포인트 쓰기는 SFSTURBO보다 3.9~58.8배, Gemini보다 최대 5.9배 빨랐습니다. 추론 통합에서는 Mooncake 대비 처리량이 최대 1.28배였고 실제 트레이스에서 첫 토큰 시간(TTFT)이 23% 줄었습니다[4].
이 최댓값들을 하나의 성능 순위로 합치면 안 됩니다. AITURBO는 대용량 전송을 대상으로 하며 XPU 64장에서는 조정 비용이 최대 45 ms였습니다. 작은 전송은 이득이 없을 수 있고, 학습 통신과 같은 연산 패브릭을 쓰므로 서비스 품질을 별도로 관리해야 합니다. 중요한 결과는 제어 인터페이스입니다. 평가한 Megatron 통합에서 코드 286줄을 추가해 애플리케이션은 작업 의도만 표현하고, 실제 그룹 이동 계획은 스토리지 시스템이 결정하도록 했습니다.
Strata는 장문맥 추론에 이 원칙을 적용합니다. 요청 하나의 KV 캐시가 GPU HBM, CPU 메모리, SSD에 흩어질 수 있습니다. 캐시 배치가 조각나면 큰 전송이 작은 I/O 여러 개로 바뀌고, 캐시 적재가 프리필을 막습니다. 데이터가 너무 늦게 도착한다면 캐시 적중 요청을 먼저 실행하는 결정도 틀릴 수 있습니다. Strata는 GPU 보조 I/O, 캐시 인식 스케줄링, 세 메모리 계층을 하나로 묶습니다. SGLang에 통합되어 실제 서비스에 배포됐으며, 평가에서는 vLLM-LMCache보다 최대 5배, TensorRT-LLM보다 최대 3.75배 높은 성능을 보였고 짧은 문맥 시험의 성능은 떨어뜨리지 않았습니다[5].
세 시스템은 데이터의 위치를 런타임 상태로 승격합니다. DeepSeek는 모델 실행에 토폴로지를 드러내고, AITURBO는 스토리지에 작업 그룹을 드러내며, Strata는 요청 스케줄러에 캐시 준비 상태를 드러냅니다. 더 빠른 장치를 설치하는 것만으로는 이 결과를 얻을 수 없습니다. 함께 소비할 데이터가 무엇인지, 지금 어디에 있는지, 언제까지 도착해야 하는지를 소프트웨어가 알아야 합니다.
스케줄러는 자원보다 작업 단계를 알아야 합니다
에이전트 애플리케이션에서는 스케줄링 단위가 모델 호출 하나보다 커집니다. Murakkab은 워크플로를 선언형 그래프로 표현해 작업 의존성과 특정 모델 및 하드웨어 배치를 분리합니다. 프로파일 기반 최적화기가 모델, 배치, 배치 위치를 선택하고, 적응형 런타임이 정확도, 지연시간, 에너지, 비용 목표를 지키면서 환경 변화에 대응합니다. 논문이 평가한 워크플로에서는 SLO를 지키면서 GPU 사용량이 최대 2.8배, 에너지가 최대 3.7배, 비용이 최대 4.3배 줄었습니다[6].
여기서 최대라는 조건이 중요합니다. 서로 다른 시험에서 나온 최댓값이며 모든 에이전트 서비스의 고정 할인율이 아닙니다. Murakkab이 효과를 내려면 선택 가능한 실행 경로, 대표성 있는 프로파일, 종단 간 SLO가 있어야 합니다. 그래도 구조적 의미는 분명합니다. 에이전트 워크플로가 불투명한 API 호출 묶음에서 벗어나면, 클라우드는 각 모델 엔드포인트를 따로 최적화하는 대신 전체 경로의 비용을 줄일 수 있습니다.
Alibaba의 Weave는 강화학습 후처리에서 작업 단계가 필요한 이유를 보여줍니다. 롤아웃은 대체로 메모리 병목이고, 학습은 연산 병목입니다. 두 작업을 완전히 분리한 클러스터는 온폴리시 의존성 때문에 빈 시간을 만들고, 같은 가속기에 함께 놓으면 단계 전환과 간섭 비용을 반복해서 지불합니다. Weave는 공동 실행 그룹을 만들고, 그룹 사이를 확률적으로 계획하며, 그룹 안의 작업을 순환 배치하고, 호스트 메모리에 준비된 상태를 남깁니다. H20 328장과 H800 328장을 사용한 산업계 규모 시험에서 표준 분리 방식보다 비용 효율이 1.84배, 동일 위치 기준선보다 1.38배였으며 시험한 SLO를 모두 지켰습니다[7].
Murakkab과 Weave는 GPU 수량만으로는 수요를 표현할 수 없다고 말합니다. 같은 애플리케이션 안에서도 정확도 민감도, 메모리 점유량, 연산 강도, 동기화 장벽이 다른 노드와 단계가 이어집니다. 요청 GPU 수만 보는 스케줄러는 실제로는 존재하지 않는 평균 자원 모양을 봅니다. 더 나은 스케줄러는 작업 순서를 보고 다음 전환에 필요한 준비 상태를 보존합니다.
플릿 이용률은 손실 원인별로 계산해야 합니다
Alibaba ASI의 트레이스는 할당과 실제 사용을 분리한다는 점에서 중요합니다. 6개월 동안 GPU 15만5,410장, 81개 부서, 여러 공급사와 세대, 개발·학습·온라인 추론·오프라인 추론을 관찰했습니다. 수요가 높아도 노드 단위 단편화, CPU 구성 불일치, 네트워크 지역성, 사용자가 남긴 여유분 때문에 GPU가 배정되지 못했습니다. GPU를 나누어 쓰는 경우 자체가 드물어 부분 GPU 단편화는 상대적으로 작았습니다. 재배치로 자원이 남는 노드 수를 20.2% 줄였고, SpotGPU는 할당률을 68%에서 93%로 높였습니다[8].
93%를 할당해도 모델이 실제로 전진했다는 뜻은 아닙니다. ByteDance의 안정성 논문은 그 다음 손실을 측정합니다. 3개월 동안 작업 77만8,135개를 관찰했으며 장애 4만4,184건과 재시작 9,582건이 포함됐습니다. GPU를 최대 9,600장 사용한 실제 작업에서 유효 학습 시간 비율(ETTR) 97%를 기록했고, 작업이 50분 넘게 전진하지 못한 구간은 없었습니다. GPU 1만6,384장 규모에서 핫 업데이트는 재대기보다 11.04배, 웜 스탠바이는 10.87배 빨랐습니다. 매 스텝 메모리 체크포인트가 작업을 막는 시간은 0.01~0.04초였고 보고한 시험에서는 모델 FLOPS 이용률이 99%를 넘었습니다[9].
이 시스템은 완벽한 진단보다 빠른 복구를 우선합니다. 빠른 감지는 최종 원인보다 많은 장치를 먼저 제외할 수 있고, 정밀 분석은 작업이 다시 움직인 뒤 백그라운드에서 계속합니다. 정상 GPU 수천 장이 동기화 장벽에서 기다리는 상황에서는 합리적인 선택입니다. 다만 성숙한 플릿, 작업과 같은 조건의 검증, 예비 자원, 복구 경로를 운영할 조직이 필요합니다. 작은 클러스터라면 같은 임곗값을 복제하기보다 감지, 복구, 원인 분석을 분리하는 원칙을 가져가야 합니다.
이 결과를 하나의 깔때기로 정리할 수 있습니다. 설치 용량은 실제 공급 가능한 전력과 냉각에서 줄어듭니다. 할당 가능 용량은 토폴로지와 메모리 조건에서 줄어듭니다. 배정된 용량은 대기열과 단편화에서 줄어듭니다. 실제 작업량은 빈 실행 구간, 지연 작업자, 복구 시간에서 다시 줄어듭니다. GPU를 더 사면 깔때기의 입구가 넓어집니다. 계층 간 런타임은 가장 좁은 구간을 넓힙니다.
논문 9편에서 얻은 다섯 가지 설계 원칙
첫째, 최적화 경계가 위로 올라갑니다. 가장 빠른 장치 설정이 클러스터에서는 손해일 수 있고, 캐시 적중도 데이터가 늦게 도착하면 좋은 선택이 아닙니다. 워크플로의 한 노드를 가장 싸게 실행해도 전체 그래프의 비용은 늘 수 있습니다. 측정 가능한 사업 목표까지 경계를 넓혀야 하며, 보통은 시설 제약과 SLO 안에서 완료한 작업량이 됩니다.
둘째, 여유 자원에는 종류가 있습니다. 전력 여유, 냉각 여유, 패브릭 대역폭, 빈 HBM, 호스트 메모리에 남은 상태, 대기열 사이의 빈 시간, 장애 복구용 예비분을 하나의 용량으로 더할 수 없습니다. 위치와 유효 시간이 다르고 조절하는 주체도 다릅니다. 스케줄러에는 평균값의 표가 아니라 시간 정보가 있는 자원 그래프가 필요합니다.
셋째, 텔레메트리는 실행할 조치와 짝을 이룰 때만 가치가 있습니다. 작업 단위 전력 조절이 없으면 배전 계측은 위험을 보고하는 데서 끝납니다. 캐시 적재 시간을 보는 스케줄러가 없으면 캐시 메타데이터는 명목 적중만 알려줍니다. 빠른 재시작 경로가 없으면 장애 분류는 손실 시간을 설명할 뿐입니다. 해당 신호가 제약이 다시 변하기 전에 어떤 안전한 결정을 바꿀 수 있는지를 물어야 합니다.
넷째, 준비된 상태 자체가 인프라입니다. Strata는 다시 쓸 캐시 블록을 남기고, Weave는 다음 단계의 상태를 호스트 메모리에 유지하며, ByteDance는 장애 뒤 모든 의존성을 다시 만드는 대신 교체 장비를 준비합니다. 중요한 자원이 순수 대역폭보다 연속성인 경우가 많습니다. 상태를 없애면 짧은 재배치가 플릿 전체의 수분짜리 대기로 바뀔 수 있습니다.
다섯째, 논문의 최댓값은 해당 조건에서만 유효한 증거입니다. 체크포인트 58.8배, 서빙 5배, 비용 4.3배, 복구 11.04배는 분모와 작업이 다릅니다. 순위를 매기거나 서로 곱하면 안 됩니다. 비교할 대상은 메커니즘, 시험한 동작 범위, 이득이 사라지는 조건입니다.
운영자가 다음으로 구축해야 할 것
먼저 계층을 연결해 유효 작업량을 계산해야 합니다. 주요 작업마다 시설 전력과 냉각 여유, 토폴로지 조건을 만족하는 용량, 메모리 계층별 대기 데이터, 대기열과 실행 단계, 실제 가속기 작업 시간, 복구 손실을 기록해야 합니다. 모든 백분율에는 분모를 붙여야 합니다. 할당률 93%와 유효 학습 시간 97%는 서로 다른 단계를 나타내므로 합치지 않아야 합니다.
다음으로 제어 수단 등록부를 만들어야 합니다. 텔레메트리마다 누가, 어느 범위에서, 얼마나 빠르게 행동할 수 있고, 실패하면 어떻게 되돌릴지를 적어야 합니다. 랙 제어기는 수초 안에 전력 상한을 바꿀 수 있습니다. 스케줄러는 아직 시작하지 않은 작업을 옮길 수 있지만 실행 중인 메모리 3.2 PB를 즉시 이동할 수는 없습니다. 서빙 런타임은 요청 순서를 바꿀 수 있지만 SSD 대역폭을 새로 만들지는 못합니다. 이 등록부가 있어야 대시보드가 실제 제어 평면으로 공급할 수 없는 용량을 약속하지 않습니다.
장비를 구매할 때는 부품뿐 아니라 API를 확인해야 합니다. 스토리지가 그룹 작업 의도를 받는지, 스케줄러가 캐시 상태를 보는지, 작업별로 전력 상한을 함께 조절할 수 있는지, 토폴로지와 장애 영역을 노출하는지, 복구 중 준비된 상태를 보존하는지를 물어야 합니다. 하드웨어를 산 뒤 소프트웨어가 묶인 용량을 되찾을 수 있는지는 이런 인터페이스에서 결정됩니다.
마지막으로 제약된 시설 시간당 완료한 작업량을 평가 지표로 삼아야 합니다. 그중에서도 지연시간이나 정확도 같은 SLO를 지킨 작업만 세어야 합니다. 분모에는 단기간에 늘릴 수 없는 MW, 냉각 가능한 랙 위치, 특정 가속기 섬처럼 가장 부족한 자원을 넣습니다. 이 지표는 순간적으로 빠르지만 요청을 놓치거나, 작업을 반복해서 재시작하거나, 토폴로지 뒤에 장비를 묶어 두는 시스템을 제대로 감점합니다. 최대 FLOPS는 여전히 부품의 속성을 설명하지만 AI 인프라라는 상품을 설명하지는 못합니다.
이 조사에서 제외된 것과 해석의 한계
이 조사는 2026년 8월 28일까지 공개된 1차 논문 가운데 산업계 운영 맥락이 분명한 연구에 집중했습니다. 산업계 배포 조건을 공개하지 않은 학술 시스템, 비공개 운영 시스템, 메커니즘이나 평가 조건이 충분하지 않은 발표는 제외했습니다. 2026년 논문 일부는 정식 프로시딩보다 학회 페이지나 프리프린트가 먼저 공개된 상태입니다. 하드웨어, 작업, 기준선, SLO가 다르므로 성능 향상 수치를 정규화하지 않았습니다.
산업계 평가는 각 회사의 플릿과 사업 조건도 반영합니다. 하이퍼스케일 사업자는 작은 운영자가 감당하기 어려운 전용 제어 평면의 비용을 큰 규모에서 나눌 수 있습니다. 반대로 공개 논문에는 총비용을 결정하는 운영 복잡도나 실패 사례가 빠질 수 있습니다. 따라서 논문 9편은 하나의 표준 구축 사양이 아니라 아키텍처가 이동하는 방향을 보여주는 증거로 읽어야 합니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 독립적인 편집 조사입니다. 9개 1차 자료의 사실과 결과를 우리 문장으로 다시 설명했으며, 원문의 문장·표·도판을 옮기지 않았습니다. 도판 3개와 카드 이미지는 모두 이 글을 위해 새로 만들었습니다. 원문 저작권은 각 저자와 출판사에 있습니다. 1차 자료는 Meta의 arXiv 기록, Prometheus의 IEEE 기록, DeepSeek-V3의 ACM 기록, AITURBO의 USENIX 페이지, Strata의 USENIX 페이지, Murakkab의 USENIX 페이지, Weave의 USENIX 페이지, Alibaba 플릿 연구의 USENIX 페이지, ByteDance 안정성 연구의 ACM 기록에서 확인할 수 있습니다.