요약
ByteDance Seed와 University of Chicago 연구진이 ASPLOS 2026에 발표한 SwiftSpec은 투기적 디코딩(speculative decoding)과 텐서 병렬성(tensor parallelism)을 동시에 적용하지 못하는 구조적 한계를 타깃 모델과 드래프트 모델을 서로 다른 GPU 그룹에 배치하고 두 단계를 비동기 파이프라인으로 겹쳐 해결한다. 8×H800 GPU에서 Llama-3-70B 기준 348 tokens/s를 달성했으며, 기존 SOTA 투기 디코딩 대비 평균 1.75배 빠르다.
왜 투기 디코딩과 텐서 병렬성은 충돌하는가
투기 디코딩은 소형 드래프트 모델이 여러 토큰을 미리 생성하고, 대형 타깃 모델이 이를 병렬로 검증·수락하는 방식이다. 드래프트 길이 γ만큼 한 번의 타깃 포워드 패스에서 여러 토큰을 확정할 수 있어 지연을 낮춘다.
텐서 병렬성은 모델 가중치를 여러 GPU에 나눠 처리량을 높인다. 그런데 두 기법을 함께 쓰면 세 가지 문제가 생긴다.
1. 연산량 불균형: 드래프트 모델과 타깃 모델은 크기가 다르다. 같은 GPU 그룹으로 텐서 병렬성을 적용하면 타깃 모델의 레이어당 연산량에 GPU 수를 맞춰야 하므로, 드래프트 단계에서 GPU 사용률이 낮아진다.
2. KV 캐시 불일치: 드래프트와 타깃이 같은 GPU에 있을 때, 수락된 토큰의 KV 캐시를 드래프트 KV 캐시와 타깃 KV 캐시 양쪽에 동기화해야 한다. 드래프트 트리(tree speculation)를 쓰면 이 동기화 비용이 커진다.
3. 소 배치 All-Reduce 오버헤드: 텐서 병렬에서 레이어마다 발생하는 All-Reduce 통신은 배치 크기가 작을 때 상대적 오버헤드가 크다. 디코딩 단계는 배치 크기가 1이 되는 경우도 흔하다.
SwiftSpec의 핵심 설계
SwiftSpec은 드래프트와 타깃을 분리된 GPU 그룹에 배치하고, 두 단계를 비동기로 중첩한다. 매 반복(iteration)에서:
- 드래프트 GPU 그룹이 드래프트 트리를 확장하는 동안,
- 타깃 GPU 그룹은 직전 반복에서 선택된 서브트리를 검증한다.
이렇게 두 작업이 병렬로 진행되므로 드래프트 생성 비용이 임계 경로에서 제거된다.
이를 가능하게 하는 세 가지 메커니즘이 있다.
1. 병렬 트리 생성 (Parallel Tree Generation)
기존 트리 투기는 드래프트 토큰을 순차로 생성한다. SwiftSpec은 드래프트 GPU를 여러 스트림으로 나눠 트리의 서로 다른 가지를 병렬로 생성한다. 드래프트 GPU의 메모리 대역폭과 연산을 더 균등하게 활용한다.
2. 트리 인식 KV 캐시 관리 (Tree-Aware KV Cache Management)
드래프트 트리의 각 노드(후보 토큰)는 고유한 KV 캐시 접두사를 가진다. SwiftSpec은 트리 구조를 이용해 KV 캐시를 공유·재사용한다. 타깃 검증 후 수락된 경로의 KV 캐시만 유지하고, 거부된 경로는 즉시 해제한다. 드래프트 측 KV 캐시와 타깃 측 KV 캐시는 GPU 그룹이 달라 불일치 문제가 없다.
3. 퓨즈 저지연 커널 (Fused Latency-Optimized Kernels)
타깃 GPU 그룹에서 작은 배치(γ+1 토큰) 검증에 최적화된 커널을 사용한다. 드래프트 토큰들을 한꺼번에 검증하는 패딩 없는 attention 커널과, 검증 결과 반환·KV 업데이트를 하나의 커널로 합친 퓨즈 연산을 설계했다. All-Reduce는 타깃 GPU 그룹 내에서만 발생하며, 드래프트 그룹과는 수락 결과(짧은 메시지)만 교환한다.
아키텍처 다이어그램
기존 시스템과 비교
| 시스템 | SD 방식 | 텐서 병렬성 | 비동기 중첩 |
|---|---|---|---|
| EAGLE (기본) | 트리 SD | 제한적 | 없음 |
| DSpark (ai-frontier #22) | 반자동회귀 | 제한적 | 없음 |
| FASER (ai-frontier #105) | SD + 공간 분할 | 같은 GPU | 부분 |
| SGLang Spec V2 (ai-frontier #25) | 트리 SD | 있음 | 부분 |
| SwiftSpec | 트리 SD + 분리 GPU | 완전 | 완전 |
기존 시스템들은 드래프트와 타깃을 같은 GPU 그룹 내에서 순차 실행해야 했다. SwiftSpec은 두 모델을 물리적으로 분리하는 방식으로 이 제약을 우회한다.
성능 결과
8×H800 GPU에서의 측정 결과:
| 모델 | 시스템 | 처리량 |
|---|---|---|
| Llama-3-70B | SwiftSpec | 348 tokens/s |
| Llama-3-70B | NVIDIA 공식 벤치마크 (8×H200) | ~267 tokens/s |
| Llama-3-70B | SOTA SD 기준 (동일 하드웨어) | ~199 tokens/s |
주목할 점은 SwiftSpec이 더 낮은 사양의 H800 GPU를 사용했음에도 NVIDIA 공식 벤치마크(H200 기준)를 상회한다는 것이다. 이는 알고리즘 수준의 비동기 중첩 이득이 하드웨어 사양 차이를 역전시킬 수 있음을 보여준다.
평균 1.75배 가속은 다양한 드래프트 수락률(acceptance rate) 조건에서 측정된 평균이다. 수락률이 높은 워크로드(코드 생성, 반복적 텍스트)에서 이득이 더 크다.
운영 고려사항
GPU 할당 전략: 드래프트 그룹과 타깃 그룹의 GPU 비율을 워크로드에 따라 조정해야 한다. 드래프트 모델이 작을수록 타깃 그룹에 더 많은 GPU를 배정하는 것이 유리하다. Open question: 최적 비율을 자동으로 결정하는 프로파일러.
배포 단위: 드래프트 모델과 타깃 모델을 별도 프로세스 또는 컨테이너로 배포한다. KV 캐시 전달에 NVLink 또는 고속 InfiniBand가 필요하다. 멀티노드 배포 시 네트워크 토폴로지가 서브트리 전달 지연에 영향을 준다.
vLLM 통합 상태: 논문은 vLLM 기반 프로토타입으로 검증됐다. 메인라인 통합 및 공개 PR 상태는 GitHub에서 확인한다. EAGLE 3.1, SGLang과의 커널 레이어 통합도 Open question이다.
대상 워크로드: 단일 사용자 대화(배치 크기 1)에서 텐서 병렬성 이점이 가장 두드러진다. 배치 크기가 커지면 타깃 GPU의 처리량이 드래프트 생성 속도를 압도해 비동기 이득이 줄어든다. TTFT(Time to First Token) 우선 환경보다는 지속적 디코딩 처리량 우선 환경에 적합하다.