vLLM Speculative Decoding, 낮은 QPS에서 지연을 줄이는 설정과 측정법

AI를 활용하여 생성한 이미지입니다.

AI · LLM · 중급 가이드

vLLM의 Speculative Decoding은 큰 모델이 모든 토큰을 처음부터 계산하는 대신, 작은 제안 경로가 다음 토큰을 미리 제시하고 큰 모델이 검증하는 방식이에요. 목표는 답변 품질을 바꾸지 않으면서 토큰 사이의 대기 시간을 줄이는 것입니다. 다만 요청이 많고 GPU가 계산으로 꽉 찬 환경보다, 낮은 QPS와 메모리 병목이 있는 서비스에서 먼저 시험할 가치가 있어요.[1]

긴 고정 문장을 반복해서 넣는 서비스라면 프롬프트 캐싱 설계 글도 함께 보세요. Prefix Caching은 이미 처리한 prefix의 KV cache를 재사용하고, Speculative Decoding은 다음 토큰 생성을 앞당기는 접근이라서 병목 지점이 다릅니다.

먼저 TTFT와 TPOT를 분리해요

첫 토큰까지 걸리는 시간은 TTFT이고, 생성 중 토큰 사이 간격은 TPOT예요. Speculative Decoding은 주로 생성 단계의 지연을 줄이는 기능이므로, 전체 응답 시간 하나만 재면 효과가 숨겨질 수 있습니다. 같은 모델·프롬프트·출력 길이로 일반 실행과 speculative 실행을 나눠 TTFT, TPOT, 전체 시간, tokens per second를 각각 기록하세요.

방법마다 필요한 비용이 달라요

vLLM은 EAGLE, MTP, draft model, PARD, MLP 같은 모델 기반 방식과 n-gram, suffix decoding 같은 가벼운 방식을 지원합니다. 모델 기반 방식은 더 큰 지연 감소를 노릴 수 있지만 제안용 구성과 메모리가 필요하고, n-gram·suffix 방식은 별도 draft 모델 없이 시작할 수 있는 대신 이득이 제한적일 수 있어요.[1]

처음부터 큰 draft model을 붙이지 말고, 현재 요청 패턴에 반복되는 문자열이 있는지부터 보세요. 코드 자동 완성이나 짧은 반복 문구처럼 최근 입력에서 다음 토큰을 예측하기 쉬운 작업은 단순한 방식으로도 변화를 볼 수 있습니다. 반대로 창작형 답변이나 매 요청의 주제가 크게 달라지는 서비스는 채택률이 낮을 수 있어요.

설정은 기본 경로와 비교 가능한 형태로 남겨요

vLLM 실행 시 --speculative-config로 사용할 방법과 제안 토큰 수를 지정하는 구조를 사용합니다.[1] 정확한 필드와 지원 방법은 설치한 vLLM의 안정 문서에서 확인해야 해요. 개발 버전 문서의 예시를 그대로 복사하지 말고, 현재 설치 버전의 도움말과 stable 문서를 기준으로 설정을 고정하세요.

vllm serve <target-model> \
  --speculative-config '<method-and-token-settings>'

위 명령의 꺾쇠 괄호는 그대로 입력하는 값이 아니에요. 실제 방법과 제안 토큰 수를 선택해 채우는 자리입니다. 실행 전에 일반 경로의 명령과 설정 파일을 보존해 두면 성능이 나쁠 때 바로 되돌릴 수 있습니다. 제안 토큰 수를 높이면 무조건 빨라지는 것도 아니에요. 검증 단계가 길어지고 GPU 메모리가 줄어들 수 있습니다.

벤치마크는 서비스 부하와 비슷하게 구성해요

한 개 요청만 보내는 테스트는 실제 서비스의 스케줄링 비용을 보여주지 못합니다. 낮은 QPS와 중간 QPS를 따로 만들고, 입력 길이와 출력 길이를 고정한 뒤 warm-up 요청을 제외하고 여러 번 측정하세요. p50만 보지 말고 p95 지연과 오류율도 확인해야 해요.

1. 일반 실행으로 같은 프롬프트 묶음을 먼저 측정해요.
2. Speculative Decoding을 켜고 동일한 순서와 출력 제한으로 다시 측정해요.
3. TTFT·TPOT·전체 시간·GPU 메모리·p95를 표로 비교해요.
4. 출력의 의미와 종료 조건이 달라지지 않았는지 샘플을 대조해요.
5. 효과가 없으면 제안 토큰 수를 줄이거나 기본 경로로 되돌려요.

Prefix Caching과 동시에 켤 때의 순서

