추측 디코딩은 가치가 있는가? Blackwell에서 vLLM 프로파일링

URL: https://www.youtube.com/watch?v=XTpyNrEgJQ4 날짜: 2026-10-07 채널: aiDotEngineer

📌 핵심 질문 / 핵심 논점

==추측 디코딩(Speculative Decoding)은 작은 초안 모델이 여러 토큰을 먼저 추측하고 큰 대상 모델이 한 번에 검증하게 만들어, 모든 워크로드에서가 아니라 구조화되고 GPU 여유가 있는 생성 작업에서만 실질적인 이득을 준다.==

• 대상 모델의 정확도를 유지하면서 토큰 생성 단계의 순차적 병목을 줄일 수 있다.
• 두 모델과 두 모델의 KV 캐시를 동시에 수용해야 하므로 GPU 메모리와 동시성 여유가 필요하다.
• 초안 모델의 수용률(acceptance rate), 초당 토큰 수, 실제 지연 시간, 메모리 비용을 업무별로 측정해야 한다.

LLM 요청은 입력을 읽어 KV 캐시를 만드는 프리필(prefill) 단계와 응답 토큰을 순차 생성하는 디코드(decode) 단계로 나뉜다. 추측 디코딩은 프리필을 빠르게 하지 않고 디코드만 가속하므로, 코딩·JSON·SQL처럼 다음 토큰의 선택지가 좁은 작업과 긴 입력에 비해 출력이 충분히 긴 작업에 특히 적합하다. 반대로 창작형 생성, 높은 temperature, 이미 높은 GPU 병렬 사용률, 긴 문서 입력 중심의 RAG에서는 추가 모델을 올리는 비용이 이득을 상쇄할 수 있다.

1. 토큰 생성의 병목과 추측 디코딩의 원리

LLM 추론의 병목을 프리필과 디코드로 분리해야 추측 디코딩의 효과를 올바르게 판단할 수 있다.

1.1. 프리필과 디코드의 두 단계

1. 프리필은 입력을 한 번 읽고 작업 메모리를 만든다

   1. 입력 처리: 모델은 사용자의 질의와 들어온 모든 토큰을 읽고 처리한다.
   2. KV 캐시 생성: 처리 결과로 KV 캐시를 만들며, 이는 나머지 질의 동안 모델이 사용하는 작업 메모리다.
   3. 일회성 작업: 하나의 질의에서 입력을 읽고 KV 캐시를 구성하는 일은 기본적으로 한 번 수행된다.

2. 디코드는 응답을 한 토큰씩 만든다

   1. 순차 의존성: 각 토큰이 앞선 토큰에 의존하므로 다음 토큰을 동시에 확정하기 어렵다.
   2. 반복 실행: 응답 토큰을 실제로 생성하는 과정은 대체로 한 번에 하나씩 진행된다.
   3. 대형 모델 비용: 700억 개 파라미터급 Llama 같은 대형 모델에서는 응답 길이에 따라 최대 수백 회의 직접적인 모델 전송·호출이 발생할 수 있어 비용과 지연 시간이 커진다.

1.2. 작은 초안 모델과 큰 대상 모델의 협력

1. 초안 모델이 여러 토큰을 먼저 제안한다

   1. 저비용 추측: 큰 모델 대신 더 작은 모델이 자동회귀 방식으로 다음 토큰들을 빠르게 추측한다.
   2. 묶음 크기: 한 사이클에 보통 3~5개의 토큰을 제안하도록 설정할 수 있다.
   3. 핵심 가정: 작은 모델이 대상 모델과 비슷한 다음 토큰을 예측할수록 한 번에 처리되는 토큰 수가 늘어난다.

2. 대상 모델이 한 번에 검증한다

   1. 병렬 검증: 정확도를 담당하는 대상 모델은 초안 모델의 예측 묶음을 한 번의 직선 패스(single pass)로 처리한다.
   2. 수용과 거부: 대상 모델은 예측 토큰을 승인하거나 거부한다.
   3. 거부 토큰 재계산: 거부된 위치의 토큰은 대상 모델이 올바른 토큰으로 다시 계산한다.
   4. 출력 보존: 최종 출력은 대상 모델의 검증 결과에 의해 결정되므로 작은 모델의 추측 때문에 대상 모델의 정확도가 낮아지는 구조가 아니다.

