💻 computer science

OmniPilot: An Uncertainty-Aware LLM Inference Advisor for Heterogeneous GPU Clusters

OmniPilot은 이질적인 GPU 클러스터를 위한 불확전성 인지 추론 어드바이저로서, 공변량 정합성이 갖춰진 분위수 모델과 분포 외 탐지를 사용하여 서빙 비용을 예측하고 신뢰할 수 없는 구성을 기권함으로써, 다양한 하드웨어 및 정밀도 설정 전반에서 높은 정확도로 경제적 효용을 최적화한다.

원저자: D. Balamurugan, Thomas W. Bush

게시일 2026-07-03✓ Author reviewed ⓘ

📖 3 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: D. Balamurugan, Thomas W. Bush

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 수백 명의 서로 다른 승객(AI 모델)을 태우고 각기 다른 목적지로 향하는 거대한 공유 우주선(GPU 클러스터)의 선장이라고 상상해 보십시오. 배가 도크를 떠나기도 전에 당신은 결정해야 합니다. 어떤 엔진을 사용할 것인가? 얼마나 많은 엔진을 하나로 연결할 것인가? 그리고 어떤 연료를 태울 것인가?

만약 당신이 잘못 추측한다면, 배는 이륙하기도 전에 덜컥거리거나, 연료가 떨어지거나, 추락할 수도 있습니다. 이것이 바로 OmniPilot이 해결하고자 하는 문제입니다.

다음은 OmniPilot을 쉽게 설명한 이야기입니다.

1. 문제점: 추측은 비용이 많이 듭니다

AI의 세계에서 "대규모 언어 모델"(지금 당신과 대화하고 있는 것과 같은 모델)을 실행하는 것은 레이스카를 운전하는 것과 같습니다. 당신은 차(GPU)를 선택해야 하고, 얼마나 많은 드라이버가 핸들을 공유할지(텐서 병렬성, Tensor Parallelism), 그리고 차가 처리해야 할 세부 정보의 양(정밀도, Precision)을 결정해야 합니다.

논문에 따르면, 단순히 감으로 결정하거나 "모두에게 적용되는 하나의 규칙"을 사용하면 14%의 확률로 실패하게 됩니다. 때로는 엔진에 비해 차가 너무 무겁거나, 연료 탱크가 너무 작을 수도 있습니다. 공유 우주선에서 발사 실패는 다른 사람이 사용할 수 있었던 귀중한 시간과 돈을 낭비하는 결과를 초합니다.

2. 해결책: "불확실성을 인지하는" 부조종사

연구진은 숙련된 부조종사 역할을 하는 똑똑한 조언자인 OmniPilot을 구축했습니다. OmniPilot은 단순히 하나의 정답만을 제시하는 대신, 두 가지 특별한 기능을 수행합니다.

미래를 예측합니다 (안전망 포함): 요청을 살펴본 뒤 이렇게 말합니다. "이 연료와 이 엔진을 사용한다면, 아마 이 정도의 속도를 낼 것입니다." 하지만 단순히 추측만 하는 것이 아니라, 신뢰 구간을 함께 제공합니다. 이는 마치 "시속 100마일 정도 나오겠지만, 오차 범위는 5마일 내외입니다"라고 말하는 것과 같습니다.
"모른다"고 말할 줄 압니다: 이것이 가장 중요한 부분입니다. 만약 당신이 이전에 본 적 없는 구성(예: 완전히 새로운 유형의 엔진이나 특이한 연료 혼합물)을 요청하면, 부조격사는 추측하지 않습니다. 대신 붉은 깃발을 올리며 이렇게 말합니다. "멈추세요! 저는 이것을 테스트해 본 적이 없습니다. 충분히 확신할 수 없습니다." 이를 **기권(Abstention)**이라고 합니다. 이는 검증되지 않은 지형에서 배를 충돌시키는 것을 방지합니다.

3. 학습 방법: "훈련 기록부"

OmniPilot은 마법이 아닙니다. 과거의 수많은 항해 기록으로부터 배운 학생입니다.

