Gemini Diffusion

• 구글이 발표한 Gemini Diffusion은 트랜스포머 대신 확산(Diffusion) 방식을 사용하는 첫 LLM임
  • Imagen 이나 Stable Diffusion 같은 이미지 모델에서 사용하는 것과 비슷
• 이 모델은 기존 자동회귀 방식이 아닌, 노이즈를 단계적으로 정제하는 확산 과정을 통해 텍스트를 생성함
• 결과적으로 응답 속도가 매우 빠르며 실험에서는 초당 857 토큰 수준의 성능을 보임
• 정확한 벤치마크는 아직 부족하지만, 구글은 Gemini 2.0 Flash-Lite 대비 5배 빠른 속도를 보인다고 주장

---

Gemini Diffusion 개요

• Gemini Diffusion은 구글이 새롭게 공개한 대규모 언어 모델(LLM)임
• 기존 트랜스포머 기반 LLM의 자동회귀(autoregressive) 방식 대신, 확산(diffusion) 접근법을 채택함
• 이 확산 방식은 이미지 생성 모델(Imagen, Stable Diffusion 등)처럼 작동하는 대신, 텍스트 생성에 적용되어 있음
• 주요 특징으로는 빠른 응답속도 및 생성 과정에서의 효율적 오류 수정 능력임
• 사용 예시에서 "Build a simulated chat app" 프롬프트에 수 초 내로 HTML+JavaScript 결과물을 제공하며, 초당 최대 857 토큰 생성 속도를 기록함

확산 언어 모델 작동 방식

• 기존 자동회귀 언어 모델은 토큰을 하나씩 순차적으로 생성하므로 속도가 느리고 출력의 일관성에도 한계가 있음
• 반면 확산 모델은 노이즈에서 출발하여 점진적으로 결과를 개선하며 전체 문장 또는 문단을 여러 단계에 걸쳐 한 번에 처리함
• 이로 인해 병렬적 토큰 생성이 가능해져 매우 빠른 결과 생성이 실현됨
• 텍스트 편집, 수학, 코드 등 즉각적 피드백이 중요한 영역에 효과를 발휘함

유사 모델 및 성능 비교

• 기존에는 상용 확산 LLM이 거의 없었으며, 2024년 2월에 Inception Mercury 프로젝트가 첫 사례로 등장함
• 속도와 성능면에서 Gemini Diffusion은 구글 기준 Gemini 2.0 Flash-Lite와 유사하나, 속도가 약 5배 빠름
• Cerebras Coder와 유사하게 높은 생성 속도를 보여주며, 향후 객관적 벤치마크 데이터가 추가될 예정임

추가 설명 및 정정

• 확산 언어 모델은 트랜스포머 아키텍처를 완전히 대체하는 것이 아닌, 자동회귀 대신 확산 방식으로 텍스트 생성 구조를 변경함
• Mercury와 Gemini Diffusion 모두 트랜스포머 기반이지만, 인풋 전체를 한 번에 처리하고 생성 방식이 다름
• 기존 BERT 스타일 마스킹·복원 방식에서 발전된 형태로, 마스킹 비율을 점점 높여가며, 모든 토큰이 마스킹된 상황에서도 점진적으로 결과를 완성해나감
• 확산 방식은 여러 단계에 걸쳐 일부 토큰만 확정(final)하며, 반복적으로 확정 토큰 비율을 늘려 전체 시퀀스를 완성하는 구조임
• 이러한 확산 LLM의 핵심 아이디어는 점진적 복원과 병렬 생성임

결론

• Gemini Diffusion은 속도와 생성 품질 측면에서 혁신적 특성을 제시하는 신형 LLM임
• 이미지 생성에서 입증된 확산 모델의 장점을 텍스트 생성 영역으로 성공적으로 확장함
• 다양한 실무 적용을 통한 활용 가치와 향후 벤치마크 결과에 대한 기대가 높아짐

[GN⁺]

Hacker News 의견

