×
Community Blog Aegaeon: 멀티 LLM 모델 플랫폼 운영을 위한 스마트 GPU 스케쥴링 시스템

Aegaeon: 멀티 LLM 모델 플랫폼 운영을 위한 스마트 GPU 스케쥴링 시스템

Alibaba Cloud의 연구팀이 제안한 **Aegaeon**은 수백~수천 개의 다양한 LLM을 동시에 서빙해야 하는 모델 마켓 환경에서 **GPU 자원 낭비를 극복**하기 위한 시스템이다.

Aegaeon: 멀티 LLM 모델 플랫폼 운영을 위한 스마트 GPU 스케쥴링 시스템

Alibaba Cloud의 연구팀이 제안한 Aegaeon은 수백~수천 개의 다양한 LLM을 동시에 서빙해야 하는 모델 마켓 환경에서 GPU 자원 낭비를 극복하기 위한 시스템이다. 기존의 "요청(request) 단위" 오토스케일링 대신 토큰(token) 단위 오토스케일링을 도입하여, GPU 풀링 효율을 극대화하고 82%의 GPU 절감을 실현했다.


🔍 배경: 왜 Aegaeon이 필요한가?

1. 모델 마켓의 현실

  • Hugging Face 같은 모델 마켓은 100만 개 이상의 LLM을 호스팅한다.
  • 대부분의 모델은 사용 빈도가 매우 낮음 (긴 꼬리 분포): 상위의 5.9% 모델이 전체 요청의 98.65%를 차지한다.
  • 모든 모델에 전용 GPU 인스턴스를 할당하면:

    • 17.7%의 GPU1.35%의 요청만 처리를 하게 되는 극심한 자원 낭비 현상이 나타난다.
  • 상위 5.9%의 인기 모델도 버스트 트래픽으로 인해 과잉 프로비저닝 필요 → 여전히 비효율적인 시스템 구조로 나타난다.

2. 기존 솔루션의 한계

접근 방식 설명 한계
Multiplexing (예: MuxServe) 여러 모델을 하나의 GPU에 동시에 올림 GPU 메모리 제약: 14B 모델 2개가 한계 → 평균 2~3개 모델/GPU 카드 당
Auto-scaling (예: ServerlessLLM) 요청이 들어올 때만 모델을 GPU에 로드 요청 단위 스케일링: 긴 LLM 응답 시간으로 인해 Head-of-Line(HOL) 블로킹 발생 → 풀링 효율 저하

📌 핵심 문제: LLM 요청 시간은 일반적인 유저가 기다리기에는 지나치게 길다 (평균 16.79초)
→ 요청이 끝날 때까지 다른 모델을 실행할 수 없음 → 또한 여전히 GPU 카드당 2~3개 모델만 서브 가능


🚀 Aegaeon의 핵심 아이디어: 토큰 단위 오토스케일링

기존 시스템은 요청이 끝날 때까지 기다림 → HOL 블로킹이 발생
Aegaeon은 중간에 선점(preemption)하여 다른 모델의 토큰을 처리 → GPU 활용률 극대화 효과

Figure 2: Request-level vs Token-level auto-scalingImage
(위쪽: 기존 방식 → 아래쪽: Aegaeon)

✅ 기대 효과

  • HOL 블로킹 해소: 대기 중인 모델도 빠르게 TTFT(Time to First Token) 달성 가능하다.
  • GPU 풀링 효율 향상: 최대 GPU 당 7개 모델 지원 가능 (기존 대비 2~3배 향상 가능)
  • 실제 배포 결과: 샘플 모델셋을 테스트해본 결과1,192 → 213 GPU로 감소 (82% 절감)

핵심 기술 1: 토큰 단위 스케줄링

Aegaeon은 PrefillDecoding 단계를 분리(disaggregate)하여 각각 최적화된 스케줄러를 적용하는 메커니즘을 가지고 있다.

1. Prefill 단계: Grouped FCFS(First-Come-First-Servce)

  • 목표: TTFT 최소화 + 오토스케일링 오버헤드 감소
  • 전략:

    • 동일 모델의 요청을 그룹화 (MAX_GPSIZE=8)
    • 기존 그룹이 있으면 해당 기존 그룹에 추가 → 모델 스위칭 횟수 감소 효과
    • 새로운 모델은 로드가 가장 적은 인스턴스에 할당
  • batch size = 1: TTFT 단축 + Decoding 단계로 빠른 전달하는 옵션

2. Decoding 단계: Weighted RR(Round-Robin)

  • 목표: TBT SLO(Service Level Objective) 만족 + 다중 모델 동시 처리 가능
  • 핵심 내용: Decoding은 버퍼링이 발생 → 순간적인 지연은 사용자에게 느껴지지 않음
  • 전략:

    • 각 배치에 시간 할당량(quota) 부여
    • 공식:

Image

  • 슬랙 시간을 활용해 다른 모델 처리 가능 → GPU 효율 극대화

⚡ 핵심 기술 2: 오토스케일링 오버헤드 97% 감소