3. 속도 향상은 순차 호출을 묶는 데서 나온다

   1. 작은 모델의 빠른 추측: 작은 모델은 대형 모델보다 빠르게 후보 토큰을 만든다.
   2. 큰 모델의 묶음 검증: 대상 모델은 후보를 토큰별로 따로 호출하는 대신 묶음으로 검증한다.
   3. 효과의 조건: 후보가 많이 승인될 때만 여러 토큰을 한 사이클에 확정하는 효과가 커진다.

2. 비용, 메모리, 초안 모델 선택

추측 디코딩은 모델 호출 비용을 줄일 수 있지만, 두 모델을 동시에 서비스하는 새로운 비용을 만든다.

2.1. 추가 모델이 만드는 자원 비용

1. 두 모델을 동시에 호스팅해야 한다

   1. 메모리 증가: 대상 모델 외에 작은 초안 모델의 가중치도 GPU 메모리에 올려야 한다.
   2. KV 캐시 증가: 대상 모델과 초안 모델 각각을 위한 KV 캐시 공간도 별도로 할당해야 한다.
   3. 상대적으로 작은 부담: 초안 모델은 작기 때문에 가중치 증가는 대상 모델보다 작지만, 남는 공간이 부족하면 추측 디코딩 자체가 불가능하다.

2. GPU 여유가 도입 전제다

   1. 적합한 상태: GPU에 사용하지 않는 메모리와 계산 여유가 있을 때 추가 모델을 배치할 수 있다.
   2. 부적합한 상태: 요청을 고도로 병렬 처리하는 워크로드에서는 GPU가 이미 모든 요청을 처리하느라 바쁘므로 초안 모델을 추가해도 의미가 없다.
   3. 판단 기준: 단순히 대상 모델의 단일 요청 속도만 보지 말고, 모델 두 개와 캐시를 넣은 뒤의 실제 동시 처리량과 지연 시간을 함께 봐야 한다.

2.2. Blackwell 단일 GPU 데모 구성

1. 한 GPU에 두 구성을 모두 배치했다

   1. 실험 목적: NVIDIA Blackwell GPU 한 장에서 기본 구성과 추측 디코딩 구성을 모두 실행해 비교했다.
   2. 메모리 분할: 같은 GPU 사용량을 두 서버 또는 두 모델 구성 사이에서 나눠야 했기 때문에 초안 모델이 충분히 작아야 했다.

2. 가중치와 캐시의 공간 배분

   1. 기본 구성: 대상 모델 가중치가 약 16GB를 차지했다.
   2. 초안 모델: 초안 모델 가중치는 약 2.5GB였다.
   3. 남은 공간: 두 가중치를 올린 뒤에도 KV 캐시를 저장할 상당한 공간이 남아 단일 GPU 실험이 가능했다.

2.3. 초안 모델 선택 체크리스트

1. 크기와 비용

   1. 크기 비율: 초안 모델은 대상 모델보다 보통 10~50배 작아야 한다.
   2. 비용의 의미: 두 모델의 속도·정확도 균형을 맞추되, 초안 모델의 운영 비용이 대상 모델의 일부에 불과해야 한다.

2. 토크나이저 호환성

   1. 같은 토크나이저: 두 모델이 같은 토크나이저를 사용해야 후보 토큰을 대상 모델이 직접 검증할 수 있다.
   2. 변환 비용 회피: 토크나이저가 다르면 모델 사이에서 토큰을 수동 변환해야 하므로 구현과 운영이 복잡해진다.

3. 모델 계열과 품질

   1. 같은 계열 우선: 이상적으로는 대상 모델과 같은 모델 패밀리의 작은 모델을 고른다.
   2. 정확도와 속도 동시 평가: 초안 모델이 충분히 정확한지와 실제로 충분히 빠른지를 함께 확인해야 한다.
   3. 균형 문제: 지나치게 작은 모델은 빠르지만 수용률이 낮아지고, 너무 큰 모델은 수용률이 높아도 추가 비용 때문에 이득이 줄어든다.

3. 워크로드에 따른 수용률 차이

