높은 활용도를 유지하면서 영향력 있는 연구를 우선시하는 클러스터 스케줄러 구축하기
Ai2의 AI Infrastructure 팀에서 우리는 연구소의 GPU 컴퓨팅 용량을 제공하는 일을 담당하고 있으며, 특히 대규모 분산 학습 워크로드를 목표로 하고 있습니다. 우리는 이 작업을 서로를 기반으로 쌓아 올리는 4가지 지표의 피라미드로 생각합니다.
그 기반은 가용성(availability)입니다. 즉, 하드웨어가 얼마나 자주 정상 상태이며 작업 준비가 되어 있는지를 나타냅니다. 그 위에는 점유율(occupancy)이 있습니다. 즉, 가용 시간 중 특정 워크로드에 할당된 비율입니다. 다음은 영향력(impact)입니다. 즉, 가장 가치 있는 워크로드가 자원을 받도록 선택되는 빈도입니다. 피라미드의 정점은 활용률(utilization)입니다. 즉, 워크로드의 수명 동안 사용된 GPU 용량의 비율입니다.
이 글은 스케줄링 결정의 영향력을 개선하는 것에 관한 내용입니다. 최근 우리는 우선순위 기반 스케줄러를 GPU 시간 예산, 계층적 fair-share 할당, 그리고 타임 슬라이싱 계약을 포함하는 시스템으로 교체했습니다. 그 결과, 각 연구 프로젝트가 얼마나 많은 GPU 시간을 받아야 하는지에 대한 논쟁을 사례별 운영 작업에서 투명한 행정적 예산 편성 절차로 전환했습니다.
과잉 커밋(Overcommitting)
Ai2에서 우리는 88개에서 1024개 규모의 클러스터에 배치된 수천 개의 NVIDIA H100, B200, B300 GPU를 관리합니다. 이 클러스터들은 AI 모델의 대규모 분산 학습을 위해 구축되었으며, LLM 및 VLM 학습의 전체 모델 흐름, 로봇공학 강화 학습(RL) 시뮬레이션, 과학적 에이전트 사용 사례를 위한 포스트 트레이닝을 포함하여 다양한 AI 분야를 다루는 약 150명의 내부 연구자 그룹에 서비스를 제공합니다.
다른 많은 연구소와 마찬가지로, 우리의 GPU 시간 수요는 공급을 훨씬 초과합니다. 제출된 워크로드를 기준으로, 어느 시점이든 우리는 가용 GPU 대비 2-3배에 달하는 미처리 요청을 보유하고 있습니다. 이를 생각하는 한 가지 방법은 클러스터의 가용 GPU 시간마다 2-3개의 서로 다른 연구 워크로드가 경쟁하고 있다는 것입니다.
역사적으로 우리는 우선순위 기반 스케줄러를 사용했으며, 워크로드가 선점(preemptability) 대상에서 제외되는 것을 허용했습니다. 각 팀은 선전으로부터 보호되는 워크로드가 사용할 수 있는 동시 GPU 수에 대한 제한이 있었습니다. 선점 가능한 워크로드는 유휴 GPU에서 그 제한을 초과할 수 있었습니다. 이 전략은 예측 가능한 병리 현상을 낳았습니다. 예를 들어, 우리는 GPU “점거(squatting)” 사례를 관찰했는데, 사용자들이 필요할 때 연결할 수 있는 no-op 워크로드를 미리 띄워두는 것이었습니다. 이는 연구자들이 실시간으로 문제를 해결하기에 충분히 낮은 지연 시간으로 디버깅 워크로드를 실행할 수 없다는 것을 발견했기 때문에 발생했습니다. 또한 우선순위 인플레이션도 관찰했는데, 결국 스케줄된 워크로드의 100%가 HIGH 우선순위를 사용하게 되었습니다. 이는 더 낮은 우선순위 수준이 GPU 시간을 전혀 배정받지 못한다는 것을 의미했습니다. 선emptability가 선택 사항이었기 때문에, 당직 엔지니어들이 티켓 대응 시간의 대부분을 알려진 유지보수 문제가 있는 호스트에서 실행 중인 비선점 워크로드의 질서 있는 종료를 협상하는 데 소비한다는 것도 발견했습니다.
공유지의 비극
이러한 문제들이 나타났을 때, 우리는 그 근본 원인을 파악하는 데 더뎠습니다. 가장 중요한 작업이 GPU 시간을 받도록 보장하려는 우리의 초기 시도는 우선순위가 설정되는 방식을 더 엄격하게 통제하는 것, 그리고 궁극적으로 중요한 프로젝트에 GPU 독점권을 명시적으로 할당함으로써 우선순위 기반 스케줄러를 우회하는 데 집중되어 있었습니다. 처음에는 인식하지 못했지만, 우리는 “공유지의 비극”을 관찰하기 위한 완벽한 실험실을 만들었던 것입니다. 개인들이 희소한 공유 자원을 두고 경쟁하면서, 개인의 결과를 극대화하려 함으로써 전 세계적으로 최적이 아닌 결과를 달성하고 근본 자원을 남용하고 있었습니다.
이런 상호작용을 관찰한 것은 우리가 처음이 아니었습니다. 자원 할당은 알고리즘 개발, 경제학, 시스템 관리가 혼합된 매력적인 연구 분야입니다. 핵심 문제는 사용자들이 자신의 작업의 가치를 조직보다 잘 알고 있는 경우가 많지만, 그 가치를 숨기거나 전체 성능에 해가 되는 경우에도 자원을 붙잡고 있을 유인이 있을 수 있다는 점입니다. 예를 들어, 2011년 논문에서 Dominant Resource Fairness를 소개하며 Ghodsi 등은 검색 회사가 사용자가 높은 활용률을 보장할 수 있는 경우에만 작업에 전용 머신을 제공했다는 일화를 이야기합니다. 그들은 곧 “사용자들이 활용률 수준을 인위적으로 부풀리기 위해 코드에 무한 루프를 심었다”는 것을 발견했습니다. 하드웨어는 바뀌지만, 자원 할당을 복잡하게 만드는 근본적인 문제는 지속됩니다.
스케줄이 아닌 예산
공유지의 비극에 대한 고전적인 해결책은 공유 자원을 사유화하는 것입니다. 즉, 소유자는 자신의 재산의 가치를 극대화할 유인을 갖게 됩니다. 우리가 팀들에게 GPU 집합에 대한 독점권을 할당했을 때, 우리는 이미 이것의 한 형태를 하고 있었지만 너무 대략적이었습니다. 이는 연구의 계절성으로 인해 GPU가 유휴 상태로 놓이게 만들었습니다. 팀들은 서로 다른 시기에 실험과 학습을 실행할 준비가 되므로, 독점권을 할당하면 실행할 준비가 된 작업이 없는 시기가 발생하고 다른 팀은 용량을 기다리게 된다는 것을 보장하게 됩니다.
우리는 수동으로 배낭 문제를 풀고 있었고, 동적으로 변하는 연구 수요를 정적인 일정에 맞추려고 애쓰고 있었습니다. 우리는 소유권 인센티브를 원했지만, 동시에 GPU의 완전한 사용률도 유지하고 싶었습니다.
우리는 소유권 모델을 개선하기로 결정했습니다. 팀에 GPU를 지급하는 대신, GPU 시간의 일부를 할당하는 방식을 택했습니다. 미래의 수요를 예측하려면 새로운 과학 실험의 결과를 알아야 하므로 정밀하게 예측할 수 없습니다. 그러나 연구 노력 간의 우선순위는 전략의 문제이며, 사전에 더 쉽게 논의하고 결정할 수 있습니다. 스케줄링 퍼즐을 푸는 대신, 우리는 리더십이 투자자처럼 생각할 수 있게 했습니다. 워크로드가 존재하기 전에, 각 연구 노력의 예상 영향력에 대한 판단을 바탕으로 GPU 시간으로 각 연구 노력에 자금을 지원할지 결정하는 것입니다. 그러면 스케줄러는 도착하는 워크로드의 우선순위를 정할 때 그 정보를 사용할 수 있습니다.
이를 바탕으로 우리는 관리자가 자신이 담당하는 프로젝트와 연구자들에게 GPU 시간을 비례적으로 할당할 수 있는 계층적 시스템을 고안했습니다. 아래 다이어그램에서 보듯이, 이는 프로그램 전략을 보장된 GPU 시간 점유율로 직접 변환합니다. Project A1은 다른 곳에서 몇 개의 프로젝트가 대기하고 있든 상관없이 전체 용량의 35%에 대한 권리가 있음을 알고 있습니다.
괄호 안의 값은 리프 프로젝트에 할당된 전체 클러스터 용량을 나타냅니다.
이 시스템에서 GPU 시간에 대한 모든 요청은 예산으로 뒷받침되어야 하며, 그렇지 않으면 선점으로부터 보호받지 못합니다. 이전 시스템에서는 HIGH 우선순위에 비용이 없었고 선점 불가능성 때문에 팀이 동시 GPU 한도를 무한정 채울 수 있었기 때문에 모두가 이를 사용했습니다. 이제는 무료인 것이 없으므로, GPU 시간을 얻기 위한 어떤 트릭도 그 혜택을 받는 사용자의 할당량에서 차감됩니다. 자리를 차지하고 있는 워크로드는 아무것도 아닌 것에 팀 예산을 소비하고 있는 것입니다. 우리의 전략은 스케줄러를 속이는 것이 더 큰 예산을 놓고 정직하게 논쟁하는 것보다 더 비싸지도록 만드는 것입니다. 우리는 이 예산 검토 프로세스를 끊임없이 개선하고 있지만, 핵심 요건은 연구자들이 필요한 시간을 주장할 수 있는 잦은 기회가 있어야 하고, 결정은 해당 트레이드오프에 대해 가장 많은 맥락을 가진 관리자가 내려야 한다는 것입니다. 즉, 연구 프로젝트 내의 할당 결정은 리드 연구원이, 연구 프로그램 내에서는 수석 연구원(principal investigator)이, 프로그램 간에는 리드 프로그램 매니저 또는 CEO가 내립니다.
공정 몫(Fair-share)
이 GPU 시간 예산 도구와 함께, 우리는 프로그램 트리 전반에서 할당의 실제 사용률을 관리하기 위한 계층적 공정 몫(fair-share) 스케줄러를 구축했습니다. 여기서의 알고리즘은 새로운 것이 아닙니다. 시간 창에 대한 계층적 공정 몫은 2009년의 Hadoop Fair Scheduler로 거슬러 올라가는 계보의 일부이며, 동일한 접근 방식이 오늘날 SLURM의 Fair Tree 와 YARN의 Fair Scheduler에서도 활발히 사용되고 있습니다. 우리에게 새로운 것은 입력값입니다. 트리가 연구 프로그램 구조를 반영하고, 가중치가 정적 할당량이 아니라 관리자가 설정한 예산이라는 점입니다.
스케줄러는 슬라이딩 룩백 창(기본값은 7일)에 걸쳐 사용률을 추적하고, 과소 사용된 할당의 워크로드를 과다 사용된 할당의 워크로드보다 위에 정렬합니다. 이렇게 하면 일주일의 시간 범위에서, 모든 그룹이 충분한 수요를 가진 워크로드를 지속적으로 제출하는 한 자신에게 할당된 GPU 시간을 받을 것으로 기대할 수 있습니다.
“새 스케줄러 덕분에 마치 30%의 추가 컴퓨트가 있는 것 같습니다. 이전 스케줄러에서는 슬롯 한도를 다 쓰지 않는 순간이 있으면 그 컴퓨트는 사실상 사라졌습니다. 이제 새 스케줄러에서는 그런 일이 발생하면 나중에 할당 한도를 넘어 버스트할 수 있고, 여전히 작업이 빠르게 예약되고 선점 없이 실행되어 사실상 그 컴퓨트를 되찾을 수 있습니다. 우리의 워크로드는 종종 버스트 형태이기 때문에, 이를 통해 상당한 양의 컴퓨트를 되찾았습니다.” — Chris Clark
스케줄러는 두 종류의 사용률을 구분합니다. 할당된 사용률(allocated occupancy) 은 워크로드가 예산에 청구되는 시간입니다. 이는 워크로드 소유자의 할당량에서 차감되며 공정 몫 예산 계산에 영향을 미치고, 이러한 워크로드는 최소 실행 시간 창 동안 선점으로부터 보호됩니다. 할당되지 않은 사용률(unallocated occupancy) 은 어떤 예산에도 청구되지 않고, 처음부터 보호되지 않으며, 할당된 요청에 의해 선점될 수 있습니다. 이를 통해 할당이 수요와 제대로 일치하지 않을 때도 GPU를 완전히 사용 상태로 유지할 수 있고, 팀이 무료 GPU 사이클을 거절하는 일을 방지할 수 있습니다.
스케줄링 계약
공정한 자원 할당을 어렵게 만드는 분산 학습의 또 다른 특성은 워크로드가 매우 오랫동안 실행될 수 있다는 점입니다. 학습 작업은 정기적으로 수 시간, 수일, 때로는 수 주 동안 실행됩니다. 일단 예약되면 워크로드는 일주일 이상 자신에게 할당된 GPU에 남아 있을 수 있으며, 다른 사람들이 예산화된 시간을 받을 기회를 제공하지 않습니다. GPU를 무단 점유하는 일이 가능했던 것은 바로 이 시스템 특성 때문입니다. 또한 이 때문에 온콜 엔지니어들이 진행 중인 유지보수 문제를 해결하기 위해 장기 실행 작업의 소유자와 협상해야 했습니다.
이러한 문제들을 해결하기 위해 우리는 “스케줄링 계약”을 도입했습니다. 클러스터 접근 권한을 받는 대가로, 워크로드는 자신의 최소 실행 시간, 즉 의미 있는 진전을 이루기 위해 필요한 최단 점유 시간을 선언해야 합니다. 이 시간 동안 워크로드는 선점으로부터 보호됩니다. 이를 통해 연구자에게는 진전에 대한 보장을 제공하는 동시에, 스케줄러에는 그 진전이 확보된 이후 재조정할 권리를 부여하여 재개 가능한 워크로드를 자동으로 다시 대기열에 넣습니다. 또는 사용자가 최소 실행 시간을 0으로 설정할 수 있는데, 이는 GPU 시간이 할당 해제되어야 함을 의미합니다. 이러한 워크로드는 항상 선점 대상이지만, 어떤 예산에도 청구되지 않는다는 점에서 무료입니다.
워크로드 수명 주기는 다음 패턴을 따릅니다:
- 워크로드가 최소 실행 시간과 함께 제출되며, 재개 가능 여부를 표시합니다.
- 워크로드는 공정 몫(fair-share) 알고리즘에 따라 스케줄링되며, 되돌아보기(lookback) 기간 동안의 실제 점유 시간 대비 할당 시간의 비율로 가중치가 적용됩니다.
- 워크로드는 최소 실행 시간 동안 실행되며, 이 시간은 해당 할당에 청구됩니다.
- 연관된 할당이 다른 워크로드보다 계속 우선순위를 부여하는 한, 워크로드는 계속 실행될 수 있습니다. 이 시간 역시 해당 할당에 청구됩니다.
- 워크로드는 선점되어 재대기열에 들어갈 수 있으며, 이 경우 2단계로 돌아갑니다.
- 워크로드가 완료되어 모든 자원에 대한 점유를 해제합니다.
이러한 합의들은 우리 스케줄러에 시간 분할(time-slicing)을 추가합니다. 실행 중인 워크로드가 자동으로 제거되고 재대기열에 들어갈 수 있어, 공정 몫의 수렴이 가능해지고 자리 점유(squatting)에 대한 유인이 감소합니다. 또한 비정상 호스트들이 워크로드가 최소 실행 시간에 도달하면 이를 배출할 수 있어, 수리 작업을 완전히 자동화할 수 있습니다. 이 마지막 사항은 이 작업을 계획할 때 우리가 생각했던 것보다 더 중요했습니다. 사람의 개입이 필요한 수리를 74% 줄였고, 이는 온콜 부담의 엄청난 절감이었습니다.
시뮬레이션
우리는 스케줄링 정책 변경이 의도치 않은 결과를 초래할 수 있음을 알고 있었습니다. 이 문제의 제로섬적 성격 때문에 한 연구자에게 시간을 주는 것은 다른 연구자로부터 빼앗는 것을 의미합니다. 이 교환에서 손해를 본 사용자들은 새로운 우회 방법을 찾으려는 경향이 있습니다. 예산 기반 시스템을 롤아웃하기 전에, 우리는 더 긴 대기 시간이 어디서 발생할 수 있는지 예측하고, 되돌아보기 기간의 길이나 최소 실행 시간으로 허용할 최대값(우리는 8시간을 선택했습니다)과 같은 구성 설정을 테스트할 빠른 방법을 원했습니다.
우리는 일련의 워크로드와 그 제출 일정을 입력으로 받아 스케줄러가 선점 및 GPU 할당 결정을 내릴 수 있게 하는 작은 시뮬레이션 환경을 구축했습니다. 각 워크로드가 요청한 GPU 수와 총 실행 시간에 대한 정보를 바탕으로, 시뮬레이터는 스케줄링 가능한 시점으로 앞서 건너뛰어, 몇 초 만에 수일치의 시뮬레이션에 대해 대기열 대기 시간, 선전 이벤트, 프로젝트 간 GPU 시간 분포에 대한 분석을 제공할 수 있었습니다. 우리는 과거 제출 데이터와 더 잘 이해하고 싶었던 가상 시나리오 모두에 대해 시뮬레이터를 실행했습니다.
우리가 테스트하고 싶었던 한 가지 가설은 “디버그 워크로드”와 관련이 있었습니다. 이러한 작업들은 소수의 GPU와 15분 이하의 최소 실행 시간을 필요로 하는데, 이는 사용자가 작업이 성공적으로 시작되는지, 아니면 버그나 설정 오류로 인해 초기에 충돌하는지 확인하기에 충분한 시간입니다. 우리는 이러한 작업들이 더 큰 학습 워크로드보다 대기열 대기 시간이 짧아지는지 알고 싶었습니다. 큰 학습 워크로드는 의미 있는 진전을 위해 많은 GPU와 수시간의 실행 시간이 필요한 경우가 많습니다. 직관적으로, 이러한 작은 작업들은 대기열 상단으로 올라가야 합니다. 작은 작업은 큰 작업보다 더 많은 곳에 들어갈 수 있기 때문입니다. 하지만 정확한 대기열 지연 시간이 중요했습니다. 1~2분의 짧은 대기는 새로운 개발 관행을 가능하게 하지만, 10분의 대기는 실행 불가능해집니다.
우리의 시뮬레이션은 수작업으로 만든 테스트 케이스 데이터를 필요로 했는데, 과거 기록에는 이러한 디버그 유사 워크로드가 충분한 양만큼 포함되어 있지 않았기 때문입니다. 결과는 가설을 뒷받침했으며, p90 디버그 워크로드 대기 시간이 약 6시간에서 단 5분으로 감소했음을 보여주었습니다.
기존 스케줄러(왼쪽)와 새로운 “할당(allocation)” 스케줄러(오른쪽)의 축소 규모 시뮬레이터 시각화. 각 행은 하나의 GPU이고, 각 막대는 하나의 작업이며, 팀별로 하나의 색조로 상위 워크로드에 따라 색칠되었습니다; 해칭은 작업이 중단 가능한 시간을 표시하고, 빨간 테두리는 선점을 표시합니다. 기존 방식에서는 긴 긴급 작업이 절대 중단되지 않으며, 낮은 우선순위 수준의 작업에서 더 적은 선점이 발생합니다. 새로운 스케줄러는 각 GPU에서 더 다양한 색상 조합을 보여주며, 팀 간 점유 순환을 나타냅니다.
결과
시뮬레이션 결과를 바탕으로, 우리는 7월 말에 클러스터 단위 롤아웃을 시작했습니다. 우리가 중요하게 여기는 결과는, 우리가 지원하기로 선택한 워크로드가 그 시간을 받았는지, 새로운 시스템이 완전한 점유율을 유지했는지, 그리고 연구자들이 스케줄러를 이해하여 정보에 기반한 결정을 내릴 수 있었는지 여부입니다.
롤아웃 이후, 사용자와 팀들이 꾸준히 자신에게 할당된 GPU 시간을 받고 있음을 확인했습니다. 우리는 팀에 지급되어야 할 시간을 시간별로 실제 수요 상한으로 제한된 할당량으로 계산합니다. 30일간의 테스트 기간 동안, 팀들은 자신들이 받아야 할 GPU 시간의 98%를 지급받았으며, 15개 팀 할당 중 13개가 95% 이상을 받았고 최악의 경우도 90%를 받았습니다. 클러스터의 점유율은 변경 전후 모두 98%로 안정적으로 유지되었으며, 두 기간 모두 수요가 용량을 2-3배 초과했습니다. 지급된 GPU 시간의 18%는 미할당 상태였으며, 이것이 지원된 사용 사례가 실행 준비가 되지 않은 기간 동안 높은 점유율을 유지한 방식입니다.
시뮬레이터 결과는 실제 결과가 예측을 상회하는 방향으로 정확성을 보여주었습니다. 새 스케줄러 하에서 디버그 워크로드의 p90 큐 대기 시간은 2시간에서 30초로 감소했으며, 이는 수작업으로 제작한 테스트 시나리오 기반의 시뮬레이션 예측치인 6시간에서 5분으로 감소한다는 예측과 비교된 것입니다. 기준선에서 디버그 워크로드의 표본 크기가 작아 해당 측정값의 분산이 더 높았다는 점은 주목할 만합니다. 전반적으로 큐 지연 시간은 타임 슬라이싱의 부수 효과로 개선되었습니다: 가장 큰 H100 클러스터에서 중앙값 큐 대기 시간은 5분에서 24초로 감소했고, p90 대기 시간은 약 3분의 1(2.8시간에서 1.8시간으로) 감소했습니다.
우리가 해결하고자 했던 세 가지 문제와 비교해 보면:
스쿼트: 짧은 디버그 워크로드는 1분 이내에 시작되어 무단 선점(squatting)의 가치를 떨어뜨립니다. 이러한 행동의 비용은 선점자의 예산에 청구되어, 정말로 필요할 때 시간을 받지 못하게 합니다.
우선순위 인플레이션: 우리는 여전히 워크로드가 우선순위를 선언하는 것을 허용하지만, 이는 팀 내 정렬에만 영향을 미칩니다. 관리자들은 예산 사용을 최적화하기 위해 그룹 전체의 우선순위를 모니터링하도록 유도됩니다.
상시 대기 업무(toil): 비정상 호스트는 워크로드가 최소 런타임에 도달하면 자동으로 드레인됩니다. 사람의 개입이 필요한 수리는 74% 감소했습니다.
도전 과제
학습 곡선은 우리가 예상했던 것보다 가팔랐습니다. 우리는 변경 사항을 점진적으로 배포했기 때문에 초기에는 연구자들이 어느 클러스터를 대상으로 하는지에 따라 다양한 동작을 경험했습니다. 게다가 우리의 인터페이스에는 의미가 변한 일부 오래된 용어(예: workload priority)가 그대로 남아 있었습니다. 문서화만으로는 혼란이 해소되지 않았습니다. What 했다 업무는 실시간 설명 세션을 진행하는 것이었고, 연구자들이 질문을 하고 엔지니어링 팀이 실제 사례를 통해 스케줄러가 우선순위 결정을 어떻게 그리고 왜 내렸는지에 대해 더 깊은 설명을 제공할 수 있는 포럼을 마련했습니다.
이것은 중요한 순간이었는데, 초기의 좌절과 비공식적 추측의 시기에서 실험 그룹들이 자신들의 GPU 필요 사항에 대해 더 자주 그리고 더 폭넓게 소통하는 현재의 방식으로의 전환을 표시했기 때문입니다. 이제 연구자들은 새로운 요청을 수용하기 위해 어떤 절충이 이루어지는지 더 명확히 알면서 예산 논의에 참여하고 있습니다.
대면 세션 외에도, 출시 후 새로운 시각화 기능을 도입하여 사용자가 자신에게 할당된 GPU 시간이 예상 할당량과 얼마나 일치하는지 더 잘 파악하고, 워크로드 대기열 정렬에 사용되는 지표를 직접 확인할 수 있도록 했습니다. 이를 통해 워크로드가 선점되었을 때 그 이유를 이해할 수 있는 간단한 확인 장소가 제공되었습니다. 이러한 시각화 기능은 관리하는 여러 프로젝트에서 GPU 시간이 어떻게 사용되고 있는지 확인할 수 있는 예산 소유자들에게도 도움이 되었습니다.
시간에 따른 할당 사용량 예시 시각화.
모든 사용 사례가 개선된 것은 아니었습니다. 분산 학습 외에도, 우리 연구자들은 대화형 세션을 시작하여 데이터 분석을 수행하고 학습 코드를 작성하면서 동시에 테스트합니다. 기존 시스템에서는 연구자가 이러한 세션을 최대 1주일까지 유지할 수 있었습니다. 타임 슬라이싱을 도입한 후에는 보호 런타임에 대한 8시간 상한의 적용을 받게 되었으며, 그 이후에는 세션이 할당량을 초과할 경우 선점 가능한 상태가 됩니다. 우리는 연구자들이 이러한 세션의 휘발성 상태에 얼마나 의존하고 있는지 그 정도를 미처 인식하지 못했습니다. 선점된다는 것은 새로운 세션을 확보할 때까지 기다려야 함을 의미했고, 동시에 상태를 수작업으로 다시 구축해야 했습니다. 연구자들을 대상으로 설문 조사를 실시하여 이 문제의 폭을 파악한 후, 우리는 로드맵에 두 가지 새로운 프로젝트를 만들었습니다. 우리는 데이터 준비 작업에 중점을 둔 개발 세션을 위해 온프레미스 스토리지 옆에 CPU 전용 클러스터에 투자하고 있습니다. 이를 통해 진정으로 필요한 워크로드를 위해 학습 클러스터 용량을 보존할 수 있습니다. 또한 이러한 CPU 전용 워크로드를 위한 복원 가능한 세션을 구축할 계획입니다. 이를 통해 유지 보수나 타임 슬라이싱을 위해 최소 런타임이 끝난 시점에 워크로드를 계속 선점하면서도, 연구자가 세션을 다시 구축하지 않고도 다른 곳에서 세션을 복원할 수 있게 됩니다. 우리는 이 새로운 시스템의 운영 및 스케줄링상의 이점을 유지하는 동시에 사용자 경험도 개선할 수 있습니다.
우리는 새로운 문제를 계속 주시하고 있습니다. 현재 조사 중인 잠재적 문제 중 하나는 용량 파편화(capacity fragmentation)로, 이로 인해 가장 큰 규모의 워크로드에서 대기 시간이 늘어날 수 있습니다. 우리의 추측으로는 최소 실행 시간 보호가 이전에 이에 의존하던 유형의 작업에 적용되고 있다는 것입니다. 선점형 팀의 동시 GPU 한도를 초과하는 메커니즘. 이전에는 그러한 작업이 언제든 중단될 수 있어 시간이 낭비될 수 있었지만, 대규모 작업을 예약하기는 더 쉬웠습니다. 이제 스케줄러는 대기 중인 대규모 작업을 배치하기 위해 여러 작업을 한 번에 중단할 기회가 줄어들 수 있습니다. 우리는 현재 시뮬레이터 도구를 사용해 이 문제를 재현하는 동시에 프로덕션 환경에서의 실제 상태(ground truth)도 측정하고 있습니다.
미래
여기서 설명한 스케줄링 작업을 넘어 바라볼 때, 우리는 피라미드의 정점인 활용도(utilization)를 목표로 하고 있습니다. 부트스트래핑, 체크포인팅, 그리고 학습 애플리케이션 자체가 모두 최대한 효율적으로 수행되도록 하여, 각 워크로드가 배정받은 시간의 가치를 극대화해야 합니다.
이러한 도전 과제를 연구자들과 긴밀히 협력하며 해결하고 싶으시다면, Ai2의 공개 엔지니어링 직무를 탐색해 보시기를 권장합니다.