DiffusionGemma: vLLM이 네이티브로 지원하는 최초의 디퓨전 언어 모델(dLLM)

9bow · 6월 11, 2026, 11:30오후

DiffusionGemma 소개

vLLM은 그동안 거의 모든 주요 대형 언어 모델(LLM)을 떠받쳐 온 고성능 추론 엔진이지만, 지금까지 다뤄온 모델은 사실상 모두 한 가지 부류였습니다. 바로 자기회귀(Autoregressive, AR) 트랜스포머, 즉 왼쪽에서 오른쪽으로 토큰을 한 개씩 차례대로 뽑아내는 모델입니다. Google DeepMind가 공개한 DiffusionGemma 는 이 전제를 정면으로 깨는 모델입니다. Gemma4 백본 위에 올린 260억(26B) 파라미터 규모의 이산 디퓨전 언어 모델(Discrete Diffusion Language Model, dLLM) 로, vLLM이 네이티브로 지원하는 최초의 dLLM이기도 합니다.

디퓨전 언어 모델은 텍스트를 생성하는 방식부터 다릅니다. 자기회귀 모델이 이미 만든 토큰을 조건으로 다음 한 토큰의 확률 분포를 구하는 일을 반복한다면, 디퓨전 모델은 고정 길이의 캔버스(canvas) 를 무작위 토큰으로 채워 놓고, 이 캔버스를 여러 번의 디노이징(denoising) 단계에 걸쳐 점진적으로 다듬어 나갑니다. 핵심은 한 번의 순전파(forward pass)에서 캔버스의 여러 위치를 동시에 정제한다는 점입니다. DiffusionGemma는 한 번에 256개 토큰 크기의 캔버스를 디노이징합니다.

이 방식이 매력적인 이유는 하드웨어 자원을 쓰는 결이 다르기 때문입니다. 자기회귀 디코딩은 토큰 하나를 뽑을 때마다 모델 가중치 전체를 메모리에서 다시 읽어야 하므로, 특히 배치 크기가 작을 때는 연산 능력이 남아돌아도 메모리 대역폭(memory bandwidth) 이 병목이 됩니다. 반면 디퓨전 디코딩은 한 번의 순전파에서 여러 토큰을 만들어내므로, 남아도는 연산 능력을 써서 메모리 대역폭 부담을 상쇄합니다. 즉 메모리 대역폭 압박을 추가 연산과 맞바꾸는(trading memory bandwidth pressure for additional compute) 셈이며, 이는 곧 매우 낮은 지연 시간(latency)으로 이어집니다. 아래 그림은 두 패러다임의 차이를 한눈에 보여줍니다.

위 그림의 (a)처럼 자기회귀 모델은 All work이라는 프롬프트 뒤에 and, no, play처럼 토큰을 한 개씩 이어 붙입니다. 반면 (b)의 DiffusionGemma는 4개(실제로는 256개) 토큰짜리 캔버스를 통째로 두고, 수렴(converged)했는가? 를 물어 가며 디노이징을 반복하다가 캔버스가 안정되면 한 블록을 한꺼번에 확정(commit)합니다. 단, 블록 안에서는 모든 위치가 병렬로 정제되지만, 블록 사이에서는 여전히 왼쪽에서 오른쪽으로 진행됩니다. 새 블록은 앞서 확정된 모든 토큰을 조건으로 삼기 때문입니다.

vLLM에 DiffusionGemma를 통합하는 일은 단순히 새 모델 클래스를 하나 추가하는 작업이 아니었습니다. dLLM은 양방향 어텐션(bidirectional attention), 반복적 정제, 블록 기반 생성, 그리고 매 디노이징 단계마다의 맞춤형 샘플링이라는, 표준 자기회귀 서빙 경로에 깔끔하게 들어맞지 않는 요구사항을 가지고 있기 때문입니다. vLLM 팀은 model runner v2에서 도입한 새로운 ModelState 추상화를 활용해 이 문제를 풀었고, 그 결과 Hugging Face 참조 구현과 동일한 정확도를 유지하면서도 효율적인 배치 서빙을 가능하게 했습니다.

두 가지 모드로 같은 가중치를 쓰는 아키텍처와 샘플링 루프

DiffusionGemma는 표준 Gemma4 백본을 그대로 쓰지만, 같은 가중치(one set of layers, used two ways) 를 두 가지 모드로 번갈아 실행한다는 점이 독특합니다.

