---
title: "구글, 텍스트를 4배 빠르게 생성하는 확산형 젬마 모델 공개"
published: 2026-06-10T16:09:37.000Z
canonical: https://jeff.news/article/4023
---
# 구글, 텍스트를 4배 빠르게 생성하는 확산형 젬마 모델 공개

구글이 텍스트 확산 방식을 실험하는 오픈 모델 디퓨전젬마를 공개했다. 기존 대규모 언어 모델처럼 토큰을 왼쪽부터 하나씩 찍는 대신 256개 토큰 블록을 병렬로 다듬어, 단일 GPU 로컬 추론에서 최대 4배 빠른 생성을 노린다.

- 구글이 디퓨전젬마(DiffusionGemma)를 공개함. 한마디로 "텍스트도 이미지 생성처럼 한 번에 깔아놓고 다듬자"는 실험 모델임
  - 아파치 2.0 라이선스로 공개된 실험적 오픈 모델임
  - 총 260억 파라미터 규모의 혼합 전문가(MoE) 모델이고, 추론 중 실제 활성화되는 파라미터는 38억 개임
  - 목표는 최고 품질 답변이 아니라, 로컬·대화형 환경에서의 빠른 텍스트 생성임

- 기존 대규모 언어 모델은 대부분 자동회귀(autoregressive) 방식이라 토큰을 하나씩 씀
  - 쉽게 말하면 타자기처럼 왼쪽에서 오른쪽으로 다음 글자를 계속 찍는 방식임
  - 클라우드 서버에서는 수천 개 요청을 묶어 배치 처리하면 하드웨어를 꽉 채울 수 있음
  - 하지만 로컬에서 사용자 1명이 돌릴 때는 전용 GPU나 TPU가 다음 토큰을 기다리느라 놀게 되는 시간이 생김

- 디퓨전젬마는 이 병목을 뒤집음. 256개 토큰짜리 블록을 한 번에 만들고 여러 번 고침
  - 무작위 placeholder 토큰으로 된 캔버스에서 시작함
  - 여러 패스를 돌며 맞는 토큰은 고정하고, 나머지는 주변 문맥을 보고 계속 정제함
  - 이미지 확산 모델이 노이즈에서 그림을 뽑아내듯, 텍스트 블록을 점점 완성하는 구조임

> [!IMPORTANT]
> 구글이 제시한 핵심 수치는 단일 엔비디아 H100에서 초당 1000개 이상, 지포스 RTX 5090에서 초당 700개 이상 토큰 생성임. 단일 GPU 로컬 추론 기준으로 최대 4배 빠른 생성을 노린다는 얘기임.

- 이 방식의 장점은 단순 속도만이 아님. 양방향 주의(bi-directional attention) 덕분에 텍스트 블록 전체를 같이 볼 수 있음
  - 자동회귀 모델은 기본적으로 이전 토큰을 보고 다음 토큰을 예측함
  - 디퓨전젬마는 256개 토큰을 병렬로 만들기 때문에 각 토큰이 블록 안의 다른 토큰을 참고할 수 있음
  - 그래서 인라인 편집, 코드 인필링, 아미노산 서열, 수학 그래프처럼 앞뒤 관계가 같이 중요한 작업에 유리하다고 구글은 설명함

- 예시로 나온 스도쿠도 꽤 적절함. 스도쿠는 왼쪽부터 한 칸씩 채우는 문제가 아니기 때문임
  - 언슬로스(Unsloth)는 디퓨전젬마를 스도쿠 풀이에 파인튜닝한 사례를 공개함
  - 스도쿠는 뒤쪽 칸의 정보가 앞쪽 칸 선택에도 영향을 주기 때문에, 한 방향 생성 모델이 헷갈리기 쉬움
  - 양방향으로 전체 판을 보며 다듬는 구조가 이런 비선형 문제에 더 잘 맞는다는 시연임

- 하드웨어 접근성도 꽤 공격적으로 잡았음. 양자화하면 18GB 비디오 메모리 안에 들어간다고 함
  - 총 모델은 260억 파라미터지만, MoE 구조라 추론 시 38억 파라미터만 켜짐
  - 고급 소비자용 전용 GPU에서도 실험할 수 있는 크기를 노린 셈임
  - 구글은 지포스 RTX 5090과 4090용 양자화, 기업용 호퍼·블랙웰 하드웨어, NVFP4 커널 최적화를 언급함

- 다만 구글도 이걸 표준 젬마 4 대체품으로 포장하진 않음
  - 전체 출력 품질은 표준 젬마 4보다 낮다고 명시함
  - 고품질 운영 답변이 중요한 앱은 여전히 자동회귀 기반 젬마 4를 쓰는 게 권장됨
  - 디퓨전젬마는 빠른 반응, 실시간 편집, 반복 실험, 비선형 텍스트 구조 생성처럼 지연 시간이 더 중요한 영역을 겨냥함

