DiffusionGemma: 4배 빠른 텍스트 생성

 (blog.google)
4P by GN⁺ | ★ favorite | 댓글 1개
  • DiffusionGemma는 텍스트 확산 방식으로 전체 텍스트 블록을 동시에 생성하는 Apache 2.0 라이선스의 26B MoE 실험용 공개 모델임
  • 일반적인 자기회귀 LLM의 순차적 토큰 생성 대신 256토큰 병렬 생성을 사용해 전용 GPU에서 최대 4배 빠른 텍스트 생성을 제공함
  • 추론 시 전체 26B 중 3.8B 파라미터만 활성화하며, 양자화하면 18GB VRAM 한도 안에서 고급 소비자용 전용 GPU에 맞게 동작함
  • 양방향 어텐션과 반복적 자체 수정으로 인라인 편집, 코드 채우기, 아미노산 서열, 수학 그래프처럼 비선형 구조가 있는 작업에 이점이 있음
  • 속도와 병렬 레이아웃 생성을 우선한 실험 모델이므로 전체 출력 품질은 표준 Gemma 4보다 낮으며, 최고 품질이 필요한 애플리케이션에는 표준 Gemma 4 배포가 권장됨

개발자를 위한 새로운 가치

  • DiffusionGemma는 텍스트 확산을 탐색하는 실험용 공개 모델이며, 일반적인 자기회귀 LLM의 토큰별 순차 처리를 넘어 전체 텍스트 블록을 동시에 생성함
  • 이 모델은 Apache 2.0 라이선스로 제공되는 26B Mixture of Experts(MoE) 모델이며, GPU에서 최대 4배 빠른 텍스트 생성을 제공함
  • Gemma 4 계열의 파라미터당 지능과 Gemini Diffusion research를 기반으로 하며, 생성 속도 극대화를 위한 새로운 확산 헤드를 통합함
  • 자기회귀 Gemma 4 모델은 고품질 프로덕션 출력의 표준으로 유지되며, DiffusionGemma는 속도가 중요한 대화형 로컬 워크플로를 탐색하는 연구자와 개발자를 위해 설계됨

  • 핵심 트레이드오프

    • 빠른 추론은 디코딩 병목을 메모리 대역폭에서 연산으로 옮겨 전용 GPU에서 최대 4배 빠른 토큰 출력을 제공함
    • 단일 NVIDIA H100에서 초당 1000개 이상 토큰, NVIDIA GeForce RTX 5090에서 초당 700개 이상 토큰을 생성함
    • 하드웨어 접근성은 전체 26B MoE 중 추론 시 3.8B 파라미터만 활성화하는 구조에서 나옴
    • 양자화하면 고급 소비자용 전용 GPU의 18GB VRAM 한도 안에 맞게 동작함
    • 양방향 어텐션은 각 순전파마다 256토큰을 병렬 생성해 모든 토큰이 서로를 참조할 수 있게 함
    • 인라인 편집, 코드 채우기, 아미노산 서열, 수학 그래프 같은 비선형 영역에서 이점이 있음
    • 자체 수정은 모델이 전체 텍스트 블록을 한 번에 평가하면서 실시간으로 실수를 고치도록 반복적으로 출력을 다듬는 방식임
    • 실험적 상태와 프로덕션 권고는 명확하며, 속도와 병렬 레이아웃 생성을 우선하기 때문에 전체 출력 품질은 표준 Gemma 4보다 낮음

  • 미세조정 예시

    • 특정 작업 성능은 미세조정으로 개선할 수 있음
    • Unsloth는 DiffusionGemma가 스도쿠를 풀도록 미세조정했으며, 스도쿠는 각 토큰이 미래 토큰에 의존하기 때문에 자기회귀 모델이 어려워하는 작업임
    • DiffusionGemma의 양방향 어텐션은 스도쿠 같은 작업을 훨씬 쉽게 만듦

