기술 요약: Astrolabe

문제 정의

대규모 언어 모델(LLM) 추론 서빙은 요청 워크로드의 본질적인 예측 불가능성으로 인해 심각한 부하 분산(load balancing) 문제에 직면해 있습니다. 전통적인 클라우드 작업과 달리, LLM 요청은 가변적인 응답 길이, 동적인 메모리 소비(KV 캐시), 그리고 배치 크기 변동 및 요청 간 간섭으로 인한 디코딩 단계 지연 시간의 높은 분산을 보입니다.

현재의 다중 인스턴스 서빙 프레임워크는 종종 단순한 휴리스틱(예: 라운드 로빈)이나 라이브 마이그레이션(예: Llumnix)과 같은 사후 대응적 재균형 전략에 의존합니다.

• 휴리스틱: 새로운 요청이 가할 구체적인 부하를 고려하지 못하여, 여러 요청이 동일한 인스턴스로 몰리는 "허딩(herding)" 현상을 유발하고 일시적인 과부하를 초래합니다.
• 라이브 마이그레이션: 부하를 재분배하는 데는 효과적이지만, 인스턴스 간에 KV 캐시를 이동시키는 과정에서 상당한 네트워크, 메모리 및 오케스트레이션 오버헤드를 발생시킵니다. 높은 부하 상황에서 이러한 비용은 누적되어 정상적인 서빙 트래픽과 충돌하며, 테일 레이턴시(tail latency)를 악화시키거나 심지어 클러스터 성능을 붕괴시킬 수 있습니다.

핵심 과제는 값비싼 마이그레이션에 의존하지 않으면서도, 스케줄러 자체의 제어 평면(control-plane) 오버헤드를 최소화하며 다중 인스턴스 LLM 클러스터에서 고품질의 부하 분산을 달형하는 것입니다.

방법론: Astrolabe

Astrolabe는 원샷(one-shot) 요청 디스패치를 위해 설계된 무작위 기반 예측 가이드 스케줄러입니다. 이 시스템은 실행 전 시뮬레이션된 지연 시간 예측을 바탕으로 고품질의 배치 결정을 내림으로써 마이그션을 피합니다.

시스템 아키텍처

시스템은 네 가지 주요 구성 요소로 이루어져 있습니다:

1. 쿼리 길이 태거(Query Length Tagger): 들어오는 요청의 프롬프트를 기반으로 응답 길이를 추정하는 경량 서비스(미세 조정된 RoBERTa 회귀 모델 사용).
2. 글로벌 스케줄러(Global Scheduler): 요청을 수신하고 대상 인스턴스를 선택하는 상태 비저장(stateless) 서비스.
3. 예측 사이드카(Predictor Sidecars): 추론 백엔드와 함께 실행되는 인스턴스별 서비스. 로컬 런타임 상태(예: 실행 중인 요청, 메모리 블록)를 쿼리하고 들어오는 요청을 시뮬레이션하여 목표 지표(기본값: 엔드 투 엔드(E2E) 지연 시간)를 추정합니다.
4. 추론 백엔드(Inference Backends): 스케줄링 로직과 무관하게 동작하는 실제 LLM 서빙 프레임워크(예: vLLM, SGLang).

핵심 디스패치 정책: Power-of-Two Choices (Po2)

모든 $N$개의 인스턴스를 쿼리하는 방식(전체 팬아웃)은 $O(N)$의 제어 평면 비용을 발생시키고 허딩 현상을 악화시키므로, Astrolbae는 Power-of-Two Choices 전략을 채택합니다:

1. 각 들어오는 요청에 대해, 스케줄러는 두 개의 무작위 인스턴스를 샘플링합니다.
2. 이 두 인스턴스의 예측 사이드카에 병렬로 쿼리를 보냅니다.
3. 예측 지연 시간이 더 낮은 인스턴스로 요청을 디스패치합니다.

이 접근 방식은 프로브 세트(probe set)를 무작위화하여 허딩 효과를 깨뜨리고(동시 요청들이 동일한 쌍을 샘플링할 가능성이 낮음), 전체 팬아웃 방식에 비해 per-request 스케줄링 CPU 비용을 약 $N/2$ 배 절감합니다.

예측 메커니즘

예측 사이드카는 지연 시간을 추정하기 위해 시뮬레이션 기반 접근 방식(Vidur 프레임워크에서 차용)을 사용합니다:

