DiffusionGemma: Generasi Teks 4x Lebih Cepat

• DiffusionGemma adalah model terbuka eksperimental 26B MoE berlisensi Apache 2.0 yang menghasilkan seluruh blok teks sekaligus dengan metode difusi teks
• Alih-alih generasi token berurutan pada LLM autoregresif biasa, model ini menggunakan generasi paralel 256 token untuk menghadirkan generasi teks hingga 4x lebih cepat di GPU khusus
• Saat inferensi, hanya 3.8B parameter dari total 26B yang diaktifkan, dan dengan kuantisasi dapat berjalan pada GPU khusus kelas konsumen tingkat atas dalam batas 18GB VRAM
• Dengan attention dua arah dan koreksi diri berulang, model ini unggul pada tugas dengan struktur nonlinier seperti pengeditan inline, pengisian kode, urutan asam amino, dan grafik matematika
• Karena ini adalah model eksperimental yang memprioritaskan kecepatan dan generasi tata letak paralel, kualitas output keseluruhan lebih rendah daripada Gemma 4 standar, sehingga deployment Gemma 4 standar direkomendasikan untuk aplikasi yang membutuhkan kualitas tertinggi

---

Nilai baru bagi developer

• DiffusionGemma adalah model terbuka eksperimental yang mengeksplorasi difusi teks, dan menghasilkan seluruh blok teks sekaligus melampaui pemrosesan berurutan per token pada LLM autoregresif biasa
• Model ini adalah model 26B Mixture of Experts (MoE) yang tersedia dengan lisensi Apache 2.0, dan memberikan generasi teks hingga 4x lebih cepat di GPU
• Dibangun di atas kecerdasan per parameter dari keluarga Gemma 4 dan Gemini Diffusion research, model ini mengintegrasikan diffusion head baru untuk memaksimalkan kecepatan generasi
• Model Gemma 4 autoregresif tetap menjadi standar untuk output produksi berkualitas tinggi, sementara DiffusionGemma dirancang untuk peneliti dan developer yang mengeksplorasi workflow lokal interaktif saat kecepatan menjadi penting

• Trade-off utama

  • Inferensi cepat memindahkan bottleneck decoding dari bandwidth memori ke komputasi, menghasilkan output token hingga 4x lebih cepat di GPU khusus
  • Menghasilkan lebih dari 1000 token per detik pada satu NVIDIA H100, dan lebih dari 700 token per detik pada NVIDIA GeForce RTX 5090
  • Aksesibilitas hardware berasal dari arsitektur yang hanya mengaktifkan 3.8B parameter saat inferensi dari total 26B MoE
  • Dengan kuantisasi, model ini dapat berjalan dalam batas 18GB VRAM pada GPU khusus kelas konsumen tingkat atas
  • Attention dua arah menghasilkan 256 token secara paralel pada setiap forward pass, sehingga semua token dapat saling merujuk
  • Ini memberi keunggulan pada domain nonlinier seperti pengeditan inline, pengisian kode, urutan asam amino, dan grafik matematika
  • Koreksi diri bekerja dengan menyempurnakan output secara iteratif agar model dapat memperbaiki kesalahan secara real-time sambil mengevaluasi seluruh blok teks sekaligus
  • Status eksperimental dan rekomendasi produksi dinyatakan dengan jelas: karena memprioritaskan kecepatan dan generasi tata letak paralel, kualitas output keseluruhan lebih rendah daripada Gemma 4 standar

• Contoh fine-tuning

  • Performa pada tugas tertentu dapat ditingkatkan dengan fine-tuning
  • Unsloth melakukan fine-tuning DiffusionGemma agar dapat menyelesaikan Sudoku, sebuah tugas yang sulit bagi model autoregresif karena setiap token bergantung pada token masa depan
  • Attention dua arah pada DiffusionGemma membuat tugas seperti Sudoku menjadi jauh lebih mudah

Mengapa memakai difusi untuk teks

• Komunitas riset AI telah mengeksplorasi generasi teks berbasis difusi selama bertahun-tahun, tetapi menerapkannya ke model besar tetap menjadi tantangan
• DiffusionGemma menangani masalah ini dengan mengubah cara model menggunakan hardware