• 구글 내부에서 실제로 어떻게 동작하는지 잘 모르겠지만, 최근 RWKV 쪽에서 주목할 만한 일이 있었음. 기존의 어텐션 메커니즘을 WKV(선형 어텐션)로 통째로 바꾸는 실험을 했고, 이 모든 과정을 포스트 트레이닝만으로 만들어 냄. 이게 시사하는 점은, 유용한 지식 대부분이 사실 FFN(피드포워드 네트워크)에 들어 있고, 어텐션 자체는 생각보다 그렇게 유니크하거나 중요한 요소가 아닐 수도 있다는 의미임. 관련 링크도 참고하면 재밌을 것. 한편, 이미 학습된 어텐션을 활용하고 GPT-2 속도 트레이닝에서 FFN만 따로 얼마나 빠른지 실험해보는 것도 규칙엔 어긋나지만 흥미로운 시도라 논문으로 읽어보고 싶은 생각임. 어제 읽은 것 중, 특정 시점에선 모든 모델의 임베딩이 (매우) 유사해져서, 간단한 변환기를 학습할 수 있고, 이 두 가지 모두 사실이라면 임베딩과 어텐션을 공유하며 전체 훈련을 훨씬 빠르게 만들 수 있을 거라는 얘기가 있었음

  • 어텐션이란, 연구자분들께 최대의 존경을 표하면서 말하자면, 네트워크의 모든 과거 정보를 입력받아서 리버스-MoE 신경망에 넣는 거라고 생각함. 여기서 전문가가 네트워크의 일부가 아니라 입력의 일부를 실행 대상으로 고르는 셈임. 이 방식은 모두 효과가 있을 거란 걸 알았지만, 너무 비효율적이라 R이나 Python 유저조차 실행해볼 생각을 못 했음. 트레이닝 자체가 느려서 실용적으로 시도조차 어려웠던 구조였음

  • 어텐션이 꼭 필요하다는 'Attention is all you need'가 사실 다른 의미로 해석될 수도 있다는 생각이 듦

  • 모델 임베딩이 서로 (매우) 유사해져서 간단한 변환기로 매핑이 가능하다는 이야기는 여기에서 나온 것임

  • 어텐션이란, 네트워크를 나누어서 병렬 학습을 가능하게 하는 완전히 임의적인 방식이라고 봄. 진짜로 성공에 기여한 부분은 레이어 간 '지름길 연결(shortcut connection)'임. 이게 학습할 때 초기 레이어에 더 많은 영향력을 부여함

  • 요즘 트랜스포머에서 쓰는 SDPA 어텐션의 상대적인 중요성 부족함은 이미 알려져 있음. FFN, 정규화, 레지듀얼 연결은 절대적으로 대체 불가능하지만, 어텐션은 토큰들 사이 정보를 나누는 다른 어떤 레이어(풀링, 컨볼루션, 랜덤 믹싱 등)로도 쉽게 대체 가능함

