vLLM의 AMD GPU 추측 디코딩 지원 범위와 설정

이번 업데이트의 핵심은 AMD Instinct™ MI300X 및 MI355X GPU와 ROCm™ 소프트웨어 플랫폼 환경에서 추측 디코딩을 사용할 수 있게 된 점이다. vLLM은 드래프트 모델이 후보 토큰을 제안하고 타겟 모델이 이를 한 번에 검증하는 '제안-검증(Draft-and-Verify)' 메커니즘을 구현했다. 지원하는 드래프팅 방식은 Native MTP, Gemma 4 MTP, EAGLE-3, DFlash, DSpark 총 5가지다.

설정은 `--speculative-config` 인자를 통해 제어한다. Native MTP의 경우 타겟 모델에 보조 예측 컴포넌트가 포함되어 있어 별도의 모델 경로를 지정하지 않지만, 그 외 방식은 학습된 드래프트 체크포인트 경로를 `model` 필드에 명시해야 한다.

bash

Native MTP 설정 예시

--speculative-config "{"method": "mtp", "num_speculative_tokens": 5}"

별도 드래프트 모델(EAGLE-3 등) 설정 예시

--speculative-config "{"method": "eagle3", "model": "checkpoint_path", "num_speculative_tokens": 5}"

드래프트 모델의 가중치는 Hugging Face 등을 통해 공개된 체크포인트를 사용하며, Google(Gemma 4 MTP), Z-Lab(DFlash), Red Hat AI(EAGLE-3, DFlash, DSpark), DeepSeek(DeepSeek) 등이 제공하는 모델을 활용할 수 있다. Native MTP를 제외한 모든 방식은 추가적인 드래프트 가중치를 로드하므로 GPU 메모리 여유 공간 확보가 필수적이다.

드래프팅 방식별 작동 구조와 검증 파이프라인

제안 단계의 구조는 후보 토큰을 생성하는 방식에 따라 순차적 생성과 병렬 생성으로 나뉜다. Native MTP와 Gemma 4 MTP, EAGLE-3는 순차적(Autoregressive) 방식을 사용한다. Native MTP는 타겟 모델의 은닉 상태(Hidden Representation)와 현재 토큰 정보를 결합해 다음 후보를 예측하며, EAGLE-3는 타겟 트랜스포머의 세 단계(시작, 중간, 끝)에서 추출한 은닉 상태를 융합해 드래프트 디코더의 입력으로 사용한다.

반면 DFlash와 DSpark는 병렬(Parallel) 예측 방식을 채택했다. DFlash는 타겟 모델이 확정한 '앵커 토큰(Anchor Token)'을 기준으로 이후의 마스크된 위치들을 한 번의 포워드 패스로 동시에 예측한다. DSpark는 여기서 한 단계 더 나아가, DFlash의 병렬 백본 뒤에 가벼운 순차적 마르코프 헤드(Markov Head)를 추가했다. 이는 병렬 예측 시 발생할 수 있는 토큰 간 불일치(예: 'of course'와 'no problem'이 섞여 'of problem'이 되는 현상)를 방지하기 위해 이전 선택 토큰의 바이어스를 적용해 보정하는 구조다.

검증 단계는 모든 방식에서 동일하게 왼쪽에서 오른쪽으로 진행된다. 타겟 모델이 제안된 시퀀스를 한 번의 패스로 평가하며, 첫 번째 거절(Rejection)이 발생하는 지점까지만 수락하고 이후의 후보 토큰은 모두 폐기한다. 거절된 위치에는 타겟 모델이 직접 생성한 토큰이 배치되며, 다음 라운드는 이 지점부터 다시 시작된다.

워크로드별 벤치마크 결과 및 튜닝 지표

AMD MI300X/MI355X 기반 측정 결과, 처리량 향상 폭은 모델과 데이터셋에 따라 상이했다. gemma-4-26B-A4B-it 모델의 경우 MATH500 데이터셋에서 DFlash가 2.87배, GSM8K에서 Gemma 4 MTP가 2.74배의 처리량 향상을 보였다. Kimi-K2.5 모델 역시 DFlash 적용 시 최대 2.68배의 성능 향상이 관찰됐다. Qwen3.5-122B-A10B에서는 Native MTP가 MATH500에서 2.20배의 효율을 기록했다.

모든 설정이 성능 향상으로 이어지지는 않았다. Qwen3-8B 모델에 EAGLE-3를 적용했을 때, GSM8K와 HumanEval 등에서는 베이스라인보다 높았으나 MATH500에서는 오히려 베이스라인보다 낮은 수치를 기록했다. 이는 드래프트 모델의 예측 정확도와 타겟 모델의 수락률이 워크로드의 특성에 따라 민감하게 반응함을 보여준다.

성능 최적화를 위한 핵심 변수는 `num_speculative_tokens`(N)이다. 순차적 방식은 N이 증가함에 따라 처리량이 완만하게 상승하다 정체되는 경향을 보였으며, DFlash와 DSpark는 N=7 설정에서 높은 처리량을 기록하는 경우가 많았다. 다만 N을 무분별하게 높이면 수락률이 낮은 후반부 위치의 드래프팅 비용과 검증 비용만 증가해 오히려 전체 처리량이 하락하는 지점이 발생한다.

실무자는 `mean_accepted_length`(평균 수락 길이)와 `per_position_acceptance_rate`(위치별 수락률)를 모니터링해야 한다. 특히 위치별 수락률을 분석해 특정 지점 이후의 수락률이 급격히 떨어진다면, `num_speculative_tokens` 값을 낮춰 불필요한 드래프트 연산 비용을 줄이는 방향으로 설정값을 조정해야 한다.