# DiffusionGemma: 4배 빠른 텍스트 생성 > Clean Markdown view of GeekNews topic #30386. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30386](https://news.hada.io/topic?id=30386) - GeekNews Markdown: [https://news.hada.io/topic/30386.md](https://news.hada.io/topic/30386.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-06-11T10:49:27+09:00 - Updated: 2026-06-11T10:49:27+09:00 - Original source: [blog.google](https://blog.google/innovation-and-ai/technology/developers-tools/diffusion-gemma-faster-text-generation/) - Points: 3 - Comments: 1 ## Topic Body - **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](https://deepmind.google/models/gemini-diffusion/)를 기반으로 하며, 생성 속도 극대화를 위한 새로운 확산 헤드를 통합함 - 자기회귀 Gemma 4 모델은 고품질 프로덕션 출력의 표준으로 유지되며, DiffusionGemma는 속도가 중요한 대화형 로컬 워크플로를 탐색하는 연구자와 개발자를 위해 설계됨 - ## 핵심 트레이드오프 - **빠른 추론**은 디코딩 병목을 메모리 대역폭에서 연산으로 옮겨 전용 GPU에서 최대 4배 빠른 토큰 출력을 제공함 - 단일 NVIDIA H100에서 초당 1000개 이상 토큰, NVIDIA GeForce RTX 5090에서 초당 700개 이상 토큰을 생성함 - **하드웨어 접근성**은 전체 26B MoE 중 추론 시 3.8B 파라미터만 활성화하는 구조에서 나옴 - 양자화하면 고급 소비자용 전용 GPU의 18GB VRAM 한도 안에 맞게 동작함 - **양방향 어텐션**은 각 순전파마다 256토큰을 병렬 생성해 모든 토큰이 서로를 참조할 수 있게 함 - 인라인 편집, 코드 채우기, 아미노산 서열, 수학 그래프 같은 비선형 영역에서 이점이 있음 - **자체 수정**은 모델이 전체 텍스트 블록을 한 번에 평가하면서 실시간으로 실수를 고치도록 반복적으로 출력을 다듬는 방식임 - 실험적 상태와 프로덕션 권고는 명확하며, 속도와 병렬 레이아웃 생성을 우선하기 때문에 전체 출력 품질은 표준 Gemma 4보다 낮음 - ## 미세조정 예시 - 특정 작업 성능은 **미세조정**으로 개선할 수 있음 - [Unsloth](https://unsloth.ai/docs/models/diffusiongemma)는 DiffusionGemma가 스도쿠를 풀도록 미세조정했으며, 스도쿠는 각 토큰이 미래 토큰에 의존하기 때문에 자기회귀 모델이 어려워하는 작업임 - DiffusionGemma의 양방향 어텐션은 스도쿠 같은 작업을 훨씬 쉽게 만듦 ### 텍스트에 확산을 쓰는 이유 - AI 연구 커뮤니티는 수년간 **확산 기반 텍스트 생성**을 탐색해 왔지만, 이를 대형 모델에 적용하는 일은 도전 과제로 남아 있었음 - DiffusionGemma는 모델이 하드웨어를 사용하는 방식을 바꿔 이 문제를 다룸 - ## 기존 모델과의 트레이드오프 - 대부분의 언어 모델은 타자기처럼 왼쪽에서 오른쪽으로 한 번에 하나의 토큰을 생성함 - 클라우드에서는 서버가 수천 개 사용자 요청을 함께 배치 처리해 하드웨어 부하를 공유할 수 있으므로 이 방식이 효율적임 - 단일 사용자가 로컬에서 실행할 때는 단어 단위 생성이 전용 GPU나 TPU를 충분히 활용하지 못하게 하며, 하드웨어가 다음 “키 입력”을 기다리는 시간이 많아짐 - DiffusionGemma는 256토큰 문단 전체를 동시에 초안 작성해 컴퓨터 프로세서에 더 큰 작업 덩어리를 한 번에 제공함 - 이 구조는 모델 추론을 순차적 타자기에서 전체 텍스트 블록을 동시에 찍는 대형 인쇄기처럼 바꾸는 방식임 - ## 로컬·저동시성 추론에 맞춘 속도 향상 - DiffusionGemma의 속도 향상은 **로컬 추론**과 낮은 동시성 추론을 위해 설계됨 - 높은 QPS 클라우드 서빙에서는 자기회귀 모델도 연산을 효율적으로 포화하도록 배포할 수 있음 - 높은 QPS 환경에서는 DiffusionGemma의 병렬 디코딩 이점이 줄어들며, 서빙 비용이 더 높아질 수 있음 - 처리량 이점은 단일 가속기에서 낮은 배치 크기부터 중간 배치 크기까지 가장 강함 ### 텍스트 확산의 작동 방식 - **텍스트 확산**은 시각적 노이즈에서 시작해 선명한 그림으로 반복 개선하는 AI 이미지 생성 방식과 유사한 절차를 텍스트에 적용함 - 첫 단계인 캔버스에서는 모델이 무작위 플레이스홀더 토큰으로 구성된 캔버스에서 시작함 - 반복 개선 단계에서는 모델이 여러 차례 패스를 수행하고, 올바른 토큰을 고정한 뒤 이를 맥락 단서로 사용해 나머지를 다듬음 - 최종 다듬기 단계에서는 텍스트가 고품질 출력으로 수렴함 - 모델이 생성 중 문단 전체를 처리할 수 있기 때문에 복잡한 Markdown 서식을 정확히 닫거나 코드를 거의 실시간으로 생성하고 렌더링하는 동작 패턴이 가능해짐 ### 시작 방법 - 실험용 모델 가중치는 허용적인 Apache 2.0 라이선스로 제공되며 Hugging Face에서 접근할 수 있음 - [DiffusionGemma developer guide](https://developers.googleblog.com/en/diffusiongemma-the-developer-guide)에서 통합 방법을 확인할 수 있으며, [A Visual Guide to DiffusionGemma](https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-diffusiongemma)에서 내부 메커니즘을 더 깊게 볼 수 있음 - 모델 서빙은 [MLX](https://huggingface.co/collections/mlx-community/diffusiongemma), [vLLM](https://vllm-project.github.io/2026/06/10/diffusion-gemma), [Hugging Face Transformers](https://huggingface.co/google/diffusiongemma-26B-A4B-it)를 사용해 수행할 수 있음 - vLLM 통합은 [Red Hat](https://huggingface.co/collections/RedHatAI/diffusiongemma-26b-a4b-it)의 지원을 받음 - 빠른 실험을 위해 조합성을 위해 설계된 모듈형 JAX 도구상자인 [Hackable Diffusion](https://github.com/google/hackable_diffusion) 기반 미세조정 튜토리얼이 제공됨 - 미세조정은 [Unsloth](https://unsloth.ai/docs/models/diffusiongemma)와 NVIDIA [NeMo](https://github.com/NVIDIA-NeMo/Automodel/blob/main/docs/guides/dllm/diffusiongemma.md)로도 탐색할 수 있음 - 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](https://console.cloud.google.com/agent-platform/publishers/google/model-garden/diffusiongemma), [NVIDIA NIM](https://catalog.ngc.nvidia.com/orgs/nim/teams/google/containers/diffusiongemma-26b-a4b-it?version=latest) 중에서 선택할 수 있음 ## Comments ### Comment 59402 - Author: neo - Created: 2026-06-11T10:49:28+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48478471) - 최근 **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]` 토큰을 확산시키는지 궁금함 - 나머지 댓글을 읽고 답 하나는 얻었음. 확산 과정 자체가 본질적으로 **추론 비슷한 과정**이라는 게 말이 됨: [https://www.inceptionlabs.ai/blog/introducing-mercury-2]() - 멋지긴 하지만 로컬 모델은 이미 괜찮아도 가장 싼 API보다도 체감상 확실히 떨어져서, 속도를 위해 품질을 조금이라도 희생할 생각은 잘 안 듦 어떤 사용 사례에는 분명 가치가 있겠지만, 실제로 프로덕션에 배포하려는 구체적인 사례가 궁금함 - **단위 테스트** 작성이나 부트스트랩에는 괜찮을 수 있음 Opus급이 아니어도 작성 가능하고, 반복하기도 쉬움