vLLM Diffusion Config와 Scheduler
마지막 수정:
vLLM에서 dLLM은 별도 diffusion config를 가진다.
핵심 필드는 두 가지다.
canvas_length:
한 canvas block의 token 위치 수
max_denoising_steps:
한 canvas를 최대 몇 번 denoise할지
왜 config가 필요한가
일반 autoregressive generation에서는 max_tokens가 “앞으로 몇 token을 더 붙일지”를 뜻한다.
dLLM에서는 한 step이 token 하나 append가 아니다. canvas position들을 denoise하고, 일정 조건에서 commit한다.
그래서 serving engine은 dLLM의 generation 단위를 알아야 한다.
몇 position을 scheduling할 것인가?
이번 step은 denoise인가 commit인가?
언제 다음 canvas로 넘어갈 것인가?
speculative decoding path 재사용
vLLM의 dLLM path는 speculative decoding data path와 닮은 부분이 있다.
speculative decoding도 한 번에 여러 draft token을 다룬다. dLLM도 한 step에서 여러 canvas position을 다룬다.
그래서 내부적으로 “여러 token position을 한 scheduling step에서 다룬다”는 구조를 재사용할 수 있다.
spec decode:
draft token positions
dLLM:
canvas positions
의미는 다르지만, data path의 모양이 비슷한 것이다.
연결
- diffusion-gemma-serving-state: request별 dLLM state
- vllm-speculative-decoding-expansion: 여러 token position을 한 step에서 다루는 기존 확장
확인
- dLLM에서
canvas_length는 무엇을 정하는가? max_denoising_steps는 latency/quality와 어떤 관계가 있는가?- dLLM이 speculative decoding data path와 닮은 이유는 무엇인가?