• Trade-off dibanding model yang ada

  • Sebagian besar model bahasa menghasilkan satu token per kali dari kiri ke kanan seperti mesin tik
  • Di cloud, pendekatan ini efisien karena server dapat mengelompokkan permintaan dari ribuan pengguna dan membagi beban hardware
  • Saat dijalankan secara lokal oleh satu pengguna, generasi per kata tidak dapat memanfaatkan GPU atau TPU khusus secara penuh, sehingga hardware sering menunggu “ketukan tombol” berikutnya
  • DiffusionGemma menyusun draf seluruh paragraf 256 token sekaligus, memberi prosesor komputer unit kerja yang lebih besar dalam satu waktu
  • Arsitektur ini mengubah inferensi model dari mesin tik berurutan menjadi seperti mesin cetak besar yang mencetak seluruh blok teks sekaligus

• Peningkatan kecepatan yang dioptimalkan untuk inferensi lokal dan konkurensi rendah

  • Peningkatan kecepatan DiffusionGemma dirancang untuk inferensi lokal dan inferensi dengan konkurensi rendah
  • Pada cloud serving dengan QPS tinggi, model autoregresif juga dapat di-deploy untuk memenuhi komputasi secara efisien
  • Dalam lingkungan QPS tinggi, keuntungan decoding paralel dari DiffusionGemma berkurang, dan biaya serving dapat menjadi lebih tinggi
  • Keunggulan throughput paling kuat pada satu akselerator dengan ukuran batch rendah hingga menengah

Cara kerja difusi teks

• Difusi teks menerapkan prosedur serupa dengan generasi gambar AI—yang dimulai dari noise visual lalu berulang kali diperbaiki menjadi gambar tajam—ke dalam teks
• Pada tahap pertama, yaitu kanvas, model dimulai dari kanvas yang terdiri dari token placeholder acak
• Pada tahap penyempurnaan berulang, model melakukan beberapa pass, mengunci token yang benar lalu menggunakannya sebagai petunjuk konteks untuk menyempurnakan sisanya
• Pada tahap penyempurnaan akhir, teks berkonvergensi menjadi output berkualitas tinggi
• Karena model dapat memproses seluruh paragraf selama generasi, pola kerja seperti menutup format Markdown yang kompleks secara akurat atau menghasilkan dan merender kode hampir secara real-time menjadi memungkinkan

Cara memulai

• Bobot model eksperimental tersedia dengan lisensi Apache 2.0 yang permisif dan dapat diakses di Hugging Face
• Integrasi dapat dipelajari lewat DiffusionGemma developer guide, dan mekanisme internalnya dapat dipahami lebih dalam lewat A Visual Guide to DiffusionGemma
• Serving model dapat dilakukan menggunakan MLX, vLLM, Hugging Face Transformers
• Integrasi vLLM didukung oleh Red Hat
• Untuk eksperimen cepat, tersedia tutorial fine-tuning berbasis Hackable Diffusion, toolkit JAX modular yang dirancang untuk komposabilitas
• Fine-tuning juga dapat dieksplorasi dengan Unsloth dan NVIDIA NeMo
• Dukungan resmi llama.cpp akan segera hadir

Optimisasi dan lingkungan eksekusi

• Melalui kolaborasi dengan NVIDIA, optimisasi dilakukan di seluruh stack hardware, menghadirkan kompatibilitas dan performa baik untuk lingkungan konsumen maupun sistem enterprise
• Lingkungan konsumen mendukung kuantisasi untuk GPU GeForce RTX 5090 dan 4090
• Lingkungan enterprise memberikan performa tinggi pada Hopper dan Blackwell yang menggunakan kernel NVFP4 tingkat lanjut
• NVIDIA DGX Spark dan DGX Station untuk deployment lokal di sisi desktop, serta RTX PRO untuk profesional AI, juga termasuk target
• Dukungan native NVFP4 floating point 4-bit mempercepat throughput komputasi sehingga model dapat berjalan lebih cepat dengan akurasi yang nyaris tanpa kehilangan
• Opsi eksekusi mencakup GPU desktop khusus, Gemini Enterprise Agent Platform Model Garden, dan NVIDIA NIM

[GN⁺]

Komentar Hacker News

