DiffusionGemma가 빠른 이유: 텍스트가 왼쪽에서 오른쪽으로 쓰여야 한다는 가정을 버렸기 때문

Google DeepMind는 이번 주에 일반적인 토큰 단위 루프 (token-by-token loop) 대신 이산 확산 (discrete diffusion) 방식으로 텍스트를 생성하는 오픈 웨이트 (open-weight) 언어 모델인 DiffusionGemma를 발표했습니다.

서빙 (serving) 수치를 확인하기 전까지는 그저 논문의 세부 사항처럼 들릴 것입니다. 보고서에 따르면 DiffusionGemma는 단일 H100에서 포워드 패스 (forward pass)당 평균 약 20개의 토큰을 생성하며, 초당 약 1,500개의 출력 토큰을 생성합니다. 동일한 표에서 다중 토큰 예측 (multi-token prediction)을 사용하는 유사한 Gemma 4 자기회귀 (autoregressive) 설정은 초당 약 303개의 토큰을 기록했습니다.

이 수치는 주목할 가치가 있습니다. 모든 모델이 확산 모델 (diffusion model)이 될 것이기 때문이 아닙니다. LLM 서빙의 지루한 병목 현상 (bottleneck)은 여전히 병목 현상으로 남아 있으며, 이것은 그 병목 현상에 대한 가장 깔끔한 공격 중 하나이기 때문입니다.

자기회귀 (Autoregressive) 모델은 추론하기 쉽습니다. 모델이 다음 토큰을 쓰고, 그다음 토큰을 쓰고, 그다음 토큰을 쓰는 방식입니다. 이 왼쪽에서 오른쪽으로 진행하는 계약은 일종의 세금이기도 합니다. 투기적 디코딩 (speculative decoding)을 사용하더라도 타겟 모델은 여전히 초안 시퀀스 (draft sequence)를 검증해야 하며, 유용한 속도 향상은 그 초안을 얼마나 수용하느냐에 달려 있습니다.

DiffusionGemma는 다른 거래를 시도합니다. Gemma 4 26B A4B에서 시작하여 이를 텍스트 확산 모델 (text diffusion model)로 미세 조정 (fine-tune)합니다. 한 번에 하나의 토큰을 확정하는 대신, 256개 토큰의 캔버스 (canvas)에서 작업하며 블록을 병렬로 노이즈 제거 (denoise)합니다. 실제로 보고서에 따르면 약 12번의 노이즈 제거 단계 (denoising steps)를 사용하므로, 포워드 패스 (forward pass)당 약 20개의 토큰을 얻습니다.

이는 작업의 중심을 "모든 토큰마다 가중치와 캐시를 이동시키는 것"에서 "단계당 더 많은 연산 (compute)을 사용하되, 단계 수를 줄이는 것"으로 전환합니다. 현대적인 가속기 (accelerators)에서는 이것이 올바른 거래가 될 수 있습니다.

주로 채팅창을 통해 LLM과 상호작용한다면 이를 과소평가하기 쉽습니다. 단일 답변을 읽는 인간에게는 초당 500 토큰이나 초당 1,500 토큰이나 모두 "충분히 빠름"으로 느껴집니다. 하지만 에이전트 시스템 (agent systems)에게 이 차이는 단순한 외관상의 차이 그 이상입니다.

에이전트 (Agents)는 루프(loops) 내에서 지연 시간 (latency)을 소모합니다. 검색, 요약, 검사, 패치, 테스트 실행, 수정 등의 과정이 반복됩니다. 모델에게 스무 번을 질문해야 하는 워크플로우 (workflow)는 단순히 최종 답변의 품질만을 신경 쓰지 않습니다. 이들은 꼬리 지연 시간 (tail latency), 사용자당 처리량 (per-user throughput), 그리고 GPU가 저활용되는 동안 머신이 메모리 이동을 기다리고 있지는 않은지를 신경 씁니다.

이것이 제가 다른 벤치마크 리더보드보다 이번 출시를 더 높게 평가하는 이유입니다. DiffusionGemma는 "우리가 더 나은 챗봇 페르소나를 찾아냈다"라고 말하는 것이 아닙니다. 서빙 (serving)의 형태가 변할 수 있음을 말하고 있는 것입니다.

