한 번에 1개의 토큰(token)을 예측하는 것. 이것이 로컬 모델을 포함하여 초기부터 모델들을 제한해 온 요소였습니다.

이 제약은 하드웨어가 불충분하거나 모델이 너무 작아서 생긴 문제가 아니었습니다. 그것은 설계 단계부터 내재된 구조적(architectural) 문제였습니다.

각 토큰을 생성하기 위해, GPU는 메모리에서 모든 모델 가중치(weights)를 로드하여 1개의 토큰을 생성한 다음, 다시 처음부터 시작합니다. 이러한 메모리 대역폭(memory bandwidth) 병목 현상 때문에 괜찮은 하드웨어에서도 로컬 추론(local inference)은 답답한 상태로 남아 있었습니다. 그리고 지난 5년간의 최적화(flash attention, 양자화 (quantization), 추측적 디코딩 (speculative decoding))가 모두 이 구조적 한계를 움직이지 못한 채 동일한 천장만을 우회해 왔던 이유이기도 합니다.

요약 (TLDR): DiffusionGemma는 디노이징(denoising) 패스당 256개의 토큰을 병렬로 생성하며, 병목 지점을 메모리 대역폭에서 순수 연산 능력(raw compute)으로 전환합니다. 이론적으로는 Gemma 4 AR보다 4배 빠르며, RTX 5090에서 초당 700개 이상의 토큰을 생성하고 RTX 4090에서도 실행 가능합니다. 하지만 속도 수치 자체가 이 기술을 흥미롭게 만드는 것은 아닙니다.

잘못된 계층(layer)에서 올바른 지표를 최적화하고 있었다는 사실을 깨달았을 때 일어나는 어떤 현상이 있습니다. Flash attention은 진정한 돌파구였고, INT4 양자화(quantization)도 진정한 돌파구였으며, 카드당 40,000달러인 H100은 그것을 감당할 수 있는 누구에게나 진정한 돌파구였습니다. 하지만 그 중 어느 것도 근본적인 제약을 움직이지 못했습니다. 가중치(weights)는 여전히 매 토큰마다 로드되어야 했습니다. 대규모 병렬 행렬 연산을 위해 설계된 GPU의 텐서 코어(tensor cores)는 추론(inference) 중에 다음 메모리 사이클을 기다리며 대부분 유휴 상태로 머물러 있었습니다. 고사양 소비자용 GPU에서 로컬 추론을 실행해 본 모든 엔지니어는 이를 일종의 낮은 수준의 좌절감으로 느꼈습니다. 수치상으로는 작동해야 하는데, 완전히 작동하지는 않는 것이죠.

아무도 의문을 제기하지 않았던 경주

Flash attention은 2022년에 등장했습니다. 진정으로 뛰어난 기술이었습니다. 어텐션(attention) 계산을 I/O 인식형(I/O-aware)으로 재작성하여, 중간 값들을 HBM에 계속 다시 쓰는 대신 SRAM에 유지하도록 했습니다. 실질적인 속도 향상이 있었고, 측정 가능했으며, 18개월 이내에 어디에서나 배포되었습니다. 해당 논문은 약 2년 만에 15,000회의 인용을 기록했습니다.

그 후 업계는 동일한 기반 위에 계속해서 계층을 쌓아 올렸습니다. INT4 양자화 (Quantization), GGUF, 투기적 디코딩 (Speculative decoding), AR 추론 (AR inference)을 중심으로 처음부터 구축된 Groq의 LPU, 카드당 40,000달러에 달하는 H100, 그 다음은 H200, 그리고 GB200까지 이어졌습니다. AR을 더 빠르게 만드는 것이 해결할 가치가 있는 문제라는 전제하에 수십억 달러의 가치를 인정받는 기업들이 속출했습니다. Groq은 AR 추론을 중심으로 맞춤형 실리콘을 처음부터 설계했고, 업계는 이를 선견지명이라고 불렀습니다. 그 자리에 있던 누구도 어쩌면 아키텍처(Architecture) 자체가 문제일 수도 있다는 의문을 제기하지 않았습니다.

업계 전체가 단 하나의 병목 현상(Bottleneck)을 중심으로 조직되었습니다. 그 병목 현상이 아키텍처적인 것인지에 대해서는 아무도 의문을 갖지 않았습니다.

