들어가며: GPU는 항상 부족하다
AI 연구소 Ai2의 인프라 팀은 수천 장의 NVIDIA H100, B200, B300 GPU를 클러스터로 묶어 150여 명의 연구자에게 제공합니다. 문제는 단순합니다. 수요가 공급의 2~3배입니다. 모든 GPU 시간마다 2~3개의 워크로드가 경쟁하는 셈이죠.
기존에는 '우선순위 기반 스케줄러'를 썼습니다. HIGH 우선순위를 주면 선점(preemption)에서 보호받을 수 있었죠. 그런데 이 방식은 예측 가능한 병리 현상을 낳았습니다.
- GPU 스쿼팅(Squatting): 아무 일도 안 하는 워크로드를 띄워두고 필요할 때 접속
- 우선순위 인플레이션: 결국 100% 워크로드가 HIGH가 되어 하위 우선순위는 굶어 죽음
- 온콜 지옥: 유지보수가 필요한 호스트에서 선점 불가 워크로드를 내리기 위해 엔지니어가 직접 협상
이 글은 Ai2가 이 문제를 '스케줄링'이 아니라 '예산 배분' 문제로 재정의하고 해결한 과정을 다룹니다. 근거자료는 Hugging Face 블로그에서 확인할 수 있어요.
핵심 아이디어: 스케줄이 아니라 예산
해법의 출발은 '공유지의 비극'을 인정하는 것이었습니다. 팀에 GPU를 통째로 주는 독점 방식은 너무 거칠었어요. 연구 시즌이 팀마다 달라서, 한 팀에 몰아주면 다른 팀은 놀고 있는 GPU를 기다려야 했죠.
그래서 Ai2는 GPU 자체가 아니라 'GPU 시간'을 할당하기로 합니다. 관리자는 투자자처럼 행동합니다. 워크로드가 생기기 전에, 연구 과제별로 GPU 시간을 얼마나 펀딩할지 결정하는 거죠. 스케줄러는 그 정보를 가지고 도착하는 워크로드의 우선순위를 정합니다.
[전체 클러스터 용량]
│
┌────┴────┐
Program A Program B
│ │
┌─┴─┐ ┌─┴─┐
A1 A2 B1 B2
35% 25% 20% 20%
핵심 규칙은 단순합니다. 모든 GPU 요청은 예산으로 펀딩되어야 하며, 그렇지 않으면 선점에서 보호되지 않습니다. 예전에는 HIGH 우선순위가 공짜였기 때문에 다들 썼지만, 이제는 아무것도 공짜가 아닙니다. 스쿼팅 워크로드는 팀 예산을 낭비하는 행위가 되죠. 스케줄러를 속이는 것이 정직하게 예산을 요구하는 것보다 비싸지도록 설계한 겁니다.
구현 디테일: 계층적 공정 분배와 시간 분할
예산 도구와 함께 계층적 공정 분배(fair-share) 스케줄러를 붙였습니다. 알고리즘 자체는 새롭지 않습니다. 2009년 Hadoop Fair Scheduler로 거슬러 올라가고, 지금도 SLURM의 Fair Tree와 YARN의 Fair Scheduler가 같은 방식을 씁니다. 새로운 건 입력값이에요. 트리는 연구 프로그램 구조를 그대로 반영하고, 가중치는 정적 쿼터가 아니라 관리자가 정한 예산입니다.
스케줄러는 최근 7일(기본값)의 점유율을 추적하고, 과소 사용된 할당의 워크로드를 과다 사용된 할당보다 위로 정렬합니다. 주 단위로 보면, 수요가 충분한 팀은 할당받은 GPU 시간을 받게 됩니다.
여기에 **'스케줄링 계약'**을 추가했습니다. 워크로드는 클러스터 접근 대가로 **최소 실행 시간(minimum runtime)**을 선언해야 합니다. 이 시간 동안은 선점에서 보호됩니다. 연구자는 진행 보장을 받고, 스케줄러는 그 진행이 '적립'된 후 재분배할 권리를 얻죠. 재개 가능한 워크로드는 자동으로 재큐잉됩니다.
# 워크로드 제출 예시 (개념도)
workload:
name: llm-pretrain-run-42
gpus: 64
min_runtime: 8h # 이 시간까지는 선점 불가
resumable: true # 체크포인트에서 재개 가능
budget_owner: program-a/a1
이 계약이 만든 가장 큰 부수 효과는 유지보수 자동화였습니다. 상태가 나쁜 호스트는 워크로드가 최소 실행 시간에 도달하는 순간 자동으로 드레인됩니다. 사람이 개입해야 하는 수리가 74% 감소했습니다.
주의사항과 트레이드오프
공짜 점심은 없습니다. Ai2도 몇 가지 함정을 밟았어요.
- 학습 곡선이 예상보다 가팔랐습니다. 클러스터별로 순차 롤아웃하다 보니 초기에는 클러스터마다 동작이 달랐고, 인터페이스에 남은 옛 용어('workload priority' 등)가 혼란을 키웠습니다. 문서만으로는 부족했고, 실시간 설명 세션이 효과적이었습니다.
- 인터랙티브 세션은 오히려 나빠졌습니다. 데이터 분석이나 코드 작성용 세션은 예전엔 일주일도 유지됐지만, 이제 8시간 보호 한도를 넘으면 선점됩니다. 상태를 수동으로 복구해야 하는 고통이 컸죠. Ai2는 이를 해결하기 위해 CPU 전용 개발 클러스터와 복원 가능한 세션을 로드맵에 올렸습니다.
- 용량 파편화 가능성. 최소 실행 시간 보호가 과거 선점형으로 굴리던 잡에 적용되면서, 대형 워크로드가 들어갈 자리를 만들기 어려워질 수 있습니다. 현재 시뮬레이터로 재현 중입니다.
실무에서 이런 스케줄러를 도입한다면, 시뮬레이터를 먼저 만드세요. Ai2는 과거 제출 데이터와 가상 시나리오로 대기시간, 선점 이벤트, 프로젝트별 GPU 시간 분포를 몇 초 만에 분석했습니다. 시뮬레이션 예측(디버그 작업 p90 대기 6시간→5분)은 실제 결과(2시간→30초)보다 보수적이었지만 방향은 정확했습니다. 관련해서 AI가 생성한 코드, 그대로 배포하면 생기는 재앙과 Vercel의 해법처럼 배포 전 검증 문화에 대한 글도 함께 보시면 좋아요.
결론: 실무 적용을 위한 체크리스트
Ai2 사례의 본질은 '스케줄링 논쟁'을 '예산 논쟁'으로 옮긴 것입니다. 이 전환 덕분에 30일 테스트 기간 동안 팀들은 할당량의 98%를 실제로 받았고, 점유율은 98%로 유지됐으며, 디버그 작업 p90 대기시간은 2시간에서 30초로 떨어졌습니다.
국내 환경에 적용한다면 다음을 고려하세요.
- 예산 결정권자를 명확히 하세요. Ai2는 프로젝트 리드, PI, 프로그램 매니저, CEO로 계층을 나눴습니다. 국내 SI/연구 조직에서는 의사결정 라인이 흐릿해 예산제가 '또 하나의 정치'가 되기 쉽습니다.
- 인터랙티브 워크로드를 분리하세요. 학습 클러스터에서 노트북 세션을 돌리면 시간 분할 정책과 충돌합니다. CPU 개발 클러스터를 별도로 두는 게 안전합니다.
- 용어를 통일하세요. 옛 우선순위 개념을 남겨두면 사용자는 반드시 오해합니다.
다음 단계로는 Ai2가 지금 공략 중인 'utilization(활용률)' 계층을 살펴보세요. 부트스트래핑, 체크포인팅, 학습 애플리케이션 자체의 효율을 높이는 문제로, 스케줄링만큼이나 임팩트가 큽니다. 유사한 대규모 마이그레이션 사례로 스포티파이가 1,800개 파이프라인을 6개월 만에 옮긴 비결 Honk 에이전트와 Fleet Management 실전 사례도 참고해 보세요.
