AdaServe: 요청마다 SLO가 다를 때 투기적 디코딩을 맞춰 LLM 서빙 효율을 높이는 방법

하나의 서빙 클러스터, 서로 다른 SLO

LLM 서빙 인프라를 운영하다 보면 익숙한 문제에 부딪힌다. 코딩 어시스턴트는 첫 토큰이 200ms 안에 나와야 사용자가 기다리지 않는다. 반면 밤새 돌아가는 데이터 분석 작업은 첫 토큰이 2초 걸려도 무방하다. 두 워크로드가 같은 클러스터를 공유한다면, 어떻게 각자의 SLO를 동시에 맞출 수 있을까?

기존 LLM 서빙 시스템은 이 문제에 약하다. vLLM 같은 현대 서빙 프레임워크는 배치 처리와 메모리 효율을 극대화하도록 설계되어 있지만, 모든 요청을 동등하게 취급한다. 어떤 요청이 엄격한 TTFT 제한을 가졌는지, 어떤 요청이 여유로운지 구분하지 않는다. 그 결과 긴 SLO를 가진 요청이 짧은 SLO 요청의 자원을 빼앗거나, 전체 배치를 위해 SLO가 엄격한 요청이 무시되는 일이 발생한다.

2026년 1월 arXiv에 공개되고 같은 해 4월 EuroSys 2026(에든버러, 영국)에서 발표된 논문 AdaServe는 이 문제를 새로운 방식으로 푼다. 핵심은 투기적 디코딩(speculative decoding)을 "SLO별로 맞춤화"한다는 것이다.

투기적 디코딩과 SLO의 연결고리

투기적 디코딩은 소형 드래프트 모델(draft model)이 여러 후보 토큰을 미리 생성하면, 대형 타깃 모델이 이를 한 번에 검증(verify)하는 방식이다. 검증 통과율이 높으면 한 번의 타깃 모델 호출로 여러 토큰을 확정할 수 있어 생성 속도가 올라간다.

그런데 투기적 디코딩은 SLO에 미묘한 영향을 준다.

• TTFT(Time-to-First-Token): 드래프트 모델이 토큰 트리를 생성하는 시간이 더해지므로 TTFT가 증가할 수 있다. SLO가 엄격한 요청에는 불리하다.
• TPOT(Time-per-Output-Token): 타깃 모델 호출 당 여러 토큰이 확정되므로 TPOT는 크게 줄어든다. SLO가 여유로운 요청에는 이 이득이 크다.

따라서 같은 배치 안에서도 SLO 타입과 엄격도에 따라 투기적 디코딩의 이득이 다르다. 엄격한 TTFT 요청에는 드래프트 토큰 수를 줄여 오버헤드를 낮추고, 여유 있는 요청에는 더 큰 트리를 써서 처리량을 높이는 것이 이상적이다.

AdaServe는 바로 이 아이디어를 구현한다.

AdaServe의 세 가지 핵심 설계

① 하드웨어 인식 투기 트리 구성

AdaServe의 핵심은 SLO 예산에 맞게 투기 트리(speculation tree)의 크기를 결정하는 알고리즘이다.

투기 트리는 드래프트 모델이 생성하는 후보 토큰들의 집합을 트리 구조로 표현한 것이다. 루트에서 시작해 각 노드가 하나의 후보 토큰이고, 깊이와 너비가 커질수록 더 많은 토큰을 한 번에 검증할 기회가 생긴다. 하지만 트리가 클수록 드래프트 모델 실행 시간도 늘어 TTFT가 올라간다.

AdaServe는 각 요청에 대해 다음을 계산한다.

• 남은 SLO 예산: 현재 시점에서 SLO를 맞추기 위해 허용된 추가 처리 시간
• GPU 하드웨어 처리량: 현재 GPU의 드래프트 토큰 생성 속도와 타깃 모델 검증 속도
• 토큰 경로 확률: 드래프트 모델이 예측한 각 토큰 경로의 수락 가능성

이 세 요소를 조합해 SLO를 어기지 않는 범위에서 처리량을 최대화하는 최적 트리 크기를 결정한다. 엄격한 TTFT 요청은 드래프트 단계의 오버헤드를 최소화하기 위해 트리를 작게, 여유로운 요청은 처리량을 높이기 위해 트리를 크게 만든다.

② 선택(Select): 검증 대상 토큰 부분집합

드래프트 모델이 후보 트리를 생성한 다음, AdaServe는 실제로 타깃 모델에 검증을 요청할 토큰 집합을 선택한다.

