DiffusionGemma: 4배 빠른 텍스트 생성

최근 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 캐시를 담을 메모리 용량이 충분하면 배치 처리가 적용될 수 있음. 확산 모델이 더 많은 연산으로 낮은 품질을 내고 메모리 대역폭 절감도 애매하다면 어떻게 도움이 되는지 잘 모르겠음

대체로 맞지만, 어텐션과 자기회귀·인과 구조를 섞어 말하고 있음. 더 많은 연산을 쓰지 못하게 막는 진짜 문제는 자기회귀·인과 구조임
확산에서도 어텐션을 쓸 수 있고, 이 모델도 실제로 어텐션을 사용함

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

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