LLM이 토큰을 하나씩 뱉지 않는다면? DiffusionGemma 완전분석

AI 모델이 텍스트를 생성하는 방식은 지난 몇 년간 사실상 단 하나였습니다. GPT, Claude, Gemini, Llama 할 것 없이 모두 왼쪽에서 오른쪽으로, 토큰 하나씩, 이전 맥락을 조건으로 다음 토큰을 예측하는 자동회귀(autoregressive) 방식입니다. 이 방식이 워낙 지배적이다 보니 "LLM = 토큰 하나씩 생성"이라는 등식이 자연스러운 상식처럼 굳어졌습니다.

 

2026년 6월 10일, Google DeepMind가 그 등식을 깼습니다. DiffusionGemma는 256개 토큰 블록을 동시에 생성하는 텍스트 확산(discrete diffusion) 방식을 채택한 26B MoE 오픈웨이트 모델로, H100 단일 GPU에서 초당 1,000토큰 이상을 뽑아냅니다. Apache 2.0 라이선스로 Hugging Face, Kaggle, Google Cloud Vertex AI에 즉시 공개됐고, 출시 당일부터 vLLM, SGLang, Hugging Face Transformers, MLX에서 바로 돌아갑니다.

자동회귀의 병목이 뭔가

DiffusionGemma가 왜 빠른지 이해하려면 기존 방식의 구조적 한계부터 이해해야 합니다. 자동회귀 모델은 토큰을 생성할 때마다 이전에 생성한 모든 토큰을 KV(Key-Value) 캐시에서 읽어와야 합니다. 시퀀스가 길어질수록 읽어야 하는 데이터가 선형으로 늘어나고, GPU의 메모리 대역폭이 이 읽기 속도를 결정합니다. 연산 코어는 빠르고 많은데 메모리 읽기를 기다리는 상태가 반복됩니다. 결국 자동회귀 디코딩의 병목은 연산(compute)이 아니라 메모리 대역폭(memory bandwidth)입니다.

 

GPU를 단순하게 비유하면 수천 개의 연산 코어가 달린 계산기입니다. 그런데 자동회귀 방식에서는 이 코어들이 한 번에 토큰 하나를 계산하기 위해 메모리에서 데이터를 기다립니다. 코어 활용률이 낮은 상태로 속도 병목이 메모리 쪽에서 발생하는 구조입니다. H100처럼 연산 성능이 뛰어난 GPU를 사용해도 메모리 대역폭 한계를 넘지 못하면 토큰 생성 속도가 한계에 걸립니다.

 

DiffusionGemma는 이 병목을 구조 자체에서 바꿉니다. 이미지 생성 모델이 노이즈에서 픽셀을 정제하는 방식을 텍스트 생성에 그대로 적용합니다. 256개 자리를 랜덤 노이즈 토큰으로 채운 캔버스에서 시작해서, 반복적인 디노이징 과정으로 전체 블록을 동시에 정제합니다. 각 스텝에서 256개 포지션이 서로를 모두 참조하는 양방향 어텐션(bidirectional attention)이 적용되어, 왼쪽에서 오른쪽으로만 보던 기존 방식과 달리 블록 내 전체 맥락을 동시에 반영합니다. 이 구조가 병목을 메모리 대역폭에서 연산으로 옮기면서 GPU 코어 활용률이 올라가고 속도가 나는 원리입니다. Google DeepMind는 이 방식을 "블록 자동회귀(block-autoregressive)"라고 부르기도 합니다.

 

양방향 어텐션 덕분에 생기는 부가 기능도 있습니다. 생성 중에 블록 전체를 동시에 보면서 자신의 실수를 실시간으로 교정할 수 있습니다. 자동회귀 모델이 한번 생성한 토큰을 되돌리지 못하고 그 위에 쌓아가는 것과 다른 점입니다. 인라인 편집이나 코드 인필링처럼 앞뒤 맥락을 동시에 고려해야 하는 태스크에서 구조적으로 유리한 이유입니다.

스펙 정리

DiffusionGemma는 Gemma 4 26B A4B 아키텍처를 백본으로 사용합니다. 총 파라미터는 252억 개이고, MoE 구조라 추론 시 활성 파라미터는 38억 개입니다. 전문가(expert)는 128개 중 8개가 활성화되고, 공유 전문가 1개가 항상 동작합니다. 레이어는 30개이고 슬라이딩 윈도우는 1,024 토큰입니다. 컨텍스트 윈도우는 256K 토큰이고 캔버스 길이(한 번에 생성하는 블록 크기)는 256 토큰입니다.

 

