논문 링크

Q : 이 논문을 아주 자세하게 읽고 논문의 강점과 독창적인 지점을 설명해주고 핵심 알고리즘을 예시 입력을 들어서 전체적인 과정을 설명해줘 추가적으로 논문의 한계점에 대해서도 알려줘

Rubick 논문 상세 분석: 강점, 핵심 알고리즘, 그리고 한계점

제공된 논문 “RUBICK: EXPLOITING JOB RECONFIGURABILITY FOR DEEP LEARNING CLUSTER SCHEDULING"에 대한 심층 분석 결과는 다음과 같습니다.

1. 논문의 강점과 독창적인 지점

Rubick 논문의 가장 큰 강점이자 독창성은 딥러닝 작업(Job)의 ‘재구성 가능성(Reconfigurability)‘을 클러스터 스케줄링의 핵심 요소로 통합한 최초의 시스템이라는 점입니다. 기존 시스템들이 딥러닝 작업을 정적인 리소스를 요구하는 ‘블랙박스’로 취급한 반면, Rubick은 작업의 내부 실행 계획을 능동적으로 변경하며 클러스터 자원과 동적으로 상호작용하는 ‘화이트박스’ 접근법을 제시합니다.

주요 강점과 독창적인 지점은 다음과 같습니다.

• [cite_start]실행 계획과 자원 할당의 공동 최적화 (Co-optimization) [cite: 6][cite_start]: 기존에는 사용자가 모델의 병렬 처리 전략(실행 계획)을 고정하고, 스케줄러는 그에 맞춰 자원을 할당했습니다. [cite: 3] [cite_start]이는 클러스터의 실시간 자원 상황과 맞지 않아 비효율을 초래했습니다. [cite: 4] [cite_start]Rubick은 특정 작업에 가장 효율적인 실행 계획(예: TP, DP, ZeRO 등)과 그에 맞는 최적의 다차원 자원(GPU, CPU, 메모리 등)을 동시에 찾아 함께 최적화합니다. [cite: 6] [cite_start]이는 특정 자원 상황에서 최상의 성능을 낼 수 있는 조합을 동적으로 찾아내는 것을 의미합니다. [cite: 36]

• [cite_start]성능 보장(SLO)의 혁신적인 재정의[cite: 138]: 전통적인 스케줄러는 사용자가 요청한 ‘자원의 양’(예: GPU 8개)을 보장하는 것을 목표로 합니다. [cite_start]반면 Rubick은 ‘자원의 양’이 아닌 **‘사용자가 원래 계획으로 얻었을 성능’**을 보장하는 것을 목표로 합니다. [cite: 138] [cite_start]예를 들어, 사용자가 비효율적인 계획으로 GPU 8개를 요청했더라도, Rubick이 더 효율적인 계획을 찾아 GPU 4개만으로도 동일하거나 더 나은 성능을 낼 수 있다면 이를 할당합니다. [cite: 139] [cite_start]이렇게 절약된 자원은 다른 작업을 위해 사용되어 클러스터 전체의 처리량을 극대화합니다. [cite: 140]

• [cite_start]자원 민감도 곡선(Resource Sensitivity Curve)을 통한 효율적인 의사결정 [cite: 179][cite_start]: 수많은 (모델, 실행 계획, 자원) 조합의 성능을 일일이 예측하는 것은 거의 불가능합니다. [cite: 111] Rubick은 ‘자원 민감도 곡선’이라는 독창적인 개념을 도입하여 이 문제를 해결합니다. [cite_start]이 곡선은 특정 작업에 대해 각 자원(주로 GPU)의 양에 따라 달성할 수 있는 최고의 성능(가장 효율적인 실행 계획을 선택했을 때의 성능)을 미리 그려놓은 것입니다. [cite: 182, 183] [cite_start]스케줄러는 이 곡선의 기울기를 통해 어떤 작업이 자원을 추가로 할당받았을 때 가장 큰 성능 향상을 보이는지(자원 민감도가 높은지)를 빠르고 직관적으로 판단하여 최적의 할당 결정을 내릴 수 있습니다. [cite: 186, 187]

• [cite_start]포괄적인 성능 모델과 다양한 전략 지원: Rubick의 성능 모델은 단순히 데이터 병렬성(DP)뿐만 아니라 3D 병렬성(TP, PP, DP), ZeRO, Gradient Checkpointing(GC), Gradient Accumulation(GA) 등 현대의 대규모 모델 학습에 사용되는 거의 모든 핵심 전략을 지원합니다. [cite: 119] [cite_start]또한 GPU뿐만 아니라 CPU, 메모리, NVLink, PCIe 대역폭 등 다차원적인 자원의 영향을 모두 모델링하여 예측의 정확도를 높였습니다. [cite: 151, 152]

2. 핵심 알고리즘 (Algorithm 1) 설명 및 예시

Rubick 스케줄링 정책의 핵심 목표는 보장(guaranteed) 작업의 성능 SLO를 만족시키면서 클러스터 전체의 처리량을 극대화하는 것입니다. [cite_start]이를 위해 자원 민감도가 낮은 작업의 자원을 회수(shrink)하여 민감도가 높은 작업에 재할당하는 영리한 전략을 사용합니다. [cite: 208, 209, 211]

