Towards Multi-Model LLM Schedulers: Empirical Insights into Offloading and Preemption
본 논문은 이기종 하드웨어에서의 멀티모델 LLM 스케줄링이 CPU-GPU 오프로딩으로 인한 모델 의존적 성능 저하와 상태 재로딩으로 인한 상당한 선점 오버헤드에 직면함을 실증적으로 규명함으로써 효율적인 차세대 스케줄러 설계의 핵심 요인을 도출함을 제시한다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
바쁜 주방 (컴퓨터 서버) 을 운영한다고 상상해 보세요. 여기에는 몇 명의 초고속 셰프 (GPU) 와 느리지만 매우 넓은 공간의 식료품 저장실 보조 (CPU) 가 있습니다. 당신의 목표는 동시에 다양한 종류의 복잡한 요리 (대규모 언어 모델 또는 LLM) 를 만드는 것입니다. 때로는 주방이 너무 혼잡해져서 빠른 셰프들이 조리대 공간이 부족해지고, 그래서 식료품 저장실 보조에게 재료를 잠시 맡기거나 심지어 일부 다지기 작업을 도와달라고 요청해야 합니다.
이 논문은 빠른 셰프와 느린 보조 사이에 요리 작업을 나누거나, 더 긴급한 요리를 위해 현재 요리를 갑자기 중단해야 할 때 발생하는 상황을 상세히 연구한 것과 같습니다.
다음은 이 연구에서 얻은 주요 발견들을 쉽게 설명한 것입니다:
1. "반쪽 셰프" 문제 (오프로딩)
요리가 셰프의 조리대에 너무 커서 레시피의 일부 단계를 식료품 저장실 보조에게 옮길 때 발생합니다.
- 발견: 이는 매끄러운 절충안이 아닙니다. 느린 보조에게 작업을 조금만 옮겨도 요리 속도가 약간 떨어지는 것이 아니라, 급격히 추락합니다.
- 비유: 릴레이 경주를 생각해 보세요. 빠른 주자 (GPU) 가 경주의 아주 작은 부분이라도 지친 느린 보행자 (CPU) 에게 배턴을 넘겨야 한다면, 전체 팀의 속도가 극적으로 느려집니다.
- 놀라운 사실: 작은 요리 (작은 AI 모델) 가 가장 큰 타격을 입습니다. 작은 모델의 아주 작은 부분이라도 오프로딩하려고 하면 속도가 매우 느려집니다. 반면 큰 요리 (더 큰 모델) 는 분할을 더 잘 처리하며 속도가 더 완만하게 떨어집니다.
- 교훈: CPU 에 얼마나 많은 작업을 할당할지 단순히 추측해서는 안 됩니다. 어떤 "요리"를 하고 있는지 정확히 알아야 합니다. 왜냐하면 어떤 모델들은 분할되는 것을 다른 모델들보다 훨씬 더 싫어하기 때문입니다.
2. "전환 비용" (선점)
때로는 VIP 고객이 새로운 요리를 주문하고, 현재 셰프를 멈추고 그들의 스테이션을 정리한 뒤 새로운 요리를 시작해야 합니다. 이를 "선점"이라고 합니다.
- 발견: 현재 요리를 1 분 후에 중단하든 1 시간 후에 중단하든, 요리를 전환하는 데 걸리는 시간은 거의 동일합니다.
- 비유: 거대한 벽화를 그리고 있다고 상상해 보세요. 누군가 다른 사람이 그림을 그리도록 하려면 멈춰야 합니다. 10 피트를 그렸든 1,000 피트를 그렸든, 붓을 정리하고 새로운 화가의 붓을 준비하는 데 걸리는 시간은 같습니다. 그림을 그리는 데 보낸 시간은 중요하지 않습니다. 전환하는 데 걸리는 시간이 고정되어 있습니다.
- 큰 발견: 대부분의 사람들은 "메모" (이미 그린 부분의 기억, KV 캐시라고 함) 를 이동하는 시간이 느린 부분이라고 생각했습니다. 하지만 연구 결과에 따르면 메모를 이동하는 것은 실제로 순간적입니다 (시간의 1% 미만). 실제 시간 낭비는 이전 셰프의 도구를 풀고 새로운 셰프의 도구를 푸는 것 (하드 드라이브에서 모델 가중치를 로드하는 것) 입니다.
- 교훈: 작업을 전환하는 것은 비용이 많이 들지만, 그 비용은 예측 가능합니다. 이는 작업이 얼마나 오래 실행되었는지와 전혀 상관없이 "도구 세트" (모델 크기) 가 얼마나 무거운지에 전적으로 달려 있습니다.
3. "교통 체증" (데이터 이동)
빠른 셰프와 느린 보조 사이에서 무언가를 이동할 때, 그들은 복도 (데이터 케이블) 를 통과해야 합니다.
- 발견: "메모" (메모리) 가 요리가 매우 길어지면서 거대해지더라도, 도구들을 푸는 것에 비해 이동하는 속도는 여전히 매우 빠릅니다.
- 비유: 한 장의 종이를 옮기는 것과 책장 전체를 옮기는 것과 같습니다. 종이를 옮기는 것 (메모) 은 너무 빨라서 거의 계산에 포함되지 않습니다. 책장 (모델 도구) 을 옮기는 데는 영원히 걸립니다.
- 교훈: 작업을 전환할지 결정할 때 "메모"의 크기에 대해 너무 걱정하지 마세요. "책장"의 크기에 대해 걱정하세요.
4. "하드웨어 성격"
이 연구는 두 가지 다른 유형의 주방 (두 가지 다른 GPU) 을 테스트했습니다.
- 발견: 한 주방은 요리 속도는 빠르지만 다른 주방보다 작업 전환 속도가 느렸습니다.
- 비유: 한 주방에는 초고속 셰프가 있지만 복도가 좁아 도구를 빠르게 교체하기 어렵습니다. 다른 주방에는 약간 느린 셰프가 있지만 복도가 넓어 교체가 쉽습니다.
- 교훈: "만능 규칙"을 적용할 수 없습니다. 작업을 스케줄링하는 최선의 방법은 정확히 어떤 하드웨어를 가지고 있는지에 달려 있습니다.
미래를 위한 요약
저자들은 차세대 "주방 관리자" (스케줄러) 가 더 똑똑해야 한다고 결론 내립니다. 그들은 단순히 대기열에 있는 주문 수만 보지 않아야 합니다. 그들은 다음을 알아야 합니다:
- 어떤 모델인가요? (일부 모델은 분할되는 것을 매우 싫어합니다).
- 도구 세트는 얼마나 큰가요? (이것이 전환 시간을 결정합니다).
- 이 주방은 어떤 종류인가요? (다른 하드웨어는 규칙을 바꿉니다).
이러한 구체적인 특징들을 이해함으로써, 관리자들은 사각형 못을 둥근 구멍에 억지로 끼우려는 시도를 멈추고, 주방을 붕괴시키지 않으면서 다양한 AI 모델을 효율적으로 실행할 수 있는 시스템을 만들 수 있습니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.