어휘 크기는 262K이고, 텍스트와 이미지를 입력으로 받아 텍스트를 출력합니다. 비전 인코더가 약 5.5억 파라미터로 내장되어 있어 이미지 이해 능력을 Gemma 4 백본에서 그대로 상속받았습니다. 공식 모델 카드에 따르면 오브젝트 감지, PDF·문서 파싱, 스크린 및 UI 이해, 차트 분석, OCR(다국어 포함), 손글씨 인식이 가능합니다. 라이선스는 Apache 2.0으로 상업적 활용과 파인튜닝, 재배포에 제한이 없습니다.

 

속도 수치는 H100에서 초당 1,008 토큰(FP8 기준), H200에서 vLLM FP8 기준 1,288 토큰, RTX 5090에서 700 토큰 이상입니다. H200 수치는 vLLM 팀이 독립적으로 검증한 유일한 수치이고, H100과 RTX 5090 수치는 Google 자체 측정값입니다. 단순한 구조 태스크(코드, 포맷팅)는 디노이징 스텝이 더 적게 필요해서 속도가 더 빠르게 나옵니다. Google은 이를 "적응형 추론 시간 연산(Adaptive Inference Time Computation)"으로 설명합니다.

벤치마크: 어디서 강하고 어디서 약한가

DiffusionGemma의 벤치마크를 보면 강점과 약점이 명확하게 갈립니다. 문서 파싱 벤치마크인 OmniDocBench 1.5에서는 Gemma 4를 앞섭니다. 양방향 어텐션이 문서 구조를 전체적으로 파악하는 데 유리하게 작용한 결과입니다.

MMLU Pro 일반 지식 추론에서는 77.6으로 Gemma 4의 82.6보다 5포인트 낮지만, 수치 차이만 보면 일반 지식 태스크에서 어느 정도 경쟁력 있는 품질임을 알 수 있습니다.

반면 멀티스텝 수학 추론과 경쟁 프로그래밍에서는 격차가 큽니다. AIME 2026 기준 Gemma 4 대비 19.2포인트 낮고, Codeforces ELO로 289점 차이가 납니다. 틀린 스텝이 누적되면 결과 전체가 망가지는 연쇄 추론 태스크에서 블록 단위 생성 방식이 불리하게 작용하는 결과입니다. 명령어 추종(instruction following) 정밀도도 초기 커뮤니티 테스트에서 Gemma 4에 미치지 못한다는 보고가 나오고 있습니다.

이를 정리하면 DiffusionGemma는 속도가 중요하고 문서 파싱, 인라인 편집, 코드 인필링, 구조화된 출력이 주요 태스크인 환경에 적합하고, 멀티스텝 수학 추론, 경쟁 프로그래밍, 고품질 창작 작문이 주요 태스크라면 Gemma 4를 쓰는 것이 맞습니다. Google 공식 문서도 이 포지셔닝을 명확히 하고 있습니다.

로컬 배포: VRAM별 선택지

양자화 버전 기준으로 필요한 VRAM 요구사항을 정리합니다. NVFP4 빌드는 약 18GB가 필요해서 RTX 4090(24GB)에서 여유 있게 돌고, RTX 4080 16GB에는 들어가지 않습니다. FP8 빌드는 약 28GB가 필요해서 RTX 5090(32GB)이나 A6000(48GB)이 적합합니다. BF16 풀 프리시전은 50GB 이상으로 A100 80GB 또는 멀티 GPU 환경이 필요합니다.

 

vLLM이 텍스트 확산 모델을 네이티브 지원한 첫 사례가 DiffusionGemma입니다. 출시 당일부터 vLLM, Hugging Face Transformers, SGLang, MLX를 지원했습니다. Ollama와 llama.cpp는 아직 공식 지원이 없고, llama.cpp PR #24427이 드래프트 상태로 열려 있어 머지되면 Ollama와 LM Studio에서도 바로 쓸 수 있게 됩니다.

실전 1: vLLM으로 서버 띄우기

vLLM 최신 버전을 먼저 설치해야 합니다. DiffusionGemma는 vLLM에서 텍스트 확산 모델 최초 지원 사례이기 때문에 구 버전에서는 모델 클래스 자체가 없습니다.

pip install -U vllm transformers

RTX 4090 단일 GPU에서 NVFP4 양자화로 서버를 띄우는 커맨드입니다.

vllm serve google/diffusiongemma-26B-A4B-it \
  --port 8000 \
  --tensor-parallel-size 1 \
  --dtype nvfp4 \
  --max-model-len 8192

