FASER: 연속 배치 내 투기 디코딩의 단계 직렬화를 공간 분할 중첩으로 해결하는 방법

연속 배치와 투기 디코딩의 충돌

투기 디코딩(speculative decoding)은 소형 드래프터가 여러 토큰을 미리 예측하고, 대형 타깃 모델이 병렬로 검증해 수락 또는 거부하는 방식으로 디코딩 속도를 높인다. 오프라인 실험에서는 2–4배 속도 향상을 보이지만, 프로덕션 연속 배치(continuous batching) 환경에서는 두 가지 구조적 문제가 드러난다.

배치 단위 투기 길이: 기존 구현은 배치 내 모든 요청에 동일한 γ(예: γ=5)를 적용한다. 수락률이 낮은 요청이 섞여 있어도 γ개 드래프트 토큰이 모두 생성되고 검증된다. 수락률이 높은 요청은 γ 이상을 활용할 여지가 있어도 배치 단위 상한에 막힌다.

단계 직렬화: 드래프트 단계(draft phase)가 끝난 뒤에야 검증 단계(verification phase)가 시작된다. 부하가 낮아 배치가 작을 때는 드래프트가 GPU 자원 일부만 소비하며 검증을 기다리게 만든다. 부하가 높을 때는 거부 예정인 토큰들을 검증 단계 끝까지 처리하며 사이클을 낭비한다.

FASER의 세 가지 메커니즘

FASER(arXiv:2604.20503, 2026-04-23, 저자: Wenyan Chen, Chengzhi Lu, Yanying Lin, Dmitrii Ustiugov)는 이 두 문제를 세 가지 독립적인 메커니즘으로 공략한다.

1. 요청별 투기 길이 조정 (Per-Request Length Adaptation)

배치 전체에 γ를 고정하는 대신, 각 요청의 직전 수락률(acceptance rate)을 피드백으로 받아 요청마다 다른 γ를 적용한다. 수락률이 높은 요청은 γ를 늘려 이득을 극대화하고, 수락률이 낮은 요청은 γ를 줄여 거부 토큰의 재계산 비용을 최소화한다.

연속 배치 환경에서는 요청들이 서로 다른 도메인과 시점에 들어오므로 수락률 편차가 크다. 짧은 대화 요청과 긴 코드 생성 요청이 같은 배치에 섞이는 경우가 전형적이다.

2. 조기 토큰 제거 (Early Token Pruning)

기존 검증 단계는 γ개 드래프트 토큰을 모두 처리한 뒤 거부 결정을 내린다. FASER는 검증을 청크 단위로 쪼개고 청크 경계마다 이미 거부된 접두사 이후의 토큰을 즉시 제거한다. 거부가 확정된 뒤의 GPU 사이클을 낭비하지 않는다.

3. 공간 분할 중첩 (Spatial Multiplexing)

드래프트와 검증을 완전히 순차로 실행하는 대신, FASER는 검증 청크와 드래프트를 같은 시간 슬롯에 GPU의 서로 다른 SM(스트리밍 멀티프로세서) 그룹에 배치한다. 드래프트 연산이 GPU 자원의 일부만 요구하는 구간에서, 나머지 SM은 검증 청크를 실행한다. 두 단계가 공간적으로 겹쳐 GPU 유휴 시간이 줄어든다.

FASER는 청크 크기와 SM 배분 비율을 부하에 따라 동적으로 조정해 두 단계의 메모리 대역폭 경쟁(간섭)을 최소화한다.

FASER 동작 흐름

FASER 메커니즘 — 기존 방식 대비 비교

실측 결과

vLLM 기반 프로토타입에서 기존 투기 디코딩 SOTA와 비교한 결과:

지표	기존 SD	FASER	개선
처리량	기준	×1.53	+53%
P99 지연	기준	÷1.92	−48%
저부하 GPU 활용	낮음 (draft 대기)	향상	—
고부하 낭비 재계산	높음	조기 제거	—

논문은 동적 부하(요청 도착률이 변동하는 온라인 트래픽) 환경에서 고정 γ 시스템 대비 이점이 가장 두드러짐을 실험으로 보인다.

기존 투기 디코딩 시스템과 비교

시스템	배치 단위 γ	단계 직렬화	동적 부하 적응
EAGLE (기본)	예	예	제한적
DSpark (ai-frontier #22)	확신도 기반 가변	예	부분
AdaServe (ai-frontier #87)	SLO 기반 가변	예	SLO 단위
FASER	요청별 적응	공간 중첩	저·고부하 전 구간

EAGLE 3.1(ai-frontier #76)은 수락 길이 자체를 늘리는 데 집중하고, AdaServe는 SLO 다양성을 다뤘다. FASER는 두 시스템과 직교하는 문제 — 연속 배치 내 γ 불균일과 단계 직렬화 — 를 공략한다. 조합 적용이 가능하다.

운영 고려사항

vLLM 통합 상태: 논문 프로토타입은 vLLM 위에 구현됐다. 메인라인 통합 상태는 Open question이며 커뮤니티 PR 진행 여부를 확인한다.

이득이 큰 워크로드: 수락률 편차가 큰 혼합 배치. 짧은 대화 요청(수락률 낮음)과 긴 코드 생성(수락률 높음)이 섞인 서비스가 전형적이다. 배치 내 요청들의 수락률이 균일하면 per-request 조정의 이득이 줄어든다.

조기 제거의 구현 요건: 타깃 모델 검증 커널이 청크 내 부분 실행을 지원해야 한다. Flash Attention 등 최적화 커널이 이 분할을 수용하도록 수정이 필요하므로 커널 레이어 통합 작업이 수반된다.

공간 분할의 전제: 드래프터와 타깃 모델이 같은 GPU에 있어야 한다. PD 분리(Prefill-Decode disaggregation) 아키텍처에서는 별도 적용 방안을 설계해야 한다.