OmniPilot은 클러스터에서 발생한 50만 건의 과거 작업을 연구하여 배가 발사에 실패하는 빈도를 이해했습니다.
다양한 종류의 첨단 엔진(A100, H100, H200)에 대해 460회의 구체적인 테스트 실행을 수행하여 엔진이 정확히 어떻게 작동하는지 학습했습니다.
OmniPilot은 규칙이 까다롭다는 점을 배웠습니다. 예를 들어, 때로는 "덜 상세한" 연료(양자화, Quantization)를 사용하는 것이 엔진에 따라 오히려 차를 더 느리게 만들 수도 있습니다. 단순한 규칙 책은 이러한 기묘한 특성을 놓칠 수 있지만, OmniPilot은 이를 학습했습니다.

4. 결과: 더 스마트한 선택

연구진이 OmniPilot을 표준적인 의사결정 방식들과 비교 테스트했을 때 다음과 같은 결과가 나타났습니다.

정확도: 엔진/연료 조합 중 최적의 조합을 95%의 확률로 선택했습니다.
비용: 잘못된 선택을 피함으로써 많은 "노드 시간(node-hours, 시간 및 비용)"을 절약했습니다.
안전성: 완전히 새로운, 테스트되지 않은 시나리오로 시스템을 속이려 했을 때, 시스템은 잘못된 답을 내놓는 대신 정확하게 "모릅로겠습니다"라고 답했습니다.

5. 하지 못하는 것 (경계 조건)

이 논문은 OmniPilot이 아닌 것에 대해서도 매우 명확히 밝히고 있습니다.

OmniPilot은 엔진이 실행되는 동안 엔진을 수리하지 않습니다 (그것은 vLLM과 같은 다른 도구의 역할입니다).
새로운 AI 모델을 훈련(학습)하는 것이 아니라, 실행(추론, Inference)하는 것에 집중합니다.
배 자체가 고장 난 경우(하드웨어 결함)에는 작동하지 않습니다 (하드웨어 결함은 이 특정 도구의 범위를 벗어납니다).

핵심 요약

OmniPilot은 AI를 위한 스마트한 여행사와 같습니다. 당신의 목적지를 확인하고, 날씨를 체크하며, 보유한 모든 비행기의 이력을 검토한 뒤, 가장 빠르고 저렴하게 도착하기 위해 어떤 비행기를 예약해야 하는지 정확히 알려줍니다. 무엇보다 중요한 것은, 만약 당신이 한 번도 가본 적 없는 항로를 요청한다면, "아직은 추천할 수 없습니다"라고 솔직하게 말함으로써 재앙적인 여행을 막아준다는 점입니다.

데이터 기반의 예측과 정직한 "모른다" 버튼을 결합함으로써, OmniPilot은 운영자가 AI 클러스터를 더욱 효율적이고 안전하게 운영할 수 있도록 돕습니다.

기술 요약: OmniPilot

문제 정의

공유된 이종(heterogeneous) GPU 클러스터에서 대규모 언어 모델(LLM)을 서빙하는 것은 복잡한 사전 제출 결정 문제를 야기한다. 운영자는 귀중한 노드 시간을 할당하기 전에 GPU 유형, 텐서 병렬성(Tensor Parallelism, TP) 차수, 그리고 수치 정밀도(numerical precision)를 결정해야 한다. 이 과정은 다음과 같은 도전 과제들로 인해 매우 까ert다:

높은 실패율: 무분별한 구성 선택은 하드웨어 불일치나 메모리 부족(OOM)으로 인한 즉각적인 실패를 초래한다. 저자들의 벤치마크 실행 결과, 14%의 작업이 즉시 실패했다.
비직관적 상호작용: 정적인 배포 레시피는 복잡한 하드웨어-소프트웨어 역학 관계를 포착하지 못한다. 예를 들어, 특정 런타임에서는 4비트 양자화가 16비트보다 느릴 수 있으며, 키-값(KV) 캐시 압박은 정밀도에 따른 비단조적(non-monotonic) 크기 변화를 만들어낸다.
데이터의 한나계: 기존의 클러스터 스케줄러(예: Slurm)는 워크로드 특유의 동작(모델 패밀리, 정밀도, 동시성 등)에 대한 가시성이 부족하며, 실제 서빙 성능을 제대로 나타내지 못하는 오래된 텔레메트리(예: 60초 간격의 DCGM 샘플링 인터벌)에 의존한다.
불확실성: 기존 시스템은 이미 선택된 구성 내에서의 실행을 최적화할 뿐, 해당 구성을 '선택'하는 과정에 대한 보정된 불확실성 추정치를 제공하지 못한다. 이로 인해 운영자는 지원 가능한 요청과 지원 불가능한(Out-of-Distribution, OOD) 요청을 구분할 수 없다.