H100이나 A100에서 FP8로 돌린다면 --dtype fp8으로 변경합니다. 서버가 뜨면 OpenAI 호환 엔드포인트로 바로 요청을 보낼 수 있습니다. DiffusionGemma는 KV 캐시 기반 증분 디코딩을 지원하지 않는 구조적 특성이 있어서, vLLM의 표준 연속 배칭(continuous batching)이 아닌 블록 단위 배칭으로 동작합니다. 고배치 환경에서 처리량이 자동회귀 모델과 다르게 나오는 이유가 여기에 있습니다.

실전 2: Hugging Face Transformers로 직접 추론

서버 없이 Python 스크립트에서 바로 추론하는 방법입니다. DiffusionGemmaForBlockDiffusion 클래스는 모델 출시 이후 버전의 transformers에만 있기 때문에 먼저 최신 버전으로 업그레이드해야 합니다.

pip install -U transformers accelerate

기본 텍스트 생성 예시입니다. max_new_tokens를 256의 배수로 설정하면 블록 경계에 맞게 생성이 이루어집니다.

from transformers import AutoTokenizer, DiffusionGemmaForBlockDiffusion
import torch

model_id = "google/diffusiongemma-26B-A4B-it"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = DiffusionGemmaForBlockDiffusion.from_pretrained(
    model_id,
    torch_dtype=torch.float16,
    device_map="auto"
)

prompt = "Explain the trade-offs between autoregressive and diffusion-based text generation."
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

outputs = model.generate(
    **inputs,
    max_new_tokens=256,
    num_diffusion_steps=10   # 디노이징 스텝 수, 낮을수록 빠르고 품질은 낮아짐
)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

num_diffusion_steps가 핵심 파라미터입니다. 스텝 수를 줄이면 속도가 빠르지만 품질이 떨어지고, 늘리면 품질이 올라가지만 속도가 감소합니다. 간단한 구조화 태스크는 5~8 스텝으로도 충분하고, 복잡한 추론이 필요한 경우 15~20 스텝을 권장합니다. 이미지를 함께 입력할 때는 AutoProcessor를 쓰는 멀티모달 파이프라인으로 전환합니다.

from transformers import AutoProcessor, DiffusionGemmaForBlockDiffusion
from PIL import Image
import requests, torch

model_id = "google/diffusiongemma-26B-A4B-it"
processor = AutoProcessor.from_pretrained(model_id)
model = DiffusionGemmaForBlockDiffusion.from_pretrained(
    model_id,
    torch_dtype=torch.float16,
    device_map="auto"
)

image = Image.open(requests.get("https://example.com/chart.png", stream=True).raw)
messages = [
    {"role": "user", "content": [
        {"type": "image", "image": image},
        {"type": "text", "text": "Summarize the key trends shown in this chart."}
    ]}
]
inputs = processor.apply_chat_template(
    messages, add_generation_prompt=True, return_tensors="pt"
).to(model.device)

outputs = model.generate(**inputs, max_new_tokens=256, num_diffusion_steps=10)
print(processor.decode(outputs[0], skip_special_tokens=True))

이미지 입력 시 OmniDocBench 1.5에서 Gemma 4를 앞서는 문서 파싱 강점이 가장 두드러집니다. PDF 슬라이드 이미지나 대시보드 스크린샷 분석에 먼저 테스트해볼 만한 이유입니다.

실전 3: SGLang으로 빠른 배포

SGLang도 출시 당일부터 DiffusionGemma를 지원합니다. vLLM보다 설정이 간결하고 구조화 출력(structured output) 처리에 강점이 있어서 JSON 스키마 기반 출력이 필요한 파이프라인에 적합합니다.

pip install sglang[all]

python -m sglang.launch_server \
  --model-path google/diffusiongemma-26B-A4B-it \
  --port 30000 \
  --tp-size 1 \
  --dtype float16

SGLang 서버가 뜨면 Python SDK로 구조화 출력을 요청하는 방식입니다. DiffusionGemma의 블록 병렬 생성 특성이 JSON 스키마 제약 조건을 처음부터 블록 전체에 적용하는 구조화 생성 방식과 잘 맞습니다.

import sglang as sgl

@sgl.function
def extract_document_info(s, document_text):
    s += sgl.system("Extract structured information from the document.")
    s += sgl.user(document_text)
    s += sgl.assistant(sgl.gen(
        "output",
        max_tokens=256,
        response_format={
            "type": "json_object",
            "schema": {
                "title": {"type": "string"},
                "summary": {"type": "string"},
                "key_points": {"type": "array", "items": {"type": "string"}}
            }
        }
    ))

sgl.set_default_backend(sgl.RuntimeEndpoint("http://localhost:30000"))
result = extract_document_info.run(document_text="[문서 내용]")
print(result["output"])