이 단계는 중요한 분리점이다. 드래프트 모델이 생성한 전체 트리와 타깃 모델에 전달하는 트리가 달라질 수 있다는 의미다. 요청의 SLO 예산이 빠듯하다면 높은 확률 경로만 선택해 검증 비용을 줄이고, 예산이 여유롭다면 더 많은 경로를 검증해 수락 길이를 늘린다.

이 분리 구조가 "speculate-select-verify" 파이프라인의 핵심이다. 선택 단계를 중간에 끼워 넣음으로써 투기 오버헤드와 검증 이득 사이의 균형을 SLO 예산에 따라 동적으로 조절할 수 있다.

③ 동적 파라미터 조정

워크로드는 시간에 따라 변한다. 요청 유입 패턴이 바뀌거나 모델 교체가 일어나면, 최적 트리 크기도 달라져야 한다. AdaServe는 실시간으로 투기 파라미터를 조정한다. 수락률(acceptance rate)이 떨어지면 트리를 줄이고, SLO 예산이 충분하다면 트리를 늘리는 방향으로 피드백 루프를 운영한다.

Multi-SLO 최적화 문제로서의 서빙

AdaServe는 multi-SLO 서빙을 제약 최적화 문제로 정식화한다.

목표: 전체 Goodput(SLO를 만족한 요청의 처리량) 최대화 제약: 각 요청 r_i가 SLO_i(TTFT 또는 TPOT 또는 둘 다)를 위반하지 않아야 함

이 관점에서 보면 투기 트리 크기는 단순한 성능 파라미터가 아니라, 제약 조건을 맞추기 위한 결정 변수가 된다. 요청마다 다른 제약이 있으므로, 같은 배치 안에서도 요청마다 다른 트리 크기가 최적이다.

평가 결과

AdaServe는 다양한 워크로드 조합에서 평가됐다. 코딩 어시스턴트(엄격한 TTFT), 문서 요약(여유로운 TPOT), 데이터 분석(완화된 E2E SLO) 등이 혼재하는 실제 운영 시나리오를 시뮬레이션했다.

비교 베이스라인은 vLLM 기반 균일 배치, TTFT 우선 스케줄링, TPOT 우선 스케줄링, 단순 투기적 디코딩 등을 포함한다.

SLO 엄격도가 높은(tight SLO) 조건에서 AdaServe의 개선폭이 가장 컸다. 투기 트리를 크게 쓰면 tight SLO를 자주 위반하는 기존 방식과 달리, AdaServe는 SLO 예산 범위 안에서 트리를 조절해 위반을 거의 방지했다.

어떤 상황에서 AdaServe가 유효한가

AdaServe의 이득은 특정 조건에서 두드러진다.

이득이 큰 경우

• 같은 클러스터에 TTFT-엄격·TPOT-여유·E2E-혼재 등 복수의 SLO 프로파일이 공존하는 경우
• 드래프트 모델의 수락률이 일정 수준(50% 이상) 유지되는 워크로드
• GPU가 드래프트 단계를 빠르게 처리할 수 있는 환경

이득이 제한적인 경우

• 모든 요청이 동일한 SLO를 가진 단일 SLO 서빙
• 드래프트 모델 품질이 낮아 수락률이 매우 떨어지는 모델 조합
• TTFT SLO가 극도로 엄격해 드래프트 오버헤드조차 허용되지 않는 경우

Open question: AdaServe의 트리 구성 알고리즘은 드래프트 모델과 타깃 모델 간의 수락률이 안정적이라고 가정한다. 모델 교체나 도메인 분포 변화가 잦은 환경에서 예측기를 얼마나 빠르게 재조정할 수 있는지는 논문에서 명확히 다루지 않았다.

관련 연구

AdaServe는 기존 투기적 디코딩 연구와 달리 SLO를 직접 최적화 목표로 삼은 첫 번째 시스템이라는 점에서 차별화된다.

요약

AdaServe의 핵심 통찰은 단순하다. 투기적 디코딩의 이득과 오버헤드는 요청의 SLO 여유에 따라 달라지므로, 트리 크기를 일률적으로 정하지 말고 SLO 예산에 맞춰 조절하라는 것이다.

References

• AdaServe: Accelerating Multi-SLO LLM Serving with SLO-Customized Speculative Decoding (arXiv:2501.12162)
• EuroSys 2026 Proceedings — AdaServe (ACM DL)
• AdaServe Artifact (Zenodo, EuroSys 2026)
• CMU Zhihao Jia Lab — AdaServe paper
• BASTION: Budget-Aware Speculative Decoding (arXiv:2605.29727)