Prefix Caching은 공통 prefix의 KV cache를 재사용해서 prefill 계산을 줄이는 기능이에요. 같은 긴 문서를 반복해서 질의하는 경우에는 도움이 될 수 있지만, 답변을 생성하는 decode 시간이 긴 작업이나 공통 prefix가 거의 없는 요청에서는 이득이 작습니다.[2] 그래서 두 기능을 한 번에 켜면 무엇이 효과를 냈는지 알 수 없어요.

먼저 Prefix Caching 없이 speculative만, 그다음 speculative 없이 Prefix Caching만, 마지막으로 둘 다 켜는 세 조건을 비교하세요. 입력 처리 시간이 줄었는지와 생성 시간이 줄었는지를 분리하면 설정 조합의 가치를 판단하기 쉽습니다.

적용하지 않는 편이 나은 경우

GPU가 이미 높은 동시 요청을 처리하고 있거나, logprobs의 재현성이 중요한 평가 파이프라인이라면 신중해야 해요. vLLM 문서도 speculative 실행에서 logprobs의 안정성을 보장하지 않는다고 안내합니다.[1] 낮은 QPS의 대화형 응답에서 지연이 실제로 줄고, 메모리와 품질 검증을 통과할 때만 운영 설정으로 올리는 편이 안전합니다.

채택률이 낮으면 설정을 되돌려요

Speculative Decoding은 제안 토큰을 많이 만들수록 좋아지는 구조가 아니에요. 큰 모델이 제안을 자주 거부하면 제안 단계와 검증 단계가 모두 남아 기본 경로보다 느려질 수 있습니다. 제안 토큰 수를 늘리는 실험은 GPU 메모리와 p95 지연을 함께 기록할 때만 의미가 있어요.

출력 품질은 같은 문자열이 나왔는지만으로 판단하지 마세요. 구조화된 응답이라면 JSON 형식, 종료 시점, 도구 호출 여부, 필수 필드 누락을 비교하고, 일반 대화라면 핵심 사실과 문장 길이가 크게 달라지지 않는지 샘플을 나란히 보세요. vLLM 문서가 이 기능을 정확도 손실 없이 동작하도록 설명하더라도, 하드웨어 정밀도와 배치 조건에 따른 차이는 남을 수 있습니다.[1]

서비스에 넣기 전 운영 지표를 정해요

운영 환경에서는 평균 한 개보다 분포가 중요합니다. 낮은 QPS에서 p50 TPOT가 줄었지만 p95가 늘었다면 일부 요청이 제안 경로 때문에 오래 기다리는 것일 수 있어요. 반대로 p95가 안정되고 GPU 메모리 여유도 남는다면 대화형 응답에 적용할 근거가 생깁니다.

로그에는 vLLM 버전, 사용한 speculative method, 제안 토큰 수, 입력·출력 토큰 수, 동시 요청 수를 남기세요. 개인 정보가 들어가는 원문 프롬프트는 저장하지 않고 길이와 해시처럼 운영에 필요한 값만 기록하는 편이 안전합니다. 설정을 바꾼 날에는 일반 경로의 기준값도 함께 보관해야 효과를 재현할 수 있습니다.

Prefix Caching과 겹치는 지점을 확인해요

긴 시스템 지침이나 동일한 문서를 여러 번 넣는 서비스라면 Prefix Caching이 prefill 시간을 줄일 수 있어요. 하지만 답변 생성이 길면 decode 시간이 그대로 남고, 매 요청의 앞부분이 달라지면 cache hit가 낮아집니다.[2] 이런 서비스에 speculative만 붙여도 기대한 전체 응답 시간 감소가 나타나지 않을 수 있습니다.

세 조건을 나누어 시험하면 원인을 볼 수 있어요. 기본 설정, Prefix Caching만 켠 설정, Speculative만 켠 설정을 비교한 다음 두 기능을 함께 켜세요. 입력이 긴데 첫 토큰이 느리면 Prefix Caching 쪽을, 첫 토큰은 빠른데 생성이 느리면 Speculative 쪽을 우선 확인하는 식입니다.

지원 범위와 되돌리기

vLLM stable 문서에는 여러 speculative 방법과 설정 스키마가 정리되어 있지만, 설치 버전에 따라 지원 범위와 호환 조건을 확인해야 해요.[1] 특히 pipeline parallelism과의 조합처럼 제한이 있는 기능은 운영 GPU 수와 병렬화 방식을 먼저 대조하세요. 설정 파일을 별도로 두고 기본 실행 명령을 보존하면 오류가 생겼을 때 플래그 하나를 제거해 빠르게 기본 경로로 돌아갈 수 있습니다.

성능이 개선되지 않았다는 결과도 유효합니다. QPS가 높거나 요청마다 출력이 길고, GPU 계산이 병목인 환경에서는 다른 최적화가 더 직접적일 수 있어요. 측정값이 기준을 넘지 못하면 speculative를 끄고 batching, 입력 길이, KV cache 사용량을 먼저 조정하세요.