예시 시나리오: [cite_start]논문의 Figure 8을 바탕으로 가상의 시나리오를 구성해 보겠습니다. [cite: 268, 270, 272]

• 클러스터 상태: 총 4개의 GPU 사용 가능.
• Job 1 (실행 중): RoBERTa 모델. 2개의 GPU를 할당받아 실행 중. 자원 민감도 곡선을 확인하니, GPU를 추가해도 성능 향상이 크지 않음 (기울기가 완만함).
• Job 2 (새로 도착): T5 모델. ‘최선형(best-effort)’ 작업으로 큐에 도착. 자원 민감도 곡선을 확인하니, GPU가 많을수록 성능이 급격히 향상됨 (기울기가 가파름).

Rubick 스케줄러의 단계별 동작 과정 (Algorithm 1 기반):

1. 새로운 작업(Job 2) 도착 및 스케줄링 시도 (line 4-5): [cite_start]스케줄러는 Job 2를 스케줄링하기 위해 클러스터의 가용 자원을 찾습니다. [cite: 202] 현재 Job 1이 2개를 쓰고 있어 2개의 GPU가 남아있습니다.

2. 자원 추가 확보를 위한 ‘Shrink’ 고려 (line 8-17): 스케줄러는 단순히 남은 2개의 GPU를 Job 2에 할당하는 것에 그치지 않고, 더 나은 할당이 가능한지 탐색합니다. [cite_start]이를 위해 현재 실행 중인 Job 1의 자원을 회수하는 것을 고려합니다. [cite: 207]

3. 자원 민감도 비교 (line 13): [cite_start]스케줄러는 두 작업의 자원 민감도 곡선의 기울기를 비교합니다. [cite: 209]

   • Job 2(T5)는 GPU를 할당받을 때 성능 향상폭(기울기)이 매우 큽니다.
   • Job 1(RoBERTa)은 이미 2개의 GPU를 가지고 있고, 여기서 자원을 뺏겨 1개로 줄어들 때의 성능 하락폭(기울기)이 Job 2의 성능 향상폭보다 작습니다.
   • [cite_start]결론적으로, Job 1에서 GPU 1개를 빼앗아 Job 2에 주는 것이 클러스터 전체의 총 처리량(throughput)을 높이는 길이라고 판단합니다. [cite: 211]

4. 자원 재할당 및 실행 계획 재구성 (line 15, 21):

   • [cite_start]스케줄러는 “가장 덜 민감한 작업(least sensitive job)“인 Job 1의 GPU 할당을 2개에서 1개로 줄입니다(shrink). [cite: 210, 213]
   • 이제 클러스터에는 총 3개의 가용 GPU(원래 있던 2개 + 회수한 1개)가 생깁니다.
   • 이 3개의 GPU를 자원 민감도가 높은 Job 2에 모두 할당합니다.
   • [cite_start]마지막으로, 변경된 자원 할당량에 맞춰 각 작업의 최적 실행 계획을 자원 민감도 곡선을 통해 다시 선택합니다. [cite: 204]
     • [cite_start]Job 1 (RoBERTa, 1 GPU)은 DP+GA 계획을 선택합니다. [cite: 272]
     • [cite_start]Job 2 (T5, 3 GPUs)는 TP+GA 계획을 선택합니다. [cite: 272]

5. 최종 결과: 단순히 2개씩 나눠 갖는 것보다, Rubick의 지능적인 재할당을 통해 T5는 3개의 GPU를, RoBERTa는 1개의 GPU를 할당받게 됩니다. [cite_start]이 결과, 두 작업의 총 처리량 합(normalized speedup)이 0.78에서 1.44로 약 85% 향상되었습니다. [cite: 270, 273]

3. 논문의 한계점

Rubick은 매우 혁신적인 시스템이지만, 다음과 같은 잠재적 한계점을 가지고 있습니다.

• [cite_start]재구성 오버헤드 (Reconfiguration Overhead): 논문에서는 재구성(체크포인트 저장, 재시작 등)에 걸리는 시간이 평균 78초이며, 총 GPU 시간의 1%에 불과하다고 언급합니다. [cite: 328] 하지만 작업의 길이가 매우 짧거나, 클러스터 상태 변화가 극심하여 재구성이 매우 빈번하게 일어나는 시나리오에서는 이 오버헤드가 무시할 수 없는 수준이 될 수 있습니다.

• 성능 모델의 정확성 및 일반화:

  • [cite_start]프로파일링 비용: 새로운 모델 아키텍처가 등장할 때마다, 성능 모델을 맞추기 위해 최소 7개의 샘플 실행을 통한 프로파일링이 필요합니다. [cite: 170] [cite_start]이 과정은 평균 210초가 걸린다고 하지만[cite: 329], 새로운 모델이 계속해서 등장하는 환경에서는 지속적인 비용이 발생합니다.
  • [cite_start]예측 오류: 모델의 평균 예측 오류는 낮지만(최대 7.4%), 특정 경우에는 최대 10.4%에 달하는 오류를 보입니다. [cite: 251] 이러한 예측 오류는 스케줄링 결정의 최적성을 저해할 수 있습니다. 또한, 논문에서 다루지 않은 완전히 새로운 병렬화 전략이나 하드웨어에 대해서도 모델이 잘 일반화될지는 미지수입니다.

