EAGLE 3.1: 투기적 디코딩의 어텐션 드리프트를 FC 정규화로 해결하고 긴 컨텍스트 수용 길이를 2배로 늘린 방법

투기적 디코딩이 도입된 이유

LLM 추론의 병목은 메모리 대역폭이다. 대형 모델의 가중치를 GPU 메모리에서 읽어오는 속도가 연산 속도보다 훨씬 느리기 때문에, 토큰을 하나씩 생성하는 표준 방식은 GPU 활용률이 낮다.

투기적 디코딩(Speculative Decoding)은 이 문제를 다음 방식으로 해결한다. 작은 드래프트 모델이 여러 토큰을 먼저 예측하고, 대형 타깃 모델이 이 예측들을 병렬로 한 번에 검증한다. 수용된 토큰은 그대로 출력에 추가되고, 거부된 지점부터는 타깃 모델의 분포에서 다시 샘플링한다. 결과의 정확성은 타깃 모델 단독 실행과 동일하게 보장되면서, 지연 시간(latency)은 대폭 줄어든다.

EAGLE(Extrapolation Algorithm for Greater Language-model Efficiency)은 이 분야에서 가장 실용적인 방법 중 하나다. 드래프트 헤드를 타깃 모델의 숨겨진 상태(hidden state)를 이용해 훈련하므로, 별도 드래프트 모델 없이 경량 헤드 하나만 붙이면 된다.

2026년 3월 arXiv:2503.01840로 발표된 EAGLE-3는 이전 버전들과 달리 다층 특성 융합(multi-layer feature fusion)을 도입했다. 초반 레이어(구문·형태 정보), 중간 레이어(의미·담화 정보), 후반 레이어(출력 확률 분포)를 동시에 드래프트 헤드에 입력하여 수용률을 크게 높였다.

그런데 EAGLE-3 배포 이후 실제 운영 환경에서 예상치 못한 문제가 보고되었다. 컨텍스트가 길어질수록, 또는 특수한 채팅 템플릿을 사용할수록 수용 길이가 불규칙하게 떨어지는 현상이었다. EAGLE 3.1은 이 문제의 근원을 찾아 수정한 릴리스다.

어텐션 드리프트: 긴 컨텍스트에서 수용률이 낮아지는 원인

EAGLE 3.1 개발팀은 이 현상을 어텐션 드리프트(Attention Drift)라고 명명했다.

투기적 디코딩에서 드래프트 헤드는 타깃 모델의 숨겨진 상태를 입력받아 다음 토큰을 예측하고, 이 과정을 k번 반복해 k개의 초안 토큰을 만든다. 문제는 이 반복 과정에서 발생한다.

드리프트의 발생 경로:

1. 단계 0: 드래프트 헤드가 타깃 모델의 숨겨진 상태 h₀를 입력받아 토큰 t₁을 예측한다.
2. 단계 1: 드래프트 헤드가 h₀와 자신이 예측한 t₁의 임베딩을 융합해 t₂를 예측한다.
3. 단계 2 이상: 드래프트 헤드가 이전 단계의 자체 출력에 점점 더 의존하기 시작한다.

EAGLE-3에서는 다층 숨겨진 상태를 FC 레이어로 융합할 때 정규화가 없었다. 초반 레이어와 후반 레이어의 숨겨진 상태는 크기(magnitude) 차이가 있으며, 깊은 레이어일수록 잔차 경로(residual path)로 인해 크기가 커지는 경향이 있다. 이 불균형이 누적되면서 드래프트 헤드가 "싱크 토큰(sink token)" — 어텐션의 기준점이 되는 초기 토큰들 — 에서 멀어지고 자신이 생성한 토큰들에 집중하게 된다.

컨텍스트가 짧을 때는 이 드리프트가 미미하다. 그러나 컨텍스트가 길어질수록, 또는 비표준 채팅 템플릿이나 긴 시스템 프롬프트가 있을수록 드리프트가 누적되어 수용 길이가 낮아진다.

EAGLE-3의 다층 특성 융합 구조

EAGLE 3.1을 이해하려면 먼저 EAGLE-3의 핵심 혁신을 짚어야 한다.

