DiffusionGemma: 256개 토큰 병렬 생성으로 초당 1,500개 출력
DiffusionGemma Technical Report
Google의 DiffusionGemma 팀이 공개한 실험적 오픈웨이트 언어 모델이 기존 자회귀(AR) 모델의 순차 디코딩 병목을 피해 256개 토큰 블록을 병렬로 정제하며, 단일 NVIDIA H100 GPU에서 초당 약 1,500개 토큰을 생성한다. 이 모델은 Gemma 4 MoE(활성 3.8B, 전체 25.2B 파라미터)를 파인튜닝하여 얻었으며, 학습 토큰 예산의 10% 미만을 사용한다. 추론 속도와 성능 간 새로운 파레토 최적점을 제시하며, thinking mode, 멀티모달 입력, 긴 문맥 지원을 유지한다.
DiffusionGemma는 생성 속도와 모델 성능 간의 트레이드오프에서 새로운 파레토 최적점을 제시한다.
HN 토론
40- kamranjon
이걸 공유하고 싶었는데, Diffusion Gemma가 어떻게 작동하는지 이해하는 데 정말 좋은 자료였어요: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...
정말 흥미로웠던 점은 이 모델을 처음부터 훈련할 필요 없이 기존의 MOE 체크포인트를 그대로 사용했다는 거였어요:
"디코더 전용 모델(Gemma 4 26B A4B)을 노이즈 제거기로 변환하려면, 토큰 생성 시 직접 사용하지 않는 것, 즉 모든 토큰의 로짓을 활용할 수 있습니다!"
이번 릴리스에 대해 기대되는 점은 아마도 이 동일한 변환을 다른 오픈 모델에도 적용할 수 있고, 기존 로컬 모델들의 diffusion 버전이 여러 개 나올 수도 있다는 거예요. 정말 흥미진진하네요!
- mmastrac
지난 몇 달 동안 macOS용으로 이 모델을 다시 구현했어요: https://github.com/mmastrac/diffgemma
이 모델을 아주 좋아하고, 추론 능력도 꽤 괜찮아요. 필요에 따라 유연하게 활용할 수도 있고요. 메모리 대역폭보다 연산 능력이 더 많은 머신을 위해 설계되었지만, 제 생각에는 Metal에서 정말 잘 작동해요.
M3급 머신에서 초당 약 15토큰까지 올렸는데, M5에서는 제가 접근할 수 없는 성능이 더 있을 거라고 생각해요.
다른 Gemma MTP 헤드를 사용해 MTP를 구현하려고 시도했지만 성능 향상을 이루지 못했어요. 드래프트 모델로 diffusion 캔버스를 미리 시딩하는 것에 대한 흥미로운 연구가 있을 거예요. DiffusionGemma는 적절한 드래프터와 함께라면 제 머신에서 초당 20-30토큰을 달성할 수 있지만, 지금까지 실행 속도보다 더 빠르게 만들기 위해 둘을 결합하지는 못했어요.
- mike_hearn
이런 모델들이 코딩에 능숙해지면 언어, 컴파일러, 테스트 스위트 러너가 작동하는 방식에 대한 재고가 강제될 거예요. "AI가 모든 것을 바꾼다"는 이쯤 되면 진부한 말이지만, 실제로 사실이라고 생각해요.
모델이 초당 1500토큰으로 추론하고 코드를 작성할 수 있다면, 프롬프트가 활성화된 동안 완전히 CPU 시간에 병목이 생겨야 해요. 그렇지 않다면 경쟁사에 비해 벽시계 시간을 잃고 있는 거예요. 하지만 우리의 전체 개발 스택은 프로그래머가 CPU를 기다리는 게 아니라(아픈 예외로 CI 클러스터가 녹아내리는 경우를 제외하고) 대부분의 시간을 생각하고, 말하고, 코딩하는 데 보낸다는 아이디어를 기반으로 해요.
제가 상상하는 것은 코드 컴파일과 인터프리터 실행을 겹칠 수 있는 일종의 하이브리드 모드로, LLM이 변경 사항을 제안하고 즉시 단위 테스트를 실행하면서 다른 모듈에 영향을 줄 수 있는 타입 오류를 병렬로 찾는 거예요. 그리고 테스트는 항상 샤딩되어 실행되며, 로컬 개발에서도 잠재적으로 원격 클러스터에서 실행될 거예요.
분명히 이 접근 방식은 어느 정도 JVM을 유명하게 만든 방식이에요. Java는 javac가 타입 검사 외에는 거의 하지 않기 때문에 매우 빠르게 컴파일되고, 타입 시스템도 단순해요. 그런 다음 JVM이 컴파일의 무거운 작업을 실행과 병렬로 수행해요. 그래서 Java가 시작 시간이 느리다는 평판이 있지만, JVM의 턴어라운드 시간은 C++, Swift 또는 Rust 같은 것에 비해 정말 훌륭할 수 있어요. 그리고 시작 시간 문제의 상당 부분은 오래된 Spring 같은 형편없는 프레임워크 때문이에요. [...]
- RandyOrion
메모리 제약이 있는 자기회귀 디코딩과 대조적으로, diffusion 디코딩은 연산 제약이 있을 수 있어요. 상당한 연산 능력이 있지만 메모리가 매우 작은 장치, 예를 들어 NVIDIA 소비자용 GPU는 diffusion 디코딩의 혜택을 크게 볼 수 있어요.
성능 측면에서 diffusion 디코딩이 자기회귀 디코딩보다 훨씬 나쁘지 않아야 한다고 생각해요. https://arxiv.org/html/2604.11035 를 참조하세요.
로컬 LLM 사용자로서, 괜찮은 성능을 가진 더 많은 소형 diffusion LLM/VLM이 나오는 것을 정말 보고 싶어요.
- anentropic
매력적인 결과네요... AR 모델 대비 정확도 격차를 줄일 여지가 있다고 생각하나요? 아니면 "양방향 추론 및 자기 수정"을 활용해 전반적인 우위를 점할 수도 있을까요?