• [cite_start]수렴 및 정확도에 대한 잠재적 영향: 논문은 전역 배치 크기(global batch size)를 일정하게 유지하여 재구성이 학습 정확도에 미치는 영향이 무시할 수 있음을 실험적으로 검증했습니다. [cite: 274, 281] 그러나 이는 제한된 학습 시간(3,000 미니배치) 내에서의 결과입니다. 매우 긴 학습 과정에서 잦은 병렬화 전략 변경(예: DP와 PP 간의 전환)이 학습 동역학(training dynamics)에 미묘한 영향을 주어 최종 모델의 수렴 지점이나 품질에 예측하지 못한 변화를 가져올 가능성을 완전히 배제하기는 어렵습니다.

• [cite_start]스케줄링 정책의 복잡성과 최적성: Rubick의 스케줄링 정책은 자원 민감도 곡선의 기울기에 기반한 탐욕(greedy) 알고리즘입니다. [cite: 177, 217] [cite_start]이 문제는 근본적으로 NP-hard 문제이므로[cite: 176], 탐욕적인 접근법이 대부분의 경우 효과적일지라도 특정 예외적인 상황(corner case)에서는 전역 최적해(globally optimal solution)가 아닌 지역 최적해(locally optimal solution)에 머무를 수 있습니다.

Q : 논문의 핵심알고리즘을 예시를 들어 아주 자세하게 설명해주고 정리해 줘

[cite_start]Rubick의 핵심 스케줄링 알고리즘(Algorithm 1)은 **‘자원 민감도 곡선(Resource Sensitivity Curve)’**을 사용하여 클러스터 전체의 처리량을 극대화하는 것을 목표로 합니다[cite: 174, 178]. [cite_start]알고리즘은 더 많은 자원을 할당받았을 때 성능 향상 폭이 큰(민감도가 높은) 작업에 자원을 우선적으로 몰아주고, 반대로 성능 향상 폭이 작은(민감도가 낮은) 작업의 자원은 회수하여 재할당하는 방식으로 동작합니다[cite: 208, 210].

예시로 보는 알고리즘 동작 과정

[cite_start]논문의 Figure 8 실험을 바탕으로 알고리즘의 동작을 단계별로 설명하겠습니다[cite: 248].

시나리오 설정

• [cite_start]클러스터: 4개의 GPU 사용 가능[cite: 268].
• 작업: RoBERTa 모델(작업 1)과 T5 모델(작업 2)을 스케줄링해야 함.
• 목표: 4개의 GPU를 두 작업에 분배하여 클러스터의 총 처리량(두 작업의 속도 합)을 최대화.

Step 1: 작업 도착 및 자원 민감도 분석

1. RoBERTa와 T5 작업이 스케줄링 큐에 도착합니다.
2. Rubick 스케줄러는 각 작업에 대해 미리 계산된 자원 민감도 곡선을 참조합니다. [cite_start]이 곡선은 GPU 개수에 따라 각 작업이 달성할 수 있는 최상의 성능(처리량)을 보여줍니다[cite: 179].
3. [cite_start]분석 결과, T5 모델은 GPU가 추가될 때마다 성능이 급격히 향상되는 반면(곡선의 기울기가 가파름), RoBERTa 모델은 상대적으로 성능 향상 폭이 작다는 것을 발견합니다[cite: 271]. 즉, T5가 RoBERTa보다 자원 민감도가 훨씬 높습니다.

Step 2: 자원 할당 결정 (Shrink & Reallocate)

1. [cite_start]단순한 스케줄러라면 4개의 GPU를 두 작업에 공평하게 2개씩 할당할 것입니다[cite: 269].
2. 하지만 Rubick은 클러스터의 총 처리량을 최대화하기 위해 다른 결정을 내립니다. [cite_start]알고리즘은 기울기(slope)를 기준으로 작업을 정렬하여(SortBySlope), 자원 민감도가 가장 높은 T5에 자원을 우선적으로 할당하고자 합니다[cite: 216].
3. [cite_start]Rubick은 RoBERTa에 1개의 GPU를, T5에 3개의 GPU를 할당하는 것이 두 작업의 처리량 합을 가장 크게 만드는 조합임을 계산해냅니다[cite: 272]. [cite_start]이 과정에서 민감도가 낮은 RoBERTa의 자원을 “축소(shrink)“하여 민감도가 높은 T5에 “재할당"하는 개념이 적용됩니다[cite: 207, 210].

Step 3: 실행 계획 선택 (Co-optimization)

