구글, 토큰을 한 글자씩 뱉지 않는 실험적 모델 ‘디퓨전젬마’ 공개

• 구글이 실험적 오픈소스 모델 ‘디퓨전젬마’를 공개함

  • 핵심은 기존 거대언어모델처럼 토큰을 왼쪽에서 오른쪽으로 하나씩 생성하지 않는다는 점임
  • 한 번에 256개 토큰 규모의 텍스트 블록을 만들고, 이후 여러 번 반복 정제해 최종 결과를 완성하는 확산 방식을 쓴다고 설명됨
  • 구글은 이를 “한 글자씩 치는 게 아니라 문단 전체를 찍어내는 대형 인쇄기”에 비유함

• 기존 자기회귀 모델의 병목을 정면으로 찌르는 구조임

  • 대부분의 거대언어모델은 이전 토큰이 있어야 다음 토큰을 만들 수 있음
  • 이 방식은 품질은 좋지만, 생성 과정이 근본적으로 순차 처리라 병렬화에 한계가 있음
  • 디퓨전젬마는 텍스트 블록 전체를 동시에 생성하니 하드웨어 활용 방식 자체가 달라짐

• 속도 향상의 핵심은 병목을 메모리 대역폭에서 연산 쪽으로 옮긴 데 있음

  • 기존 모델은 다음 토큰을 만들 때마다 이전 상태를 읽고 쓰는 과정에서 메모리 대역폭 병목이 커짐
  • 디퓨전젬마는 그래픽처리장치가 기다리는 시간을 줄이고 실제 연산 자원을 더 많이 쓰도록 설계됐다고 함
  • 실시간 채팅, 즉각적인 문서 수정, 대화형 코딩 도구처럼 지연시간이 곧 사용자 경험인 앱에서 이점이 커질 수 있음

• 하드웨어 요구사항도 로컬 AI를 의식한 쪽임

  • 전체 모델 크기는 260억 매개변수지만, 전문가 혼합(MoE) 구조 덕분에 추론 중에는 38억 매개변수만 활성화함
  • 양자화를 적용하면 약 18GB 비디오 메모리로도 구동할 수 있다고 설명됨
  • RTX 4090이나 RTX 5090 같은 고성능 소비자용 그래픽카드에서도 실행 가능한 수준을 노린 셈임

• 디퓨전젬마가 특히 노리는 작업은 “앞뒤 문맥을 동시에 봐야 하는 생성”임

  • 기존 자기회귀 모델은 현재 토큰이 이전 토큰만 참조하는 구조임
  • 디퓨전젬마는 256개 토큰 블록 안의 토큰들이 서로를 모두 참조하는 양방향 주의집중을 활용함
  • 문서 중간 수정, 코드 인필링, 아미노산 서열 생성, 수학적 그래프 생성처럼 비선형적인 문제에서 강점을 보인다고 함

• 마크다운 문서 생성 같은 구조화 텍스트에도 유리하다고 설명됨

  • 마크다운은 시작과 끝이 맞아야 하는 구조가 많음
  • 목록, 코드 블록, 강조 표시처럼 앞뒤 짝이 깨지면 결과물이 바로 어색해짐
  • 블록 전체를 보고 정제하는 방식이면 이런 구조적 일관성을 맞추는 데 유리할 수 있음

• 생성 과정에서 모델이 스스로 결과를 고치는 ‘자기 정제’도 들어감

  • 초기 텍스트를 만든 뒤 여러 차례 반복하면서 전체 문단을 다시 검토함
  • 이미 확정된 토큰을 기준점으로 삼고 나머지 부분을 계속 개선하는 방식임
  • 이미지 생성 인공지능이 노이즈에서 시작해 점점 선명한 이미지를 만드는 과정과 비슷한 흐름임

• 구글은 디퓨전젬마를 연구자와 개발자용 실험 플랫폼으로 보고 있음

  • 로컬 AI, 실시간 편집, 고속 반복 작업, 비선형 텍스트 생성 사례를 탐색하는 데 적합하다고 설명함
  • 모델 가중치는 허깅페이스를 통해 공개됐고, 개발자 가이드도 함께 제공됨
  • 설치, 추론 환경 구성, 활용 사례, 최적화 기법을 단계별로 익힐 수 있게 자료를 제공한다고 함

sequenceDiagram
    participant 사용자
    participant 디퓨전젬마
    participant 토큰블록
    participant 정제루프
    participant 결과문서
    사용자->>디퓨전젬마: 프롬프트 입력
    디퓨전젬마->>토큰블록: 256개 토큰 블록 동시 생성
    토큰블록->>정제루프: 전체 문맥 기준으로 반복 검토
    정제루프->>토큰블록: 오류와 구조 불일치 수정
    토큰블록->>결과문서: 최종 텍스트 출력

기술 맥락

• 디퓨전젬마의 선택은 “모델을 더 크게 만들자”가 아니라 “생성 방식을 바꿔 병목을 줄이자”에 가까워요. 자기회귀 모델은 다음 토큰을 만들려면 이전 토큰이 필요해서, 좋은 그래픽처리장치가 있어도 순서대로 기다리는 시간이 생기거든요.

• 확산 방식을 텍스트에 적용한 이유는 블록 단위 병렬성을 얻기 위해서예요. 256개 토큰을 한꺼번에 만들고 여러 번 다듬으면, 그래픽처리장치가 놀지 않고 더 많은 연산을 한 번에 처리할 수 있어요.

• 양방향 주의집중이 중요한 건 문서 수정과 코드 인필링 때문이에요. 중간에 들어갈 내용을 만들 때는 앞쪽만 보면 부족하고, 뒤쪽 문맥까지 같이 봐야 자연스럽게 맞아떨어지거든요.

• 전문가 혼합 구조와 양자화는 로컬 실행을 위한 현실적인 타협이에요. 260억 매개변수 모델을 그대로 굴리면 부담이 크지만, 추론 때 38억 매개변수만 활성화하고 약 18GB 비디오 메모리로 맞추면 개인 워크스테이션에서도 실험 가능한 범위가 돼요.