DiffusionGemma Serving State

DiffusionGemma는 vLLM에서 볼 수 있는 dLLM 예시다.

중요한 점은 모델 class만 다른 것이 아니라, request별 serving state도 달라진다는 것이다.

request마다 필요한 상태

autoregressive LLM은 보통 token list와 KV cache를 중심으로 request 상태를 관리한다.

DiffusionGemma 같은 dLLM은 canvas와 denoising 상태를 관리해야 한다.

request state:
- current canvas
- denoising step counter
- commit 여부
- argmax canvas
- self-conditioning signal

이 상태들은 “지금까지 몇 token을 append했는가”만으로 설명되지 않는다.

encoder mode와 decoder mode

DiffusionGemma는 prompt를 처리하는 encoder 성격의 단계와, canvas를 denoise하는 decoder 성격의 단계를 나눠 볼 수 있다.

encoder mode:
prompt를 읽고 조건 정보를 만든다.

decoder mode:
canvas를 bidirectional하게 denoise한다.

이것도 일반 decoder-only autoregressive LLM과 다른 지점이다.

왜 serving engine에 부담이 되는가

serving engine은 request가 어느 단계에 있는지 알아야 한다.

아직 prompt 처리 중인가?
denoise 중인가?
commit해야 하는가?
다음 canvas로 넘어가야 하는가?

따라서 dLLM 지원은 단순히 sampler만 바꾸는 문제가 아니다. request lifecycle과 model state 관리가 같이 바뀐다.

연결

• dllm-token-canvas-denoising: canvas와 denoising step
• vllm-diffusion-config-and-scheduler: vLLM config와 scheduler 관점

확인

• dLLM request state가 autoregressive request state보다 복잡한 이유는 무엇인가?
• DiffusionGemma에서 canvas와 step counter는 왜 필요한가?
• encoder mode와 decoder mode를 나눠 보는 것이 serving 이해에 도움이 되는 이유는 무엇인가?