> [!TIP]
> 로컬 인공지능 앱을 만드는 개발자라면 "품질 최고 모델 하나"보다 "작업별로 빠른 모델과 품질 모델을 나눠 쓰는 구조"를 고민해볼 만함.

- 클라우드 대규모 서빙에서는 이 장점이 그대로 먹히지 않을 수 있음
  - 고동시성 환경에서는 자동회귀 모델도 많은 요청을 배치로 묶어 계산 자원을 꽉 채울 수 있음
  - 디퓨전젬마의 병렬 디코딩은 단일 가속기에서 낮거나 중간 정도의 배치 크기일 때 이점이 가장 큼
  - 구글도 높은 초당 요청량 환경에서는 비용 이점이 줄고, 오히려 서빙 비용이 높아질 수 있다고 설명함

- 개발 도구 생태계는 꽤 넓게 잡고 있음
  - 가중치는 허깅페이스에서 받을 수 있음
  - MLX, vLLM, 허깅페이스 트랜스포머로 서빙할 수 있고, 레드햇이 vLLM 통합을 지원함
  - 파인튜닝은 해커블 디퓨전(Hackable Diffusion), 언슬로스, 엔비디아 네모(NeMo) 쪽을 언급함
  - 라마닷씨피피(llama.cpp) 공식 지원도 곧 온다고 밝힘

- 결론적으로 디퓨전젬마는 "더 똑똑한 모델"이라기보다 "다른 지연 시간 곡선을 가진 모델"에 가까움
  - 로컬 코드 에디터, 실시간 문서 편집, 빠른 초안 생성, 구조화 텍스트 수정 같은 곳에서 체감이 클 수 있음
  - 반대로 법률 문서, 고신뢰 답변, 긴 추론 품질이 중요한 서비스라면 표준 젬마 4가 더 맞을 가능성이 큼
  - 개발자 입장에선 모델 선택 기준에 지능뿐 아니라 배치 크기, 하드웨어 활용률, 지연 시간, 품질 저하 폭을 같이 넣어야 함

---

## 기술 맥락

- 디퓨전젬마의 핵심 선택은 토큰을 하나씩 생성하지 않고 256개 토큰 블록을 병렬로 다듬는 거예요. 왜 이게 중요하냐면 로컬 추론에서는 사용자 요청이 하나뿐인 경우가 많아서, 자동회귀 모델이 GPU를 충분히 바쁘게 만들기 어렵거든요.

- 구글이 품질보다 속도와 반응성을 앞세운 것도 이 맥락이에요. 서버에서 수많은 요청을 배치 처리하는 제품이라면 기존 모델도 효율이 잘 나오지만, 개인용 그래픽카드에서 인라인 편집이나 코드 보완을 할 때는 첫 응답과 토큰 속도가 훨씬 크게 느껴져요.

- MoE 구조도 같은 목표를 향해 있어요. 전체 모델은 260억 파라미터지만 추론 때 38억 개만 활성화하면, 모델 표현력은 어느 정도 유지하면서 실제 계산량과 메모리 부담을 줄일 수 있어요. 그래서 양자화 시 18GB 비디오 메모리 안에 넣는 전략이 가능해져요.

- 자동회귀 모델을 버린다는 뜻은 아니에요. 구글도 고품질 운영 출력은 표준 젬마 4를 권장해요. 대신 빠른 초안, 코드 인필링, 비선형 텍스트 생성처럼 앞뒤 문맥을 동시에 보는 게 유리한 작업에는 확산형 텍스트 생성이 별도 선택지가 될 수 있다는 얘기예요.

## 핵심 포인트

- 디퓨전젬마는 아파치 2.0 라이선스로 공개된 260억 총 파라미터 규모의 혼합 전문가 모델
- 추론 시 활성화되는 파라미터는 38억 개라 양자화하면 18GB 비디오 메모리 안에 들어감
- 단일 엔비디아 H100에서 초당 1000개 이상, 지포스 RTX 5090에서 초당 700개 이상 토큰 생성을 제시함
- 품질은 표준 젬마 4보다 낮아 고품질 운영 환경보다는 로컬·대화형·저동시성 워크플로에 맞춰짐

## 인사이트

로컬 인공지능 앱에서 병목이 되는 지연 시간을 정면으로 겨냥한 모델이다. 품질보다 반응성이 중요한 코드 인필링, 실시간 편집, 구조화 텍스트 생성 쪽에서는 자동회귀 모델만 고집할 이유가 줄어들 수 있다.