1. [cite_start]자원 할당(GPU 개수)이 결정된 후, Rubick은 다시 자원 민감도 곡선을 사용하여 해당 자원량에서 최고의 성능을 내는 최적의 실행 계획(execution plan)을 자동으로 선택합니다 (GetBestPlan 함수)[cite: 6, 204].
2. [cite_start]T5 (GPU 3개): 최적 계획으로 TP+GA (Tensor Parallelism + Gradient Accumulation)를 선택합니다[cite: 272].
3. [cite_start]RoBERTa (GPU 1개): 최적 계획으로 DP+GA (Data Parallelism + Gradient Accumulation)를 선택합니다[cite: 272].

Step 4: 결과

• [cite_start]이처럼 자원 민감도에 기반한 비대칭적 자원 할당과 그에 맞는 실행 계획의 공동 최적화를 통해, Rubick은 단순 스케줄러 대비 총 처리량을 85% 향상시키는 결과를 얻었습니다[cite: 273].

알고리즘 요약 정리

• [cite_start]목표: 보장된 작업의 성능(SLO)을 만족시키면서 클러스터 전체의 총 처리량을 극대화합니다[cite: 174].
• [cite_start]핵심 도구: 자원 민감도 곡선을 사용하여 GPU 등 특정 자원의 양에 따른 작업의 최대 성능과 잠재적 성능 향상률(기울기)을 파악합니다[cite: 179, 187].
• 핵심 전략:
  • [cite_start]우선순위 부여: 자원 민감도가 높은(곡선의 기울기가 가파른) 작업에 자원을 우선적으로 할당합니다[cite: 178, 216].
  • [cite_start]자원 회수 및 재할당 (Shrink): 현재 실행 중인 작업 중 민감도가 가장 낮은 작업의 자원을 회수하여, 더 민감한 신규 또는 다른 실행 중인 작업에 재할당함으로써 전체 효율을 높입니다[cite: 207, 210].
  • [cite_start]공동 최적화: 자원 할당량이 결정되면, 해당 자원량에 가장 적합한 실행 계획(병렬화 전략 등)을 자동으로 선택하여 작업 성능을 최적화합니다[cite: 6].

Q : 이 논문에서 제시한 결과를 자세하게 보고 다른 방법론에 비하여 특출난 점과 논문에서 제기하는 어떠한 방법이 이러한 결과를 도출하게 되었는지 논문에서 제시하는 이유와 너의 생각을 알려줘

[cite_start]논문에서 제시된 Rubick의 핵심 결과는 기존 최신 스케줄링 시스템 대비 평균 작업 완료 시간(JCT)을 최대 3.2배, 전체 작업 완료 시간(Makespan)을 최대 1.4배 단축했다는 것입니다[cite: 9, 309].

Rubick 결과의 특출난 점

Rubick의 결과가 다른 방법론에 비해 특히 뛰어난 점은 다양한 환경에서 일관되게 높은 성능 향상을 보였다는 것입니다.

• [cite_start]초기 계획의 질과 무관한 성능: 작업의 초기 실행 계획이 무작위로 설정된 경우(Base trace)뿐만 아니라, 각 작업에 가장 좋은 계획이 미리 설정된 경우(Best-plan trace)에도 Rubick은 Sia 대비 1.9배, Synergy 대비 2.4배의 JCT 단축을 보였습니다[cite: 315]. 이는 클러스터의 자원 상황이 동적으로 변하기 때문에, 고정된 최적 계획만으로는 한계가 있으며 지속적인 재구성이 필수적임을 증명합니다.
• [cite_start]대규모 모델에서 더 커지는 격차: 흥미롭게도, 전체 작업에서 LLaMA와 같은 대규모 모델의 비율이 높아질수록 Rubick의 성능 우위는 더욱 커져 JCT 감소율이 2.6배에서 3.4배까지 증가했습니다[cite: 340]. 이는 대규모 모델일수록 선택 가능한 실행 계획의 폭이 넓어 재구성의 이점이 극대화되기 때문입니다.
• [cite_start]자원 보장과 성능 향상의 두 마리 토끼: 다중 사용자(Multi-tenant) 환경에서 Rubick은 AntMan과 비교하여 보장(guaranteed) 작업의 JCT를 1.7배, 최선형(best-effort) 작업의 JCT를 1.6배 단축했습니다[cite: 318, 322, 323]. 이는 단순히 자원을 보장하는 것을 넘어, 더 효율적인 계획을 찾아 성능 자체를 개선했기 때문에 가능했습니다.

결과 도출의 핵심 원리

이러한 뛰어난 결과는 논문에서 제시하는 다음 두 가지 핵심 방법론의 시너지 효과 덕분입니다.

1. 실행 계획과 자원 할당의 공동 최적화 (Co-optimization)

논문에서 제시하는 이유: [cite_start]논문은 기존 시스템들이 작업의 실행 계획을 고정된 ‘블랙박스’로 보고 자원만 할당하는 반면, Rubick은 실행 계획 재구성과 다차원 자원 재할당을 하나의 문제로 보고 동시에 최적화한다고 말합니다[cite: 6]. [cite_start]Breakdown 연구에서 실행 계획 재구성만 하는 경우(Rubick-E)나 자원 재할당만 하는 경우(Rubick-R)보다, 두 가지를 함께 수행하는 완전한 Rubick이 각각 2.5배와 1.7배 더 높은 JCT 감소를 보인 결과가 이를 뒷받침합니다[cite: 325, 327].

