Alibaba의 ASI 플랫폼은 사내 81개 부서에 GPU 15만5,410장을 제공한다. 이 정도면 파편화가 사라질 것 같지만, 6개월간의 실제 운영 trace는 반대를 보여준다[1]. 작업의 99% 이상이 특정 GPU 모델을 지정하고, 대규모 작업은 연속된 네트워크 위치를 요구하며, 호스트의 CPU core가 부족하면 비어 있는 GPU도 쓸 수 없다. GPU 8장과 CPU core 128개를 요청한 작업이 시작하지 못했을 때 대상 GPU의 유휴 비율은 최대 28%였다.
OSDI 2026 논문의 가치는 공유 fleet을 재고 목록이 아니라 운영체제로 설명하는 데 있다. 서로 다른 하드웨어, 높은 우선순위의 서비스, 심야 여유분, 애플리케이션 이식성이 모두 스케줄러 상태가 된다. Alibaba는 배치 복구, 네트워크 위치를 고려한 packing, 회수 가능한 작업, 장치별 소프트웨어 최적화를 결합한다. 높은 우선순위와 낮은 우선순위 작업을 합친 GPU 할당률은 68%에서 93%로 오른다. 두 숫자의 차이는 GPU를 더 산 결과가 아니다. 사용 가능하다는 말의 정의를 더 정확히 만든 결과다.
하나의 fleet에 들어 있는 서로 다른 모양
작업 구성은 과거 공개 trace[2][3]와 다르다. 온라인 추론이 54.6%, 오프라인 추론이 21.6%, 학습이 19.5%, 개발이 3.4%다. 생성형 AI는 학습의 71%와 오프라인 추론의 98%를 차지하지만, 온라인 추론에서는 추천 모델이 여전히 63%다. 작업 실행시간 중앙값은 5시간이다. 과거 Alibaba PAI trace의 23분, Microsoft Acme trace의 2분보다 길다. 잘못 놓은 배치가 오랫동안 남는 환경이다.
우선순위는 fleet을 두 시장으로 나눈다. 온라인 추론과 대부분의 학습은 우선순위가 높고, 오프라인 추론은 낮은 쪽을 채운다. 개발 작업도 엔지니어의 대기시간을 서비스 목표에 포함하므로 높은 우선순위를 받는다. 스케줄링 지연시간 중앙값은 1초지만 높은 우선순위 작업의 90백분위는 101초다. 작업 실행시간의 90백분위는 약 24시간이므로 작은 파편화도 배치 주변에 누적된다.
하드웨어가 다양하다고 애플리케이션이 유연해지는 것은 아니다. 서로 다른 GPU 모델을 한 작업에서 함께 쓰는 경우는 1% 미만이고, 99% 이상이 한 모델을 정확히 지정한다. fat-tree 네트워크는 모양 제약을 하나 더 만든다. access switch 하나가 GPU 8장짜리 노드 3264개, 즉 GPU 256512장을 연결한다. 같은 switch 아래에서 수행한 all-reduce는 switch 경계를 넘을 때보다 최대 27% 빠르다. 따라서 GPU 256장 요청은 비어 있는 아무 장치 256개로 채울 수 없다. 같은 모델, 충분한 CPU core, 가능하면 하나의 네트워크 구역을 요구한다.
서비스를 멈추지 않고 배치를 고친다
Alibaba의 in-place compaction(IPC)은 이미 실행 중인 allocation을 옮겨 파편화를 복구한다. 전역 정수계획법은 더 나은 배열을 찾을 수 있지만 이 규모에서 끝나지 않는다. 최적해 solver는 노드 25개에 5분, 100개에 이틀이 걸릴 수 있지만 실제 partition은 500개 노드를 포함한다. IPC는 클러스터를 나누고 깊이 3의 재귀식 ejection chain을 적용하며 최대 다섯 번 반복한다.
Ejection chain은 원하는 노드를 점유한 allocation을 옮기고, 그 이동 때문에 밀려난 allocation의 새 위치를 다시 찾는다. 새 container를 먼저 실행한 뒤 기존 container를 해제하는 make-before-break 방식이므로 높은 우선순위 서비스를 유지한다. 결정은 2분 안에 끝나며 일부만 점유된 노드를 20.2% 줄인다. 별도의 entropy 기반 배치 정책은 대규모 분산 작업을 더 적은 access-switch 구역에 모아 다음 요청을 위한 연속 공간을 보존한다.
이 복구 과정은 파편화의 원인이 바뀌었다는 점도 드러낸다. 과거 GPU 클러스터는 fractional sharing에 많은 관심을 썼지만 ASI trace에서는 영향이 미미하다. 생성형 작업이 GPU 전체를 소비하면서, 주요 손실은 일부만 점유된 노드의 남은 GPU, 부족한 CPU core, 네트워크 위치에서 생긴다. 스케줄링 정책도 과거의 병목이 아니라 현재 작업을 따라가야 한다.
남는 시간을 두 번 팔되, 첫 구매자를 지킨다
높은 우선순위 수요에는 뚜렷한 일간 주기가 있으며 자정 무렵에는 대기 상태 GPU가 최대 1만 GPU-hour에 이른다. Alibaba는 두 메커니즘으로 이 시간을 회수한다. 첫 번째는 온라인 추론 container를 따뜻한 상태로 유지하되 traffic을 분리하고 sleep 상태로 전환한다. 수요가 돌아오면 퇴거에 평균 13초, 95백분위 48초가 걸리고 강제 종료가 필요한 비율은 5% 미만이다. 낮은 우선순위 작업은 서비스를 처음부터 다시 띄우는 비용 없이 대기 GPU-hour의 90%를 사용한다.
SpotGPU는 일반적인 선점 작업을 처리한다. 가장 작거나 최근에 시작한 작업을 고르는 대신, GPU 수에 마지막 checkpoint 이후 시간을 곱해 잃을 계산량을 추정한다. 재계산 비용이 가장 낮은 작업에서 자원을 회수한다. 실제 운영 실험에서 높은 우선순위 성능은 유지하면서 낮은 우선순위 작업의 완료시간을 24% 줄였다. 두 우선순위 작업을 결합해 할당률이 68%에서 93%로 오른 배경이다.
이식성은 더 어려운 여유분 회수 수단이다. XPU-A로 표기한 대체 가속기는 특정 작업에서 H20보다 이론 성능이 높지만 초기 실제 성능은 H20의 80%에 불과했다. kernel과 framework 최적화로 처리량을 최대 43% 높이고 prefill kernel을 1.58배 개선하자, 이 장치에 대한 높은 우선순위 수요가 2.5배 늘었다. 이종 fleet은 하드웨어 선택지마다 소프트웨어 예산이 필요하다. 그렇지 않으면 스케줄러에는 용량이 보여도 애플리케이션은 그 장치를 요청하지 않는다.
활용률은 하나의 숫자가 아니다
남은 텔레메트리는 할당과 유효 연산을 같은 값으로 보면 안 된다고 경고한다. 온라인 추론의 streaming multiprocessor 활용률 중앙값은 6%, 메모리 사용률은 30%다. 생성형 추론은 메모리 사용률이 94%지만 SM은 5%이고, 기존 DNN은 각각 약 20%와 6%다. 서로 보완적으로 보이는 작업을 함께 놓을 수 있지만 성능 격리와 메모리 압력 때문에 단순한 백분율 덧셈으로 끝나지 않는다.
CPU 작업의 동시 배치는 더 잘 보이지 않는 간섭을 만든다. GPU 노드의 80%에서 CPU-only 작업이 CPU 사용량의 대부분을 차지한다. 이때 학습 SM 활용률은 중앙값에서 10%, 90백분위에서 18% 낮아진다. 스케줄러가 높은 GPU 할당률을 보고하는 동안 함께 놓은 CPU 작업이 완료한 학습 토큰을 줄일 수 있다.
논문은 전용 클러스터에서 수행하는 초대형 foundation model 사전학습을 명시적으로 제외한다. 따라서 모든 초대형 시스템에 결과를 그대로 적용해서는 안 된다. 대신 여러 세대의 가속기에서 추론, 개발, 학습이 경쟁하는 다중 tenant AI cloud의 넓은 중간 영역을 설명한다. 이 환경에서 남는 교훈은 장부의 구분이다. 물리적으로 비어 있음, 스케줄러가 배치할 수 있음, 실제 작업에 기여함은 서로 다른 값이다. 첫 번째 숫자만 판매하는 네오클라우드는 나머지 두 값을 queue에서 발견하게 된다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 요약이다. 아래 논문의 주장과 결과를 우리 표현으로 다시 썼다. 논문의 문장, 표, 도판은 옮기지 않았으며, 본문의 두 도판은 보고된 수치를 바탕으로 이 글을 위해 새로 만들었다. 원문은 OSDI 2026 회의록에서 공개돼 있다. 저작권 (c) 2026 원저자. 원문은 USENIX 논문 페이지에서 확인할 수 있다.