LLM 추론을 더 빠르게: EAGLE 3.1과 vLLM의 합작, Speculative Decoding의 진화

LLM이 느린 진짜 이유부터 짚어볼게요

요즘 ChatGPT나 Claude를 쓰면 답변이 한 글자씩 또르륵 나오죠? 그게 그냥 연출이 아니라, 실제로 LLM이 토큰(token, 단어 조각)을 하나씩 차례대로 만들어내는 과정이에요. 이걸 자기회귀 생성(autoregressive generation)이라고 부르는데, 모델이 "안"을 만들고 그걸 다시 입력으로 넣어서 "녕"을 만들고, 또 그걸 넣어서 "하"를 만드는 식이에요.

이 방식의 문제는 한 토큰을 만들 때마다 거대한 모델 전체가 한 번씩 돌아가야 한다는 거예요. 700억 파라미터짜리 모델이라면, 토큰 100개 만드는 데 모델을 100번 통과시켜야 하는 거죠. GPU 메모리에서 가중치를 읽어오는 비용이 어마어마하고, 이게 LLM 응답이 느린 가장 큰 이유예요.

그래서 등장한 게 Speculative Decoding(추측 디코딩)이라는 기법이에요. 이번에 발표된 EAGLE 3.1이 바로 이 영역의 최신 작품이고, vLLM 팀과 TorchSpec 팀이 협업한 결과물이에요.

Speculative Decoding이 뭔지 비유로 풀어볼게요

쉽게 설명하면 이래요. 회사에서 사장님(큰 모델)이 모든 결재를 다 봐야 하면 너무 느리잖아요? 그래서 부장님(작은 모델)이 먼저 "이건 이렇게 처리해야 할 것 같습니다" 하고 초안을 4~5개 한꺼번에 만들어와요. 사장님은 그 초안들을 한 번에 모아서 검토하면서 "이건 맞고, 이건 맞고, 이것까진 OK, 여기부턴 틀렸네" 하고 한 방에 판단해요. 맞는 것까지는 그대로 채택하고, 틀린 지점부터만 직접 다시 작성하는 거예요.

LLM에서도 똑같아요. 작고 빠른 "드래프트 모델(draft model)"이 미리 몇 토큰을 추측해서 만들어두면, 진짜 큰 모델은 그걸 한 번의 forward pass로 검증해요. 핵심은 검증은 병렬로 한 번에 가능하다는 점이에요. 자기회귀로 한 토큰씩 만드는 것보다 훨씬 빠르죠. 만약 드래프트가 잘 맞으면 한 스텝에 3~4개 토큰을 확정할 수 있어요. 출력 결과는 큰 모델이 직접 만든 것과 완전히 동일하다는 게 이 기법의 우아한 점이에요. 품질 손실 없이 속도만 올리는 거죠.

EAGLE이 기존 방식보다 똑똑한 이유

초기 Speculative Decoding은 "작은 모델을 따로 학습시켜서 드래프터로 쓴다"는 단순한 발상이었어요. 그런데 작은 모델은 큰 모델과 분포가 달라서 추측이 자주 빗나갔어요. 빗나가면 그 토큰부터는 버려야 하니까 이득이 줄죠.

EAGLE(Extrapolation Algorithm for Greater Language-model Efficiency)의 아이디어는 "드래프터를 큰 모델의 마지막 hidden state 위에 얹자"는 거예요. 큰 모델이 이미 계산해둔 풍부한 표현(feature)을 재활용해서 다음 토큰을 예측하니까, 단순히 작은 LLM을 따로 돌리는 것보다 훨씬 정확도가 높아요. 그래서 한 번에 더 많은 토큰을 채택할 수 있고, 결과적으로 처리량(throughput)이 더 늘어나죠.

버전이 올라가면서 EAGLE은 점점 정교해졌어요. EAGLE-2는 트리 형태의 후보 토큰을 만들어서 더 다양한 경로를 동시에 탐색했고, EAGLE-3는 표현 재사용을 더 깊이 끌어와서 정확도를 높였어요. 이번 EAGLE 3.1은 거기에 더해 vLLM과의 통합, 그리고 TorchSpec(PyTorch 진영의 speculative decoding 라이브러리)과의 협업으로 실전 배포 환경에서 바로 쓸 수 있게 다듬어졌다는 점이 핵심이에요.

