DiffusionGemma: Google DeepMind의 텍스트 확산 모델이 초당 1,000개의 토큰을 생성하는 방법

대부분의 언어 모델은 동일한 방식으로 텍스트를 생성합니다. 즉, 한 번에 하나의 토큰씩, 왼쪽에서 오른쪽으로, 각 단어가 이전에 나온 모든 것에 의존하며 생성합니다. 이는 잘 알려진 접근 방식이지만, 메모리 대역폭 (memory bandwidth)과 결부된 근본적인 속도 한계가 존재합니다. 2026년 6월 10일에 출시된 Google DeepMind의 DiffusionGemma는 다른 경로를 택했습니다. 이미지 생성에서 사용하는 노이즈 제거 (denoising) 프로세스를 빌려와 텍스트 블록 전체를 병렬로 생성합니다. 그 결과, 단일 NVIDIA H100에서 초당 1,000개 이상의 토큰 처리량 (throughput)에 도달하며, 이는 유사한 자기회귀 (autoregressive) 모델보다 약 4배 더 빠릅니다.

이 포스트에서는 이것이 어떻게 작동하는지, 어떤 트레이드오프 (trade-offs)가 있는지, 그리고 이러한 종류의 모델을 실제로 어디에 사용하는 것이 타당한지 설명합니다.

핵심 아이디어: 노이즈 제거 문제로서의 텍스트

이미지를 위한 확산 모델 (Diffusion models)은 무작위 노이즈에서 시작하여 일관된 그림을 향해 반복적으로 정제하는 방식으로 작동합니다. DiffusionGemma는 동일한 원리를 텍스트에 적용하지만, 이산적 토큰 (discrete tokens)에 적합하도록 변형을 가했습니다.

토큰을 순차적으로 생성하는 대신, 모델은 한 번에 최대 256개의 마스크된 플레이스홀더 (masked placeholder) 토큰으로 구성된 "캔버스"에서 시작하여, 이를 정제하기 위해 여러 번의 순전파 (forward passes)를 수행합니다. 각 패스에서 모든 토큰은 블록 내의 다른 모든 토큰을 참조할 수 있으며 (양방향 어텐션 (bidirectional attention)), 이는 모델이 어떤 방향으로든 의존성을 해결할 수 있음을 의미합니다. 노이즈 제거 프로세스가 끝나면 전체 블록이 한 번에 완성됩니다.

이는 토큰 N이 토큰 1부터 N-1까지만 볼 수 있는 자기회귀 생성 (autoregressive generation)과는 근본적으로 다릅니다. 양방향 뷰 (bidirectional view)를 통해 DiffusionGemma는 5번 위치의 정답이 20번 위치에 무엇이 오는지에 따라 결정되는 작업을 처리할 수 있습니다. 이는 자기회귀 모델이 사고의 사슬 (chain-of-thought)이나 다른 우회 방법을 통해 근사해야 하는 작업입니다.

아키텍처: Gemma 4의 MoE 백본을 기반으로 구축

DiffusionGemma는 Gemma 4 26B-A4B 아키텍처를 기반으로 구축되었습니다. 이는 총 252억 개의 파라미터(parameters)를 보유하고 있지만, 특정 추론(inference) 단계에서는 38억 개의 파라미터만 활성화되는 전문가 혼합(Mixture-of-Experts, MoE) 설계입니다. MoE 구조는 모델이 전체 파라미터 세트를 활성화하는 대신, 각 토큰을 전문화된 "전문가(expert)" 서브 네트워크의 하위 집합을 통해 라우팅(route)한다는 것을 의미합니다. 이를 통해 효과적인 대용량 용량을 유지하면서도 연산량을 관리 가능한 수준으로 유지합니다.

이 백본(backbone) 위에 Google은 마스크된 토큰 정제(masked token refinement) 프로세스를 처리하는 확산 헤드(diffusion head)를 추가했습니다. 이 모델은 멀티모달(multimodal) 입력(텍스트, 이미지, 비디오)을 수용하지만, 텍스트 출력만을 생성합니다.

NVIDIA의 배포 가이드에서 발췌한 주요 하드웨어 수치:

• NVIDIA H100: 초당 1,000개 이상의 토큰 생성
• NVIDIA DGX Station: 최대 초당 2,000개 토큰 생성
• GeForce RTX 5090: 초당 약 700개 토큰 생성
• VRAM 요구 사항: 양자화(quantized) 시 약 18GB (RTX 4090 또는 5090에 적합)

이 모델은 Hugging Face에서 Apache 2.0 라이선스 하에 사용 가능하며(google/diffusiongemma-26B-A4B-it), Hugging Face Transformers, vLLM, Unsloth에서 출시 당일 지원됩니다.

로컬 추론이 클라우드보다 더 유리한 이유

이해할 가치가 있는 한 가지 세부 사항은, 확산(diffusion) 방식의 속도 이점이 대규모 클라우드 배포보다 로컬의 단일 사용자 환경에서 더 두드러진다는 점입니다.

클라우드 추론 시스템은 수많은 사용자의 요청을 동시에 배치(batching) 처리함으로써 자기회귀(autoregressive) 모델을 효율적으로 실행하며, 이를 통해 GPU를 포화 상태로 유지하고 고대역폭 메모리(HBM)를 잘 활용합니다. 그러한 환경에서는 하드웨어가 항상 바쁘게 작동하기 때문에, 자기회귀 생성의 순차적인 특성이 병목 현상(bottleneck)으로 작게 작용합니다.

로컬 추론 (Local inference)은 다릅니다. 단일 사용자의 GPU는 토큰 사이의 시간 동안 유휴 상태(idle)로 머물게 되며, 각 토큰을 위해 모델 가중치 (model weights)를 로드하는 데 필요한 메모리 대역폭 (memory bandwidth)이 제한 요인이 됩니다. 확산 (Diffusion) 모델은 병목 현상을 메모리 대역폭에서 순수 연산 (raw compute)으로 전환함으로써 이를 우회합니다. 즉, 한 번의 순전파 (forward pass) 당 256개의 토큰을 생성한다는 것은 가중치 로드 비용이 훨씬 더 큰 출력 블록에 걸쳐 분할 amortized 된다는 것을 의미합니다.

이것이 Google의 클라우드 기반 Gemini 모델들이 자기회귀 (autoregressive) 방식을 유지하는 이유이기도 합니다. 클라우드 서빙의 배치 (batching) 이점이 확산 모델의 상대적 이점을 감소시키는 반면, 품질 측면의 트레이드오프 (trade-offs, 아래에서 자세히 설명)는 여전히 남아 있기 때문입니다.

확산 모델이 진정한 이점을 갖는 영역

DiffusionGemma의 양방향 어텐션 (bidirectional attention)은 자기회귀 모델로는 다루기 까다로운 사용 사례들을 가능하게 합니다:

코드 인필링 (Code infilling): 기존 함수의 중간에 코드를 삽입해야 할 때, 올바른 삽입은 앞뒤 문맥 모두에 달려 있습니다. 자기회귀 모델은 미래의 문맥을 추측해야 하지만, DiffusionGemma는 양쪽을 동시에 볼 수 있습니다.

인라인 텍스트 편집 (In-line text editing): 주변 텍스트의 일관성을 유지하면서 문단의 중간에 있는 문장을 수정하는 것도 유사한 문제입니다. 확산 모델은 이를 자연스럽게 처리합니다.

제약 조건이 많은 생성 (Constraint-heavy generation): 스도쿠 풀기, 분자 서열 생성, 수학적 포맷팅과 같은 작업은 나머지 부분을 확인하기 전에 각 토큰을 확정 짓는 대신, 전체 출력 블록에 걸쳐 스스로 수정할 수 있는 모델의 능력으로부터 이득을 얻습니다.

고처리량 로컬 애플리케이션 (High-throughput local applications): 대화형 코딩 어시스턴트, 실시간 문서 초안 작성 도구와 같이 로컬 하드웨어에서 대량의 텍스트를 빠르게 생성해야 하는 모든 애플리케이션은 순수 속도 측면의 이점을 누릴 수 있습니다.

트레이드오프는 실재합니다