공정하게 말하자면, 그들이 왜 의문을 갖겠습니까? 모델은 출시되었고, 제품은 작동했습니다. 트레이닝 스택 (Training stack), 추론 서빙 인프라 (Inference serving infrastructure), CUDA 커널 생태계, vLLM부터 TGI, Ollama에 이르는 모든 배포 패턴이 모두 자기회귀 (Autoregressive) 방식의 다음 토큰 예측 (Next-token prediction)을 중심으로 구축되었습니다. 해당 생태계 내부에서 아키텍처에 의문을 제기하는 것은, 더 빠른 타이어를 설계하는 도중에 자동차에 바퀴가 있어야 하는지를 의심하는 것과 같습니다. 전환 비용 (Switching cost)은 단순히 기술적인 문제만이 아니었습니다. 그것은 업계의 누적된 매몰 비용 (Sunk cost)이었습니다. 모든 CUDA 커널, 모든 서빙 최적화, 모든 하드웨어 구매가 AR 처리량 (Throughput) 수치를 기준으로 정당화되었습니다.

Inception Labs는 실제로 다른 무언가를 처음으로 출시했습니다. Mercury는 2025년 초에 출시되었고, Mercury 2는 2026년 초에 출시되어 초당 1,000개 이상의 토큰을 생성했습니다. 진정으로 인상적인 수치였습니다. 하지만 완전히 접근 불가능했습니다. 상용 API 형태였고, 가중치 (Weights)가 폐쇄되어 있어 직접 실행할 수 없었습니다. 시장의 신호로서는 유용했지만, 자체 하드웨어에서 구축하려는 누구에게도 실행 가능한 대안은 아니었습니다.

DiffusionGemma는 2026년 6월 10일에 출시되었습니다. Apache 2.0 라이선스 하의 오픈 웨이트 (Open weights) 모델이며, 출시 당일부터 vLLM을 지원하고 RTX 4090에서 구동됩니다.

개발자 커뮤니티에게 "Tier-1 연구소의 첫 번째 오픈 릴리스"라는 말은 출시 당일의 vLLM 지원, HuggingFace 모델 카드, Unsloth 통합, 그리고 며칠 내로 흥미로운 파인튜닝 (fine-tunes) 결과물을 내놓을 커뮤니티를 의미합니다. Gemini Diffusion이 I/O 2025에서 실험적인 모델로 발표되었을 때, 연구 논문과 실제로 구축 가능한 무언가 사이의 간극은 예상보다 약 18개월 더 빠르게 좁혀졌습니다.

이것은 "누군가 이론적으로 작동함을 증명했다"와 "오늘 밤 바로 가중치 (weights)를 내려받을 수 있다" 사이의 차이입니다.

5년간의 우회책. 실제 해결책은 어제 당신의 GPU에서 실행되었습니다.

DiffusionGemma가 실제로 바꾸는 것 (그리고 바꾸지 않는 것)

TITLE "AR vs Diffusion: Where the Bottleneck Lives" + subtitle "Memory-bound vs compute-bound inference on the same GPU". Metaphor: two factory assembly lines side by side: left line labeled AUTOREGRESSIVE has a giant VRAM warehouse door that opens and closes for every single item on the belt, workers labeled TENSOR CORES sit idle waiting; right line labeled DIFFUSION loads once at start then all workers process 256 items simultaneously. Style: engineer blueprint, thick pen technical drawing, cross-section view, grid paper background. Palette: deep navy #1a2744, electric blue #3b82f6, amber #f59e0b, white #ffffff, light gray #e5e7eb. Content: left side station labels LOAD WEIGHTS x256 TIMES, PRODUCE 1 TOKEN, REPEAT 256x; right side labels LOAD WEIGHTS ONCE PER PASS, GENERATE 256 TOKENS IN PARALLEL, REFINE VIA DENOISING. Highlight: amber oversized bottleneck arrow on left labeled THE REAL CEILING in bold annotation box; right tensor cores block highlighted electric blue labeled NOW THE CEILING SHIFTS. Footer: copyright rentierdigital.xyz. NOT flat corporate infographic, NOT minimalist startup aesthetic.

AR vs Diffusion GPU 병목 현상 (Bottleneck) 비교

자기회귀 (AR, Autoregressive) 추론 루프는 메모리 대역폭 제한 (memory-bound) 상태입니다. 256개의 토큰을 생성하려면, GPU는 메모리로부터 전체 가중치 행렬 (weight matrix)을 토큰당 1회씩 총 256번 로드해야 합니다. 대규모 병렬 행렬 곱셈을 위해 설계된 텐서 코어 (tensor cores)는 전체 시간 중 약 1% 정도의 시간 동안만 실제 연산을 수행합니다. 나머지 99%는 VRAM으로부터 데이터가 도착하기를 기다리는 시간입니다. 미슐랭 스타 셰프들로 주방 인력을 채우고, 매 코스 사이에 모든 접시를 300미터 떨어진 창고를 거쳐 가져오도록 경로를 설정한 주방을 상상해 보십시오. 그것이 AR 추론을 수행하는 당신의 H100입니다. 이것이 GPU의 이론적 FLOPS 확장이 추론 속도로 선형적으로 이어지지 않았던 이유입니다. 당신은 연산 제한 (compute-bound)이 아니라 메모리 제한 (memory-bound) 상태였으며, 더 많은 텐서 코어를 가진 카드를 사는 것보다 더 높은 메모리 대역폭 (memory bandwidth)을 가진 카드를 사는 것이 더 도움이 되었습니다. Flash Attention 이후의 모든 최적화는 그 99%의 대기 시간을 없애는 것이 아니라 단축하는 데 집중해 왔습니다. 천장은 항상 동일한 천장이었으며, 단지 약간 다른 각도에서 접근했을 뿐입니다.