측정 조건을 고정해야 비교가 돼요

Speculative Decoding을 비교할 때는 모델 가중치와 양자화 방식뿐 아니라 샘플러 설정, 최대 출력 토큰, 입력 길이도 고정해야 합니다. 한 조건만 달라져도 채택률과 TPOT가 바뀔 수 있어요. 특히 스트리밍 응답은 네트워크 전송 시간이 섞이므로 서버 내부 지표와 사용자가 체감하는 전체 시간을 나눠 기록하는 게 좋습니다.

낮은 QPS에서 효과를 봤다면 바로 동시 요청을 늘리지 마세요. 요청 수를 한 단계씩 올리면서 GPU 메모리, 대기열 길이, p50·p95 TPOT를 함께 기록해야 합니다. speculative 경로가 단일 요청에서는 빨라도 배치가 커지면 검증 작업과 메모리 사용량 때문에 오히려 지연이 늘 수 있어요. 이런 결과는 실패가 아니라 적용 가능한 부하 범위를 알려주는 자료입니다.

draft model 방식은 제안 모델을 별도로 관리해야 하므로 버전과 토크나이저 호환성을 기록해 두세요. 모델이 달라지면 같은 프롬프트라도 제안 토큰의 분포가 바뀌고, 채택률 비교가 이전 실험과 이어지지 않을 수 있습니다. n-gram이나 suffix처럼 별도 모델을 덜 쓰는 방식부터 시작하면 메모리 증가 없이 기준선을 만들기 쉽습니다.[1]

운영 전 되돌리기 경로를 준비해요

설정 파일에는 기본 실행 명령과 실험용 실행 명령을 분리해 두는 편이 안전합니다. 실험용 설정에서 오류가 나거나 p95가 기준을 넘으면 speculative 설정만 제거해 기본 경로로 돌아갈 수 있어야 해요. Prefix Caching을 함께 시험할 때도 세 조건을 별도로 남겨야 어느 기능이 입력 처리 시간을 줄였는지 설명할 수 있습니다.[2]

품질 확인은 문자열 일치만으로 부족합니다. 구조화된 출력은 JSON 파싱, 필수 필드, 도구 호출과 종료 조건을 비교하고, 대화형 출력은 동일한 질문을 여러 번 보내 사실 오류와 응답 길이를 확인하세요. 운영 반영 기준을 미리 정하지 않으면 작은 p50 개선 때문에 메모리와 p95 악화를 받아들이게 됩니다.

실험 기록을 남겨야 재현돼요

성능 결과를 남길 때는 단순히 “빨라짐”이라고 쓰지 말고 실행 조건을 함께 적으세요. 대상 모델, vLLM 버전, GPU 수와 메모리, speculative method, 제안 토큰 수, 입력·출력 토큰 수, 동시 요청 수를 한 줄에 기록하면 다음 실험과 비교하기 쉽습니다.[1]

응답 품질은 같은 출력이 나왔는지보다 서비스 계약이 지켜졌는지로 판단하세요. JSON 스키마, 종료 토큰, 도구 호출, 최대 길이 초과 여부를 자동으로 확인하고, 사람이 읽는 답변은 같은 질문을 여러 번 보내 사실 오류를 따로 검토합니다. 낮은 QPS에서 얻은 개선을 다른 부하에 일반화하지 않는 태도가 중요해요.

Prefix Caching을 쓰는 서비스는 cache hit가 실제로 발생하는 입력 구조인지 먼저 살펴보세요. 공통 prefix가 짧거나 요청마다 시스템 지침이 달라지면 prefill 절감 효과가 작을 수 있습니다.[2] 이 경우에는 speculative의 생성 지연만 따로 측정해야 결과가 섞이지 않습니다.

낮은 QPS에서 특히 조심할 점

요청이 드문 서비스는 배치 처리량보다 첫 토큰까지의 대기 시간이 더 중요할 수 있어요. 이때 speculative decoding을 켜고 평균 토큰 속도만 비교하면 실제 사용자의 체감과 다른 결론이 나옵니다. 단일 요청, 짧은 입력, 긴 입력, 여러 동시 요청을 나눠 p50과 p95를 각각 기록하세요.

제안 모델의 출력이 자주 거부되면 검증 오버헤드가 커져서 오히려 느려질 수 있습니다. 거부율을 직접 측정할 수 없다면 최종 토큰 속도만 보고 기능을 유지하지 말고, 같은 하드웨어에서 일반 디코딩과 동일한 입력 세트로 비교한 뒤 되돌릴 수 있는 설정으로 운영하세요.

Sources

• vLLM: Speculative Decoding [1]
• vLLM: Automatic Prefix Caching [2]