파인튜닝을 원한다면 Google이 공개한 JAX 기반 hackable_diffusion 저장소가 공식 레시피를 제공합니다. Unsloth와 NVIDIA NeMo를 통한 파인튜닝도 지원하고 있습니다.

Mercury 2와의 비교: 오픈 vs 클로즈드

텍스트 확산 모델의 상용 경쟁 제품으로 Inception Labs의 Mercury 2가 있습니다. 두 모델 모두 초당 1,000 토큰 수준의 속도를 내지만 방식이 전혀 다릅니다. Mercury 2는 클로즈드 상용 API로만 제공되고 자체 배포가 불가능합니다.

DiffusionGemma는 Apache 2.0 오픈웨이트로 로컬 배포, 파인튜닝, 상업적 활용 모두 제한이 없습니다. 텍스트 확산 방식에서 동급 속도를 오픈 라이선스로 제공한 첫 번째 모델이라는 점에서 의미가 있습니다.

속도 우위가 사라지는 조건

속도 4배 향상이라는 수치는 저배치 로컬 단일 사용자 환경에서 측정된 수치입니다. 실제 운용 환경에서 이 수치가 그대로 나오지 않는 경우가 있습니다.

고배치 클라우드 서빙에서는 자동회귀 모델이 사용자를 연속 배칭으로 효율적으로 묶어 처리하기 때문에 DiffusionGemma의 속도 우위가 줄어들거나 역전될 수 있습니다. 이 경우 실제 서빙 환경에서 벤치마크를 직접 해보고 판단하는 것이 필요합니다. RTX 3060, RTX 4060 같은 저사양 소비자 GPU와 Apple Silicon에서는 GPU 코어 수가 적어 병렬 블록 생성의 이점이 크게 줄어듭니다. RTX 4060 Ti 16GB는 양자화해도 VRAM이 18GB 기준에 빡빡하게 들어가고, 속도는 기대치보다 낮게 나옵니다. 파인튜닝 생태계도 아직 초기입니다. LoRA·QLoRA 레시피가 확립되어 있지 않고 커뮤니티 어댑터 생태계도 없어서, 특화 도메인 파인튜닝은 시간이 더 필요합니다.

왜 중요한가: 아키텍처 전환의 신호

DiffusionGemma 자체의 현재 실용성보다 이 릴리스가 갖는 장기적 의미가 더 큽니다. Google DeepMind가 자동회귀 외의 텍스트 생성 패러다임을 본격적으로 오픈웨이트로 밀기 시작한 첫 번째 시점입니다. 2025년 Google I/O에서 Gemini Diffusion을 선택적 데모로만 보여줬을 때는 클로즈드 실험이었는데, 1년 만에 Apache 2.0 오픈웨이트로 나왔습니다.

 

연구자들 사이에서는 텍스트 확산이 자동회귀 수준의 품질에 도달하는 것이 원칙적으로 가능하다는 견해가 많습니다. 그 전환 시점이 언제냐의 문제입니다. 만약 그 시점이 온다면 LLM 배포 방식이 근본적으로 달라집니다. 로컬에서 초당 1,000 토큰 이상을 GPT-4급 품질로 돌리는 시나리오가 현실화됩니다. DiffusionGemma는 그 방향으로 가는 첫 번째 오픈웨이트 이정표입니다.

결론

DiffusionGemma는 지금 당장 프로덕션 전환용 모델이 아니라 새로운 텍스트 생성 패러다임의 첫 번째 오픈웨이트 구현입니다. H100 기준 초당 1,008 토큰이라는 속도는 인라인 편집, 코드 인필링, 문서 파싱처럼 낮은 레이턴시가 핵심인 로컬 워크플로에서 즉시 실용적입니다.

 

양방향 어텐션 덕분에 자동회귀 모델이 구조적으로 불리했던 인필링과 편집 태스크에서 더 나은 결과를 낼 수 있고, OmniDocBench에서 Gemma 4를 앞서는 문서 파싱 성능도 실용적인 활용 포인트입니다. 단 멀티스텝 수학 추론과 경쟁 프로그래밍에서 Gemma 4 대비 격차가 크고, 고배치 클라우드 환경과 저사양 GPU에서는 속도 이점이 감소하며, Ollama와 llama.cpp 지원이 아직 미완성이라는 점은 도입 전 반드시 확인이 필요합니다.

텍스트 확산이 자동회귀 수준의 품질에 도달하는 시점이 언제냐는 것이 앞으로 LLM 추론 아키텍처의 가장 중요한 질문이 됩니다.

---