구글, 텍스트를 4배 빠르게 생성하는 확산형 젬마 모델 공개

• 구글이 디퓨전젬마(DiffusionGemma)를 공개함. 한마디로 "텍스트도 이미지 생성처럼 한 번에 깔아놓고 다듬자"는 실험 모델임

  • 아파치 2.0 라이선스로 공개된 실험적 오픈 모델임
  • 총 260억 파라미터 규모의 혼합 전문가(MoE) 모델이고, 추론 중 실제 활성화되는 파라미터는 38억 개임
  • 목표는 최고 품질 답변이 아니라, 로컬·대화형 환경에서의 빠른 텍스트 생성임

• 기존 대규모 언어 모델은 대부분 자동회귀(autoregressive) 방식이라 토큰을 하나씩 씀

  • 쉽게 말하면 타자기처럼 왼쪽에서 오른쪽으로 다음 글자를 계속 찍는 방식임
  • 클라우드 서버에서는 수천 개 요청을 묶어 배치 처리하면 하드웨어를 꽉 채울 수 있음
  • 하지만 로컬에서 사용자 1명이 돌릴 때는 전용 GPU나 TPU가 다음 토큰을 기다리느라 놀게 되는 시간이 생김

• 디퓨전젬마는 이 병목을 뒤집음. 256개 토큰짜리 블록을 한 번에 만들고 여러 번 고침

  • 무작위 placeholder 토큰으로 된 캔버스에서 시작함
  • 여러 패스를 돌며 맞는 토큰은 고정하고, 나머지는 주변 문맥을 보고 계속 정제함
  • 이미지 확산 모델이 노이즈에서 그림을 뽑아내듯, 텍스트 블록을 점점 완성하는 구조임

• 이 방식의 장점은 단순 속도만이 아님. 양방향 주의(bi-directional attention) 덕분에 텍스트 블록 전체를 같이 볼 수 있음

  • 자동회귀 모델은 기본적으로 이전 토큰을 보고 다음 토큰을 예측함
  • 디퓨전젬마는 256개 토큰을 병렬로 만들기 때문에 각 토큰이 블록 안의 다른 토큰을 참고할 수 있음
  • 그래서 인라인 편집, 코드 인필링, 아미노산 서열, 수학 그래프처럼 앞뒤 관계가 같이 중요한 작업에 유리하다고 구글은 설명함

• 예시로 나온 스도쿠도 꽤 적절함. 스도쿠는 왼쪽부터 한 칸씩 채우는 문제가 아니기 때문임

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

• 하드웨어 접근성도 꽤 공격적으로 잡았음. 양자화하면 18GB 비디오 메모리 안에 들어간다고 함

  • 총 모델은 260억 파라미터지만, MoE 구조라 추론 시 38억 파라미터만 켜짐
  • 고급 소비자용 전용 GPU에서도 실험할 수 있는 크기를 노린 셈임
  • 구글은 지포스 RTX 5090과 4090용 양자화, 기업용 호퍼·블랙웰 하드웨어, NVFP4 커널 최적화를 언급함

• 다만 구글도 이걸 표준 젬마 4 대체품으로 포장하진 않음

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

• 클라우드 대규모 서빙에서는 이 장점이 그대로 먹히지 않을 수 있음

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

• 개발 도구 생태계는 꽤 넓게 잡고 있음

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

• 결론적으로 디퓨전젬마는 "더 똑똑한 모델"이라기보다 "다른 지연 시간 곡선을 가진 모델"에 가까움

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

---

기술 맥락

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

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

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

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