텍스트에 확산을 쓰는 이유

  • AI 연구 커뮤니티는 수년간 확산 기반 텍스트 생성을 탐색해 왔지만, 이를 대형 모델에 적용하는 일은 도전 과제로 남아 있었음
  • DiffusionGemma는 모델이 하드웨어를 사용하는 방식을 바꿔 이 문제를 다룸

  • 기존 모델과의 트레이드오프

    • 대부분의 언어 모델은 타자기처럼 왼쪽에서 오른쪽으로 한 번에 하나의 토큰을 생성함
    • 클라우드에서는 서버가 수천 개 사용자 요청을 함께 배치 처리해 하드웨어 부하를 공유할 수 있으므로 이 방식이 효율적임
    • 단일 사용자가 로컬에서 실행할 때는 단어 단위 생성이 전용 GPU나 TPU를 충분히 활용하지 못하게 하며, 하드웨어가 다음 “키 입력”을 기다리는 시간이 많아짐
    • DiffusionGemma는 256토큰 문단 전체를 동시에 초안 작성해 컴퓨터 프로세서에 더 큰 작업 덩어리를 한 번에 제공함
    • 이 구조는 모델 추론을 순차적 타자기에서 전체 텍스트 블록을 동시에 찍는 대형 인쇄기처럼 바꾸는 방식임

  • 로컬·저동시성 추론에 맞춘 속도 향상

    • DiffusionGemma의 속도 향상은 로컬 추론과 낮은 동시성 추론을 위해 설계됨
    • 높은 QPS 클라우드 서빙에서는 자기회귀 모델도 연산을 효율적으로 포화하도록 배포할 수 있음
    • 높은 QPS 환경에서는 DiffusionGemma의 병렬 디코딩 이점이 줄어들며, 서빙 비용이 더 높아질 수 있음
    • 처리량 이점은 단일 가속기에서 낮은 배치 크기부터 중간 배치 크기까지 가장 강함

텍스트 확산의 작동 방식

  • 텍스트 확산은 시각적 노이즈에서 시작해 선명한 그림으로 반복 개선하는 AI 이미지 생성 방식과 유사한 절차를 텍스트에 적용함
  • 첫 단계인 캔버스에서는 모델이 무작위 플레이스홀더 토큰으로 구성된 캔버스에서 시작함
  • 반복 개선 단계에서는 모델이 여러 차례 패스를 수행하고, 올바른 토큰을 고정한 뒤 이를 맥락 단서로 사용해 나머지를 다듬음
  • 최종 다듬기 단계에서는 텍스트가 고품질 출력으로 수렴함
  • 모델이 생성 중 문단 전체를 처리할 수 있기 때문에 복잡한 Markdown 서식을 정확히 닫거나 코드를 거의 실시간으로 생성하고 렌더링하는 동작 패턴이 가능해짐

시작 방법

  • 실험용 모델 가중치는 허용적인 Apache 2.0 라이선스로 제공되며 Hugging Face에서 접근할 수 있음
  • DiffusionGemma developer guide에서 통합 방법을 확인할 수 있으며, A Visual Guide to DiffusionGemma에서 내부 메커니즘을 더 깊게 볼 수 있음
  • 모델 서빙은 MLX, vLLM, Hugging Face Transformers를 사용해 수행할 수 있음
  • vLLM 통합은 Red Hat의 지원을 받음
  • 빠른 실험을 위해 조합성을 위해 설계된 모듈형 JAX 도구상자인 Hackable Diffusion 기반 미세조정 튜토리얼이 제공됨
  • 미세조정은 Unsloth와 NVIDIA NeMo로도 탐색할 수 있음
  • llama.cpp 공식 지원은 곧 제공될 예정임