• Baru-baru ini pindah ke OpenCode dan mencoba banyak model yang bukan dari lab frontier besar di AS, dan model yang paling saya suka secara tak terduga adalah Mercury
  Bukan karena “lebih pintar”, tetapi karena kecepatannya benar-benar gila. Rasanya lebih mirip pair programming daripada pengalaman agen modern yang memasukkan prompt lalu menunggu, jadi saya tetap mendapat manfaat AI sambil sedikit mendapatkan kembali sensasi ngoding sebelum era AI, dan itu jadi lebih menyenangkan. Rasanya bukan seperti mesin slot yang memasukkan prompt lalu berharap arahnya benar, dan saya juga jadi lebih sering memakai model kecil seperti Gemini Flash Lite atau GPT Mini/Nano. Saya menantikan model open-weight ini keluar dan akan langsung mengujinya

  • Kalau pengujian bisa dijalankan cepat dan murah, dan kita juga bisa cepat membuat metrik berbiaya rendah untuk membedakan kode buruk atau kode asal jadi, maka saat waktu itu penting, model yang lebih cepat tapi sedikit lebih lemah bisa lebih baik daripada model yang jauh lebih bagus tetapi lambat
    Saya memakai metrik yang mengukur kompleksitas nyata, bukan kompleksitas siklomatik, lalu mengatur agar perubahan dibatalkan otomatis sampai kompleksitas tambahan dibanding fungsinya masuk akal, dan hasil penggunaan LLM-nya cukup bagus
  • Mercury-2 sangat bagus. Saya sering memakainya sebagai arbiter di llm-consortium
    Jendela konteksnya relatif kecil, jadi untuk konsorsium yang lebih besar bisa disusun seperti meta-konsorsium rekursif:
    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
    Sekarang kalau memberi prompt ke cns-meta-glm-kimi, sistem akan memilih yang terbaik dari masing-masing 5 jawaban kimi dan glm, lalu menyintesis dua jawaban pemenang itu
  • Saya penasaran seberapa besar pengaruhnya terhadap model lokal untuk coding. Jika memakai model difusi yang beberapa kali lebih cepat daripada Qwen atau Gemma 4, mungkin saya harus lebih banyak menyiapkan sendiri seperti sebelum era AI, tetapi itu justru bisa jadi hal yang bagus, dan sepertinya kita bisa bekerja dengan model yang sangat cepat dan murah secara lokal
    Kalau tidak melakukan komputasi berat dalam waktu lama, bukankah biaya menjalankannya di hardware lokal juga jadi lebih murah?
  • Saya paham sekali maksudnya. Untuk proyek pribadi, Claude terlalu lambat dan bikin frustrasi, jadi saya beralih ke Google Antigravity dan model Flash, dan perbedaan kecepatannya luar biasa
    Saya jadi lebih mudah masuk ke flow dan lebih fokus pada pekerjaan. Saya tidak sadar kalau kecepatan bisa memberi perbedaan sebesar ini. Untuk codebase yang sangat kompleks dan besar, waktu respons Claude yang lambat mungkin masih sepadan dengan kompleksitas tugas yang bisa ditanganinya, tetapi Antigravity atau model cepat lain jauh lebih cocok saat ingin mengulang siklus menulis, menjalankan, dan debugging kode yang kecil dan ringan
  • Betul, kecepatan adalah kuncinya. Menyenangkan sekali kalau boilerplate POJO atau data class bisa dihasilkan dengan kecepatan gila 300+ tok/s, dan dalam situasi seperti ini Flash-Lite lebih berguna daripada GPT-5.5
    Kalau terlalu lambat, kita malah terjebak di loop menunggu asinkron sialan itu

• Google terus menunjukkan kekuatannya. Agak mengejutkan bahwa Gemini belum lebih kompetitif daripada model Claude atau OpenAI untuk coding atau penggunaan agen, tetapi jelas Google masih punya talenta AI kelas dunia
  Namun Google tampaknya lebih fokus pada use case yang berjalan di ponsel atau hampir real-time daripada LLM penalaran besar. Peningkatan efisiensi seperti ini kemungkinan akan sangat penting bagi AI ke depannya. Masa ketika token diberi semurah subsidi demi mengunci orang ke ekosistem tertentu mulai berakhir, dan waktunya untuk membayar biaya sebenarnya akan datang. Perusahaan yang menemukan cara menjalankan model yang benar-benar pintar secara hemat biaya akan menang. DeepSeek harganya lebih dari satu digit kelipatan lebih murah daripada GPT 5.5 atau Opus 4.8, dan meskipun lebih buruk dari keduanya, itu tidak sampai fatal. Kalau model coding terbaik benar-benar cukup menghemat waktu manusia, saya rela membayar 10x, tetapi kalau selisihnya 100x seperti pada benchmark terbaru ketika GPT 5.5 Pro kadang lebih dari 200x lebih mahal daripada DeepSeek, dan Opus 4.8 sekitar 30x lebih mahal, itu sulit diterima

  • Fable biayanya dua kali Opus dan tampak cukup kompetitif dengan GPT-Pro, jadi kalau pengaman yang terlalu sensitif bukan masalah besar, ini bisa jadi pilihan yang oke
    Google juga punya opsi “Deep Research” sendiri di area ini dan tampaknya bekerja dengan baik. Nilai plus DeepSeek adalah bisa dijalankan di hardware lokal tanpa biaya API. Kalau itu penting, maka sedikit tertinggal dari Opus atau GPT bukan masalah besar
  • Pada akhirnya Google sepertinya akan menang. Mereka fokus pada hal penting: performa per watt dan performa per dolar
    Mereka membuat hardware inferensi sendiri dan bergerak ke edge computing untuk mengurangi latensi dan overhead komputasi. LLM besar masih belum efisien secara biaya, dan Google sedang membiarkan para pesaingnya membakar modal investasi untuk “menjual” ke konsumen di bawah biaya produksi. Bahkan setelah gelembung AI pecah, perusahaan seperti Google akan tetap bertahan baik-baik saja, dan gelembung ini tampak seperti sedang mengelupas lapisan luar beberapa perusahaan raksasa tertentu