저의 생각: 이것이 Rubick의 가장 근본적인 차별점입니다. 클러스터의 자원 가용성은 실시간으로 변하는데, 실행 계획이 고정되어 있다면 최적의 성능을 낼 수 없습니다. [cite_start]예를 들어, GPU가 부족할 때는 ZeRO-Offload처럼 CPU와 메모리를 더 많이 사용하더라도 적은 GPU로 실행 가능한 계획으로 바꾸고 [cite: 32, 101][cite_start], 반대로 CPU가 여유로울 때는 이를 활용해 파라미터 업데이트를 가속화하는 등 [cite: 259] 상황에 맞는 최적의 카드를 계속해서 바꿔 내는 능력이 뛰어난 결과를 만든 핵심입니다.

2. 자원 민감도 기반의 지능적인 스케줄링

논문에서 제시하는 이유: [cite_start]Rubick은 **‘자원 민감도 곡선(Resource Sensitivity Curve)’**을 사용하여 어떤 작업이 자원을 추가로 할당받았을 때 가장 큰 성능 향상을 보이는지 정량적으로 파악합니다[cite: 179]. [cite_start]스케줄링 알고리즘은 이 곡선의 기울기를 기반으로, 민감도가 낮은(자원을 줘도 성능 향상이 적은) 작업의 자원을 회수(shrink)하여 민감도가 높은 작업에 재할당함으로써 클러스터 전체의 처리량을 극대화합니다[cite: 210, 211].

저의 생각: 이 방법은 “한정된 자원을 가장 똑똑하게 사용하는 방법"에 대한 효과적인 해답입니다. 모든 작업에 자원을 공평하게 분배하는 대신, 가장 큰 잠재력을 가진 작업에 자원을 집중하는 것입니다. [cite_start]예를 들어, Figure 8에서 T5 모델이 RoBERTa 모델보다 GPU에 더 민감하다는 것을 파악하고, T5에 더 많은 GPU(3개)를, RoBERTa에는 더 적은 GPU(1개)를 할당하여 총 처리량을 85%나 향상시킨 것이 대표적인 사례입니다[cite: 271, 272, 273]. 이러한 선택과 집중 전략이 클러스터의 유휴 자원을 최소화하고 전체 효율성을 끌어올린 것입니다.

결론적으로, Rubick의 뛰어난 결과는 단순히 하나의 기능이 아닌, 실행 계획의 유연한 재구성 능력과 자원 민감도에 기반한 지능적인 자원 배분 전략이 유기적으로 결합하여 만들어낸 필연적인 성과라고 할 수 있습니다.

Q : 이 논문의 한계를 극복하기 위한 방법으로 어떤 연구흐름이 있는지 정리해서 자세하게 설명해 줘

Rubick의 한계를 극복하기 위한 향후 연구는 현재의 시스템을 더욱 지능적이고, 적응적이며, 비침습적(non-intrusive)으로 만드는 방향으로 진행될 수 있습니다. Rubick이 제기한 ‘재구성 가능성’이라는 패러다임을 더욱 발전시키기 위한 구체적인 연구 흐름은 다음과 같습니다.

1. 실시간/무중단 재구성을 통한 오버헤드 최소화

• [cite_start]한계점: Rubick의 재구성은 작업을 잠시 멈추고, 체크포인트를 저장한 뒤, 새로운 계획으로 재시작하는 방식을 사용합니다[cite: 228]. [cite_start]이 과정은 평균 78초의 오버헤드를 발생시키는데[cite: 328], 이는 작업이 짧거나 클러스터 변화가 잦을 때 부담이 될 수 있습니다.
• 연구 방향: 이를 극복하기 위해 ‘실시간/무중단 재구성(Live/Seamless Reconfiguration)’ 연구가 필요합니다. 이는 작업을 중단하지 않고 실행 중에 동적으로 병렬화 전략이나 자원 할당을 변경하는 기술입니다. 예를 들어, 데이터 병렬(DP)의 워커 수를 늘리거나 줄일 때, 혹은 텐서 병렬(TP)의 분할 방식을 변경할 때 작업의 상태(state)를 그대로 유지한 채 통신 패턴과 연산 그래프를 실시간으로 전환하는 것입니다.
• 기대 효과: 재구성에 따른 유휴 시간을 거의 0으로 만들어, 더 짧은 주기로 정밀하게 클러스터 변화에 대응할 수 있게 됩니다. 이는 클러스터 효율성과 작업 응답성을 극대화할 수 있습니다.

2. 온라인 자기 학습 및 전이 학습 기반 성능 모델 고도화