실질적인 비용도 존재합니다. 디퓨전 모드 (diffusion mode)가 순수 능력 면에서 Gemma 4 AR 베이스라인 (baseline)을 능가하지는 못합니다. 보고서의 표를 보면, DiffusionGemma는 AIME 2026에서 MTP를 사용하는 Gemma 4의 88.3점 대비 69.1점을 기록했고, LiveCodeBench v6에서는 77.1점 대비 69.1점, GPQA Diamond에서는 82.3점 대비 73.2점을 기록했습니다. 이 모델은 마법처럼 더 똑똑해진 것이 아니라, 더 빨라진 것입니다.

한계점 (limitations) 섹션 또한 매우 구체적이어서 신선합니다. 저자들은 짧은 출력 (outputs), 간헐적인 토큰 떨림 (token stuttering), 멀티모달 사고 태그 (multimodal thinking-tag) 문제, 그리고 배치 크기 (batch sizes)가 커질수록 처리량의 이점이 사라진다는 사실을 지적합니다. 약 32명의 동시 사용자까지는 DiffusionGemma가 처리량 면에서 승리할 수 있습니다. 그 범위를 넘어서면, 토큰당 더 높은 연산 비용 (compute cost)으로 인해 자기회귀 (autoregressive) 서빙이 다시 따라잡게 됩니다.

따라서 실질적인 해석은 "디퓨전이 자기회귀를 대체한다"가 아니라, "라우팅 (routing)이 흥미로워진다"입니다.

동시성이 낮고 지연 시간에 민감한 작업에는 디퓨전 디코딩 (diffusion decoding)이 적절한 모드일 수 있습니다. 어려운 추론, 긴 출력, 또는 높은 배치 서빙의 경우에는 자기회귀 디코딩 (autoregressive decoding)이 여전히 더 안전한 기본값일 수 있습니다. DiffusionGemma가 AR 모드를 유지하고 있다는 점은 바로 그 이유 때문에 중요합니다. 유용한 시스템은 아마도 이념적인 것이 아니라 하이브리드 (hybrid) 형태일 것입니다.

이는 LLM 인프라가 나아가는 방향과 일치합니다. 모든 곳에서 하나의 모델 모드가 승자가 되는 경우는 드뭅니다. 승자는 언제 정확도에 비용을 지불해야 하는지, 언제 속도에 비용을 지불해야 하는지, 그리고 언제 더 짧고 약간 약한 답변이 올바른 엔지니어링 결정인지를 아는 라우터 (router)입니다.

오픈 웨이트 (open-weight) 방식 또한 중요합니다. 폐쇄형 (closed) 확산-텍스트 (diffusion-text) API도 흥미롭지만, 개발자들에게 검사하거나 적응시킬 수 있는 여지를 많이 주지 않습니다. Hugging Face Transformers 및 vLLM에서 참조 지원을 제공하는 Apache 라이선스 모델은 커뮤니티에 프로파일링하고, 분석하고, 미세 조정 (fine-tune)하며, 일반적인 자기회귀 (AR) 스택과 비교할 수 있는 진정한 기준점 (baseline)을 제공합니다.

과장된 버전에서는 텍스트 확산 (text diffusion)이 LLM의 미래라고 말합니다.

유용한 버전은 더 간결합니다. 토큰 단위 디코딩 (Token-by-token decoding)이 신성불가침한 것은 아닙니다. 그것은 매우 값비싼 결과를 초래하는 하나의 설계 선택일 뿐입니다. DiffusionGemma는 AI에서 남겨진 가장 큰 이득 중 일부가 또 다른 약간 더 큰 모델을 만드는 것이 아니라, 배관 (plumbing)을 바꾸는 데서 올 수 있다는 점을 상기시켜 줍니다.

저는 그런 종류의 발전을 지지합니다. 그것은 새로운 벤치마크 왕좌를 차지하는 것만큼 화려하지는 않지만, 에이전트 워크플로 (agent workflows)가 매우 비싼 타자기 앞에서 기다리는 것처럼 느껴지지 않게 만들 수 있는 종류의 일입니다.

더 빠르지만 약간은 약한 모드를 어디에 가장 먼저 사용하시겠습니까?