적응형 검증

적응형 검증 (Adaptive Verification)

스펙큘레이티브 디코딩은 더 적은 디코드 스텝을 더 많은 컴퓨트로 사는 기법이에요. 배치 크기 1에서는 좋은 거래예요 — GPU가 메모리 바운드라 여유 컴퓨트가 있으니 추가 드래프트 토큰이 거의 공짜에 가깝죠. 그런데 배치 크기 256에서는 훨씬 미묘해집니다. 이 페이지에서 적응형 검증(Adaptive Verification) 이 이 문제를 어떻게 푸는지 살펴볼게요.

출처: vLLM 공식 문서 — Adaptive Verification

왜 필요한가 (Why it matters)

배치가 커지면 드래프트 토큰이 실제 토큰과 같은 컴퓨트를 두고 경쟁하게 되고, 거부된 토큰 하나하나가 낭비된 컴퓨트예요. 그런 토큰이 많아지면 처리량이 떨어지죠.

여기에 위치별 수용률(acceptance rate)도 빠르게 감소한다는 점이 더해져요. GPU가 메모리 바운드일 때는 그 슬롯이 사실상 공짜라 도박할 만하지만, 컴퓨트가 포화되면 그 도박은 실질적인 처리량 비용을 갖게 돼요. 이 교차점은 로드와 워크로드 의존 수용률에 따라 움직이므로, 고정된 num_speculative_tokens는 어떤 동시성에서도 옳을 수 없어요.

적응형 검증은 매 스텝마다 드래프트 중 얼마나 검증할지를 대신 결정해요.

동작 방식 (How it works)

모든 (요청, 위치) 드래프트 슬롯은 그 요청의 위치별 신뢰도들의 누적 곱인 survival probability(생존 확률) 로 점수 매겨져요. 전역 예산이 소진될 때까지 가장 높은 점수의 슬롯이 수용되죠.

슬롯은 요청을 가로질러 경쟁해요. 신뢰도 높은 요청의 5번째 위치가 신뢰도 낮은 요청의 1번째 위치를 이길 수 있고, 그래서 한 요청은 전체 블록을 유지하는 동안 다른 요청은 토큰 한두 개 뒤에서 잘려나갈 수 있어요.

사용법 (Usage)

--speculative-config에서 enable_adaptive_verification: true를 설정해 켜요. 기본적으로 요청별로 검증 크기를 결정하며, false로 설정하면 모든 요청에 대해 전체 블록을 검증해요.

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를 설정하면 모든 요청에 대해 전체 블록을 검증해요.

참고: 이 기능은 현재 DSpark에서만 사용할 수 있어요. (확인 필요)

적응형 검증