NVIDIA Dynamo SLA Planner 예측기 비교

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

NVIDIA Dynamo의 SLA Planner가 다음 구간의 부하를 예측해 prefill·decode worker 수를 정하는 구조에서, 작성자는 MAE가 아니라 GPU-hours와 SLO 위반률로 예측기를 비교하는 벤치마크를 만들었습니다. BurstGPT trace의 400개 구간에서 모든 예측기를 동일한 1.0% 위반 목표에 맞춰 provisioning headroom을 조정한 결과, TimesFM 3.0은 단순한 last-value 방식과 사실상 동률이었고 Chronos는 50% 더 많은 GPU-hours를 사용했습니다. 완벽한 one-step foresight는 last-value보다 50~58% 저렴했지만 여섯 예측기가 그 절감 여지를 포착하지 못해, 한 구간 앞 예측에서는 최근 관측값이 대부분의 신호를 이미 담고 인터페이스가 추가 개선 폭을 제한한다는 해석이 나왔습니다. 다만 단일 trace의 400개 구간, 20배로 확대한 요청률, 보정되지 않은 analytic simulator, 거친 headroom grid 때문에 절대 GPU-hours와 몇 퍼센트 차이의 해석에는 한계가 있습니다.

실용적 조언

LLM serving autoscaling 예측기를 비교할 때는 MAE만 보지 말고 동일한 SLO 위반 목표를 맞춘 뒤 GPU-hours를 비교해야 합니다.
단일 trace와 소수 구간에서 발생한 몇 퍼센트 차이는 noise와 grid 오차를 함께 검토하고, 반복 trace와 실제 요청률 조건을 추가한 뒤 결론을 확장해야 합니다.

섹션별 상세

NVIDIA Dynamo의 SLA Planner는 다음 구간 부하를 예측해 prefill worker와 decode worker 수를 정하며, predictor 인터페이스는 `def predict_next(self) -> float`처럼 한 구간 앞의 숫자 하나만 반환합니다. 작성자는 이 점 추정치를 TimesFM 3.0과 Chronos 같은 시계열 foundation model, last observed value, constant, Kalman, ARIMA, Prophet과 비교했습니다. 예측 오차 자체가 아니라 실제 운영 비용과 SLO 위반을 측정해야 provisioning 선택의 의미를 판단할 수 있다는 문제의식이 벤치마크의 출발점입니다.

작성자는 예측기마다 서로 다른 headroom에서 GPU-hours를 비교하면 덜 배치한 모델이 유리해진다고 보고, 동일한 1.0% SLO 위반 목표를 먼저 만족시키는 가장 저렴한 provisioning 지점을 찾았습니다. BurstGPT trace 400개 구간에서 last observed value는 175.00 GPU-hours와 0.49% 위반을 기록했고, TimesFM 3.0은 176.85 GPU-hours와 0.49% 위반으로 집계됐습니다. 두 값의 차이는 단일 window의 noise 범위 안에 있어 작성자는 TimesFM 3.0의 승패가 아니라 동률로 해석했습니다.

Chronos는 264.05 GPU-hours와 0.27% 위반으로 last-value보다 약 50% 높은 비용을 기록했으며, Apache-2.0 라이선스로 실제 배포가 가능한 선택지라는 점과 별개로 단순히 아무것도 하지 않는 기준보다 나빴습니다. Kalman은 370.30 GPU-hours와 0.93%, ARIMA는 501.95 GPU-hours와 0.24%를 기록했습니다. NVIDIA Dynamo의 기본 Prophet은 1253.95 GPU-hours와 2.35% 위반으로 1.0% 목표를 어떤 headroom에서도 달성하지 못했습니다.

완벽한 one-step foresight를 가정한 oracle은 73.85 GPU-hours와 0.00% 위반으로, last-value보다 50~58% 낮은 비용을 기록했습니다. 그러나 여섯 예측기 중 두 foundation model을 포함한 어느 것도 이 oracle과의 비용 격차를 줄이지 못했습니다. 작성자는 한 구간 앞 provisioning에서는 최근 관측값이 이용 가능한 신호의 대부분을 이미 포함하고, 부하를 숫자 하나로만 전달하는 인터페이스가 예측기 교체의 상승 여지를 제한한다고 해석했습니다.