인코더 모드(Encoder mode) 는 인과(causal) 어텐션을 사용하며 KV 캐시에 기록합니다. 한 블록당 두 번 실행되는데, 한 번은 프롬프트를 프리필(prefill)할 때, 또 한 번은 완성된 블록을 확정(commit)할 때입니다.
디코더 모드(Decoder mode) 는 양방향(bidirectional) 어텐션을 사용하며 KV 캐시를 읽기만 합니다. 이것이 바로 디노이징 모드로, 캔버스의 모든 위치가 다른 모든 위치를 참조할 수 있어 블록 전체를 한꺼번에 정제할 수 있게 해줍니다.

여기서 중요한 부수 효과가 하나 있습니다. 인코더가 평범한 인과 어텐션을 쓰고, 확정된 KV가 자기회귀 모델과 정확히 동일하게 기록되기 때문에, vLLM의 자동 프리픽스 캐싱(automatic prefix caching) 이 별도 수정 없이 그대로 동작합니다. 즉, 공유된 프롬프트 접두사는 디퓨전 전용 변경 없이도 여러 요청 사이에서 재사용됩니다.

256개 토큰짜리 한 블록의 루프는 다음과 같이 돕니다. 프롬프트가 인코더로 프리필되고 나면, 캔버스는 무작위 토큰으로 초기화되고 상태가 디노이징으로 설정됩니다. 매 디노이징 단계는 디코더 모드로 백본을 전체 캔버스에 대해 실행하고, 모든 위치에서 후보 토큰을 샘플링한 뒤, 어떤 위치를 유지할지 결정합니다. 블록이 더 이상 바뀌지 않으면 상태를 다시 인코딩으로 되돌리고, 마지막 인코더 패스로 그 블록을 확정합니다. 이때 KV가 기록되고 256개 토큰이 방출되며, 다음 블록은 새로운 무작위 캔버스에서 시작합니다.

엔트로피 기반 디노이징

매 디노이징 단계는 캔버스의 모든 위치를 다시 샘플링하지만, 모델이 충분히 확신하는 위치만 유지하고 나머지는 버린 뒤 다음 단계를 위해 새로운 무작위 토큰으로 교체합니다. 여기서 확신의 정도는 각 위치의 예측 분포가 갖는 엔트로피(entropy) 로 측정합니다. 엔트로피가 낮다는 것은 모델이 그 위치에 대해 거의 마음을 정했다는 뜻입니다. 확률 분포 $p$에 대한 엔트로피는 다음과 같이 정의됩니다.

H(p) = -\sum_i p_i \log p_i

DiffusionGemma는 몇 개의 위치를 받아들일지 결정할 때 엔트로피 한계(entropy-bound) 규칙을 사용합니다. 가장 확신하는 위치부터 가장 덜 확신하는 위치 순으로 훑어 내려가면서, 누적 엔트로피가 정해진 예산(budget)을 넘어서기 직전까지 토큰을 받아들입니다. 초반에는 모델이 거의 모든 것에 대해 확신이 없으므로 소수의 위치만 고정됩니다. 그러나 이 고정된 위치들이 닻(anchor) 역할을 하며 주변에 문맥을 전파하면, 이웃 위치들의 분포가 날카로워지고, 예산 아래로 들어오는 위치가 늘어나면서 블록이 단 몇 단계 만에 초점을 잡습니다. 아래 그림은 여러 단계에 걸쳐 캔버스가 안개에서 또렷한 문장으로 수렴해 가는 과정을 보여줍니다.

캔버스는 두 조건이 모두 만족될 때 수렴(converged) 한 것으로 간주됩니다. 첫째, 최선 추정(argmax) 예측이 연속 몇 단계 동안 더 이상 바뀌지 않아야 하고, 둘째, 토큰당 평균 엔트로피가 확신 임계값 아래로 떨어져야 합니다. 둘 중 하나라도 만족하지 못한 채 디노이징 단계 상한에 도달하면 거기서 멈춥니다. 이때 확정되는 토큰은 단계 사이를 오가던 잡음 섞인 샘플 캔버스가 아니라, 그 깨끗한 argmax 예측입니다.

자기 조건화