vLLM과의 통합이 왜 중요한가

vLLM은 현재 LLM 서빙 분야에서 가장 널리 쓰이는 오픈소스 엔진이에요. PagedAttention이라는 메모리 관리 기법으로 처리량을 비약적으로 늘려서 표준으로 자리잡았죠. 많은 회사가 자체 LLM 서비스를 vLLM 위에 올리고 있어요.

EAGLE 같은 기법은 논문에선 멋져 보여도, 실제 서빙 시스템에 녹여 넣는 게 만만치 않아요. 배치 처리, KV 캐시 관리, 연속 배칭(continuous batching) 같은 운영 환경의 복잡성과 잘 맞물려야 하거든요. EAGLE 3.1이 vLLM 팀과 직접 협업해서 통합됐다는 건, 운영 환경에서 별도 튜닝 없이 바로 속도 향상을 누릴 수 있다는 뜻이에요. 보통 이론적인 2~3배 가속이 실전에선 1.5배도 안 나오는 경우가 많은데, 네이티브 통합은 이 갭을 줄여줘요.

TorchSpec과의 협업도 의미가 커요. PyTorch 생태계에서 speculative decoding이 1급 시민으로 자리잡는다는 신호거든요. 향후 다른 모델이나 다른 서빙 프레임워크에서도 비슷한 패턴이 더 쉽게 적용될 수 있게 되는 거죠.

비슷한 기술들과의 관계

LLM 가속 분야엔 여러 갈래가 있어요. 양자화(quantization)는 모델 가중치를 8비트나 4비트로 줄여서 메모리와 연산을 아끼는 방식이고, Medusa는 EAGLE과 비슷하게 여러 헤드를 붙여 multi-token 예측을 하는 기법이에요. Lookahead Decoding, PLD(Prompt Lookup Decoding) 같은 변형도 있고요.

EAGLE 계열은 그중에서도 "품질 손실 없는 정확한 가속"이라는 점에서 평가가 좋아요. 양자화는 미세하게라도 품질이 떨어질 수 있지만, speculative decoding은 출력이 원본과 완전히 같다는 보장이 있거든요. 그래서 품질에 민감한 서비스에 부담 없이 적용할 수 있죠.

한국 개발자에게 어떤 의미일까

자체 LLM을 서빙하는 회사들에겐 정말 반가운 소식이에요. 네이버 하이퍼클로바X, 카카오의 자체 모델, 그리고 LLM API를 자체 GPU로 돌리는 스타트업들 모두 비용의 큰 부분이 GPU 시간이에요. EAGLE 3.1 같은 기법으로 처리량을 1.5~3배 올릴 수 있다면, 그만큼 인프라 비용이 줄거나 같은 인프라로 더 많은 사용자를 받을 수 있어요.

특히 vLLM을 이미 쓰고 있다면 도입 장벽이 낮아요. 본인 모델에 맞는 EAGLE 드래프터를 학습시키거나, 공개된 체크포인트를 활용해서 붙이는 정도의 작업으로 효과를 볼 수 있거든요. 사이드 프로젝트에서 오픈소스 LLM을 굴리는 개발자들에게도 충분히 시도해볼 만한 영역이에요.

정리하며

EAGLE 3.1은 화려한 신모델 발표는 아니지만, LLM을 실제로 서비스하는 사람들에게 가장 와닿는 종류의 발전이에요. 같은 GPU, 같은 모델, 같은 출력 품질로 더 많은 요청을 처리할 수 있다는 건 비용과 사용자 경험 양쪽에 직접적인 영향을 주거든요.

LLM 서빙을 직접 운영해보신 분 계신가요? Speculative decoding을 실전에 적용해본 경험이나, 어떤 가속 기법이 가장 효과가 컸는지 같이 이야기 나눠보면 좋겠어요.