추측 디코딩, 토큰을 미리 쓰면 메모리 병목이 풀릴까

요즘 AI 추론 속도 이야기를 보면 ‘토큰을 미리 만든다’는 표현이 자주 보인다.

처음에는 작은 모델이 정답을 대신 맞히는 기술처럼 들렸는데, 조금 더 들여다보니 큰 모델이 무거운 일을 몇 번 덜 하게 만드는 쪽에 가깝다.

다만 후보를 미리 만든다고 HBM 병목이 사라지는 것은 아니다. 초안을 만드는 모델과 검증, 캐시도 결국 자리를 차지한다.

그렇다면 추측 디코딩은 AI 메모리의 가치를 낮추는 기술일까, 아니면 같은 메모리를 더 바쁘게 쓰게 만드는 기술일까?

이전 Tech(KR) 글: MoE가 덜 계산해도, 전문가 가중치는 어디에 둘까



핵심 요약

  • 추측 디코딩은 작은 draft 모델이 여러 후보 토큰을 먼저 제안하고, 큰 target 모델이 이를 한 번에 검증하는 추론 방식이다.
  • 실제로 받아들여진 후보가 많을 때에만 target 모델의 한 번의 실행을 여러 유효 토큰에 나눠 쓸 수 있다.
  • draft의 가중치·KV 캐시, 검증 연산, 후보 길이, batch와 요청 유형이 추가 비용을 만들기 때문에 항상 빨라지는 것은 아니다.
  • 정확한 확률 샘플링 방식은 target의 출력 분포를 보존할 수 있지만, 매번 눈으로 같은 문장이 나온다는 뜻은 아니다.
초안 모델이 여러 토큰 후보를 만들고, 큰 모델이 이를 검증한 뒤 일부를 수락하거나 다시 계산하는 speculative decoding 흐름 개념도.
Speculative decoding은 작은 초안 모델의 후보를 큰 모델이 한 번에 검증해, 수락된 구간만 다음 생성으로 이어 가는 방식이다.

이 글을 위해 AI로 생성한 자체 제작 오리지널 개념도이며, 제3자 이미지·논문 도식·로고·상표를 사용하지 않았습니다.



큰 모델이 여는 문을 한 번에 여러 후보 앞에서 열어 본다

일반적인 LLM 출력 과정은 토큰 하나를 만든 뒤, 그 결과를 다시 입력에 붙여 다음 토큰을 만드는 순서로 이어진다. 이때 큰 target 모델은 토큰마다 다시 실행되고, 가중치와 KV 캐시에 반복적으로 접근한다. 특히 작은 batch의 대화형 추론에서는 이 반복이 지연 시간과 메모리 대역폭의 영향을 크게 받을 수 있다.

추측 디코딩에서는 더 가벼운 draft 모델이 다음 후보를 여러 개 먼저 제안한다. 이후 target 모델이 후보들을 한 번의 검증 과정에서 순서대로 확인한다. 후보 가운데 실제로 받아들여진 토큰이 여러 개라면, 원래 여러 차례였을 target 실행을 더 많은 유효 출력 토큰에 나눠 쓴 셈이 된다.

여기서 중요한 숫자는 후보를 몇 개 만들었는지가 아니라 acceptance length, 즉 target 검증 뒤 실제로 살아남은 토큰 수다. NVIDIA의 2026년 9월 기술 설명도 전체 시간에는 target 검증뿐 아니라 draft 생성 시간이 함께 들어가며, draft 길이·acceptance·메모리 부담을 같이 봐야 한다고 설명한다.



‘출력이 같다’는 말도 두 가지로 나눠 봐야 한다

추측 디코딩을 설명할 때 결과가 같다고 말하는 경우가 있다. 확률 샘플링에서는 정확한 acceptance·rejection과 보정 샘플링을 올바르게 적용할 때 target 모델의 샘플링 분포를 보존한다는 뜻이다. 무작위성이 있는 생성에서 매번 똑같은 문장이 나온다는 뜻은 아니다.

greedy decoding처럼 결정적으로 다음 토큰을 고르는 경우에는 조건이 또 다르다. 같은 tokenizer, logit 처리, tie-breaking, acceptance 규칙 아래에서 target의 토큰과 일치하는 제안만 유지하고 처음 어긋난 지점부터 target 결과로 돌아가면, 표준 greedy decode와 같은 결정 경로를 만들 수 있다.

반대로 후보를 더 쉽게 받아들이거나 draft·router·target 자체를 바꾸는 방법은 별도의 품질 검증이 필요하다. 더 빠르다는 이유만으로 ‘동일 출력’이나 ‘정확한 분포 보존’까지 따라오는 것은 아니다.



HBM 병목이 사라지는 것이 아니라, 유효 토큰당 부담이 달라진다

target 모델이 한 번 실행될 때 받아들여지는 토큰이 늘어나면, 반복적인 target 가중치 접근을 유효 출력 토큰에 나눠 볼 여지가 생긴다. NVIDIA는 이 과정이 일부 조건에서 target의 arithmetic intensity를 높여 decode의 성격을 memory-bound에서 compute-bound 쪽으로 옮길 수 있다고 설명한다. 그렇다고 HBM 대역폭의 가치가 없어지는 것은 아니다.