디노이징 루프를 더 안정적으로, 더 빠르게 수렴하도록 만들기 위해 DiffusionGemma는 자기 조건화(Self-conditioning) 를 사용합니다. 단계와 단계 사이에서 모델을 자기 자신의 이전 예측 으로 조건화하는 기법입니다. 다만 하드 토큰(hard token)을 그대로 되먹이는 대신, 이전 단계의 전체 소프트맥스 분포를 가져와 토큰 임베딩의 확률 가중 평균으로 변환한 뒤, 작은 게이트형 MLP(gated MLP)를 통해 다음 패스 직전의 캔버스 임베딩에 더해 줍니다.

이렇게 하면 각 단계가 모델이 직전에 무엇을 믿었는지에 대한 기억을 갖게 되어, 무작위 토큰으로 다시 잡음 처리된(renoised) 위치조차 처음부터 다시 시작하지 않고 이전 단계의 정보를 이어받습니다. 자기 조건화는 디코더/디노이즈 모드에서만 활성화됩니다. 인코더의 프리필과 확정 패스에서는 이 피드백이 0으로 처리되어, 해당 패스들은 순수한 토큰 임베딩만 보게 됩니다.

심화 학습: 디퓨전 언어 모델과 블록 확산

DFlash: 블록 확산(Block Diffusion) 기반으로 LLM 추론 속도를 높이는 오픈소스 라이브러리 (feat. Z.ai)

dFactory: 쉽고 효율적인 Diffusion LLM의 파인튜닝을 위한 오픈소스 프레임워크

Orthrus: Dual-View 디퓨전 디코딩으로 LLM 추론을 가속하는 무손실 병렬 토큰 생성 프레임워크

vLLM에서의 구현: 추측 디코딩 경로를 재활용하다

DiffusionGemma를 vLLM에 통합한 방식에서 가장 영리한 결정은, 디퓨전을 위한 완전히 새로운 실행 경로를 만들지 않고 이미 검증된 기존 경로를 빌려 쓴 점입니다.

추측 디코딩 데이터 경로 재활용

vLLM의 엔진에는 이미 매우 성숙하고 안정적인 추측 디코딩(Speculative Decoding) 경로가 있습니다. vLLM 팀은 RFC #36155에서 영감을 받아 이 경로를 그대로 재활용해 DiffusionGemma를 구현했습니다. 디퓨전 LLM에 추측 디코딩 경로를 빌려 쓰는 것은 사실 자연스러운 선택입니다. 매 단계에서 현재 캔버스는 전부 거부되거나 전부 받아들여질 대규모 초안(draft) 토큰 집합 으로 볼 수 있기 때문입니다.

덕분에 스케줄러나 모델 러너 같은 vLLM 핵심 컴포넌트의 변경은 극히 최소화되었습니다. 한 가지 눈에 띄는 예외는, 추측 디코딩이 항상 추가 토큰 한 개(추측 디코딩 문헌에서 흔히 보너스 토큰(bonus token) 이라 부르는)를 샘플링한다는 점입니다. 디퓨전을 위해 0개 토큰을 샘플링하는 경우에 대한 지원이 새로 추가되었고, 이는 ModelState로 제어됩니다. 아래 그림처럼 스케줄러, 모델 러너, Gemma4 백본은 변경 없이 재사용되고, ModelState와 샘플러만 디퓨전 전용입니다.

ModelState 인터페이스

ModelState가 등장하기 전이었다면, vLLM V1에 비자기회귀 모델을 추가하려면 모델 러너를 통째로 포크하고 디퓨전 전용 상태를 입력 준비, 어텐션 메타데이터, 샘플링 전반에 일일이 엮어 넣어야 했을 것입니다. ModelState는 모델 러너가 순전파 루프의 각 단계에서 호출하는 일련의 훅(hook)을 정의함으로써 이 문제를 피해 갑니다. DiffusionGemma가 각 훅을 어떻게 쓰는지는 다음과 같습니다.

훅(Hook)	DiffusionGemma의 용도
`prepare_inputs()`	캔버스 토큰을 임베딩하고 자기 조건화를 적용
`prepare_attn()`	요청별로 인과(인코더) vs 양방향(디노이즈) 어텐션을 설정
`custom_sampler()`	기본 샘플러를 `DiffusionSampler`로 교체
`add_request()` / `remove_request()`	요청별 디퓨전 상태(예: 캔버스와 자기 조건화 확률)를 초기화하고 해제

모델은 자신의 클래스에 get_model_state_cls()를 정의함으로써 ModelState를 스스로 등록합니다. 모델 러너는 일반적인(generic) 상태를 유지하면서, 매 단계마다 prepare_attn(...)을 호출해 메타데이터를 만들고, prepare_inputs(...)를 순전파 인자에 병합한 뒤, 샘플링을 custom_sampler()가 설치한 DiffusionSampler에 위임합니다.