추측 디코딩의 핵심 변수는 작은 모델이 대상 모델의 다음 토큰을 얼마나 자주 맞히는가이며, 작업의 구조성과 생성 온도가 그 비율을 좌우한다.

3.1. 구조화된 생성이 유리한 이유

1. 선택지가 좁은 작업

   1. 코딩: 프로그래밍 코드는 문법과 기존 문맥의 제약이 강해 다음 토큰의 후보가 상대적으로 좁다.
   2. JSON: 키, 따옴표, 콜론, 쉼표, 중괄호 등 형식 제약이 강해 초안 모델이 대상 모델과 같은 경로를 따라갈 가능성이 높다.
   3. SQL: 스키마와 문법이 다음 토큰을 제한하므로 후보 수가 넓은 자연어보다 수용률이 높을 가능성이 있다.

2. 수용률의 의미

   1. 정의: 수용률은 초안 모델이 생성한 전체 후보 토큰 가운데 대상 모델이 승인한 토큰의 비율이다.
   2. 성능 연결: 수용률이 높으면 대상 모델이 다시 계산해야 하는 토큰이 줄고, 한 번의 검증으로 확정되는 토큰 수가 늘어난다.
   3. 측정 항목: 수용률만으로 결론 내리지 말고 초당 토큰 수와 실제 지연 시간까지 함께 봐야 한다.

3.2. 창작형 생성이 불리한 이유

1. 다음 토큰의 다양성

   1. 시와 브레인스토밍: 시 쓰기, 아이디어 브레인스토밍처럼 여러 표현이 모두 자연스러운 작업은 다음 토큰 선택지가 넓다.
   2. 초안과 대상의 분기: 작은 모델이 그럴듯한 문장을 만들어도 대상 모델이 다른 표현을 선택할 가능성이 커 수용률이 낮아진다.

2. temperature의 영향

   1. 높은 temperature: 창작형 데모는 temperature를 높게 설정했으며, 그 결과 다음 토큰의 변동성이 커졌다.
   2. 낮은 수용률: 두 번째 사용 사례에서 핵심 신호는 낮은 수용률이었고, 높은 temperature와 생성 다양성이 그 원인으로 설명됐다.
   3. 운영 판단: 창작 작업에 추측 디코딩을 적용할 수는 있지만, 구조화된 작업과 같은 속도 향상을 기대해서는 안 된다.

4. 데모 결과와 프로파일링 방법

실제 작업을 두 탭으로 비교해 구조화된 추론과 창작형 추론의 수용률 차이를 확인했다.

4.1. 구조화된 추론 데모

1. 실행 과정

   1. 비교 화면: 기본 구성과 추측 디코딩 구성을 두 탭에 놓고 수용률이 작업 유형에 따라 어떻게 달라지는지 확인했다.
   2. 초기 장애: 첫 실행에서는 데모가 정상 동작하지 않아 기술적 문제가 발생했다.
   3. 복구 절차: VLM 서버와 시스템을 재시작하고 연결을 다시 확인한 뒤 데모를 다시 실행했다.

2. 속도와 처리량 결과

   1. 속도 배수: 추측 디코딩 구성은 화면 오른쪽에서 기본 구성보다 약 1.6배 빠르게 토큰을 생성했다.
   2. 수용률 확인: 속도 배수와 함께 수용률을 확인해야 하며, 수용률은 생성된 후보 가운데 승인된 토큰의 비율이다.
   3. 초당 토큰 수: 추측 디코딩을 켜면 초당 더 많은 토큰을 생성할 수 있어 처리량이 개선된다.

4.2. 창작형 추론 데모

1. 낮은 수용률 관찰

   1. 예상된 결과: 두 번째 사용 사례에서도 기본 구성과 추측 구성의 비교를 수행했지만, 구조화된 작업과 달리 수용률이 낮았다.
   2. 원인: 높은 temperature와 창작형 작업의 다양성 때문에 다음 토큰을 예측하는 경로가 더 많이 갈라졌다.

