이 논문은 vLLM 과 같은 실제 배포 환경에서 다양한 작업 부하와 배치 크기를 대상으로 추측적 디코딩 (Speculative Decoding) 의 성능을 체계적으로 분석하여, 검증 과정이 실행 시간을 지배하고 이론적 상한선과 실제 성능 간에 상당한 격차가 존재함을 규명함으로써 향후 연구 방향을 제시합니다.
원저자:Xiaoxuan Liu, Jiaxiang Yu, Jongseok Park, Ion Stoica, Alvin Cheung
대형 언어 모델 (LLM) 이 글을 쓸 때, 한 번에 한 글자 (토큰) 씩만 작성합니다. 마치 엄격한 사장님이 한 번에 한 마디만 하고, 그 말이 맞는지 확인한 다음에야 다음 말을 하는 것과 같습니다.
문제: 사장님이 매번 "이게 맞나?"라고 확인하는 과정 (계산) 이 너무 느려서, 많은 사람이 동시에 글을 요청하면 (배치 크기 증가) 대기 시간이 길어집니다.
2. 해결책: 추측적 디코딩 (Speculative Decoding)
이 문제를 해결하기 위해 **'현명한 비서 (Draft Model)'**를 고용했습니다.
방식: 비서가 먼저 사장님이 할 말을 3~5 개 정도 미리 추측해서 종이에 적어둡니다.
검증: 사장님은 비서가 쓴 종이를 한 번에 훑어보며 "이거 맞네, 저거 맞네, 근데 이거는 틀렸네"라고 확인합니다.
효과: 만약 비서의 추측이 맞다면, 사장님은 한 번의 확인으로 여러 마디를 동시에 인정해 주는 셈이 되어 속도가 빨라집니다.
3. 이 연구의 핵심 발견 (실제 현장에서의 진실)
기존 연구들은 실험실 수준의 작은 규모 (비서 1 명, 사장님 1 명) 에서만 테스트했지만, 이 연구는 **실제 대형 공장 (vLLM 엔진)**에서 수백 명의 비서와 사장님이 일하는 상황을 시뮬레이션했습니다.
① 비서의 실력은 '상황'에 따라 천차만별
코드 작성 (InstructCoder): 코드는 반복되는 패턴이 많아서, 비서가 **"이전 문장을 그대로 베껴 쓰는 것 (n-gram)"**만으로도 아주 잘 맞습니다. 이때는 비서의 추측이 길게 이어져 속도가 매우 빨라집니다.
수학/추론 (Reasoning): 논리적인 추론은 패턴이 복잡해서, 비서가 단순히 베끼는 것보다 **학습된 비서 (EAGLE)**가 더 잘 맞습니다.
결론: "어떤 비서 (기술) 가 최고인가?"는 **무엇을 쓰느냐 (작업 종류)**에 따라 다릅니다.
② 병목 현상은 '사장님의 확인'에 있다
비서가 아무리 빨리 추측해도, 사실상 시간을 가장 많이 쓰는 것은 사장님이 그 추측을 확인하는 (Verification) 과정입니다.
비서가 틀린 말을 많이 추측하면, 사장님은 그 틀린 말을 확인하느라 시간을 낭비하게 됩니다.
특히 **사람이 많이 몰릴 때 (배치 크기 증가)**는 사장님의 확인 능력이 포화 상태가 되어, 비서가 틀린 말을 추측하는 비용이 오히려 전체 속도를 늦추게 됩니다.
③ 이론적 한계 vs 현실의 괴리
연구진은 **"만약 비서가 100% 틀리지 않고, 사장님이 확인하는 시간만 0 초라면?"**이라는 가상의 시나리오를 만들었습니다.
결과: 현재 기술로는 이론적 최대 속도 (비서와 사장님이 완벽하게 조율된 상태) 에 비해 아직 갈 길이 멉니다.
새로운 기회: 비서 A 는 특정 자리에서 잘 맞고, 비서 B 는 다른 자리에서 잘 맞습니다. 이 둘을 **상황에 따라 섞어서 쓰는 것 (Adaptive Combination)**만으로도 속도를 4.9 배까지 높일 수 있다는 희망적인 가능성을 발견했습니다.
4. 요약: 이 논문이 우리에게 주는 메시지
현실적인 평가: 실험실에서의 "완벽한 속도"는 실제 공장에서는 나오기 어렵습니다. 특히 사람이 많을수록 속도 향상 폭은 줄어듭니다.
검증 비용이 핵심: 비서가 아무리 빨라도, 사장님의 확인 시간이 병목이 됩니다. 틀린 추측을 확인하는 낭비를 줄이는 것이 핵심입니다.
맞춤형 전략: 모든 상황에 하나의 비서만 쓰는 것은 비효율적입니다. 코드 작업에는 '베끼기 비서 (n-gram)'를, 복잡한 추론에는 '학습된 비서 (EAGLE)'를 상황에 따라 섞어 쓰는 것이 미래의 해법입니다.
한 줄 요약:
"AI 의 속도를 높이기 위해 '예측 비서'를 쓰는 건 좋은 아이디어지만, 비서가 틀린 말을 할 때 '사장님'이 확인하느라 시간을 낭비하지 않도록, 상황에 따라 가장 잘 맞는 비서를 골라 쓰는 지능적인 시스템이 필요합니다."
1. 문제 정의 (Problem)
현실과 연구의 괴리: 기존 SD 연구는 대부분 프로토타입 구현체와 배치 크기 1(batch size=1) 같은 비현실적인 환경에서 수행되었습니다. 이는 실제 대규모 배치 처리 환경에서의 성능을 반영하지 못합니다.
다양한 변형의 부재: 드래프트 모델 기반, n-gram 기반, 트리 기반 등 다양한 SD 변형들이 존재하지만, 어떤 변형이 어떤 워크로드나 모델 아키텍처에 적합한지에 대한 체계적인 비교 분석이 부족합니다.
성능 저하 요인 불명확: SD 가 왜 특정 조건에서는 표준 디코딩보다 느려질 수 있는지, 그리고 성능 병목이 정확히 어디에 있는지 (예: 검증 단계의 비용) 에 대한 심층적인 분석이 필요했습니다.
2. 방법론 (Methodology)
실험 환경: 생산 수준의 추론 엔진인 vLLM을 기반으로 실험을 수행했습니다. CUDA Graphs, KV 캐시 관리, 연속 배치 (continuous batching) 등 실제 서비스 환경의 최적화 기능을 모두 활성화했습니다.
하드웨어 및 모델: NVIDIA H100 GPU 를 사용했으며, Llama3.1-8B, Llama3-70B, Qwen3-8B, GLM-4.5-Air-106B 등 다양한 규모의 모델을 평가 대상으로 삼았습니다.
워크로드: 요약 (CNN/DailyMail), 대화 (ShareGPT), 코드 편집 (InstructCoder), 수학 (GSM8K), 복잡한 추론 (AIME22-24, GPQA-Main) 등 6 가지 다양한 실제 워크로드를 평가했습니다.
평가 지표: 생성 길이의 변동성 (비결정성) 을 고려하여 **초당 토큰 처리량 (Token Throughput)**을 주요 성능 지표로 사용했습니다.
비교 대상 SD 변형:
드래프트 모델 기반 (Draft-model-based)
EAGLE / EAGLE-3 (학습된 보조 헤드)
멀티 토큰 예측 (MTP)
n-gram (학습 불필요, 프롬프트 룩업)
트리 기반 검증 (Tree-style verification)
3. 주요 기여 (Key Contributions)
생산급 환경에서의 체계적 평가: vLLM 을 활용한 첫 번째 체계적인 SD 연구로, 연구용 프로토타입과 실제 배포 간의 격차를 해소했습니다.
성능 병목 및 가속도 분해 분석: SD 의 전체 속도가 검증 (Verification) 단계에 의해 지배되며, 제안된 토큰의 수용 (Acceptance) 행동이 요청 내, 요청 간, 데이터셋 간에 크게 변동됨을 규명했습니다.
이론적 상한선 (Theoretical Upper Bound) 제시: 현재 관측된 성능과 이상적인 성능 사이의 갭을 정량화하고, 이를 통해 향후 최적화를 위한 새로운 연구 방향을 제시했습니다.
4. 주요 결과 (Key Results)
A. 전체 성능 및 배치 크기 영향
배치 크기와 가속도: 배치 크기가 작을 때 (메모리 병목) SD 는 큰 가속도 (약 1.7~2.0 배) 를 보이지만, 배치 크기가 커질수록 (계산 병목) 가속도는 감소합니다. 이는 거절된 토큰을 검증하는 오버헤드가 커지기 때문입니다.
모델 규모: 모델이 클수록 (예: 70B) 배치 크기가 커짐에 따라 가속도 감소 폭이 더 큽니다. 70B 모델은 작은 배치에서도 이미 계산 병목 상태이기 때문입니다.
B. SD 변형별 성능 비교
n-gram: 일반적인 텍스트 작업에서는 성능이 낮지만, **코드 편집 (InstructCoder)**과 같이 국소적인 반복 패턴이 많은 작업에서는 뛰어난 성능을 보입니다. 이는 프롬프트와 출력 간의 높은 중복 (Overlap) 을 효과적으로 활용하기 때문입니다.
드래프트 모델 기반: 70B 모델에서는 EAGLE 보다 우수한 성능을 보이지만, 8B 모델에서는 드래프트 모델 실행 오버헤드가 상대적으로 커져 성능이 떨어집니다.
EAGLE/EAGLE-3: 다양한 워크로드에서 안정적인 수용률을 보이며, 특히 긴 문맥 (Reasoning) 작업에서 유리합니다.
트리 기반 검증: 배치 크기 1 에서는 약간의 이점이 있으나, 배치 크기가 증가하면 거절된 분기 (rejected branches) 를 검증하는 비용이 커져 오히려 성능이 저하됩니다.
C. 실행 시간 및 메모리 분석
시간 분해: SD 실행 시간의 대부분 (42%~95%) 은 대형 모델의 검증 (Verification) 단계에서 소모됩니다. 제안 (Drafting) 단계의 비용은 상대적으로 작습니다.
메모리: n-gram 은 메모리 오버헤드가 거의 없으나, 드래프트 모델 기반 방법은 추가 모델 가중치와 KV 캐시로 인해 메모리 사용량이 증가합니다.
D. 수용 행동 (Acceptance Behavior) 분석
변동성: 토큰 수용 길이는 요청 내 위치, 요청 간, 데이터셋 간에 큰 변동을 보입니다.
상보성: n-gram 은 반복 패턴이 있을 때 긴 수용을 보이지만, EAGLE 은 더 일관된 수용을 보입니다. 두 방법은 서로 다른 조건에서 강점을 가지므로, **적응형 결합 (Adaptive Combination)**이 가능함을 시사합니다.
E. 이론적 상한선 및 오라클 분석
오라클 시뮬레이션: 모든 제안된 토큰이 수용된다고 가정하는 '오라클 (Oracle)' 시나리오를 통해 이론적 최대 가속도를 계산했습니다.
갭 (Gap): 현재 방법론과 오라클 사이에는 상당한 성능 격차가 존재합니다. 이는 불필요한 검증 (거절된 토큰 검증) 을 줄일 여지가 있음을 의미합니다.
적응형 결합의 잠재력: n-gram 과 EAGLE 의 강점을 위치별로 적응적으로 결합하는 'Oracle Combine' 시나리오에서는 표준 디코딩 대비 최대 4.9 배의 가속도가 가능함이 이론적으로 증명되었습니다.
5. 의의 및 결론 (Significance)
이 논문은 SD 가 단순히 "빠른 기술"이 아니라, 검증 비용과 수용률의 균형에 의해 결정되는 복잡한 시스템임을 밝혔습니다.
실무적 통찰: 코드 편집과 같은 반복적 작업에는 n-gram 이, 긴 추론 작업에는 EAGLE 이 적합하다는 구체적인 가이드를 제공합니다.
연구 방향 제시: 현재 SD 의 성능 병목은 제안 (Drafting) 이 아닌 검증 (Verification) 단계에 있으며, 특히 불필요한 검증 비용을 줄이는 방향 (예: 수용 확률이 높은 토큰만 검증하거나, 여러 방법을 적응적으로 결합) 이 미래의 주요 연구 과제임을 강조합니다.
도구 공개: 프로파일링 및 시뮬레이션을 위한 코드와 벤치마크를 공개하여 후속 연구를 촉진합니다.
결론적으로, 이 연구는 SD 의 현재 한계를 명확히 규명하고, 이론적 상한선에 도달하기 위한 구체적인 최적화 방향 (적응형 전략, 검증 비용 절감) 을 제시함으로써 대규모 LLM 추론 시스템의 효율성을 높이는 데 중요한 기여를 했습니다.