• 정말 엄청나게 빠른 속도임. 지금까지 모델의 최고 활용 사례는 완전히 새로운 코드 작성과 빠른 프로토타이핑이라고 생각함. 이미 여러 번 반복적으로 개선된 대규모 코드베이스 개선에는 그리 강점을 보지 못했다고 느낌. 그 이유 중 하나는, 정의상 모델은 코드베이스에 '포함되지 않은 것'에 대해 알 수 없기 때문임. 무언가 코드에 '없다'는 사실에도 의미심장한 신호가 있는데, 이걸 표현하는 게 꽤 어려운 문제임. 아무리 똑똑한 모델이라도 그 지점에서 '내부적 맥락과 경험'이 부족해서 근본적인 한계가 남는다고 생각함. 예를 들어, 엄청난 실력의 개발자에게 대형 코드베이스를 주고 특정 문제를 바로 해결하라고 해도, 코드베이스를 잘 아는 평범한 개발자가 같은 시간에 더 가치 있는 결과를 낼 수 있음

  • 의사소통 방식에 초점을 두면 이 문제를 해결할 수 있음. 요즘 내 주요 워크플로는, 대규모 작업(새로운 기능, 리팩토링 등)이 필요하면 동료처럼 o3와 대화를 시작함. 필요한 소스 파일들을 맥락 제공을 위해 계속 붙여넣으면서, 목표와 현재 코드 상황에 대해 고차원적 토론을 진행함. 이 과정에서 내가 하고자 하는 바와 코드베이스 맥락이 명확해진다고 느낌. 이후에 o3에게 구현 계획을 요청하고, 그걸 Codex에 넘겨 소스 읽기, 파일 수정, 테스트 등 일련의 자동화 과정을 실행함. PR이 나오면 약간의 수동 편집이나 바로 머지가 가능할 때도 있음. 모델이 풍부한 맥락을 필요로 한다는 점엔 동의하지만, 이건 본질적 한계가 아니라 효과적으로 협업하는 방식의 문제임. 숙련도만 갖추면 생산성은 물론, 나에게는 머릿속이 더 즐거워지는 작업 방식임

  • "코드베이스에 존재하지 않는 것이 의미 있는 신호를 가진다"는 관점에 깊은 공감을 느낌. 오래 소프트웨어를 했는데, 이 근본적인 진실을 이토록 명확하게 의식한 적 없었음. 고마운 통찰임

  • 지금까지 내 경험상 LLM은 기존 좋은 코드를 모방하는 데에는 능숙하지만, 새롭고 독창적인 부분을 특별히 명시적으로 요청하지 않는 이상 스스로는 잘 만들어내지 못함. 코드베이스를 충분히 ingest하지 못해 프로젝트 내 다른 부분을 직접 지정해줘야 할 때가 많음. 그래도 Stable Diffusion에서처럼 "네거티브 프롬프트"를 줄 수 있다면 정말 멋질 것 같음

  • LLM이 전체 git 히스토리, 이슈 트래커, 미팅 레코딩까지 모두 컨텍스트로 읽을 수 있다면 어떤 결과가 나올지 궁금함. 아주 큰 컨텍스트 입력이 실용적으로 쓸 수 있는 결과로 이어질지는 좀 더 지켜봐야 함

• 이번 발표에 정말 놀람. IO 행사에서 가장 큰 발표라고 생각하지만, Veo 3 등 다른 소식에 밀려 아쉬움. 코드 생성에 diffusion 모델을 쓴다는 건 굉장히 큰 의미가 있음. 만약 트랜스포머를 쓰면 DiT(디퓨전 트랜스포머) 계열에 해당할 텐데, 몇 년 전 U-Net 기반 디퓨전을 조합한 하이브리드 모델에 참여한 경험이 있는데 그 뒤로도 많은 발전이 있었음. 앞으로 diffusion 분야에서 큰 도약이 있을 것 같음

  • 비전 트랜스포머에서의 직관을 코드에 적용할 때 어떻게 동작할지 궁금함. 비전 분야에서는 노이즈에서 출발해 계층별로 점점 선명하게 target 이미지를 만들어냄. 이 원리를 코드 생성에 적용하면, 예를 들어 'Django를 사용해야 한다', '엔드포인트 목록 정하기', '구체적 코드 생성' 등 점차 추상도를 내려가는 계층적 구조가 필요해 보임. 그런데 diffusion은 백트래킹 메커니즘이 없어 하위 레벨 문제가 탐지돼도 상위 레이어에 즉시 피드백을 주기가 제한적임. 반면 트랜스포머는 토큰마다 전체 모델을 돌리기 때문에 문제마다 필요한 백트래킹과 설계 변경이 용이함. 내 모델에 결함이 있을 수 있으니 추가 통찰을 듣고 싶음

  • Veo 3는 성능과 차별점이 아주 직관적으로 보이기 때문에 화제가 된 반면, 텍스트 완성 분야에서의 중요한 진보 가치를 이해하려면 기존 성과와 잠재적 활용을 알아야 함. 아직 많은 이들은 LLM이 코딩에 유용하다는 사실 자체에 확신이 없는 상황임

  • Diffusion 기반 코드 생성 모델은 정말 혁신임. 이런 모델이 할 수 있는 간단한 아이디어로는 다음과 같음. 함수 시그니처와 결과를 고정하며 그 사이 토큰을 생성하는 방식(쌍방향 정보 활용). 두 번째로, 먼저 함수 레이아웃의 큰 윤곽을 작성하고(LLM에 기사 '챕터'를 작성하는 것처럼), 그 다음 구현으로 점점 세부 작업을 나누는 식. 더 큰 컨텍스트 속에서 linters, AST 정보 등 각종 신호로 방향성을 잡으며 반복 생성. 실험해볼 게 정말 많음

  • 원칙적으로는 이 방식이 큰 장점이 있을 것 같지만 실제 경험해본 LLaDA 같은 모델은 학습 자원이 적음에도 인상적이었음. 하지만 perplexity 등 기준에서는 아직 뒤처짐. 생성 중간에 고정되는 경향이 강해 텍스트를 깊이 수정하는 데 한계가 있을 것 같음(마스킹 확률이 높아질수록 동시 수정이 어려움). 그렇지만 실제 실험에서 꽤 실용적인 결과를 얻었음

  • InceptionLabs 등에서 이미 데모를 본 적이 있기 때문에 그렇게 놀랄 만하지는 않음