2. 프로파일링 해석

   1. 속도 숫자의 한계: 특정 데모에서 1.6배가 나왔더라도 모든 작업에 동일한 배수가 적용되는 것은 아니다.
   2. 현실적인 평가: 실제 애플리케이션의 프롬프트, temperature, 출력 길이, 동시성으로 수용률과 초당 토큰 수를 다시 측정해야 한다.

5. 긴 문맥과 프리필 지배형 애플리케이션

입력 문맥이 길고 출력이 짧은 애플리케이션에서는 디코드 가속만으로 전체 응답 시간이 크게 줄지 않을 수 있다.

5.1. RAG와 문서 분석의 병목

1. 추측 디코딩이 건드리지 않는 구간

   1. 프리필 비가속: 추측 디코딩은 모델이 질의를 읽고 KV 캐시를 만드는 부분이 아니라 응답 토큰을 생성하는 부분을 빠르게 한다.
   2. 긴 입력의 영향: 많은 문서를 모델에 넣으면 KV 캐시 구축에 더 많은 시간이 쓰인다.

2. 출력보다 입력이 긴 경우

   1. RAG 사례: 검색된 문서가 길고 답변이 짧은 RAG 애플리케이션은 입력 처리 시간이 전체 지연 시간에서 큰 비중을 차지한다.
   2. 문서 분석 사례: 다량의 문서를 분석하는 업무도 같은 이유로 프리필 지배형이 된다.
   3. 제한된 효과: 짧은 출력에서 디코드 토큰을 조금 빠르게 만드는 것만으로는 긴 입력을 읽는 비용을 상쇄하기 어렵다.

5.2. 도입 전 질문

1. 업무 구조와 생성 특성

   1. 구조성: 애플리케이션이 코드·JSON·SQL처럼 강하게 구조화되어 있는가?
   2. 창의성: 다양한 표현을 허용하는 창작형 작업인가?
   3. 출력 길이: 입력 문맥에 비해 생성 토큰이 충분히 긴가?

2. 인프라 상태

   1. 비디오 메모리: 초안 모델과 두 KV 캐시를 넣을 충분한 VRAM이 남아 있는가?
   2. 병렬성: GPU가 이미 높은 병렬 처리량으로 포화되어 있지 않은가?
   3. 배치 크기: 작은 배치 크기나 낮은 동시성 환경처럼 추가 초안 모델의 공간을 확보할 수 있는가?

3. 실측 항목

   1. 수용률: 후보 토큰 중 대상 모델이 승인하는 비율을 측정한다.
   2. 처리량: 초당 토큰 수가 실제로 증가하는지 확인한다.
   3. 전체 지연 시간과 비용: 프리필 시간을 포함한 요청 지연 시간, 두 모델의 메모리·운영 비용, 동시 처리량을 함께 비교한다.

6. 도구, 구현 경로, 추가 자료

vLLM의 기본 추측 디코딩 통합은 실험을 시작하기에 적합하며, 더 발전된 방법은 별도 학습이 필요하다.

6.1. vLLM으로 시작하기

1. 권장 구현

   1. vLLM 서비스: 실험은 vLLM의 서비스 메커니즘을 사용해 구현했다.
   2. 문서 활용: vLLM은 추측 디코딩을 시작하는 방법을 설명하는 문서를 제공한다.
   3. 기본형의 장점: 가장 단순한 형태의 추측 디코딩부터 적용해 수용률과 처리량을 확인할 수 있다.

2. 고급 방식

   1. N-gram 방식: 이전 텍스트의 n-gram 패턴을 활용하는 대안이 있다.
   2. EAGLE: 더 발전된 아키텍처 기반 접근으로 소개됐다.
   3. 선택 순서: 처음부터 고급 방식을 도입하기보다 기본형으로 업무 적합성을 검증한 뒤 복잡도를 높이는 접근이 적절하다.

6.2. 읽을거리와 Akamai 자료

1. 외부 자료

   1. General Compute 블로그: “speculative decoding”을 검색했을 때 상위에 보이는 General Compute의 글이 개념을 자세히 설명하는 입문 자료로 언급됐다.
   2. 연구 논문: Google과 다른 한 회사가 발표한 두 편의 연구 논문도 더 깊은 이해를 위한 자료로 언급됐다.
   3. 추가 콘텐츠 계획: 더 많은 블로그 글이나 짧은 코드 스니펫을 포함한 영상으로 내용을 보완하고 싶다는 계획이 언급됐다.

