대규모 언어 모델(LLM)의 '추론(Inference)'을 위한 '오토스케일링(Autoscaling)' 기술 소개

https://www.youtube.com/watch?v=N68BDLoVofw

 

이 동영상은 대규모 언어 모델(LLM)의 '추론(Inference)'을 위한 '오토스케일링(Autoscaling)' 기술에 대해 심층적으로 다루고 있습니다. [01:50] 특히 바이트댄스(ByteDance)에서 발표한 논문을 중심으로, 수만 개의 GPU를 효율적으로 관리하여 사용자 요청을 처리하는 복잡한 최적화 문제와 해결 방안을 설명합니다.

다음은 영상의 핵심 내용을 상세히 정리한 것입니다.

1. LLM 추론 및 서빙의 기본 개념

• 추론 (Inference): 사용자가 "하늘의 색깔은?"과 같이 프롬프트를 입력했을 때, [03:35] 모델이 응답 토큰을 생성하여 사용자에게 다시 전송하는 전체 과정을 말합니다. [04:02]
• 서빙 (Serving): 서비스를 제공하는 회사 입장에서 사용자의 추론 요청을 처리해주는 것을 의미합니다. [04:15]
• SLO (Service Level Objective): 서비스 수준 목표. 사용자의 요청을 정해진 시간 내에(예: 몇 초) 성공적으로 처리해야 하는 비율을 의미하며, 추론 시스템의 핵심 성능 지표입니다. [04:55], [05:03]

2. 핵심 문제: Prefill(사전 채우기) vs. Decode(디코딩)

LLM 추론은 두 개의 매우 다른 단계로 나뉩니다. [15:17]

• Prefill (사전 채우기):
  • 사용자가 입력한 프롬프트 전체를 한 번에 병렬로 처리하여, 다음에 생성될 토큰을 위한 'KV 캐시'를 구축하는 단계입니다. [15:17]
  • 이 과정은 **컴퓨팅 집약적(Compute-intensive)**이며 높은 연산 능력(Flops)이 필요합니다. [19:23]
• Decode (디코딩):
  • Prefill 단계에서 생성된 KV 캐시를 바탕으로, 한 번에 한 토큰씩 순차적으로(Auto-regressive) 생성하는 단계입니다. [15:24], [20:23]
  • 이 과정은 순차적이며, 저장된 KV 캐시를 계속해서 읽어야 하므로 **메모리 대역폭 집약적(Memory-bound)**입니다. [20:38], [21:00]

이 두 단계는 필요한 하드웨어 자원이 다릅니다. 예를 들어, 연산에 강한 GPU(A40 등)는 Prefill에, 메모리 대역폭이 높은 GPU(3090 Ti 등)는 Decode에 더 적합할 수 있습니다. [20:53]

3. '오토스케일링' 최적화 문제

'오토스케일링'은 이러한 복잡한 환경에서 최소한의 비용으로 SLO를 만족시키기 위해 GPU 자원을 동적으로 할당하는 기술입니다. [11:03], [11:51]

• 이종(Heterogeneous) 하드웨어: 데이터 센터는 A100, H100, 3090 등 성능과 비용이 각기 다른 다양한 종류의 GPU로 구성되어 있습니다. [09:41], [12:12]
• 분리된 아키텍처: 이 GPU 풀(Pool)을 'Prefill 풀'과 'Decode 풀'로 분리하여 관리합니다. [13:22], [22:09]
• 토폴로지 인식 (Topology-Aware): GPU들이 어떻게 연결되어 있는지가(예: 같은 랙, 다른 데이터센터) 통신 속도와 지연 시간에 큰 영향을 미칩니다. [12:50], [26:12] 따라서 스케줄러는 이 '위상(Topology)'을 반드시 인지하고 자원을 배분해야 합니다. [13:07]

4. 오토스케일링의 주요 난제

1. 예측 불가능한 작업량 (Variable Workload):
   • 사용자의 요청은 24시간 일정하지 않고, 업무 시간(오전 10시)에 급증하고 점심시간이나 새벽에는 급감하는 등 변동성이 매우 큽니다. [39:00], [40:02]
   • 오토스케일러는 이 패턴을 예측하고 자원을 미리 준비하거나 줄여야 합니다.
2. 잘못된 측정 지표 (Misleading Metrics):
   • 단순히 'GPU 사용률'만 보는 것은 위험합니다. [14:22] 예를 들어, Decode 노드는 KV 캐시 메모리 병목 현상 때문에 실제 처리량은 낮은데도 GPU 사용률은 100%로 높게 나타날 수 있습니다. [44:09]
3. 과잉 반응 (Overshooting & Flapping):
   • 요청이 급증할 때 필요 이상으로 너무 많은 GPU를 할당했다가(Overshoot), 요청이 줄면 다시 급격히 줄이는 '출렁임(Flapping)' 현상이 발생하기 쉽습니다. [47:50], [48:31]
   • 이로 인해 많은 GPU가 할당만 되고 실제로는 유휴 상태로 대기하며 자원을 낭비하게 됩니다. [50:32]
   • 영상에서는 이를 안정화시키기 위해 '쿨링 주기', '히스테리시스 임계값' 등을 설정하는 방식을 언급합니다. [51:25]
4. 수많은 하이퍼파라미터 (Hyperparameters):
   • Prefill과 Decode 풀의 비율(PD ratio), 배치 크기, 쿨링 주기 등 상호 의존적인 하이퍼파라미터가 너무 많아, 대규모 환경에서 이를 튜닝하는 것은 거의 불가능에 가깝습니다. [37:43], [41:55]

5. 해결 전략

• 계층적 제어 (Hierarchical Control):
  • 주기적 정책 (Periodic Policy): 예측 가능한 일간/주간 패턴에 따라 GPU 풀의 규모를 거시적으로 조정합니다. [45:29]
  • 메트릭 기반 정책 (Metric-Driven Policy): SLO, 큐 크기 등 실시간 지표를 바탕으로 배치 크기 등을 미시적으로 미세 조정합니다. [45:29], [28:35]
• 그래프 파티셔닝 (Graph Partitioning):
  • GPU의 '그래프(연결망)'를 분석하여, 어떤 GPU 그룹을 Prefill에 할당하고 어떤 그룹을 Decode에 할당할지(즉, 그래프를 어떻게 분할할지) 동적으로 최적화합니다. [01:02:22]
  • 이를 위해 그룹을 합치거나, 쪼개거나, GPU를 다른 그룹으로 이동시키는 등의 작업을 반복합니다. [01:08:50]
• 생성 길이 예측 (Generation Length Prediction):
  • 사용자 요청마다 생성될 토큰의 길이가 불확실하기 때문에 스케줄링이 어렵습니다. [01:17:25]
  • 짧은 요청을 먼저 처리하거나 생성 길이를 예측하여, 긴 요청 하나 때문에 짧은 요청 여러 개가 대기하는 상황을 방지합니다. [01:20:56]

요약

LLM 추론 오토스케일링은 단순히 서버를 늘리고 줄이는 문제가 아닙니다. [43:00] 이는 각기 다른 하드웨어의 특성(연산 vs. 메모리), [20:53] 하드웨어 간의 물리적 연결(토폴로지), [12:50] 그리고 예측 불가능한 사용자 요청 패턴 [39:00] 사이에서 최소의 비용으로 최대의 효율을 뽑아내야 하는 매우 복잡한 다차원 최적화 문제입니다. [01:36:08]