구글, 토큰을 한 글자씩 찍지 않는 오픈소스 모델 ‘디퓨전젬마’ 공개

• 구글이 텍스트 생성 방식을 아예 다르게 가져가는 오픈소스 모델 ‘디퓨전젬마’를 공개함

  • 기존 대규모 언어 모델은 보통 자기회귀 방식이라 토큰을 왼쪽에서 오른쪽으로 하나씩 만듦
  • 디퓨전젬마는 확산 방식으로 한 번에 256개 토큰짜리 텍스트 블록을 만들고, 여러 번 반복하면서 문단 전체를 정제함
  • 구글은 기존 방식을 ‘타자기’, 디퓨전젬마를 ‘대형 인쇄기’에 비유함. 비유가 좀 세긴 한데 방향은 명확함

• 핵심 숫자는 속도임. 구글 기준으로 같은 하드웨어에서 기존 자기회귀 모델보다 최대 4배 빠름

  • 엔비디아 H100에서는 초당 1000토큰 이상 생성 가능
  • 지포스 RTX 5090에서도 초당 700토큰 이상을 낸다고 밝힘
  • 병목을 메모리 대역폭 중심에서 연산 중심으로 옮겨, 그래픽카드가 기다리는 시간을 줄였다는 설명임

• 모델 구조도 로컬 실행을 꽤 의식하고 설계됨

  • 전체 규모는 260억 파라미터지만 전문가혼합 구조라 실제 추론 때는 약 38억 파라미터만 활성화됨
  • 양자화를 적용하면 약 18GB 브이램으로도 돌릴 수 있다고 함
  • RTX 4090, RTX 5090 같은 고성능 소비자용 그래픽카드를 가진 개발자라면 실험 대상에 들어오는 수준임

• 디퓨전젬마가 특히 흥미로운 지점은 양방향 주의집중을 쓴다는 점임

  • 자기회귀 모델은 현재 토큰을 만들 때 과거 토큰만 참고하는 구조임
  • 디퓨전젬마는 한 번에 생성되는 256개 토큰이 서로를 모두 참고할 수 있음
  • 그래서 문서 중간 수정, 코드 인필링, 마크다운 구조 생성처럼 앞뒤 문맥을 동시에 맞춰야 하는 작업에 잘 맞을 수 있음

• 구글은 스도쿠 사례로 차이를 보여줌

  • 스도쿠는 각 칸의 답이 다른 칸과 강하게 연결돼 있어서 순서대로 답을 쓰는 모델에게 불리함
  • 언슬로스가 디퓨전젬마를 스도쿠 전용으로 파인튜닝했는데, 전체 퍼즐을 동시에 고려하는 구조가 문제 특성과 잘 맞았다는 설명임
  • 이게 최적화 문제, 과학 계산, 구조화 데이터 생성 쪽으로 이어질 수 있다는 게 구글의 기대임

• 그렇다고 당장 젬마4를 대체하는 모델은 아님

  • 구글도 출력 품질은 아직 젬마4가 더 낫다고 선을 그음
  • 최고 품질 응답이 필요한 상용 서비스라면 젬마4를 쓰는 게 낫다는 입장임
  • 디퓨전젬마는 연구자와 개발자가 로컬 AI, 실시간 편집, 고속 반복 작업, 비선형 텍스트 생성을 실험해보는 플랫폼에 가까움

• 생태계 연동은 꽤 공격적으로 깔아둠

  • 허깅페이스를 통해 모델 가중치를 공개했고, 개발자 가이드와 시각적 가이드도 제공함
  • MLX, vLLM, 허깅페이스 트랜스포머, 엔비디아 니모, 언슬로스, 해커블 디퓨전과 연동됨
  • 레드햇은 vLLM 통합을 지원하고, 엔비디아는 H100과 블랙웰 최적화를 맡았음
  • 엔비디아의 4비트 부동소수점 포맷 NVFP4를 활용해 정확도 손실을 줄이면서 처리량을 높였다고 함

---

기술 맥락

• 디퓨전젬마의 선택은 “언어 모델은 반드시 다음 토큰 예측이어야 하나”에서 출발해요. 자기회귀 방식은 품질이 강하지만 순차성이 너무 강해서, 로컬 실행처럼 요청이 하나씩 들어오는 환경에서는 그래픽카드가 놀게 되는 시간이 생기거든요.

• 확산 방식은 한 블록을 먼저 만들고 여러 번 고치는 구조라서 병렬 연산을 더 많이 태울 수 있어요. 그래서 H100이나 RTX 5090 같은 그래픽카드에서 초당 토큰 수가 크게 올라가는 건데, 대신 반복 정제 과정에서 품질을 얼마나 안정적으로 끌어올리느냐가 숙제로 남아요.

• 전문가혼합 구조도 같은 맥락이에요. 전체 모델은 260억 파라미터지만 매번 약 38억 파라미터만 쓰면, 모델 용량은 확보하면서 실제 추론 비용은 줄일 수 있어요. 로컬 AI를 노린다면 이 절충이 꽤 중요해요.

• 양방향 주의집중은 문서 편집이나 코드 인필링에서 의미가 커요. 앞부분만 보고 다음을 쓰는 게 아니라 앞뒤 문맥을 동시에 보고 빈칸을 채울 수 있으니, “문장 중간을 자연스럽게 바꾸는” 작업에는 구조적으로 더 잘 맞는 편이에요.