P90 분위수로 provisioning하는 방식도 시험했지만 Chronos에는 도움이 되고 TimesFM에는 불리해 일관된 결과를 내지 못했습니다. 결과는 trace의 29,278개 구간 중 400개만 사용했고 반복 측정이 아니며, 실제 요청률에서는 모든 구간에 worker 하나만 필요해 예측기 간 차이가 사라지므로 요청률을 20배로 키웠습니다. 또한 simulator는 engine simulator가 아닌 analytic 모델이고 engine profile은 보정되지 않은 placeholder 수치이며, headroom grid가 거칠고 작성자의 ARIMA는 Dynamo 구현과 달리 매 호출마다 `pmdarima.auto_arima`를 재적합하므로 절대 GPU-hours보다 동일 조건의 상대 비교와 oracle 격차를 우선해서 읽어야 합니다.

이미지 분석

Screenshot
이미지는 본문에서 만든 벤치마크 저장소의 이름과 평가 기준을 확인해 줍니다. 본문이 TimesFM 3.0과 Chronos 등을 비교한 근거 저장소라는 점과 연결되지만, 개별 실험 수치나 차트는 이미지에 표시되지 않았습니다.
GitHub 저장소 `pjdurden/planner-bench`의 화면으로, LLM serving autoscaling forecaster를 forecast error가 아닌 GPU-hours와 SLO violations로 평가한다는 설명이 보입니다.

용어 해설

SLA 플래너(SLA Planner): — 서비스 부하를 예측해 다음 구간에 필요한 prefill worker와 decode worker 수를 결정하는 구성 요소입니다. 이 글의 Planner는 한 구간 앞의 부하를 숫자 하나로 예측하고, 그 결과를 GPU 프로비저닝 규모로 변환해 SLO 위반률과 비용을 함께 평가합니다.
GPU 시간(GPU-hours): — GPU를 몇 시간 동안 사용했는지를 나타내는 자원 비용 지표입니다. 이 벤치마크에서는 예측 오차 대신 각 예측기가 동일한 1.0% SLO 위반 목표를 만족하는 최소 headroom을 찾은 뒤, 그 provisioning 규모를 GPU-hours로 환산해 비교합니다.
SLO 위반(SLO violation): — 서비스가 정한 성능 목표를 지키지 못한 요청이나 구간의 비율입니다. 글에서는 GPU 비용을 낮추는 과정에서 SLO 위반률이 1.0%를 넘지 않도록 각 예측기의 headroom을 조정하고, 비용 비교의 공통 기준으로 사용합니다.
프로비저닝 여유분(provisioning headroom): — 예측된 부하보다 더 많은 worker나 GPU를 미리 배치하는 여유 자원입니다. 여유분이 작으면 GPU-hours는 줄지만 SLO 위반이 늘어나므로, 글은 예측기마다 동일한 위반 목표를 만족하는 가장 저렴한 지점을 찾아 공정성을 확보합니다.
점 추정치(point estimate): — 미래 값에 대한 불확실성 범위 없이 대표 숫자 하나만 출력하는 예측 방식입니다. NVIDIA Dynamo의 predictor 인터페이스는 다음 구간의 부하를 float 하나로 반환하므로, P90 같은 분위수 정보를 활용할 여지가 제한되고 예측기 선택의 비용 개선 폭도 줄어들 수 있습니다.
P90 분위수(P90 quantile): — 관측값의 90%가 그 아래에 위치하는 수준을 뜻하는 분위수입니다. 이 글에서는 점 추정치 대신 P90 부하를 기준으로 worker를 배치하는 방식을 시험했지만, Chronos에는 도움이 되고 TimesFM에는 불리해 일관된 개선으로 이어지지 않았습니다.

코드 예제

python

def predict_next(self) -> float

다음 구간의 부하를 불확실성 없이 숫자 하나로 반환하는 predictor 인터페이스입니다.

언급된 도구

NVIDIA Dynamo중립

SLA Planner를 통해 다음 구간의 부하에 맞는 prefill worker와 decode worker 수를 정하는 serving 시스템입니다.

TimesFM 3.0중립

다음 구간 부하를 예측하는 시계열 foundation model 후보입니다.

Chronos비추천

LLM serving autoscaling 부하 예측에 사용한 Apache-2.0 시계열 foundation model 후보입니다.

Prophet비추천

NVIDIA Dynamo에 기본 제공되는 부하 예측기입니다.

pmdarima.auto_arima중립

작성자의 ARIMA 비교 구현에서 매 호출마다 모델을 자동 선택하고 재적합하는 데 사용한 도구입니다.

언급된 리소스

GitHubpjdurden/planner-bench

문서ARIMA default upstream issue