이 설계의 의미는 분명합니다. 새로운 블록 디퓨전 모델을 추가하려면 ModelState 하나를 구현하고 모델 클래스에 한 줄짜리 등록만 추가하면 되며, 러너나 스케줄러, 그 밖의 공유 인프라는 전혀 손댈 필요가 없습니다. vLLM 팀은 이 방식이 앞으로 디퓨전 언어 모델을 vLLM에 깔끔하게 추가하는 청사진(blueprint) 이 될 수 있다고 봅니다.

DiffusionGemmaModelState와 DiffusionSampler

DiffusionGemmaModelState는 DiffusionGemma를 위한 ModelState 구현체입니다. 요청이 확정 단계인지 디노이즈 단계인지를 나타내는 위상 플래그(phase flag), 현재 canvas, 수렴 검사에 쓰는 이력(history), 자기 조건화 확률 등 디퓨전 루프와 관련된 요청별 상태를 보관합니다. 이 상태는 미리 할당된(pre-allocated) GPU 텐서에 들어 있으며 제자리(in place)에서 갱신됩니다. prepare_inputs()는 캔버스 토큰을 임베딩하고 자기 조건화를 적용합니다. 즉 내부 요청별 상태에서 이전 디노이즈 단계의 소프트맥스 분포를 가져와 토큰 임베딩의 확률 가중 평균을 계산하고, 이를 게이트형 MLP에 통과시켜 모델이 자신의 이전 예측을 볼 수 있게 합니다. prepare_attn()은 위상 플래그를 보고 어텐션이 인과(확정 단계/인코더)여야 할지 양방향(디노이즈 단계/디코더)이어야 할지를 결정해 메타데이터를 만듭니다.

DiffusionSampler는 vLLM의 평소 (Sampler, RejectionSampler) 쌍을 대신하며, 위상 변경 시점에 캔버스와 요청별 디퓨전 상태를 초기화하고 재설정하는 책임을 집니다. 매 단계의 실제 작업은 @torch.compile된 단일 함수 _compiled_sample_step이 담당하며, 진행 중인 모든 디코드 요청에 대해 벡터화되어 다음 세 경우를 처리합니다.

프리필(Prefill): 캔버스를 무작위 토큰으로 초기화하고 num_sampled = 0을 반환합니다.
디노이즈(Denoise): 로짓을 온도(temperature)로 스케일링하고, 검벨-맥스 기법(Gumbel-max trick)으로 각 캔버스 위치에서 후보 토큰을 뽑은 뒤(\arg\max(\text{logits}/T + g), 여기서 $g$는 검벨 노이즈), 엔트로피 한계까지 가장 확신하는 위치를 받아들이고 나머지는 무작위 토큰으로 다시 잡음 처리합니다. 또한 argmax 캔버스를 기록하고 수렴 여부를 검사합니다.
확정(Commit): 깨끗한 argmax_canvas를 방출하고(num_sampled = 256), 다음 블록을 위해 캔버스를 다시 초기화하며 요청별 상태를 재설정합니다.

여기서 스케줄러와의 회계(accounting)를 맞추는 방식이 특히 우아합니다. 디노이즈 단계에서 샘플러는 num_sampled = 0과 num_rejected = query_len을 보고하므로 KV 캐시 위치가 움직이지 않고, 오직 확정만이 위치를 전진시킵니다. 모든 캔버스 위치를 거부됨으로 표시한다는 것은 스케줄러에게 "이 시퀀스를 제자리에 두고 다음 단계에서 같은 블록을 다시 스케줄하라" 고 알리는 것과 같습니다. 이렇게 함으로써 전체 디노이징 루프가 스케줄러 변경 없이 기존 추측 디코딩 회계 안에 그대로 머무릅니다.

시퀀스별로 동적으로 바뀌는 인과 어텐션