• 이 소식의 핵심이 묻혀 있는 듯함. 정말 빠르고 우수한 InstructGPT임. 앞으로 맞춤법 검사, codemod, 코드 에디터 등에 반드시 쓰일 것임. Instant edits 기능 덕분에 불필요한 추가와 제안 없이 정말 빠르고 정밀한 텍스트 편집이 가능함. ShaderToy 샘플 코드를 변수명을 더 알기 쉽게 바꿔달라고 요청해서 결과를 복사해 실행했는데 여전히 잘 돌아가서 놀랐음

  • 맞춤법 검사라면 이미 완벽하게 해결된 문제 아닌가

• 디퓨전의 장점은 단순히 속도뿐만이 아님. 초기 벤치마크에 따르면 AR에 비해 같은 파라미터로도 추론과 계획 면에서 더 뛰어남. 디퓨전은 중간 편집이 가능하고, 초기 토큰 바이어스 문제를 겪지 않음

  • 흥미로운 주장임. 관련 벤치마크나 근거 자료 링크를 공유해 줄 수 있는지 궁금함

  • AR 자체가 긴 플랜 수립을 방해하지는 않지만, 최신 인기 AR 모델들의 구현 방식 상 그런 한계가 있는 경우가 종종 있음. AR은 기본적으로 올바른 분포를 학습하는 데 매우 중요함

  • 개인적으로 동의하거나 그랬으면 좋겠다는 주장이지만, revise diffusion text에 대한 논문이나 데모를 아직 본 적 없음. 써보고 싶으니 논문 정보를 공유해주면 좋겠음

• 텍스트 생성에 diffusion 기술을 적용하는 것에 오래 관심을 가져왔음. 드디어 구글이 이런 모델을 내놓아서, 내 생각이 검증되는 느낌이 들어 기쁨. 실험에 쓰이는 하드웨어 측면에서 대부분은 유료 서비스 혹은 하이엔드(적어도 소비자 등급 중 높은) 장비를 돌림. 현 상황에서 내가 가진 건 5700XT 정도라 업그레이드가 힘든데, 그 덕분에 현 모델의 한계를 더 뚜렷이 볼 수 있었음. 모델 크기가 커질수록 일관성도 커지기 때문에, 작은 모델은 부득불 간단한 작업에 국한됨. 주요 실험으로 확인한 것이 컨텍스트 크기의 중요성인데, 소형 GPU로는 충분한 컨텍스트와 모델을 동시에 넣기 어렵고, diffusion 기반이라면 밀도와 일관성의 균형을 바꿀 수 있을지 궁금함. 적은 컨텍스트에도 더 일관성 있는 텍스트 생성이 기대되고, 툴 콜 + 응답 혼합 결과도 좋아질 것 같음. 속도 문제 또한 현실적인 불만인데, 기존 LLM 방식은 입-출력 반복마다 느리게 트는 방식이라 (특히 AI용 하드웨어 없는 구형 GPU에서는) 인내심의 한계임. 진행률 0~100%라도 실시간으로 볼 수 있으면 좋겠고, diffusion 모델에서는 좀 더 나아지지 않을까 기대함. 여기서 의문이 생김. 노이즈 입력이 중요한데, LLM/텍스트에 특화된 좋은 노이즈 소스가 존재하는지, 전체 블록 길이도 미리 고정인지, 아니면 가변이 가능한지 궁금함