2. Akamai Developers 리소스

   1. 재현 자료: Akamai Developers 웹사이트와 GitHub에서 실험을 재현하는 자료를 찾을 수 있다.
   2. 관심 분야: 논리적 추론 최적화(logical inference optimization)를 중심으로 관련 자료가 제공된다.
   3. 다른 주제: AI 기반 에이전트 구축, 관리형 Kubernetes 서비스, Akamai 기능 활용을 다루는 자료도 있다.
   4. 커뮤니티: 관련 대화를 위한 Discord 채널을 만들고 있는 단계라고 소개됐다.

주요 발언 모음

“추측 디코딩을 켤 가치가 있는지는 여러분의 워크로드에 달려 있습니다.”

“작은 모델이 토큰을 생성하고, 대상 모델이 그 예측을 승인하거나 거부합니다.”

“대상 모델이 정확도를 가진 기반 모델이므로 출력은 그대로 유지됩니다.”

“GPU에 여유 공간이 있다면 고려할 만하지만, 워크로드가 고도로 병렬적이면 의미가 없습니다.”

“추측 디코딩은 모델이 질의를 읽는 부분이 아니라 생성 부분을 빠르게 하도록 설계됐습니다.”

“코딩, JSON, SQL처럼 구조화된 작업은 시 쓰기나 브레인스토밍보다 더 큰 이득을 얻을 가능성이 높습니다.”

“처음 시작한다면 vLLM 문서만으로도 충분히 출발할 수 있습니다.”

핵심 데이터 & 수치

• 3~5개: 초안 모델이 한 사이클에 제안하도록 설정할 수 있는 일반적인 후보 토큰 수.
• 10~50배: 초안 모델이 대상 모델보다 작아야 한다고 제시된 대략적인 크기 비율.
• 약 16GB: Blackwell 단일 GPU 데모에서 기본 대상 모델 가중치가 차지한 공간.
• 약 2.5GB: 같은 데모에서 초안 모델 가중치가 차지한 공간.
• 약 1.6배: 구조화된 추론 데모에서 추측 디코딩 구성이 기록한 생성 속도 향상.
• 수용률: 초안 모델이 생성한 후보 토큰 중 대상 모델이 승인한 토큰의 비율.
• 초당 토큰 수: 추측 디코딩을 켰을 때 처리량 개선을 확인하는 핵심 지표.
• 두 종류의 캐시: 대상 모델과 초안 모델 각각에 KV 캐시 공간이 필요하다.

결론 및 시사점

1. 도입 판단은 워크로드별 벤치마크로 내려야 한다: 모델 이름이나 이론적 속도만 보고 켜지 말고 실제 프롬프트와 생성 설정으로 수용률, 초당 토큰 수, 전체 지연 시간, 비용을 측정한다.
2. 구조화된 생성부터 검증한다: 코딩, JSON, SQL처럼 다음 토큰의 선택지가 좁은 업무가 첫 후보이며, 높은 temperature의 창작형 업무는 후순위로 둔다.
3. 메모리 예산을 먼저 계산한다: 대상 모델 가중치, 초안 모델 가중치, 두 KV 캐시, 동시 요청 버퍼를 모두 GPU에 넣을 수 있어야 한다.
4. 프리필과 디코드를 분리해 해석한다: 긴 RAG 문맥이나 문서 분석처럼 입력 처리가 지배적인 시스템에서는 생성 가속이 전체 지연 시간에 미치는 효과가 제한적이다.
5. 기본형으로 시작한다: vLLM의 기본 추측 디코딩을 이용해 업무별 수용률을 확인한 다음 n-gram이나 EAGLE 같은 고급 방식을 검토한다.
6. 1.6배는 기준점이지 보장값이 아니다: Blackwell 데모의 수치는 구조화된 작업에서 나온 결과이며, 창작형 작업에서는 낮은 수용률 때문에 효과가 줄어든다.
7. 최종 기준은 총소유비용이다: 토큰 생성 비용 절감액이 추가 모델 호스팅과 KV 캐시 비용보다 클 때만 추측 디코딩이 가치가 있다.