• [cite_start]한계점: Rubick의 성능 모델은 새로운 모델에 대해 최소 7번의 사전 프로파일링이 필요하며 [cite: 170, 329][cite_start], 최대 10.4%의 예측 오차를 보입니다[cite: 251].
• 연구 방향:
  • 온라인 자기 학습(Online Self-Tuning) 모델: 사전 프로파일링의 부담을 줄이고 정확도를 높이기 위해, 클러스터에서 실행되는 모든 작업의 실제 성능 데이터를 지속적으로 수집하여 성능 모델을 실시간으로 자동 업데이트하고 정교화하는 연구가 가능합니다. [cite_start]Rubick도 온라인 업데이트를 언급하지만[cite: 172], 이를 여러 작업에 걸쳐 학습하는 범용 모델로 확장하는 것입니다.
  • 전이 학습 및 GNN 기반 예측: 완전히 새로운 아키텍처의 모델이 등장했을 때 프로파일링 없이 성능을 예측하기 위해 **전이 학습(Transfer Learning)**을 활용할 수 있습니다. [cite_start]수많은 기존 모델의 구조와 성능 데이터로 메타(meta) 모델을 학습시킨 후, 새로운 모델의 연산 그래프를 **그래프 신경망(GNN)**으로 분석하여 성능을 예측하는 방식입니다[cite: 363].
• 기대 효과: 프로파일링 비용을 최소화하고, 실제 워크로드에 더 잘 맞는 정확한 성능 예측을 통해 스케줄링 결정의 질을 높일 수 있습니다.

3. 모델 수렴을 고려한 스케줄링 (Convergence-Aware Scheduling)

• [cite_start]한계점: Rubick은 전역 배치 크기를 유지하여 학습 정확도에 큰 영향이 없음을 보였지만[cite: 274], 잦은 재구성이 장기적인 학습 과정에서 모델의 최종 수렴 품질에 미칠 미묘한 영향까지는 고려하지 못했습니다.
• 연구 방향: 스케줄링의 목표를 단순히 ‘처리량(throughput)’ 극대화를 넘어, ‘모델의 최종 품질’까지 고려하는 방향으로 확장하는 연구입니다. 이는 스케줄러가 재구성을 결정할 때, 성능 향상 폭과 더불어 재구성으로 인해 발생할 수 있는 **통계적 비용(예: 학습 안정성 저하 가능성)**을 함께 평가하는 것을 의미합니다. 예를 들어, 큰 성능 향상이 보장되지 않는 한 잦은 계획 변경을 피하도록 페널티를 부여하는 방식입니다.
• 기대 효과: 클러스터 효율성뿐만 아니라 최종적으로 사용자가 얻게 될 모델의 성능과 품질까지 보장하는, 한 차원 높은 수준의 스케줄링이 가능해집니다.

4. 강화학습(RL) 기반 스케줄링 정책 탐색

• [cite_start]한계점: Rubick의 스케줄링 정책은 자원 민감도 곡선의 기울기에 기반한 탐욕(greedy) 알고리즘입니다[cite: 217]. [cite_start]이 방식은 효과적이지만, 복잡한 상황에서는 전역 최적해가 아닌 지역 최적해에 머무를 수 있습니다[cite: 176].
• 연구 방향: 정해진 규칙(heuristic) 대신 강화학습(RL)을 통해 스케줄링 정책 자체를 학습하는 연구입니다. RL 에이전트는 시뮬레이션 환경에서 수많은 시행착오를 겪으며, 현재 클러스터 상태(state)에서 어떤 재구성 및 할당(action)을 하는 것이 장기적으로 가장 높은 총 처리량(reward)을 가져오는지 학습합니다.
• 기대 효과: 인간이 설계한 규칙보다 더 복잡하고 비직관적인 최적의 정책을 발견할 수 있습니다. 예를 들어, 단기적으로는 손해처럼 보이는 결정이 장기적으로는 더 큰 이득을 가져오는 전략을 학습하여 클러스터 효율을 이론적 한계에 가깝게 끌어올릴 수 있습니다.

Q : 기존 스케줄러와 비교하여, Rubick이 ‘실행 계획’과 ‘자원 할당’을 동시에 최적화하는 ‘공동 최적화’ 방식은 구체적으로 어떻게 동작하며, 이것이 클러스터 효율성에 어떤 근본적인 이점을 제공하는가?

[cite_start]Rubick의 ‘공동 최적화’ 방식은 딥러닝 작업의 **실행 계획(어떻게 학습할 것인가)**과 **자원 할당(어떤 자원을 얼마나 쓸 것인가)**을 분리된 문제가 아닌, 서로 맞물려 있는 하나의 최적화 문제로 취급합니다[cite: 6]. [cite_start]기존 스케줄러가 작업의 실행 계획을 변경 불가능한 ‘블랙박스’로 보고 단순히 자원만 할당해주는 것과 근본적으로 다릅니다[cite: 3].

공동 최적화 동작 방식

Rubick의 공동 최적화는 다음 두 단계로 구체적으로 동작합니다.

1. [cite_start]성능 모델링: Rubick은 먼저 성능 모델을 통해 특정 작업에 대해 가능한 여러 실행 계획(예: 3D 병렬성, ZeRO, Gradient Checkpointing 등)과 다양한 자원(GPU, CPU, 메모리) 조합이 어떤 성능(처리량)을 낼지 예측합니다[cite: 7, 49]. [cite_start]이 모델은 자원의 변화가 각기 다른 실행 계획의 성능에 미치는 영향을 이해하고 있습니다[cite: 124].