DiffusionGemma는 명시적으로 실험적이라고 설명되어 있으며, DataNorth의 분석에 따른 벤치마크 수치는 표준 Gemma 4와 비교했을 때 유의미한 품질 격차를 보여줍니다:

벤치마크 (Benchmark)	DiffusionGemma	Gemma 4 26B
MMLU Pro	77.6%	82.6%
...

정확도 격차는 추론 (reasoning), 과학 (science), 코딩 (coding) 벤치마크 전반에서 일관되게 나타납니다. 이는 텍스트 확산 (text diffusion) 모델이 가진 알려진 과제를 반영합니다. 언어는 이산적 (discrete)이기 때문에, 단 하나의 잘못 예측된 토큰이 이미지의 잘못 배치된 픽셀과는 달리 전체 블록을 비논리적으로 만들 수 있습니다. 모델은 오류로부터 회복하기 위해 더 많은 작업을 수행해야 하며, 반복적 정제 (iterative refinement) 과정이 정교한 좌측-우측 (left-to-right) 생성만큼 항상 동일한 품질로 수렴하는 것은 아닙니다.

또한 짧은 출력에 대해서는 실질적인 비효율성이 존재합니다. 확산 모델 (Diffusion models)은 출력 길이에 관계없이 전체 디노이징 (denoising) 과정을 실행해야 합니다. 즉, 5개의 토큰을 생성하는 것이 256개를 생성하는 것과 거의 동일한 연산량 (compute)을 요구합니다. 자기회귀 (Autoregressive) 모델은 출력 길이와 선형적으로 비례하여 확장되므로, 짧은 응답에는 더 효율적입니다.

이것이 오픈 모델의 방향성에 대해 시사하는 바

DiffusionGemma는 단순히 단독 출시 모델로서가 아니라, Google이 자사의 오픈 모델 라인업에서 비자기회귀 (non-autoregressive) 아키텍처를 적극적으로 탐색하고 있다는 신호로서 주목할 만합니다. Gemini Diffusion (폐쇄형, 대기 명단 전용 인프라 실험)과 DiffusionGemma (오픈 웨이트, Apache 2.0)의 동시 존재는 Google이 병렬 트랙을 운영하고 있음을 시사합니다. 즉, 내부적으로는 대규모 확산 모델을 테스트하는 동시에, 커뮤니티가 실험할 수 있도록 오픈 모델을 출시하고 있는 것입니다.

개발자들에게 주는 실질적인 시사점은 명확합니다. DiffusionGemma는 최고 정확도보다 처리량 (throughput)이 더 중요한, 지연 시간 (latency)에 민감한 로컬 추론 (local inference) 워크로드에 유용한 도구입니다. 정교한 추론, 긴 문맥 검색 (long-context retrieval), 또는 높은 신뢰도가 요구되는 출력 작업의 경우에는 표준 Gemma 4 모델이 여전히 더 나은 선택입니다.

Apache 2.0 라이선스와 폭넓은 프레임워크 지원 (Transformers, vLLM, Unsloth) 덕분에 실험하기가 매우 쉽습니다. 만약 로컬 하드웨어에서 텍스트를 빠르게 생성하는 것이 주요 제약 사항인 애플리케이션을 구축하고 있다면, 품질 저하(quality trade-off)가 귀하의 특정 사용 사례에서 수용 가능한 수준인지 테스트해 볼 가치가 있습니다.

시작하기

모델 가중치(model weights)는 Hugging Face의 google/diffusiongemma-26B-A4B-it에서 사용할 수 있습니다. 소비자용 하드웨어에서 로컬 배포를 할 경우, INT8 또는 INT4로 양자화(quantization)하면 VRAM 요구 사항을 각각 28GB 및 약 18GB로 낮출 수 있습니다. NVIDIA의 배포 가이드는 RTX GPU 및 DGX 시스템 설정을 다루고 있으며, vLLM의 데이 제로(day-zero) 지원 덕분에 추가 설정 없이 표준 추론 스택(inference stack)으로 모델을 서빙할 수 있습니다.

출처: Google DeepMind DiffusionGemma 페이지, Ars Technica 보도, NVIDIA 배포 블로그, DataNorth 벤치마크 분석