• Beberapa tanggapan melewatkan keunggulan pendekatan difusi. Ini bisa berdampak besar pada perangkat edge seperti ponsel atau GPU komputer.
  Decoder LLM harus mempertimbangkan semua token sebelumnya, jadi token dihitung satu per satu. Decoder LLM konvensional bisa diskalakan dengan baik jika bebannya cukup besar untuk mengelompokkan beberapa inferensi ke dalam batch, dan dalam lingkungan seperti itu keuntungan difusi terbatas. Di edge, masalahnya berbeda. Akselerator inferensi kelaparan karena terus memindahkan bobot berukuran GB dari RAM. RAM konsumen seperti LPDDRx/GDDRx memiliki bandwidth lebih rendah daripada HBM, dan karena permintaan bersifat serial, perhitungan bobot bersama tidak bisa digabungkan dalam batch. Difusi dapat menghitung token secara paralel sehingga mengurangi bottleneck bandwidth memori

  • Perangkat edge bukan hanya kekurangan bandwidth memori, tetapi juga kinerja komputasi sangat terbatas. Dalam praktiknya, bahkan tanpa banyak batch pun jumlah komputasi yang mungkin dilakukan cepat mencapai saturasi dan terbentur batas panas serta daya yang jelas.
    Pernyataan bahwa dalam inferensi edge “permintaan pada dasarnya serial” juga tidak benar. Ada beberapa permintaan sekaligus, yaitu beberapa chat berjalan bersamaan, dan jika kapasitas memori untuk menampung cache KV cukup, pemrosesan batch tetap bisa diterapkan. Jika model difusi menghasilkan kualitas lebih rendah dengan komputasi lebih banyak dan penghematan bandwidth memorinya juga tidak jelas, saya kurang paham bagaimana ini membantu
  • Secara umum benar, tetapi ini mencampuradukkan attention dengan struktur autoregresif/kausal. Masalah sebenarnya yang mencegah penggunaan komputasi lebih banyak adalah struktur autoregresif/kausal.
    Difusi juga bisa memakai attention, dan model ini memang benar-benar menggunakan attention

• NVIDIA menyediakan endpoint gratis untuk model ini. Detailnya ada di https://build.nvidia.com/google/diffusiongemma-26b-a4b-it, dan Anda harus membuat akun, mungkin juga perlu verifikasi nomor telepon.
  Saya juga mencobanya untuk menggambar pelikan: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...

  • Kalau modelnya benar-benar cepat, mungkin bisa juga meminta frame animasi. Misalnya frame 1 kaki kanan di jam 12, kaki kiri di jam 6, frame 2 kaki kanan di jam 3, kaki kiri di jam 9.
    Maka metrik yang wajar bukan token per detik, melainkan tentu saja frame pelikan per detik
  • Saya mendaftar beberapa minggu lalu, tetapi meski sudah mengikuti prosedurnya akun saya masih belum diverifikasi. Kalau akun belum diverifikasi, API tidak bisa dipakai

• Penjelasan visual yang bagus tentang cara kerja model difusi teks seperti DiffusionGemma: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