2. 동적 선택 및 할당: 스케줄링 시점마다 Rubick은 이 성능 모델의 예측값을 기반으로 다음과 같은 결정을 내립니다.

   • [cite_start]자원에 계획을 맞추기: 클러스터에 가용 자원이 제한적일 경우, 현재 자원 상황에서 최고의 성능을 낼 수 있는 최적의 실행 계획을 선택하여 작업을 실행합니다[cite: 36].
   • [cite_start]계획에 자원을 맞추기: 반대로 자원이 풍부할 경우, 가장 높은 성능을 내는 실행 계획을 먼저 선택한 뒤, 해당 계획이 요구하는 만큼의 자원을 할당합니다[cite: 37].

[cite_start]이 과정은 일회성으로 끝나지 않고, 클러스터 상황이 변할 때마다 지속적으로 실행되어 항상 최적의 (실행 계획, 자원 할당) 조합을 찾아냅니다[cite: 6].

근본적인 이점

이러한 공동 최적화 방식은 클러스터 효율성에 다음과 같은 근본적인 이점을 제공합니다.

[cite_start]실행 계획과 자원 간의 ‘불일치(Mismatch)’ 해소. 기존 방식에서는 사용자가 클러스터의 동적인 자원 상황을 모른 채 정적으로 실행 계획을 결정하기 때문에, 작업이 요구하는 자원과 실제 가용 자원 사이에 불일치가 발생합니다[cite: 4]. 이로 인해 자원이 부족하면 작업이 하염없이 대기하거나, 자원이 과도하게 할당되어 낭비되는 문제가 있었습니다.

Rubick은 작업을 ‘재구성’하여 이러한 불일치를 해소합니다.

• [cite_start]유연한 자원 활용: 작업이 더 적은 GPU로도 효율적으로 실행될 수 있는 계획(예: ZeRO-Offload)으로 동적으로 변경될 수 있어, 바쁜 클러스터에서도 더 빨리 실행을 시작할 수 있습니다[cite: 32, 338].
• [cite_start]전체 처리량 극대화: 각 작업이 현재 할당된 자원에서 최대의 효율을 내는 계획으로 계속해서 바뀌기 때문에, 클러스터의 모든 자원이 낭비 없이 사용되어 전체적인 작업 처리량이 극대화됩니다[cite: 8].

결론적으로, Rubick은 작업을 클러스터 환경에 수동적으로 맞추는 것이 아니라, 작업 자체가 환경에 능동적으로 적응하도록 만들어 클러스터 효율성을 근본적으로 개선합니다.

Q : ‘자원 민감도 곡선(Resource Sensitivity Curve)‘은 Rubick의 스케줄링 결정에 어떻게 활용되며, ‘Shrink(자원 회수)’ 메커니즘과 결합하여 클러스터 전체의 처리량을 극대화하는 과정은 구체적으로 어떻게 이루어지는가?

‘자원 민감도 곡선’은 특정 작업에 자원을 추가로 투입했을 때 얼마나 큰 성능 향상을 기대할 수 있는지를 보여주는 핵심 지표입니다. Rubick은 이 곡선과 ‘Shrink’ 메커니즘을 결합하여, 마치 경제 원리처럼 한정된 자원을 가장 수익률이 높은 곳에 투자함으로써 클러스터 전체의 처리량을 극대화합니다.

‘자원 민감도 곡선’의 활용법: 투자 가이드라인 📈

• [cite_start]정의: 자원 민감도 곡선은 특정 작업에 대해 각 자원(주로 GPU)의 양에 따라 달성할 수 있는 최고의 성능(처리량)을 미리 그려놓은 그래프입니다. [cite: 179, 182]
• [cite_start]핵심 지표 (기울기): 이 곡선의 **기울기(slope)**는 ‘자원 1단위를 추가했을 때 얻게 되는 처리량의 증가분’을 의미합니다. [cite: 187] [cite_start]기울기가 가파를수록 해당 작업은 자원에 ‘민감’하며, 자원을 투자했을 때 높은 성능 향상을 기대할 수 있습니다. [cite: 186]
• [cite_start]활용: Rubick 스케줄러는 이 기울기를 보고 어떤 작업이 자원을 할당받을 “가장 자격 있는” 후보인지, 즉 투자 가치가 높은지를 신속하게 판단합니다. [cite: 185, 186]

‘Shrink’와 결합하여 처리량을 극대화하는 과정 ⚙️

이 과정은 ‘선택과 집중’이라는 말로 요약할 수 있습니다.