앞서 설명했듯 DiffusionGemma는 인과 어텐션을 쓰는 인코더 모드와 양방향 어텐션을 쓰는 디코더 모드를 오갑니다. 그런데 지금까지 vLLM에서 인과성(causality)은 배치 전체에 걸친 단일 속성이었습니다. 한 번의 순전파에 들어간 모든 요청이 같은 마스크 유형을 공유했다는 뜻입니다. 일반적인 디코더 모델은 인과 어텐션만 쓰고, Whisper 같은 인코더-디코더 모델은 인코더 레이어에서 양방향 어텐션만 씁니다. 그러나 DiffusionGemma에서는 프롬프트가 프리필되고 캔버스가 반복적으로 디노이즈되고 받아들여지는 과정에서 요청이 두 모드 사이를 오갑니다. 게다가 vLLM은 지연 시간을 줄이기 위해 서로 다른 단계에 있는 요청들을 한 배치에 섞어 넣습니다.

그래서 vLLM 팀은 시퀀스별 동적 인과 어텐션(dynamic per-sequence causal attention) 을 구현했습니다. 어텐션 마스크를 각 요청의 인과성에 맞춰 조정하는 방식입니다. 아래 그림은 세 요청이 각기 다른 단계에 있는 배치를 보여줍니다.

요청 0 은 길이 6의 프리필이라 인과 어텐션을 씁니다(인코더 패스). 대각선 위쪽 항목이 마스킹되어, 각 질의 토큰은 자기 자신까지의 키만 참조합니다. 어텐션은 타일(tile) 단위로 계산되는데(그림에서는 2x2이지만 실제로는 훨씬 크고 하드웨어에 맞춰 튜닝됩니다), 마스킹된 항목만 들어 있는 타일은 통째로 건너뛰어 연산과 K/V 타일을 HBM에서 읽어오는 메모리 대역폭을 모두 아낍니다.
요청 1 은 길이 6의 프리필을 이미 마치고 디코더 모드로 새 토큰을 생성 중입니다. 크기 4의 캔버스 안에서 모든 질의가 양방향 어텐션으로 캔버스의 모든 키를 참조하고, 문맥(context)의 모든 키도 참조합니다. 마스킹되거나 건너뛰는 블록이 없습니다.
요청 2 는 디노이징 단계를 마치고 캔버스를 받아들일 준비가 되었습니다. 마지막으로 인코더 패스를 한 번 더 실행해 인과 어텐션을 쓰면서, 새로 받아들인 토큰의 항목으로 KV 캐시를 채웁니다.

vLLM 팀은 이 동적 인과 어텐션을 두 가지 어텐션 백엔드에서 지원합니다. Triton Attention(TRITON_ATTN)과 FlashAttention 4(FLASH_ATTN)입니다. 두 백엔드 모두에서 단일 불리언 인자 causal이 각 요청의 인과성을 나타내는 텐서로 교체되었고, 마스크가 그에 맞춰 갱신되며 타일링 동작은 그대로 보존됩니다.

슬라이딩 윈도우 어텐션도 대칭으로

마지막으로, DiffusionGemma의 일부 레이어는 슬라이딩 윈도우 어텐션(sliding window attention) 을 사용합니다. 캔버스 안의 토큰에 대해서는 이 슬라이딩 윈도우 역시 대칭이 되어야 합니다. 윈도우 크기가 $W$라면, 캔버스 토큰은 자기 자신과 앞쪽 $W$개 토큰만 보는 대신 뒤쪽 $W$개 토큰까지 참조하여 총 2W + 1 크기의 윈도우를 갖습니다.

위 그림은 $W=2$인 슬라이딩 윈도우 레이어에서 동일한 세 요청을 보여줍니다. 요청 0과 2(프리필과 확정)는 한쪽 방향의 인과 윈도우를 유지하여 각 질의가 자기 자신과 앞쪽 $W$개 키만 보는, 대각선을 따라 좁아지는 띠 형태의 어텐션을 갖습니다. 반면 요청 1의 디노이징 캔버스는 대칭 윈도우를 사용해 양쪽 $W$개씩 키를 참조하므로, 윈도우 안에 들어오는 문맥 토큰만 봅니다. 두 백엔드에서 이를 지원하기 위해 필요했던 변경은 양방향 요청에 대해 윈도우의 오른쪽 경계만 수정하는 것뿐이었습니다. 인과 요청은 왼쪽만 보는 윈도우를 유지하고, 양방향 요청은 양쪽으로 $W$씩인 대칭 윈도우를 씁니다.

심화 학습: vLLM 추론 엔진 내부 구조

LLM 추론 엔진 이해하기: Nano-vLLM 내부 살펴보기 - 1부

vLLM Recipes 개편: 모델과 하드웨어 조합별 설정을 한 번에

Gemma 모델군의 아키텍처에 대한 설명 글 (feat. Google Blog)