DiffusionGemma는 디노이징 패스 (denoising pass)당 가중치를 한 번만 로드하며 256개의 토큰을 병렬로 생성합니다. 병목 현상 (bottleneck)의 위치가 바뀝니다. 이제 텐서 코어 (tensor cores)가 실제 천장이 되며, 각 순전파 (forward pass) 시 전체 256-토큰 블록에 대해 양방향 어텐션 (bidirectional attention)을 실행합니다. 이것이 바로 이 칩들이 설계된 목적입니다. 메모리 대역폭 (memory bandwidth)의 벽이 사라지는 것은 아니지만, 더 이상 당신을 제한하는 요소가 되지 않습니다.

Google과 NVIDIA의 수치에 따르면: RTX 5090에서 700+ tokens/sec, H100에서 1,000+ tokens/sec를 기록하며, 동일한 하드웨어 상의 Gemma 4 AR보다 4배 더 빠릅니다. 이 모델은 Mixture of Experts (MoE) 구조의 26B 파라미터 모델로, 추론 (inference) 중에는 3.8B가 활성화되며, 양자화 (quantized) 시 18GB VRAM에서 실행됩니다.

주의 사항은 실재하며, 솔직하게 언급할 가치가 있습니다.

DiffusionGemma는 추론 (reasoning) 벤치마크에서 Gemma 4 AR에 비해 유의미한 차이로 뒤처집니다. AIME 2026: 69.1% vs 88.3%. LiveCodeBench v6: 69.1% vs 77.1%. GPQA Diamond: 73.2% vs 82.3%. 이는 단순한 반올림 오차가 아니라, 어려운 추론 작업에서 15-20포인트의 격차를 보이는 것입니다.

컨텍스트 윈도우 (context window)는 8,192 토큰입니다. 대부분의 현재 AR 모델은 128K 이상으로 작동합니다. 에이전트 (agentic) 기능이나 긴 컨텍스트 (long-context)를 다루는 모든 작업에 있어 이는 실제적인 벽입니다. 적당히 복잡한 TypeScript 파일 하나가 3,000 토큰을 소모합니다. 파일 3개면 이미 한계치에 도달합니다.

Google 스스로도 이를 "실험적 (experimental)"이라고 부릅니다. 출시 시점에도 파인튜닝 (fine-tuning) 레시피가 여전히 발표되고 있는 단계였습니다. Apple Silicon을 위한 MLX 지원도 출시 첫날에는 불완전했습니다. 대규모 클라우드 서빙 (cloud serving)의 경우, AR 모델이 여전히 대규모 스케일에서 더 효율적으로 배치 (batch) 처리합니다.

성능은 실재하며, 천장 또한 실재합니다. 질문은 당신의 사용 사례 (use case)에 그 천장이 중요한가 하는 점입니다.

속도 그 이상의 증거

스도쿠 판에는 81개의 셀이 있습니다. 각 셀은 행, 열, 그리고 3x3 사각형에 의해 동시에 제약을 받습니다. 이를 올바르게 풀기 위해서는 그 모든 제약 조건을 한 번에 시야에 담아야 합니다.

자기회귀 (Autoregressive) 모델은 왼쪽에서 오른쪽으로, 위에서 아래로 한 번에 하나의 셀을 생성합니다. 72번 셀을 채울 때쯤이면, 이미 지나온 3번 셀로 돌아가 수정할 수 없습니다. 모델은 오직 이미 생성된 내용에만 조건화 (Conditioning) 됩니다. 이는 규모 (Scale)의 실패나 학습 데이터의 문제가 아닙니다. 이는 순차적 생성 (Sequential generation) 의 구조적 특성입니다. AR 모델을 더 크게 만들고, 더 빠르게 만들고, 패턴 매칭을 더 잘하게 만들더라도, 구조적으로 앞을 내다볼 수 없기 때문에 전역적 제약 조건 해결 (Global constraint resolution) 없이 셀을 채우게 될 것입니다.

Google은 이를 직접 테스트했습니다. Sudoku 퍼즐에 대한 DiffusionGemma 베이스 모델의 성공률은 0%였습니다. 반면, Sudoku 데이터셋에 JAX 레시피를 사용한 표준 SFT 미세 조정 (Fine-tuning)을 적용했을 때는 80%의 성공률을 기록했으며, 베이스라인보다 4배 적은 추론 단계 (Inference steps)를 사용했습니다.