방법론

OmniPilot은 예측 성능 비용을 예측하고 최적의 구성을 추천하는 동시에 불확실성을 명시적으로 처리하도록 설계된 런칭 어드바이저(launch advisor)이다. 그 아키텍처는 세 가지 핵심 구성 요소로 이루어져 있다:

1. 데이터 인프라

OmniPilot은 계보(lineage)와 재현성을 보장하기 위해 두 가지 별도의 데이터 저장소를 활용한다:

개인 저장소(Personal Store): 특정 모델 패밀리, GPU, 정밀도를 다루는 통제된 벤치마크 그리드(1,667행).
클러스터 전체 저장소(Cluster-wide Store): 500,000개의 과거 작업으로부터 집계된 텔레메트리로, 런칭 성공 사전 확률(priors)과 수요 패턴을 도출하는 데 사용된다.
특징 공학(Feature Engineering): 시스템은 로그 변환된 수치(모델 크기, 동시성), 선형 수치(TP 차수, 메모리), 그리고 모델 패밀리, GPU 종류, 양자화 형식을 위한 원-핫 인코딩을 포함하여 약 28개의 특징을 인코딩한다. 결정적으로, 데이터 수집 전에 새로운 축(예: 양자화 유형)을 피처라이저(featurizer)에 표현함으로써 특징 누수(feature leakage)를 방지한다.

2. 추론 비용 모델

핵심 예측기는 곱셈적 오차(multiplicative errors)를 처리하기 위해 로그 공간에서 학습된 양자 손실(quantile loss) 기반의 그래디언트 부스팅 회귀 모델 세트이다.

대상(Targets): 총 토큰/초, 요청 처리량, 첫 토큰 시간(TTFT), 콜드 스타트 시간, 피크 KV-캐시 사용량, 평균 전력을 포함한 8가지 대상을 예측한다.
보정(Calibration): 모델은 예측 구간을 생성하기 위해 **Conformalized Quantile Regression (CQR)**을 채택한다. 이는 홀드아웃 셀 잔차(held-out cell residuals)에서 보정된 분할-컨포멀 가산 오프셋(split-conformal additive offset)을 사용하여, 미지의 워크로드에 대해 80%의 커버리지를 달配合한다.
기권 메커니즘(Abstention Mechanism): OOD 요청을 처리하기 위해, OmniPilot은 지원 거리(support-distance) 체크를 사용한다. 요청이 (7개 축에 걸쳐 정의된) 측정된 지원 엔벨로프(support envelope)를 벗어나는 경우, 시스템은 구간 너비와 상관없이 이를 저신뢰도로 플래그를 지정하고 기권(abstain)한다.

3. 결정 유틸리티 및 배치

OmniPilot은 운영자의 선호도에 따라 보정된 경제적 유틸리티 지표를 사용하여 구성 "암(arms)"(GPU, TP, 정밀도의 조합)의 순위를 매긴다.

유틸리티 함수: $Utility = (Throughput \times Runtime \times Value) - (Compute Cost + Queue Wait + Expected Failure Cost + SLO Violation Cost + KV-Saturation Penalty)$ .
런칭 성공 사전 확률(Launch-Success Prior): 베타-이항 추정기(beta-binomial estimator)를 사용하여 개별 구성의 실패율을 풀 클러스터 비율로 수축(shrinkage)시킨다. 이는 멀티 GPU 구성(예: TP=4)이 단일 GPU 설정보다 런칭 성공률(~38%)이 현저히 낮다는 관찰 결과를 반영한다.
KV-포화 페널티(KV-Saturation Penalty): KV-캐시 점유율이 0.85를 초과할 때 곱셈적 처리량 페널티를 적용하여, 선점(preemption)을 유틸리티 비용으로 변환한다.

주요 기여