양자화 체크포인트 지원

DiffusionGemma는 양자화 체크포인트도 함께 제공됩니다. 이 체크포인트들은 LLM Compressor로 생성되어 compressed-tensors 형식으로 저장되었습니다. 가중치를 양자화하고 활성값을 완전 동적(fully dynamic)으로 처리하는 FP8 모델과, 가중치와 활성값을 모두 NVFP4 형식으로 양자화한 NVFP4 모델 두 가지가 있습니다. 두 체크포인트 모두 RedHatAI 허브에서 받을 수 있습니다.

NVFP4 체크포인트: RedHatAI/diffusiongemma-26B-A4B-it-NVFP4
FP8 체크포인트: RedHatAI/diffusiongemma-26B-A4B-it-FP8-dynamic

모델의 정확도를 검증하기 위해, 사고(thinking) 기능을 켠 경우와 끈 경우 각각에 대해 AIME 2025, GPQA Diamond, GSM8k 벤치마크에서 vLLM을 사용한 예비 평가가 수행되었습니다. 구체적인 평가 수치와 복원 점수(recovery score)는 각 모델 카드에서 확인할 수 있습니다.

성능 결과: 배치 1에서 빛나는 저지연 추론

DiffusionGemma의 아키텍처는 극도로 낮은 지연 시간의 추론을 가능하게 하며, 이는 대화형 애플리케이션처럼 응답 속도가 중요한 환경에 잘 맞습니다. vLLM 팀은 이 설정에서의 성능을 측정하기 위해, 단일 H100과 H200 GPU에서 배치 크기 1로 vLLM 내장 vllm bench serve를 사용해 벤치마크했습니다.

결과는 인상적인 수준을 넘어 패러다임의 차이를 보여줍니다. FP8 디퓨전 모델은 H200에서 초당 1,288개 생성 토큰 에 도달했는데, 이는 표준 자기회귀 베이스라인의 약 6배, 다중 토큰 예측(multi-token prediction)을 쓴 경우의 약 3배에 해당합니다. H100에서도 초당 1,008개 토큰 으로, 각각 약 5배와 약 2.6배입니다.

위 차트에서 볼 수 있듯, 다중 토큰 예측 없이(no-MTP) FP8로 돌린 Gemma4가 H200에서 초당 213토큰, MTP를 쓴 Gemma4가 429토큰인 데 비해, DiffusionGemma는 1,288토큰으로 크게 앞섭니다. 배치 크기가 작을 때 남아도는 연산 능력을 병렬 디노이징에 쏟아부어 메모리 대역폭 병목을 정면으로 회피한 결과입니다. 벤치마크 재현 명령은 공개된 gist에서 확인할 수 있습니다.

디퓨전 LLM이 추론 엔진에 던지는 질문

DiffusionGemma의 vLLM 통합이 갖는 의미는 단일 모델 하나를 지원하게 되었다는 데 그치지 않습니다. 더 중요한 것은, 자기회귀라는 단일 가정 위에 쌓아 올린 추론 엔진이 근본적으로 다른 디코딩 패러다임을 기존 추상화를 재활용하면서 받아들일 수 있음을 보였다는 점입니다. 추측 디코딩 경로를 빌려 캔버스를 초안 토큰 집합으로 다루고, ModelState 훅으로 디퓨전 전용 상태를 격리하며, 어텐션을 시퀀스별로 동적으로 전환한 일련의 결정은, 비자기회귀 모델 일반에 적용될 수 있는 청사진을 만들었습니다.

성능 측면에서도 디퓨전 LLM은 배치 크기가 작은 저지연 환경, 특히 대화형 에이전트나 온디바이스에 가까운 추론 환경에서 자기회귀 모델이 부딪히는 메모리 대역폭 병목을 우회하는 실질적 대안임을 보여줍니다. 물론 디퓨전 디코딩은 남아도는 연산 능력을 전제로 하므로, 배치 크기가 커져 연산 자원이 포화되는 고처리량 환경에서는 트레이드오프가 달라질 수 있습니다. 그럼에도 dLLM이 vLLM 같은 프로덕션 추론 엔진의 1급 시민(first-class citizen)이 되었다는 사실은, 앞으로 더 다양한 비자기회귀 모델이 같은 경로를 따라 들어올 길을 열어 둔 셈입니다.

DiffusionGemma 소개 블로그

vLLM GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! (기본은 Weekly지만 Daily로 변경도 가능합니다.)

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~