• 입력: 요청 프롬프트, 추정된 응답 길이, 현재 로컬 런타임 상태.
• 프로세스: 로컬 스케줄러의 배치 로직을 통해 요청을 시뮬레이션하고, 선형 모델을 사용하여 결과 배치에 대한 실행 시간을 예측합니다.
• 출력: 스칼라 지표(예: 예상 E2E 지연 시간).
• 견고성: 시스템은 절대적인 값보다는 두 후보 간의 상대적 순위에 의존함으로써 예측 오류를 처리합니다. 공통 모드 오류(예: 시스템 노이즈)는 상쇄되며, 시스템은 실험적으로 최소한의 성능 저하만 보이면서 상당한 노이즈(최대 100% 가우시안 노이즈)를 견딜 수 있도록 설계되었습니다.

주요 기여

1. 예측 불가능성 분석: 논문은 왜 런타임 메트릭(메모리, 처리량)이 LLM 부하 분산에 불충분한지 식별하고, 고가변 환경에서 결정론적 디스패치가 유발하는 특정 "허딩" 문제를 강조합니다.
2. Astrolabe 시스템 설계: 응답 길이 추정, 인스턴스별 시뮬레이션, Po2 디스패치를 결합한 원샷 무작위 스케줄러를 제안하고 구현합니다. 이 설계는 라이브 마이그레이션 없이 고품질의 부하 분산을 달성합니다.
3. 포괄적 평가: 저자들은 두 개의 클러스터(12-GPU A30 및 2-노드 A100), 두 개의 모델(Llama-2-7B/70B, Qwen2-7B), 그리고 여러 데이터셋(ShareGPT, BurstGPT)을 통해 Astrolabe를 평가합니다. 또한 다섯 가지 베이스라인(Random, Round-Robin, Min QPM, INFaaS++, Llumnix-)과 비교하고 예측 오류, 버스트 트래픽 및 구성 변화에 대한 민감도를 분석합니다.

실험 결과

Llama-2-7B 및 ShareGPT 데이터셋을 사용하여 12-GPU A30 클러스터에서 평가한 결과:

• 용량(Capacity): Astrolabe는 가장 우수한 부하 인식 베이스라인(Llumnix- (마이그레이션 미사용))의 SLO 용량인 31.6 QPS와 대등한 성능을 보였습니다 (vs. 31.5 QPS).
• 지연 시간(Latency):
  • 평균 TTFT: 최상의 베이스라인보다 8–36% 낮음.
  • P99 TTFT: 최상의 베이스라인보다 16–77% 낮음.
  • 평균 E2E: 최대 5.6% 낮음.
• 안정성: 용량 도달 시(QPS=32), Astrolabe는 Llumnix- (1,800)에 비해 약 6배 적은 프리엠션(preemption) (300)을 경험했습니다.
• 오버헤드: per-predictor CPU 사용량이 전체 팬아웃 방식 대비 약 2.8배 감소했습니다.
• 마이그레이션과의 비교 (A100 클러스터): A100 클러스터에서 라이브 마이그레이션이 활성화된 풀 버전의 Llumnix와 비교했을 때, Astrolabe는 포화 상태에서 최대 2.6배 높은 처리량을 보였으며 수 차례 낮은 per-token 지연 시간을 달성했습니다. 이는 마이그레이션 오버헤드가 고부하 상황에서 서빙 성능을 붕괴시킬 수 있음을 입증합니다.
• 견고성: Astrolabe는 구성 변화(다른 배치 크기, 모델, 데이터셋) 하에서도 성능을 유지하며, 주입된 예측 노이즈에도 탄력적입니다.

의의 및 주장

본 논문은 예측 가이드 원샷 디스패치가 마이그레이션 기반 재균형보다 동등하거나 더 나은 부하 분산을 제공할 수 있음을 보여주며, 동시에 KV 캐시 전송에 따른 상당한 오버헤드를 피할 수 있음을 주장합니다.

저자들이 강조한 핵심 요점은 다음과 같습니다:

• 마이그션이 항상 정답은 아니다: 고부하 상황에서는 마이그레이션의 네트워크 및 오케스트레이션 비용이 재균형의 이점보다 테일 레이턴시와 처리량을 더 크게 저하시킬 수 있습니다.
• 무작위화가 효과적이다: Power-of-Two Choices 정책은 복잡한 글로벌 상태 없이도 효과적으로 요청 허딩을 완화하고 제어 평면 오버헤드를 줄입니다.
• 시뮬레이션은 실행 가능하다: LLM의 예측 불가능성에도 불구하고, 길이 추정과 결합된 시뮬레이션 기반 지연 시간 예측은 불완전한 예측기 환경에서도 효과적인 스케줄링 결정을 내릴 만큼 충분히 정확합니다.

저자들은 결론적으로 Astrolabe가 기존 백엔드와 호환성을 유지하면서 마이그레이션의 복잡성을 피하고 지연 시간과 처리량을 개선하는, 실용적이고 확장 가능한 멀티 인스턴스 LLM 서빙 솔루션임을 제시합니다.