Adaptive Verification

Adaptive Verification (적응형 검증)

추측 디코딩은 더 많은 연산을 써서 디코드 스텝을 줄이는 기법이에요. 배치 크기 1에서는 훌륭한 거래이지만, 배치 크기 256에서는 훨씬 섬세한 균형이 필요해요. Adaptive Verification(적응형 검증)은 스텝마다 드래프트를 어느 정도 검증할지를 결정해서, 드래프트 토큰이 실제 토큰과 연산을 놓고 경쟁할 때 생기는 처리량 손실을 줄여줘요.

출처: 문서

본문

배경

추측 디코딩은 더 많은 연산으로 디코드 스텝을 줄여요. 배치 크기 1에서는 좋은 거래인데, GPU가 메모리 바운드 상태라 연산 여유가 있어 추가 드래프트 토큰이 거의 공짜에 가깝기 때문이에요. 하지만 배치 크기 256에서는 훨씬 까다로워져요. 드래프트 토큰이 이제 실제 토큰과 같은 연산을 두고 경쟁하고, 거부된 토큰마다 낭비된 연산이 되며 그렇게 쌓이면 처리량이 떨어져요.

이는 위치별 수락율(position-wise acceptance)이 빠르게 감소하기 때문에 중요해요. GPU가 메모리 바운드일 동안에는 그 슬롯이 사실상 공짜라 도박할 가치가 있지만, GPU가 포화되면 도박은 실제 처리량 비용을 가지게 돼요. 이 전환점은 로드와 워크로드에 따라 달라지는 수락율에 따라 움직이므로, 고정된 num_speculative_tokens는 여러 동시성(concurrency)에서 항상 맞을 수 없어요.

동작 방식

Adaptive Verification은 대신 스텝마다 드래프트를 얼마나 검증할지 결정해요. 모든 (요청, 위치) 드래프트 슬롯이 생존 확률(survival probability), 즉 그 요청의 위치별 신뢰도의 누적 곱으로 점수가 매겨지고, 점수가 높은 슬롯부터 전역 예산이 소진될 때까지 수락돼요. 슬롯은 요청 간에 경쟁해요. 신뢰도 높은 요청의 위치 5가 의심스러운 요청의 위치 1보다 높은 순위를 받을 수 있으므로, 한 요청은 전체 블록을 유지하는 반면 다른 요청은 토큰 한두 개 후에 잘려나갈 수 있어요.

예산 자체는 시작 시 프로파일링된 비용 모델에서 나와요. vLLM은 각 형태(shape)에서 스텝 비용이 얼마인지 측정한 다음, 예상 수락 토큰 수/초(expected accepted tokens per second)를 최대화하는 토큰 수를 골라요.

실질적인 효과는 하나의 설정이 전체 로드 범위에서 유지된다는 것, 즉 배포마다 num_speculative_tokens을 튜닝할 필요가 대부분 사라진다는 점이에요.

지원

Adaptive Verification은 위치별 수락 추정치가 필요하므로, 현재는 confidence head를 가진 DSpark에서만 지원돼요.

사용법

기본적으로 꺼져 있어요. speculative config에서 활성화하세요:

vllm serve deepseek-ai/DeepSeek-V4-Flash-DSpark \
  --tokenizer-mode deepseek_v4 --trust-remote-code \
  --speculative-config '{
    "method": "dspark",
    "model": "deepseek-ai/DeepSeek-V4-Flash-DSpark",
    "num_speculative_tokens": 7,
    "draft_sample_method": "probabilistic",
    "enable_adaptive_verification": true
  }'

enable_adaptive_verification: false로 설정하면 모든 요청에 대해 전체 블록을 검증해요.

요구 사항과 제한 사항

attention 백엔드는 장치가 결정한 쿼리 길이(device-decided query lengths)를 허용해야 해요. CPU 길이는 위에서 그들을 제한할 뿐이기 때문이에요. CPU 길이를 기준으로 계획하는 백엔드는 attention 선택기에서 제외되며, 백엔드를 하드와이어하는 모델은 시작 시 거부돼요.
전체 cudagraphs가 필요해요. 스텝 비용이 캡처된 그래프에서 프로파일링되므로 --enforce-eager는 시작 시 거부돼요.
LoRA에서는 지원되지 않아요 (토큰별 LoRA 매핑이 CPU 측 경계에서 만들어지기 때문) 그리고 파이프라인 병렬화에서도 지원되지 않아요 (비용 곡선과 신뢰도가 마지막 rank에만 존재하기 때문).

비용 프로필 튜닝

스텝 비용은 합성 KV 컨텍스트(기본 8192 토큰)에 대해 프로파일링돼요. 훨씬 긴 컨텍스트를 서빙하는 배포는 프로파일링된 스텝이 더 현실적인 캐시 양을 읽도록 값을 높이는 게 좋아요 (DeepSeek-v4 같은 희소 어텐션 모델에서는 컨텍스트 길이에 따라 커지는 주 비용이 저렴한 인덱서라 덜 중요해요).

export VLLM_ADAPTIVE_VERIFICATION_PROFILE_CONTEXT_LEN=131072

Adaptive Verification