이러한 개선은 단순한 속도가 아니라 양방향 어텐션 (Bidirectional attention)에서 비롯되었습니다. 256개 토큰 블록 내의 모든 토큰은 생성 과정 동안 다른 모든 토큰을 참조합니다. 모델은 보드 전체를 한 번에 봅니다. 모델은 각 디노이징 패스 (Denoising pass)마다 전체 블록에 걸쳐 제약 조건을 전파하며, 출력이 확정되기 전에 스스로를 수정합니다.

저는 출시 관련 보도들조차 확산형 LLM (Diffusion LLMs)의 장기적인 중요성을 과소평가하고 있다고 생각합니다. 속도 수치들이 헤드라인을 장식하지만, 실제로 더 흥미로운 특성은 바로 양방향성 (Bidirectionality)입니다.

당신의 코드베이스는 스도쿠 판보다 더 어렵습니다. 모든 함수는 반환하는 타입(types), 호출하는 API, 그리고 파일 전반에 걸쳐 암묵적으로 가정하는 계약(contracts)에 의해 제약을 받습니다. 코드 인필링 (Code infilling, 앞뒤 문맥이 주어졌을 때 함수 본문을 채워 넣는 것)은 구조적으로 정확히 이와 같은 문제입니다. AR (Autoregressive) 모델은 방향성 제약에 대한 우회책인 특별한 'fill-in-the-middle' 학습 목표를 통해 인필링을 처리합니다. DiffusionGemma는 이를 아키텍처적으로 처리합니다. 동일한 문제 범주이지만, 해결책의 층위가 다릅니다. 동일한 패턴은 SQL 스키마 마이그레이션, 설정 파일 생성, 즉 양쪽 모두에 엄격한 제약 조건이 있는 구조를 채워 넣어야 하는 모든 상황에서 나타납니다. 컬럼을 추가하는 마이그레이션은 기존 스키마와 이를 참조하는 다운스트림 쿼리(downstream queries) 모두와 일관성을 유지해야 합니다. AR은 나중에 나타나는 제약 조건을 바탕으로 이전의 선택을 재고하지 않고 왼쪽에서 오른쪽으로 생성합니다. 당신은 신중한 프롬프팅과 멀티 패스 생성 (multi-pass generation)을 통해 이를 우회할 수 있습니다. 하지만 이들 모두는 우회책일 뿐입니다.

저는 Claude Code 세션 동안 파일 전반에 걸쳐 미묘하게 일치하지 않는 타입 시그니처 (type signatures)를 추적하는 데 3개월을 보냈습니다. 컨텍스트 윈도우 (context window)가 관련 계약들을 두 세션으로 나누고 있었습니다. 생성 블록 내의 양방향 어텐션 (Bidirectional attention)이 파일 간의 일관성 문제를 완전히 해결하지는 못하지만, 불일치가 발생하는 지점을 옮겨 놓습니다. 문제는 다르지만, 해결책도 다릅니다.

전환할 때와 유지할 때

매일 Claude Code를 사용하는 빌더(builder)를 위한 차익 거래 (arbitrage)는 다음과 같습니다.

DiffusionGemma는 구조적 제약이 있는 단기중기 출력물의 처리량 (throughput)이 병목 구간인 작업에 적합합니다. 구체적으로는 배치 형태의 보일러플레이트 (boilerplate) 생성, 주변 컨텍스트가 가용한 상태에서의 코드 인필링 (code infilling), 구조화된 템플릿 (API 스키마, 설정 파일, 마이그레이션 스텁) 채우기, 그리고 4,000 토큰 미만에서 1020개의 변형을 재생성해야 하는 빠른 반복 주기 (rapid iteration cycles) 등이 이에 해당합니다. 이 모델은 현재 출시되었으며, Apache 2.0 라이선스 하의 오픈 웨이트 (open weights) 모델로, vLLM에서 즉시 사용 가능하며 RTX 4090에서 배포할 수 있습니다. 이러한 작업들에서 발생하는 가변적인 API 비용은 0으로 수렴합니다. 이는 반복성이 높은 로컬 워크플로우 (local workflows)에서 매우 구체적이고 실질적인 경제적 변화를 가져옵니다.

반면, 다단계 추론 체인 (multi-step reasoning chains), 여러 단계를 거쳐 로직을 추적해야 하는 디버깅, 대규모의 일관된 컨텍스트 (context)가 필요한 아키텍처 결정, 단일 패스에서 8K 토큰 이상이 필요한 모든 프로덕션 작업, 그리고 15~20점의 차이가 유용한 출력물과 그럴듯해 보이는 오답을 가르는 추론 집약적 (reasoning-heavy) 계층의 모든 작업에는 Claude를 계속 사용하십시오.