LLM 추론을 빠르게 만드는 대표 기법 중 하나가 추론적 디코딩(speculative decoding)입니다. 작은 드래프터 모델이 여러 토큰을 먼저 제안하고, 큰 타깃 모델이 이를 한 번에 검증합니다. 제안이 맞으면 여러 토큰을 한꺼번에 확정할 수 있어 응답 속도가 빨라집니다.
EAGLE 3.1은 이 접근을 개선한 최신 알고리즘입니다. EAGLE 팀, vLLM, TorchSpec이 공동 공개했으며, EAGLE 1·2·3로 이어진 EAGLE 계열의 실전 배포 안정성을 높이는 데 초점을 둡니다.1
핵심은 단순히 “더 빠르게”가 아닙니다. 실제 서비스 환경에서 추론적 디코딩이 왜 흔들리는지, 그리고 그 흔들림을 어떻게 줄일 것인지에 있습니다.
추론적 디코딩의 약점: 환경이 바뀌면 성능도 흔들린다
추론적 디코딩은 통제된 벤치마크에서는 잘 작동합니다. 하지만 실제 서비스에서는 조건이 계속 바뀝니다. 채팅 템플릿이 달라지고, 입력 컨텍스트가 길어지며, 분포 밖 시스템 프롬프트가 들어올 수 있습니다.1
이런 변화가 생기면 드래프터가 제안한 토큰을 타깃 모델이 덜 받아들이게 됩니다. 결국 한 번에 확정되는 토큰 수가 줄고, 기대했던 추론 가속 효과도 약해집니다.
EAGLE 3.1이 주목한 문제는 이 성능 저하의 한 원인인 어텐션 드리프트(attention drift)입니다.
어텐션 드리프트: 드래프터가 원문보다 자기 초안에 끌리는 현상
어텐션 드리프트는 추측 깊이가 커질수록 드래프터가 원래 문맥의 기준점인 싱크 토큰보다, 자신이 생성한 토큰에 더 많은 주의를 두는 현상입니다.1
쉽게 말하면 초안 작성자가 원문을 덜 보고, 방금 자신이 쓴 문장을 더 믿기 시작하는 상황입니다. 초반에는 문맥을 잘 따라가지만, 여러 토큰을 연속으로 추측할수록 기준이 조금씩 흔들립니다.
이 흔들림은 실전에서 중요합니다. 드래프터의 제안 품질이 낮아지면 타깃 모델이 받아들이는 토큰 길이, 즉 acceptance length가 줄어듭니다. 추론적 디코딩의 이득은 “얼마나 많은 토큰을 한 번에 받아들일 수 있는가”에 달려 있으므로, 어텐션 드리프트는 곧 가속 효과의 병목이 됩니다.
EAGLE 3.1의 해법: 정규화된 상태를 다시 입력으로 사용한다
EAGLE 3.1은 거대한 구조 변경보다 입력 안정화에 초점을 맞춥니다. 구체적으로 각 타깃 히든 상태 뒤와 FC 레이어 앞에 FC 정규화를 추가합니다.1
또한 정규화 이후의 히든 상태를 다음 디코딩 단계의 입력으로 사용합니다.1 이 post-norm 설계는 타깃 모델에 레이어를 계속 덧붙이는 방식이라기보다, 디코딩 단계마다 드래프터를 더 안정적으로 재귀 호출하는 방식에 가깝습니다.1
이 설계의 의미는 명확합니다. 추측 단계가 깊어져도 드래프터의 입력 스케일이 과도하게 흔들리지 않도록 만드는 것입니다. 그 결과 긴 컨텍스트, 채팅 템플릿 변경, 낯선 시스템 프롬프트처럼 실제 배포 환경에서 자주 나타나는 변화에 더 잘 버티는 방향을 지향합니다.
운영 관점: 평균 속도보다 “덜 흔들리는가”를 봐야 한다
EAGLE 3.1은 긴 컨텍스트 작업에서 EAGLE 3 대비 최대 2배 긴 acceptance length를 보였다고 보고됐습니다.1 Kimi K2.6 기반 vLLM 벤치마크에서는 동시성 1에서 per-user output throughput 2.03배도 제시됐습니다.1
다만 운영팀이 봐야 할 지표는 평균 처리량 하나로 충분하지 않습니다. 실제 적용 여부를 판단하려면 다음을 함께 확인해야 합니다.
프롬프트 유형별 acceptance length
긴 입력에서의 성능 저하 폭
채팅 템플릿 변경 이후의 안정성
분포 밖 시스템 프롬프트에서의 fallback 빈도
동시성 조건이 바뀔 때의 처리량 변화
EAGLE 3.1의 메시지는 분명합니다. LLM 추론 최적화는 단순 가속 경쟁을 넘어, 실제 배포 환경의 분포 변화까지 견디는 안정성 문제로 이동하고 있습니다. 추론적 디코딩을 도입하거나 개선하려는 팀이라면 “얼마나 빠른가”만이 아니라 “조건이 바뀌어도 얼마나 일정하게 빠른가”를 기준으로 평가해야 합니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.