최적화와 실행 환경

  • NVIDIA와의 협업으로 하드웨어 스택 전반에서 최적화가 이뤄졌으며, 소비자 환경과 엔터프라이즈 시스템 모두에서 호환성과 성능을 제공함
  • 소비자 환경은 GeForce RTX 5090과 4090 GPU용 양자화를 지원함
  • 엔터프라이즈 환경은 고급 NVFP4 커널을 사용하는 Hopper와 Blackwell에서 고성능을 제공함
  • 로컬 데스크사이드 배포용 NVIDIA DGX Spark와 DGX Station, AI 전문가용 RTX PRO도 대상에 들어감
  • NVFP4 4비트 부동소수점 네이티브 지원은 연산 처리량을 가속해 모델이 더 빠른 속도와 거의 손실 없는 정확도로 실행되게 함
  • 실행 방식은 데스크톱 전용 GPU, Gemini Enterprise Agent Platform Model Garden, NVIDIA NIM 중에서 선택할 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 최근 OpenCode로 옮겨서 미국 주요 프런티어 연구소가 아닌 모델들을 많이 써봤는데, 예상 밖으로 가장 마음에 든 모델은 Mercury였음
    “똑똑해서”가 아니라 말도 안 되게 빨랐기 때문임. 프롬프트를 넣고 기다리는 최신 에이전트식 경험보다 페어 프로그래밍에 가까웠고, AI의 이점은 얻으면서도 AI 이전 코딩 감각이 일부 돌아와 더 재미있었음. 프롬프트를 넣고 기다리며 방향이 맞기를 비는 슬롯머신 같지 않았고, Gemini Flash Lite나 GPT Mini/Nano 같은 작은 모델도 더 자주 쓰게 됨. 오픈 가중치 모델이 나와서 기대되고 바로 테스트해볼 예정임

    • 테스트를 빠르고 싸게 돌릴 수 있고, 나쁜 코드나 대충 짠 코드를 판별하는 저비용 지표도 빠르게 만들 수 있다면, 시간이 중요할 때는 느리지만 훨씬 좋은 모델보다 빠르지만 조금 떨어지는 모델이 더 나을 수 있음
      순환 복잡도가 아닌 실제 복잡도를 측정하는 지표를 두고, 기능에 비해 추가된 복잡도가 합리적인 범위에 들어올 때까지 자동으로 되돌리게 했더니 LLM 사용 성과가 꽤 좋았음
    • Mercury-2는 훌륭함. llm-consortium에서 중재자 역할로 자주 쓰고 있음
      문맥 창이 비교적 작아서 더 큰 컨소시엄에 쓰려면 재귀적인 메타 컨소시엄 비슷하게 구성할 수 있음:
      llm consortium save cns-glm -m glm-5.2 -n 5 --arbiter mercury-2 --judging-method rank
      llm consortium save cns-kimi -m k2.6 -n 5 --arbiter mercury-2 --judging-method rank
      llm consortium save cns-meta-glm-kimi -m cns-glm -m cns-kimi --arbiter mercury-2 --judging-method synthesis
      이제 cns-meta-glm-kimi에 프롬프트를 넣으면 kimi와 glm에서 각각 5개 중 최선을 고른 뒤, 두 우승 답변을 합성함
    • 이게 코딩용 로컬 모델에 얼마나 영향을 줄지 궁금함. Qwen이나 Gemma 4보다 몇 배 빠른 확산 모델을 쓰면 AI 이전처럼 내가 더 많이 준비해야 하겠지만, 그게 오히려 좋을 수 있고 로컬에서 매우 빠르고 저렴한 모델과 작업할 수 있을 듯함
      오래 무거운 계산을 하지 않는다면 로컬 하드웨어에서 돌리는 비용도 더 싸지 않을까 싶음
    • 무슨 말인지 정확히 알겠음. 개인 프로젝트에서 Claude가 너무 느려 답답해서 Google Antigravity와 Flash 모델로 바꿨는데 속도 차이가 엄청남
      흐름을 더 잘 타고 작업에 더 집중하게 됨. 속도가 이렇게 큰 차이를 만드는 줄 몰랐음. Claude는 아주 복잡하고 큰 코드베이스에서는 느린 응답 시간이 과업 복잡도와 맞바꿀 만하지만, Antigravity나 다른 빠른 모델들은 작고 가볍게 코드 작성, 실행, 디버깅을 반복하고 싶을 때 훨씬 잘 맞음
    • 맞음, 속도가 핵심임. 보일러플레이트 POJO나 데이터 클래스를 300+ tok/s의 미친 속도로 생성해주는 게 좋고, 이런 식이면 Flash-Lite가 GPT-5.5보다 더 유용함
      너무 느리면 그 빌어먹을 비동기 대기 루프에 갇혀버림

  • Google이 계속 힘을 보여주는 중임. Gemini가 코드나 에이전트 용도에서 Claude나 OpenAI 모델보다 더 경쟁력 있지 않은 게 놀랍지만, Google에 여전히 업계 최고 수준의 AI 인력이 있는 건 분명함
    다만 Google은 큰 사고형 LLM보다 휴대폰에서 돌거나 거의 실시간인 사용 사례에 집중하는 듯함. 이런 효율 개선은 앞으로 AI에 매우 중요해질 가능성이 큼. 특정 생태계에 묶어두려고 토큰을 보조금처럼 싸게 주던 시기는 끝나가고, 실제 비용을 내야 할 때가 오고 있음. 정말 똑똑한 모델을 비용 효율적으로 돌리는 법을 찾는 회사가 이길 것임. DeepSeek는 GPT 5.5나 Opus 4.8보다 한 자릿수 배 이상 싸고, 둘보다 나쁘긴 하지만 치명적으로 나쁘지는 않음. 최고의 코딩 모델이 인간 시간을 충분히 아껴준다면 10배는 기꺼이 내겠지만, 최근 벤치마크에서 GPT 5.5 Pro가 DeepSeek보다 200배 이상, Opus 4.8보다 약 30배 비싼 경우처럼 100배 차이면 받아들이기 어려움

    • Fable은 Opus의 두 배 비용이고 GPT-Pro와도 꽤 경쟁력 있어 보여서, 과민한 안전장치가 큰 문제가 아니라면 괜찮은 선택지일 수 있음
      Google도 이 영역에 자체 “Deep Research” 옵션이 있고 잘 작동하는 듯함. DeepSeek의 좋은 점은 API 비용 없이 로컬 하드웨어에서 돌릴 수 있다는 점임. 그걸 중요하게 본다면 Opus나 GPT보다 조금 떨어지는 건 큰 문제가 아님
    • 결국 Google이 이길 것 같음. 와트당 성능과 달러당 성능이라는 중요한 부분에 집중하고 있음
      자체 추론 하드웨어를 만들고 있고, 지연 시간과 계산 오버헤드를 줄이는 엣지 컴퓨팅으로 가고 있음. 큰 LLM들은 아직 비용 효율적이지 않고, Google은 경쟁사들이 소비자에게 원가 이하로 “팔기” 위해 투자금을 태우게 두는 중임. AI 거품이 터진 뒤에도 Google 같은 회사는 멀쩡히 살아남을 것이고, 이 거품은 일부 거대 기업의 껍질을 벗겨내려는 것처럼 보임

  • 일부 반응은 확산 방식의 장점을 놓치고 있음. 휴대폰이나 컴퓨터 GPU 같은 엣지 기기에는 큰 영향을 줄 수 있음
    LLM의 디코더는 이전 토큰들을 모두 고려해야 해서 토큰을 하나씩 계산함. 기존 LLM 디코더는 여러 추론을 배치로 묶을 만큼 부하가 충분하면 잘 확장되고, 그 환경에서는 확산의 이점이 제한적임. 엣지에서는 문제가 다름. 추론 가속기가 RAM에서 GB 단위 가중치를 계속 옮기느라 굶주림 상태가 됨. LPDDRx/GDDRx 같은 소비자용 RAM은 HBM보다 대역폭이 낮고, 요청이 직렬이라 공통 가중치 계산을 배치로 묶을 수 없기 때문임. 확산은 토큰을 병렬로 계산할 수 있어 메모리 대역폭 병목을 완화함

    • 엣지 기기는 메모리 대역폭만 부족한 게 아니라 연산 성능도 매우 제한적임. 실제로는 많은 배치가 없어도 가능한 연산량을 금방 포화시키고 명확한 발열·전력 한계에 걸림
      엣지 추론에서 “요청이 본질적으로 직렬”이라는 말도 사실이 아님. 동시에 여러 요청, 즉 여러 채팅이 진행 중이고 KV 캐시를 담을 메모리 용량이 충분하면 배치 처리가 적용될 수 있음. 확산 모델이 더 많은 연산으로 낮은 품질을 내고 메모리 대역폭 절감도 애매하다면 어떻게 도움이 되는지 잘 모르겠음
    • 대체로 맞지만, 어텐션과 자기회귀·인과 구조를 섞어 말하고 있음. 더 많은 연산을 쓰지 못하게 막는 진짜 문제는 자기회귀·인과 구조임
      확산에서도 어텐션을 쓸 수 있고, 이 모델도 실제로 어텐션을 사용함

  • NVIDIA가 이 모델용 무료 엔드포인트를 제공하고 있음. 자세한 내용은 https://build.nvidia.com/google/diffusiongemma-26b-a4b-it에 있고, 계정을 만들고 아마 전화번호 인증도 해야 함
    펠리컨을 그리게도 해봤음: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...

    • 아주 빠른 모델이라면 애니메이션 프레임을 요청할 수도 있겠음. 예를 들어 1프레임은 오른발 12시, 왼발 6시, 2프레임은 오른발 3시, 왼발 9시 같은 식임
      그러면 초당 토큰 수가 아니라 당연히 초당 펠리컨 프레임 수를 보고해야 함
    • 몇 주 전에 등록했는데 절차를 따랐어도 아직 계정이 인증되지 않았음. 계정이 인증되지 않으면 API를 쓸 수 없음

  • DiffusionGemma 같은 텍스트 확산 모델이 어떻게 작동하는지 보여주는 좋은 시각 설명: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

  • 며칠 전만 해도 Google이 1년 전 I/O에서 시연한 뒤 확산 텍스트 생성 모델에 대해 전혀 말하지 않는다고 생각했음
    돌리기 너무 비싸다는 소문이 있었지만, 제공된 차트처럼 같은 1x H100 하드웨어에서 DiffusionGemma와 일반 Gemma를 비교한다면 그렇지는 않아 보임. Gemma보다 약간 약하다는 것 말고 이 속도의 단점이 무엇인지 궁금함

    • “이 속도의 단점이 무엇인지 궁금함”에 대한 답은 이 부분 같음:
      “DiffusionGemma의 속도 향상은 로컬 및 낮은 동시성 추론을 위해 설계됐다. 높은 QPS의 클라우드 서빙에서는 자기회귀 모델을 효율적으로 배치해 연산을 포화시킬 수 있으므로, DiffusionGemma의 병렬 디코딩 이점은 줄어들고 서빙 비용이 더 높아질 수 있다”
    • 표준 자기회귀 모델이라면 사용자가 256명 있을 때 예를 들어 한 번에 256개 토큰을 생성할 수 있음. 이 방식은 사용자 한 명에게 256개 토큰을 생성할 수 있지만 여러 번의 순전파 단계가 필요함
      그래서 확산 과정은 더 많은 GFLOPs를 쓰고, 사용자가 충분히 많으면 이미 메모리와 연산의 균형을 맞출 수 있음

  • “DiffusionGemma는 이 비효율을 뒤집는다. 단어를 순차적으로 예측하는 대신 256토큰 문단 전체의 초안을 동시에 만든다. 컴퓨터 프로세서에 더 큰 작업 덩어리를 한 번에 줌으로써 하드웨어를 최대한 활용한다. 모델 추론을 한 글자씩 치는 타자기에서 텍스트 블록 전체를 동시에 찍어내는 거대한 인쇄기로 업그레이드한다”
    “추론 중 3.8B 파라미터만 활성화하는 총 26B 규모의 전문가 혼합(MoE) 모델로 동작하며, 양자화하면 고급 소비자용 전용 GPU의 18GB VRAM 한계 안에 편안히 들어간다”
    그러니까 Gemma 4 26B는 ollama로 내 24GB GPU에서 아주 빠르게 도는 MoE 모델임. 이건 추측 디코딩처럼 들리지만, MoE 모델에서는 그게 작동하지 않는다고 생각했음. 이걸 따라가는 게 일이 아닌 사람에게는 변화가 너무 많아 따라가기 힘듦

    • 이건 기존 gemma4 MoE와 혼란스럽게도 파라미터 수가 거의 같은 다른 모델임. 둘 중 하나가 다른 하나에서 어떤 방식으로 학습됐는지는 빠르게 훑어봐서는 불분명함
      메커니즘은 추측 디코딩과 같지 않음. 추측 디코딩은 순차적으로, 보통 몇 개 토큰씩 진행됨. 확산은 그렇지 않고 텍스트 블록을 한 번에 다룸. 아직 자료를 읽어보진 않았지만, 확산 블록 전체에서 특정 전문가들이 안정적으로 유지되도록 학습했을 것이라고 추정함

  • 내 3090 Ti에서는 광고된 속도 근처에도 못 미치지만, 답변을 “채워 넣는” 모습을 보는 건 재미있음
    Simon의 “자전거 탄 SVG 펠리컨” 테스트를 해봤고 결과는 꽤 미니멀하지만 요구사항에는 맞았음: https://gist.github.com/peterc/7672e74ec1437945e5fca5ce2c1c9... -- 패치된 llama.cpp에서 Q4 양자화로 돌린 결과임. Simon의 결과가 많이 다른지도 궁금함

  • 확산형 추론 모델은 어떤 모습일까? 미리 정해진 길이의 [thinking] 블록을 오래 확산시키고, 최종 출력 블록은 그 thinking 블록 내용을 입력의 일부로 쓰는 식일까?
    그리고 확산 모델은 애초에 출력 길이를 어떻게 정할까? 미리 정한 파라미터인지, 아니면 중간 어딘가에 [end] 토큰을 확산시키는지 궁금함

  • 멋지긴 하지만 로컬 모델은 이미 괜찮아도 가장 싼 API보다도 체감상 확실히 떨어져서, 속도를 위해 품질을 조금이라도 희생할 생각은 잘 안 듦
    어떤 사용 사례에는 분명 가치가 있겠지만, 실제로 프로덕션에 배포하려는 구체적인 사례가 궁금함

    • 단위 테스트 작성이나 부트스트랩에는 괜찮을 수 있음
      Opus급이 아니어도 작성 가능하고, 반복하기도 쉬움
답변달기