기존 EAGLE(1, 2)는 타깃 모델의 마지막 레이어 숨겨진 상태만 드래프트 헤드에 입력했다. 마지막 레이어는 출력 확률 분포와 가장 가깝지만, 구문이나 문장 맥락 같은 중간 레벨 표현은 이미 압축·변환된 후다.

EAGLE-3는 세 지점의 숨겨진 상태를 동시에 사용한다.

이 세 숨겨진 상태는 concat 후 FC 레이어를 통해 드래프트 헤드의 입력 차원으로 투영된다. 문제는 이 FC 레이어가 다른 크기 분포를 가진 벡터들을 단순 연결한다는 점이다. 후반 레이어 벡터는 잔차 경로 누적으로 초반 레이어보다 크기가 크며, 이 불균형이 FC 투영을 통해 드래프트 헤드에 그대로 전달된다.

FC 정규화: EAGLE 3.1의 핵심 수정

EAGLE 3.1은 한 가지 정밀한 변경을 가한다: 각 타깃 숨겨진 상태를 FC 융합에 넣기 전에 LayerNorm을 적용한다.

# EAGLE-3 (정규화 없음)
fused = FC([h_early; h_mid; h_late])

# EAGLE 3.1 (FC 정규화 적용)
fused = FC([LayerNorm(h_early); LayerNorm(h_mid); LayerNorm(h_late)])

이 변경의 효과:

• 세 레이어 벡터의 크기를 동일한 스케일로 맞춘다.
• 드래프트 단계가 진행되면서 누적되는 잔차 크기 불균형을 차단한다.
• 드래프트 헤드가 어떤 레이어 정보에도 동등하게 어텐션을 줄 수 있게 된다.

이 변경은 모델 가중치를 추가하지 않는다. LayerNorm 파라미터는 기존 FC 레이어의 미미한 오버헤드로 흡수된다. 또한 EAGLE 3 체크포인트를 그대로 사용할 수 있다 — 기존에 훈련된 드래프트 헤드를 재훈련 없이 EAGLE 3.1 방식으로 실행할 수 있다는 뜻이다.

성능: 긴 컨텍스트에서의 개선

EAGLE 3.1이 가장 효과적인 상황은 긴 컨텍스트 서빙이다.

수용 길이 개선:

• 짧은 컨텍스트(1K 토큰 이하)에서는 EAGLE 3과 유사한 수용 길이
• 긴 컨텍스트(32K 토큰 이상)에서는 수용 길이 최대 2배 향상

실제 처리량 측정 (Kimi-K2.6-NVFP4 기준):

단일 사용자 환경(C=1)에서 효과가 가장 크고, 동시 요청이 늘어날수록 배치 효과로 인해 상대적 이득이 줄어든다. 이는 투기적 디코딩 일반의 특성으로, 낮은 배치 크기(낮은 동시성)에서 지연 시간 절감이 두드러진다.

채팅 템플릿 및 시스템 프롬프트 강건성: EAGLE 3 체크포인트가 특정 채팅 템플릿에 맞춰 훈련된 경우, 다른 템플릿에서 수용 길이가 눈에 띄게 하락하는 문제가 있었다. EAGLE 3.1은 FC 정규화 덕분에 이 하락이 대폭 감소한다.

P-EAGLE: 병렬 초안 생성

EAGLE 3.1과 별도로, 2026년 3월 vLLM 블로그에서 P-EAGLE(Parallel EAGLE)를 소개했다.

기존 투기적 디코딩은 초안 토큰을 자동 회귀적으로 생성한다. 드래프트 헤드가 t₁을 예측하고, t₁을 입력받아 t₂를 예측하는 식이다. 이 순차 구조는 초안 생성 단계에서 병렬화를 막는다.

P-EAGLE는 초안 토큰 k개를 단일 순방향 패스(forward pass)로 동시에 예측한다. 토큰 간 의존성을 완화된 마스크 어텐션으로 처리하며, 실험에서 EAGLE-3 대비 최대 1.69배 처리량 향상을 보였다(NVIDIA B200 기준).

P-EAGLE와 EAGLE 3.1은 독립적인 개선이므로 조합하여 사용할 수 있다.

vLLM 통합과 운영 체크리스트