보정 및 기권 기능이 있는 어드바이저: OmniPilot은 컨포멀하게 보정된 양자 비용 모델과 명시적인 OOD 기권 레이어를 결-합한 최초의 LLM 추론 시스템이다. 이는 성능 지표와 함께 보정된 구간 및 안전 신호를 예측하여 지원되지 않는 요청을 차단한다.
결정 결합형 평가(Decision-Coupled Evaluation): 본 논문은 어드바이저를 모델 프리(model-free) 베이스라인과 비교하기 위해 워크로드 셀 단위로 그룹화된 GroupKFold를 사용하는 누수 없는 평가 프레임워크를 도입한다. 이는 경제적 유틸리티(비용 및 실패 위험 포함)를 최적화하는 것이 처리량만을 고려하거나 규칙 기반 정책보다 배치 정확도 측면에서 훨씬 우수함을 입증한다.
클러스터 텔레메트리 연구 (부정적 결과): 저자들은 스케줄러 메타데이터(Slurm)가 수요 및 런칭 성공 사전 확률을 도출하는 데는 충분하지만, 클러스터 전체의 처리량 어드바이저를 구축하는 데는 불충분함을 보여준다. 이는 스케줄러가 자원 할당(GPU가 어떻게 사용되었는지)은 기록하지만, 구체적인 소프트웨어 워크로드(그 위에서 무엇이 실행되었는지)는 기록하지 않기 때문이다.

결과

A100, H100, H200 하드웨어에서 460개의 벤치마크 실행을 통해 평가되었다:

예측 정확도: OmniPilot은 총 처리량을 **6.2%의 평균 절대 백분율 오차(MAPE)**와 로그 공간 $R^2$ 0.92로 예측한다.
배치 정확도: 어드바이저는 최적의 구성을 선택하는 데 있어 95%의 Top-1 정확도를 달성했으며, 평균 유틸리티 후회(regret)는 0.003이었다. 이는 "크기 임계값(size-threshold)" 규칙(후회 1.97)이나 "처리량 최대화(throughput-max)" 정책(후회 4.73)과 같은 베이스라인보다 한 자릿수 더 나은 성능이다.
OOD 처리: 5개의 미지원 셀(새로운 모델 패밀리 또는 극단적 컨텍스트)에 대한 홀드아웃 세트에서 예측 오차는 24~46%로 상승했고, 컨포멀 구간은 실제 값을 커버하는 데 실패했다. 그러나 기권 레이어가 이 5개 모두를 저신뢰도로 성공적으로 식별하여 위험한 배포를 방지했다.
데이터 효율성: 태스크 축(task axes)이 커버되면 약 150개의 훈련 행 이후부터 정확도가 포화된다. 이는 원시 데이터의 양보다 구성 공간의 커버리지가 더 중요하다는 것을 시사한다.

의의 및 주장

본 논문은 하드웨어 구성 선택을 보정된 경제적 결정으로 변환함으로써, 다중 사용자 공유 GPU 클러스터의 중요한 매크로 수준의 격차를 메운다고 주장한다. 그 의의는 다음과 같다:

안전 및 신뢰성: 명시적으로 OOD 요청에 대해 기권함으로써, 정적인 레시피나 "최선 노력(best-effort)" 스케줄러가 초래할 수 있는 비용이 큰 실패를 방지한다.
경제적 최적화: 단순한 처리량 최대화를 넘어 비용, 실패 위험, SLO의 균형을 맞추는 복잡한 유틸리티 함수를 최적화함으로써 운영자의 실제 제약 조건에 부합한다.
방법론적 엄밀성: "데이터 전(before)의 특징(feature)" 설계를 통한 체계적인 접근 방식을 확립하였으며, 많은 성능 문제가 단순히 모델 용량을 늘리는 것이 아니라 정교한 유틸리티 설계(예: KV-포화 페널티)나 측정 정밀도(예: 신선도 윈도우)를 통해 해결될 수 있음을 입증한다.

저자들은 시스템이 현재 단일 노드 vLLM 추론 서빙에 국한되어 있다는 점을 언급하며 범위를 겸손하게 제한하였다. 훈련 워크로드, 결함 복구, 멀티 노드 서빙 아키텍처는 향후 연구 과제로 명시적으로 남겨두었다. 또한, 시스템은 특정 클러스터(Kempner AI)의 경험적 데이터에 의존하며, 절대적 임계값(예: KV 포화 지점)은 배포 환경에 따라 달라질 수 있다.