1. [cite_start]가장 민감한 작업 선택 (투자 대상 선정): 새로운 작업을 스케줄링하거나 기존 작업의 성능을 향상시켜야 할 때, Rubick은 현재 대기 중이거나 실행 중인 모든 작업 중에서 자원 민감도 곡선의 기울기가 가장 가파른, 즉 가장 자원 민감도가 높은 작업을 우선순위로 둡니다. [cite: 216]
2. [cite_start]가장 둔감한 작업에서 자원 회수 (Shrink): Rubick은 가용 자원을 찾는 과정에서, 현재 실행 중인 작업들 중 자원 민감도 곡선의 기울기가 가장 낮은(가장 완만한) 작업을 식별합니다. [cite: 210] [cite_start]이 작업은 자원을 회수당하더라도 성능 하락 폭이 가장 적을 것으로 예상되는 ‘가장 둔감한’ 작업입니다. [cite: 210]
3. [cite_start]자원 재할당 및 공동 최적화: Rubick은 2단계에서 회수한 자원을 1단계에서 선택한 가장 민감한 작업에 재할당합니다. [cite: 207, 210] 이 재할당은 다음과 같은 경우에 허용됩니다.
   • [cite_start]총 처리량 증가: 자원을 받는 작업의 성능 향상(기울기)이 자원을 뺏기는 작업의 성능 하락(기울기)보다 커서, 클러스터 전체의 총 처리량이 증가할 때. [cite: 211]
   • [cite_start]성능 보장(SLO) 충족: 총 처리량이 다소 감소하더라도, 성능 보장이 필요한 ‘보장(guaranteed) 작업’이 최소 요구 성능에 도달하지 못했을 때. [cite: 212]
4. [cite_start]최적 실행 계획 자동 선택: 자원 재할당이 완료되면, 각 작업은 변경된 자원량에 맞춰 최고의 성능을 낼 수 있는 실행 계획으로 자동 재구성됩니다. [cite: 204]

결론적으로, 이 과정은 클러스터 내의 모든 자원이 항상 가장 큰 성능 향상을 이끌어낼 수 있는 작업에 동적으로 흘러가도록 만듭니다. 덜 중요한 곳에서 자원을 빼내어 가장 중요한 곳에 집중 투자하는 이 전략이 바로 Rubick이 클러스터 전체의 처리량을 극대화하는 핵심 원리입니다.

Q : Rubick은 자원의 양을 보장하는 대신 ‘성능’을 보장하는 새로운 SLO 개념을 제시한다. 이러한 접근 방식이 실제 다중 사용자(multi-tenant) 환경에서 ‘보장(guaranteed) 작업’의 효율성을 높이고 ‘최선형(best-effort) 작업’에 더 많은 기회를 제공하는 원리는 무엇이며, 이 과정에서 발생하는 트레이드오프는 무엇인가?

Rubick의 ‘성능’ 기반 서비스 수준 목표(SLO)는 더 적은 자원으로 동일하거나 더 높은 성능을 달성하는 영리한 방식을 통해 ‘보장(guaranteed) 작업’과 ‘최선형(best-effort) 작업’ 모두에게 이득을 줍니다.

효율성 및 기회 제공의 원리 💡

기존 스케줄러는 사용자가 요청한 자원의 ‘양’ (예: GPU 8개)을 보장하는 데 집중합니다. 하지만 사용자의 실행 계획이 비효율적이라면, 이 8개의 GPU는 낭비될 수 있습니다.

Rubick은 이 패러다임을 바꿉니다. [cite_start]Rubick은 “사용자가 GPU 8개와 원래 계획으로 얻었을 ‘성능’“을 목표로 설정합니다[cite: 138]. 그리고 더 효율적인 실행 계획을 찾아, 예를 들어 GPU 4개만으로도 그 목표 성능을 달성합니다.

이러한 접근 방식은 다음과 같은 연쇄 효과를 낳습니다.

• [cite_start]‘보장 작업’의 효율성 향상: 더 적은 자원으로 목표 성능을 달성하므로, 작업이 더 빨리 완료될 수 있습니다 (JCT 감소)[cite: 322]. 불필요한 자원을 기다릴 필요가 없고, 할당된 자원을 최대한 효율적으로 사용하기 때문입니다.
• [cite_start]‘최선형 작업’에 더 많은 기회 제공: ‘보장 작업’이 더 적은 자원을 사용하게 되면서 절약된 자원(위 예시에서는 4개의 GPU)이 클러스터에 반환됩니다[cite: 140]. [cite_start]이 남는 자원은 ‘최선형 작업’들이 기회주의적으로 사용하여 실행될 수 있는 소중한 기회가 됩니다[cite: 135]. 결과적으로 클러스터 전체의 유휴 자원이 줄어들고 총 처리량이 증가합니다.

과정에서 발생하는 트레이드오프 (Trade-off) ⚖️

이러한 접근 방식의 가장 중요한 트레이드오프는 **재구성 오버헤드(Reconfiguration Overhead)**입니다.

• 실행 계획을 변경하기 위해서는 현재 진행 중인 작업을 잠시 중단하고, 상태를 체크포인트로 저장한 뒤, 새로운 계획으로 재시작하는 과정이 필요합니다.
• [cite_start]논문에 따르면 이 과정에 평균 78초가 소요되며, 이는 총 GPU 시간의 약 1%를 차지합니다[cite: 328].
• 비록 그 비율이 작더라도, 이 오버헤드는 즉각적인 성능 손실을 의미합니다. 따라서 Rubick의 스케줄러는 재구성으로 인한 단기적인 손실보다 장기적인 성능 향상이 더 클 때만 재구성을 실행해야 하는 정교한 결정을 내려야 합니다.