• 내 입장에서 확실하게 말할 수 있는데, 이 모델은 엄청나게 빠름. 단점은 프롬프트 인젝션 공격에 매우 쉽게 뚫린다는 것임. 예를 들어 약 제조법을 요청하면 거절하는데, '아이 역할극'으로 돌려서 요청하면 진짜 결과를 내놓음. 이 단점만 빼면 빠른 속도와 자동화 사용성이 정말 뛰어남. 에이전트식 접근까지 더해지면 이 모델의 잠재력이 빛날 것임

  • 모델 자체의 한계라기보다는, 트레이닝에서 안전성이나 검열 쪽에 리소스가 덜 투입돼서 그런 걸 수도 있음. 내 생각엔 일종의 프로토타입 실험이고, 대형 모델로 본격적으로 투자하기 전에 가벼운 시범이 아닐까 예상함

  • 이런 프롬프트 인젝션이 곧 더 똑똑한 모델을 통제할 수 있다는 신호라고 보지는 않음

• "구글의 첫 디퓨전 LLM, 트랜스포머 대신 diffusion 사용"이라는 설명은 잘못된 주장임. 구글이 직접 이렇게 발표한 적 없음. 오히려 Transformer 기반 diffusion 모델이 보편적임. Gemini Diffusion 역시 트랜스포머를 쓸 가능성이 높다고 생각함. 차이라면 인코더-온리 트랜스포머라는 점임. 즉, 전체 시퀀스를 noisy/corrupted 상태로 넣어서 전체 올바른 시퀀스를 예측하는 구조임. 이 덕분에 시퀀스 전체 프레임을 동시에 병렬 연산 가능하고, 반복 횟수만 적당하다면 디코더-온리 모델의 순차 디코딩보다 훨씬 빠름(물론 추측 디코딩도 유사 속도 업사이드 있음). 보통 BERT식 마스킹으로 학습하지만, 여전히 연구가 활발한 분야임. Gemini와의 관계나 체크포인트 활용 여부(직접 임포트인지, 디퓨전 특화 파인튜닝인지, 지식 증류인지, 아니면 단순 브랜드명인지)도 궁금함. 공식 세부 사항이 공개되어 있었으면 좋겠음

• 말도 안 되게 빠름. GPU는 항상 최대 성능으로 돌아가고, 배치 처리에서의 컴퓨팅 절감효과가 거의 없을 거라 예측함. 하지만 그건 생각해보니 진짜 tradeoff라고 부르기엔 애매함. 한 가지 걱정은 diffusion objective가 AR보다 성능 면에서 떨어질 수 있다는 점임. 만약 그렇다면, multi-token AR 모델이 diffusion과 같은 속도를 내거나, diffusion 모델을 스펙큘레이티브 디코딩의 초안 발생기로 활용하는 식이 대안이 될 수 있음

  • dLLM이 arLLM보다 품질이 뒤떨어질 거라고 생각하는 이유가 궁금함. 출력물을 '구조화된 전체(주제, 요점, 개념, 단어 트리)'로 반복 처리하기에 품질 면에서 오히려 더 나을 수 있다는 의견임

  • 이 구조적 tradeoff는 개인 호스팅 환경에서 훨씬 유리함. 대규모 배치가 필요 없는 환경이라서, 클라우드에선 이점이 적지만, 로컬 LLM엔 큰 장점임

• 디퓨전 LLM에 굉장히 흥분되는 상태임. 우리 팀이 목소리 → 코드로 이뤄지는 게임 메커니즘을 꿈꾸는데, diffusion이 바로 그 완성형 요소가 될 수 있을 것 같음. Cerebras, Groq는 대단하지만 커스텀 하드웨어 때문에 파인튜닝/스케일에 한계가 존재함. 나머지 대안은 액티브 파라미터 0.5b 수준의 MoE이지만, 당장은 그 프로젝트에 리소스를 쏟을 여유가 없음. 구글/Deepmind 관계자가 보신다면 꼭 API 제공을 부탁드림. 우리 팀은 생성형 샌드박스 게임을 개발 중이고, 첫 작품은 실시간으로 몬스터에게 명령을 내리는 구조임. 프로토타입 영상도 있으니 참고하면 좋겠음