EAGLE 3.1은 vLLM에 설정 기반 확장(config-driven extension)으로 통합된다. 기존 EAGLE 3 설정에서 speculative_config의 버전만 바꾸면 된다.

vLLM 배포 전 확인 사항:

1. 드래프트 모델 체크포인트: EAGLE 3 체크포인트를 그대로 사용 가능. 재훈련 불필요.
2. 긴 컨텍스트 여부 확인: 평균 컨텍스트가 16K 이상이라면 EAGLE 3.1 전환 효과가 크다.
3. 수용률 모니터링: 배포 후 speculative_num_accepted_tokens 메트릭으로 수용 길이를 확인한다. EAGLE 3 대비 향상이 보여야 정상.
4. 배치 크기별 이득 평가: 낮은 동시성(C≤4)에서 지연 시간 중심 서빙이라면 효과가 가장 크다.
5. 채팅 템플릿 변경 계획: 서비스에서 여러 채팅 템플릿을 사용 중이라면 EAGLE 3.1이 필수.

수용률이 개선되지 않는 경우:

• 컨텍스트가 짧고 시스템 프롬프트가 고정된 환경에서는 EAGLE 3과 차이가 미미하다.
• 드래프트 모델의 도메인 미스매치가 더 큰 요인일 수 있다. 이 경우 도메인별 드래프트 헤드 훈련을 검토한다.

투기적 디코딩 방법 비교

EAGLE 3.1을 맥락 안에서 이해하기 위해 주요 방법들을 비교한다.

한계와 열린 질문

현재 한계:

• EAGLE 3.1은 드래프트 헤드가 타깃 모델의 숨겨진 상태에 접근할 수 있어야 한다. 블랙박스 API로는 사용할 수 없다.
• 드래프트 헤드는 타깃 모델과 아키텍처가 매칭되어야 한다. Llama 3 드래프트 헤드로 Qwen 3 타깃을 서빙할 수는 없다.
• 높은 동시 요청 수(C≥32)에서는 투기적 디코딩의 이득 자체가 줄어든다. 배치 효율이 이미 충분히 높기 때문이다.

Open question: 투기적 디코딩의 수용 길이가 내려가기 시작하는 컨텍스트 길이 임계점은 모델 아키텍처에 따라 다르다. EAGLE 3.1이 이 임계점을 일반적으로 얼마나 올리는지 — 모델 계열별 체계적인 측정 — 은 아직 미완이다.

정리

EAGLE 3.1은 EAGLE-3의 핵심 혁신(다층 특성 융합)을 유지하면서, 실제 운영에서 발견된 어텐션 드리프트를 FC 정규화 하나로 해결한다. 수정은 최소화되어 있고(추가 파라미터 없음), 효과는 크다(긴 컨텍스트에서 수용 길이 2배).

투기적 디코딩을 이미 배포하고 있다면, EAGLE 3에서 3.1로의 전환은 재훈련 없이 가능하며 특히 다음 환경에서 효과적이다:

• 평균 응답 컨텍스트가 16K 토큰을 넘는 서비스
• 여러 채팅 템플릿을 지원하는 다목적 API
• 낮은 동시성에서 p50/p99 지연 시간을 관리하는 환경

투기적 디코딩이 처음이라면, EAGLE 3.1 + vLLM 조합이 현재 시점에서 가장 실용적인 출발점이다.

References

• EAGLE 3.1: Advancing Speculative Decoding Through Collaboration Between the EAGLE Team, vLLM, and TorchSpec — vLLM Blog (2026-05-26)
• EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test — arXiv:2503.01840 (2026-03)
• P-EAGLE: Faster LLM inference with Parallel Speculative Decoding in vLLM — vLLM Blog (2026-03-13)
• EAGLE-3 Speculative Decoding on AMD Instinct GPUs — vLLM Blog (2026-07-13)
• Meet EAGLE 3.1: The Speculative Decoding Algorithm That Fixes Attention Drift in LLM Inference — MarkTechPost (2026-05-27)
• Eagle-3 Speculative Decoding on GPU Cloud: 3-4x Faster LLM Inference — Spheron Blog (2026)
• Speculative Decoding in Practice: How EAGLE3 Makes LLMs Faster Without Changing Their Outputs — Hugging Face Blog