토큰 단위 스케일링은 매우 빠른 스위칭이 필수 요소이며 이를 접목한 Aegaeon은 풀스택 최적화를 통해 스위칭 시간을 수십 초 → 수 밀리초 수준으로 단축했다.

1. 컴포넌트 재사용 (Component Reuse)

  • 기존 문제: 기존 LLM 엔진 초기화는 분산 실행기(Ray/NCCL), 프로파일링, 토크나이저 로드 등으 프로세스로 26.9초 소요
  • 해결 방법:

    • 모델 가중치 & KV 캐시만 교체, 나머지 컴포넌트는 캐시 & 재사용
    • 사전 할당된 메모리 풀로 KV 캐시 핀(pin) 오버헤드 제거
  • 효과: 엔진 초기화 시간 80% 감소

2. 명시적 메모리 관리 (Explicit Memory Management)

  • 기존 문제: GPU/호스트 메모리 단편화 → 가비지 컬렉션 필요 → 지연 발생
  • 해결 방법:

    • Self-managed VRAM Buffer: 전체 VRAM을 단일 버퍼로 할당 → Bump Allocation 사용

      • torch.nn.Parameter monkey-patching으로 텐서 라이브러리 우회
    • Unified CPU KV Cache: Slab Allocation 기반

      • 모델별 KV 캐시 크기 (예: Qwen-72B = 2560KB/토큰)에 따라 슬랩 풀 할당 관리
      • 메모리 단편화 <20%
    • 모델 프리패칭: 순차적 다음 모델을 별도 CUDA 스트림으로 미리 로드 → 스위칭 시 지연 시간 거의 zero

3. 세밀한 KV 캐시 동기화 (Fine-grained KV Cache Sync)

  • 기존 문제: KV 캐시 스왑 인/아웃을 비동기로 중첩하려면 데이터 경합 위험
  • 해결 방법: CUDA Events를 활용한 세밀한 동기화

    • cudaEventRecord, cudaStreamWaitEvent으로 의존성 명시
    • Move Lists로 안전하지 않은 CPU 블록 추적 → Daemon thread(cudaEventRecord)가 완료 시 해제
  • 효과: KV 캐시 전송 오버헤드 1초 미만

📊 평가 결과

1. 성능 비교 (SLO 달성률)

  • Aegaeon vs ServerlessLLM: 2~2.5배 더 높은 요청 처리율1.5~9배 더 높은 굿풋(goodput)

2. 실제 배포 성과 (Alibaba Cloud Model Studio에 적용한 결과)

  • 모델 수: 47개 (1.8B ~ 72B 파라미터)
  • GPU 수: 1,192 → 213 (82% 절감)
  • GPU 활용률: 13.3~33.9% → 48.1% 로 향상
  • SLO 기준 미달: 0건 (70시간 모니터링 기준)

💡 시사점 & 한계

✅ 장점

  • 실제 프로덕션 환경에서 검증: 단순 논문 이론이 아닌 실제 클라우드 환경에서 검증
  • 유연한 SLO 지원: TTFT=10s, TBT=100ms 기준에서 최적화 → 챗봇, 검색 추천 등 다양한 실시간성 애플리케이션 적용 가능
  • 확장성: 모델 병렬화(TP=4) 지원 → 72B 대형 모델도 처리 가능

⚠️ 한계

  • 매우 엄격한 SLO (TTFT=2s, TBT=20ms)에서는 정적 멀티플렉싱(MuxServe)이 더 나을 수 있음

    • 이유: 오토스케일링 오버헤드가 SLO 슬랙보다 큼
  • 하드웨어 의존성: 고성능 GPU(H series 이상)에서 최적화 → 저사양 GPU(A10)에서는 프리패칭 불가

🔮 결론

Aegaeon은 LLM 모델 마켓이라는 새로운 패러다임에서 GPU 자원 효율성이라는 근본적인 문제를 해결한 획기적인 시스템이다.
토큰 단위 오토스케일링 + 풀스택 최적화를 통해 이론과 실전을 모두 잡았으며, 82%의 GPU 절감이라는 압도적인 성과로 그 가치를 입증했다.
또한 Aegaeon이 적용된 Alibaba Cloud Modelstudio는 다양한 모델(LLM, Visual Model 등)을 서빙하는데 최적의 성능을 제공하여 API를 통한 모델 호출의 퍼포먼스를 크게 증가시켰다.

이 기술은 향후 Alibaba Cloud의 AI Infrastructure에 적용 될 것으로 기대된다. 이는 Alibaba Cloud 를 활용하는 AI Serving 기업의 인프라 효율성을 크게 증가시키는 결과로 이어질 것이다.

"LLM 서빙의 미래는 '모델당 GPU'가 아니라 'GPU당 다수 모델'이다."
— Aegaeon은 이 미래를 현실로 만들 수 있을 것으로 기대된다.


참고 자료:

0 0 0
Share on

JJ Lim

24 posts | 4 followers

You may also like

Comments