draft도 공짜가 아니다. 외부 draft 모델은 자체 가중치와 KV 캐시가 필요하고, target에 보조 구조를 붙이는 방식도 추가 레이어·상태 또는 hidden state를 사용한다. 후보 길이를 길게 잡으면 target 검증과 attention, 통신, KV 관련 부담도 함께 커질 수 있다.

결국 이득은 조건부다. acceptance length가 낮으면 draft가 만든 후보와 검증 비용을 회수하지 못할 수 있고, 이미 compute-bound인 환경에서는 후보를 더 늘리는 것이 오히려 부담이 될 수 있다. 긴 문맥, 높은 동시성, 모델 업데이트 뒤 달라진 요청 분포도 모두 다시 측정해야 하는 변수다.



관련 기업

NVIDIA(NASDAQ: NVDA)는 TensorRT-LLM에서 speculative decoding, quantization, KV cache 등을 포함한 GPU용 LLM 추론 최적화 기능을 제공한다. 이 글의 target·draft runtime과 GPU 메모리 활용을 읽는 데는 관련이 있지만, 특정 최적화가 특정 고객의 배포나 GPU 추가 구매로 이어졌다고 볼 근거는 별도로 필요하다.

AMD(NASDAQ: AMD)의 Instinct MI350 Series 공식 제품 페이지는 GPU당 최대 288GB HBM3E와 최대 8TB/s의 peak theoretical memory bandwidth를 제시한다. 이런 용량과 대역폭은 target·draft 구조가 고려하는 하드웨어 변수지만, 제품 사양만으로 실제 애플리케이션의 지연 시간이나 특정 추측 디코딩 구현의 성능을 추론할 수는 없다.

국내에서는 SK hynix(KRX 000660)의 2026년 2분기 자료에서 HBM, AI 서버 DRAM, eSSD 제품군을, Samsung Electronics(KRX 005930)의 2026년 2분기 자료와 PM1763 발표에서 HBM·서버 DRAM·enterprise SSD 사업 노출을 확인할 수 있다. HBM은 target 가중치와 연산 가까이의 고대역폭 메모리, 서버 DRAM과 eSSD는 다른 계층의 용량·저장 역할로 나눠 봐야 한다. 이 제품군이 특정 draft 모델이나 논문의 장비에 채택됐다는 뜻은 아니며, 효율 개선이 곧바로 매출이나 주가로 이어진다는 주장도 아니다.



투자 체크포인트

  • acceptance length의 평균뿐 아니라 요청 유형별 분포가 실제로 유지되는지
  • draft 생성 시간과 target 검증 시간이 합쳐진 뒤에도 사용자당 토큰 지연이 개선되는지
  • p50 평균값과 함께 p95·p99 지연, GPU당 동시성, fleet 전체 처리량을 따로 보는지
  • target·draft의 상주 가중치와 KV 캐시가 GPU 메모리를 얼마나 차지하는지
  • 기업의 경우 고객 인증, 실제 출하, HBM·DRAM·NAND 제품 mix와 재고·설비투자가 공식 자료로 확인되는지

추론 최적화 기사 하나로 메모리 반도체 수요나 개별 종목의 방향을 확정하기는 어렵다. 이 글은 매수·매도 추천이 아니라, AI 추론 구조와 메모리 공급망을 읽기 위한 정보다.



빠른 추론이 메모리 수요를 한 방향으로 정하지 않는 이유

추측 디코딩이 잘 작동하면 같은 장비에서 더 많은 요청을 처리하거나, 사용자가 느끼는 토큰 간 지연을 줄일 가능성이 생긴다. 하지만 서비스 사업자는 확보한 HBM을 절약하는 대신 더 높은 동시성에 쓸 수도 있고, draft와 KV 캐시를 위해 다른 메모리 자원을 더 쓸 수도 있다. 알고리즘 효율이 메모리 수요를 늘리는지 줄이는지는 서비스 규모와 서버 설계까지 봐야 한다.

그래서 HBM, 서버 DRAM, eSSD를 서로 대체재처럼 놓기보다는 각 계층이 어떤 상태와 가중치를 맡는지 보는 편이 낫다. 추측 디코딩은 HBM을 덜 쓰는 마법이라기보다, 큰 모델의 비싼 한 회전을 더 많은 유효 토큰에 배분할 수 있는지 시험하는 방식에 가깝다.



Appendix. draft 모델과 target 모델은 무엇이 다를까

target 모델은 최종 검증을 맡는 큰 모델이고, draft 모델은 다음 토큰 후보를 빠르게 제안하는 가벼운 모델 또는 보조 구조다. target이 후보를 모두 받아들이는 경우도 있고, 중간에서 거절한 뒤 target의 결과로 이어지는 경우도 있다.

따라서 추측 디코딩의 성패는 draft가 얼마나 빨리 후보를 만들었는지와, target이 그 후보를 얼마나 자주 받아들였는지의 균형에 달려 있다. 후보가 자주 맞을수록 이득을 기대할 수 있지만, 후보를 만드는 비용과 메모리 상태까지 함께 계산해야 한다.



출처 및 확인일

라벨: , , , ,

댓글 없음:

댓글 쓰기

안녕하세요 :)

피드 구독하기: 댓글 (Atom)