• Sampai beberapa hari lalu saya mengira Google sama sekali tidak membicarakan model generasi teks difusi setelah mendemokannya di I/O setahun lalu.
  Pernah ada rumor bahwa menjalankannya terlalu mahal, tetapi jika DiffusionGemma dan Gemma biasa dibandingkan pada hardware 1x H100 yang sama seperti di grafik yang diberikan, tampaknya tidak begitu. Selain sedikit lebih lemah daripada Gemma, saya penasaran apa kekurangan dari kecepatan ini

  • Jawaban untuk “saya penasaran apa kekurangan dari kecepatan ini” tampaknya bagian ini:
    “Peningkatan kecepatan DiffusionGemma dirancang untuk inferensi lokal dan konkurensi rendah. Pada cloud serving dengan QPS tinggi, model autoregresif dapat dibatch secara efisien untuk menyaturasi komputasi, sehingga keunggulan decoding paralel DiffusionGemma berkurang dan biaya serving bisa lebih tinggi”
  • Dengan model autoregresif standar, jika ada 256 pengguna misalnya, Anda bisa menghasilkan 256 token sekaligus. Metode ini memang bisa menghasilkan 256 token untuk satu pengguna, tetapi membutuhkan beberapa langkah forward pass.
    Jadi proses difusi memakai lebih banyak GFLOPs, dan kalau jumlah pengguna cukup banyak, keseimbangan antara memori dan komputasi sebenarnya sudah bisa dicapai

• “DiffusionGemma membalik ketidakefisienan ini. Alih-alih memprediksi kata secara berurutan, ia membuat draf seluruh paragraf 256 token sekaligus. Dengan memberi prosesor komputer potongan pekerjaan yang lebih besar sekaligus, hardware bisa dimanfaatkan semaksimal mungkin. Ini seperti meng-upgrade inferensi model dari mesin tik yang mengetik satu karakter demi satu karakter menjadi mesin cetak raksasa yang mencetak seluruh blok teks sekaligus.”
  “Ia berjalan sebagai model mixture-of-experts (MoE) berukuran total 26B, dengan hanya 3.8B parameter yang aktif saat inferensi, dan setelah dikuantisasi ukurannya muat dengan nyaman dalam batas 18GB VRAM GPU khusus konsumen kelas atas.”
  Jadi Gemma 4 26B adalah model MoE yang berjalan sangat cepat di GPU 24GB saya dengan ollama. Ini terdengar seperti speculative decoding, tetapi saya kira itu tidak bekerja pada model MoE. Bagi orang yang tidak mengikuti ini sebagai pekerjaan, perubahannya terlalu banyak sehingga sulit diikuti

  • Ini adalah model lain yang, agak membingungkan, memiliki jumlah parameter yang hampir sama dengan gemma4 MoE yang sudah ada. Sekilas tidak jelas apakah salah satunya dilatih dari yang lain dengan cara tertentu.
    Mekanismenya tidak sama dengan speculative decoding. Speculative decoding berjalan berurutan, biasanya beberapa token sekaligus. Difusi tidak seperti itu, melainkan menangani satu blok teks sekaligus. Saya belum membaca materinya, tetapi saya menduga model ini dilatih agar pakar tertentu tetap stabil di seluruh blok difusi

• Di 3090 Ti saya, kecepatannya bahkan tidak mendekati angka yang diiklankan, tetapi menyenangkan melihat bagaimana jawaban itu “terisi” sedikit demi sedikit.
  Saya mencoba uji “pelikan SVG bersepeda” dari Simon, dan hasilnya cukup minimalis tetapi sesuai permintaan: https://gist.github.com/peterc/7672e74ec1437945e5fca5ce2c1c9... -- dijalankan dengan kuantisasi Q4 di llama.cpp yang sudah ditambal. Saya juga penasaran apakah hasil Simon jauh berbeda

• Model penalaran berbasis difusi itu akan seperti apa? Apakah semacam mendifusikan blok [thinking] dengan panjang yang sudah ditentukan sebelumnya dalam waktu lama, lalu blok output akhirnya memakai isi blok thinking itu sebagai bagian dari input?
  Lalu model difusi pada dasarnya menentukan panjang output bagaimana? Apakah lewat parameter yang sudah ditetapkan sebelumnya, atau menyebarkan token [end] di suatu titik di tengah, saya jadi penasaran

  • Setelah membaca komentar lainnya, setidaknya saya dapat satu jawaban. Masuk akal kalau proses difusi itu sendiri pada dasarnya adalah proses yang mirip penalaran: https://www.inceptionlabs.ai/blog/introducing-mercury-2

• Keren sih, tapi meskipun model lokal sudah lumayan, secara terasa tetap jelas kalah bahkan dibanding API termurah, jadi saya tidak terlalu tertarik mengorbankan kualitas meski sedikit demi mengejar kecepatan
  Untuk beberapa kasus penggunaan tentu ada nilainya, tapi saya penasaran contoh konkret kasus yang benar-benar ingin dideploy ke production

  • Untuk menulis unit test atau bootstrap, ini mungkin cukup oke
    Walau bukan sekelas Opus, tetap bisa dipakai dan juga mudah diiterasi