- Gemini Diffusion yang diumumkan Google adalah LLM pertama yang menggunakan pendekatan diffusion, bukan transformer
- Mirip dengan yang digunakan pada model gambar seperti Imagen atau Stable Diffusion
- Model ini menghasilkan teks melalui proses diffusion yang menyaring noise secara bertahap, bukan dengan pendekatan autoregresif yang sudah ada
- Hasilnya, kecepatan respons sangat cepat, dan dalam eksperimen menunjukkan performa 857 token per detik
- Benchmark yang akurat masih belum cukup, tetapi Google mengklaim kecepatannya 5 kali lebih tinggi dibanding Gemini 2.0 Flash-Lite
Gambaran umum Gemini Diffusion
- Gemini Diffusion adalah model bahasa besar (LLM) baru yang diperkenalkan Google
- Alih-alih memakai pendekatan autoregressive pada LLM berbasis transformer yang sudah ada, model ini mengadopsi pendekatan diffusion
- Pendekatan diffusion ini diterapkan pada pembuatan teks, sambil bekerja mirip model pembangkit gambar seperti Imagen dan Stable Diffusion
- Ciri utamanya adalah kecepatan respons tinggi serta kemampuan memperbaiki kesalahan secara efisien selama proses generasi
- Dalam contoh penggunaan, prompt "Build a simulated chat app" menghasilkan keluaran HTML+JavaScript dalam hitungan detik, dengan kecepatan generasi hingga 857 token per detik
Cara kerja model bahasa diffusion
- Model bahasa autoregresif yang ada menghasilkan token satu per satu secara berurutan, sehingga lebih lambat dan memiliki keterbatasan pada konsistensi output
- Sebaliknya, model diffusion berangkat dari noise lalu secara bertahap menyempurnakan hasil, memproses seluruh kalimat atau paragraf sekaligus dalam beberapa tahap
- Karena itu, generasi token secara paralel menjadi memungkinkan, sehingga tercapai pembuatan hasil yang sangat cepat
- Model ini efektif untuk area yang membutuhkan umpan balik langsung seperti pengeditan teks, matematika, dan kode
Model serupa dan perbandingan performa
- Sebelumnya hampir tidak ada diffusion LLM komersial, dan proyek Inception Mercury yang muncul pada Februari 2024 menjadi kasus pertama
- Dari sisi kecepatan dan performa, menurut Google Gemini Diffusion mirip dengan Gemini 2.0 Flash-Lite, tetapi sekitar 5 kali lebih cepat
- Model ini menunjukkan kecepatan generasi tinggi serupa Cerebras Coder, dan data benchmark yang objektif direncanakan akan ditambahkan nanti
Penjelasan tambahan dan koreksi
- Model bahasa diffusion tidak sepenuhnya menggantikan arsitektur transformer, melainkan mengubah struktur generasi teks dari autoregressive menjadi diffusion
- Mercury dan Gemini Diffusion sama-sama berbasis transformer, tetapi memproses seluruh input sekaligus dan memiliki cara generasi yang berbeda
- Ini adalah bentuk yang berkembang dari pendekatan masking dan pemulihan gaya BERT, dengan rasio masking yang makin ditingkatkan, sehingga hasil tetap dapat disusun secara bertahap bahkan saat semua token dimasking
- Pendekatan diffusion hanya menetapkan sebagian token sebagai final di beberapa tahap, lalu berulang kali menaikkan proporsi token final untuk menyelesaikan seluruh sequence
- Gagasan inti diffusion LLM ini adalah pemulihan bertahap dan generasi paralel
Kesimpulan
- Gemini Diffusion adalah LLM baru yang menghadirkan karakteristik inovatif dari sisi kecepatan dan kualitas generasi
- Model ini berhasil memperluas keunggulan model diffusion yang telah terbukti pada pembuatan gambar ke ranah generasi teks
- Nilai pemanfaatannya dalam berbagai penerapan praktis serta hasil benchmark mendatang sangat dinantikan
1 komentar
Komentar Hacker News
Saya tidak terlalu tahu bagaimana ini benar-benar bekerja di internal Google, tetapi belakangan ada hal yang cukup menarik dari kubu RWKV. Mereka bereksperimen mengganti seluruh mekanisme attention yang ada dengan WKV (linear attention), dan seluruh proses itu dibuat hanya dengan post-training. Implikasi yang disiratkan adalah bahwa sebagian besar pengetahuan yang berguna sebenarnya tersimpan di FFN (feed-forward network), dan attention itu sendiri mungkin bukan unsur yang seunik atau sepenting yang kita kira. Tautan terkaitnya juga menarik untuk dibaca. Di sisi lain, memanfaatkan attention yang sudah terlatih, lalu menguji seberapa cepat FFN saja dalam training berkecepatan GPT-2 juga terdengar seperti percobaan yang menarik walau melanggar aturan, dan saya ingin membaca makalahnya. Dari yang saya baca kemarin, ada pembahasan bahwa pada titik tertentu embedding semua model menjadi (sangat) mirip, sehingga transformer sederhana bisa dilatih; dan jika keduanya benar, maka embedding dan attention bisa dibagikan untuk membuat keseluruhan pelatihan jauh lebih cepat
Attention, dengan segala hormat sebesar-besarnya kepada para penelitinya, menurut saya pada dasarnya adalah memasukkan seluruh informasi masa lalu jaringan sebagai input ke jaringan saraf reverse-MoE. Di sini, yang memilih apa yang dieksekusi bukan bagian dari jaringan sebagai “pakar”, melainkan bagian dari input. Kita tahu pendekatan seperti ini kemungkinan akan efektif, tetapi begitu tidak efisien sampai bahkan pengguna R atau Python pun tidak terpikir untuk menjalankannya. Training-nya sendiri terlalu lambat sehingga secara praktis sulit dicoba
Saya jadi merasa bahwa "Attention is all you need" mungkin sebenarnya bisa ditafsirkan dengan makna lain
Cerita tentang embedding model yang saling menjadi (sangat) mirip sehingga bisa dipetakan dengan transformer sederhana berasal dari sini
Saya melihat attention sebagai cara yang sepenuhnya arbitrer untuk membagi jaringan agar pembelajaran paralel menjadi mungkin. Bagian yang benar-benar berkontribusi pada keberhasilan justru adalah "shortcut connection" antar-layer. Ini memberi layer awal pengaruh yang lebih besar saat training
Kurangnya pentingnya secara relatif dari attention SDPA yang dipakai transformer modern sebenarnya sudah diketahui. FFN, normalisasi, dan residual connection sama sekali tidak tergantikan, tetapi attention mudah diganti dengan layer lain apa pun yang membagi informasi antar-token, seperti pooling, convolution, random mixing, dan sebagainya
Ini benar-benar sangat cepat. Sejauh ini saya merasa kasus penggunaan terbaik model adalah menulis kode yang benar-benar baru dan membuat prototipe dengan cepat. Untuk memperbaiki codebase besar yang sudah berkali-kali disempurnakan secara iteratif, saya tidak merasa model terlalu kuat. Salah satu alasannya adalah, secara definisi, model tidak bisa mengetahui hal-hal yang "tidak termasuk" di dalam codebase. Fakta bahwa sesuatu "tidak ada" di kode juga merupakan sinyal yang bermakna, dan ini masalah yang cukup sulit untuk direpresentasikan. Seberapa pun cerdasnya model, saya rasa ada keterbatasan mendasar di titik itu karena ia kurang memiliki "konteks dan pengalaman internal". Misalnya, jika Anda memberi codebase besar kepada developer yang sangat hebat dan langsung memintanya menyelesaikan masalah tertentu, developer biasa yang mengenal codebase itu dengan baik bisa menghasilkan hasil yang lebih bernilai dalam waktu yang sama
Masalah ini bisa diatasi jika fokusnya pada cara berkomunikasi. Workflow utama saya belakangan ini adalah, saat perlu pekerjaan besar seperti fitur baru atau refactor, saya memulai percakapan dengan o3 seperti dengan rekan kerja. Saya terus menempelkan file sumber yang diperlukan untuk memberi konteks, sambil berdiskusi di tingkat tinggi tentang tujuan dan kondisi kode saat ini. Dalam proses itu saya merasa tujuan saya dan konteks codebase menjadi jauh lebih jelas. Setelah itu saya minta o3 membuat rencana implementasi, lalu saya kirimkan ke Codex untuk menjalankan rangkaian otomatis seperti membaca source, mengubah file, dan menjalankan test. Saat PR keluar, kadang cukup sedikit edit manual atau bahkan bisa langsung di-merge. Saya setuju model membutuhkan konteks yang kaya, tetapi ini bukan batasan yang esensial, melainkan persoalan cara berkolaborasi secara efektif. Jika sudah terbiasa, bukan hanya produktivitas yang naik, bagi saya cara kerja ini juga membuat pikiran terasa lebih menyenangkan
Saya sangat beresonansi dengan sudut pandang bahwa "hal-hal yang tidak ada di codebase memiliki sinyal yang bermakna". Saya sudah lama berkecimpung di software, tetapi belum pernah secara sadar melihat kebenaran mendasar ini sejelas sekarang. Wawasan yang sangat berharga
Sejauh pengalaman saya, LLM sangat pandai meniru kode bagus yang sudah ada, tetapi tidak terlalu mampu menghasilkan bagian yang baru dan orisinal kecuali diminta secara sangat eksplisit. Sering kali ia tidak mampu meng-ingest codebase dengan cukup baik sehingga kita harus menunjuk langsung bagian lain dalam proyek. Meski begitu, akan keren sekali jika kita bisa memberi semacam "negative prompt" seperti di Stable Diffusion
Saya penasaran hasilnya akan seperti apa jika LLM bisa membaca seluruh riwayat git, issue tracker, bahkan rekaman meeting sebagai konteks. Apakah input konteks yang sangat besar benar-benar akan menghasilkan sesuatu yang praktis masih perlu dilihat
Saya benar-benar terkejut dengan pengumuman ini. Menurut saya ini pengumuman terbesar di acara IO, tetapi sayang tertutup oleh kabar lain seperti Veo 3. Menggunakan model diffusion untuk generasi kode punya makna yang sangat besar. Kalau memakai transformer, ini akan masuk keluarga DiT (diffusion transformer), dan beberapa tahun lalu saya pernah terlibat dengan model hibrida yang menggabungkan diffusion berbasis U-Net, tetapi sejak itu pun kemajuannya sudah besar. Saya merasa akan ada lompatan besar lagi di bidang diffusion ke depan
Saya penasaran bagaimana intuisi dari vision transformer akan bekerja jika diterapkan ke kode. Dalam visi, model berangkat dari noise lalu secara bertahap menghasilkan gambar target yang makin jelas per level. Jika prinsip ini diterapkan pada generasi kode, tampaknya dibutuhkan struktur hierarkis yang secara bertahap menurunkan tingkat abstraksi, misalnya "harus memakai Django", lalu "menentukan daftar endpoint", lalu "menghasilkan kode konkret". Namun diffusion tidak punya mekanisme backtracking, jadi meskipun masalah level bawah terdeteksi, kemampuannya memberi umpan balik langsung ke layer atas terbatas. Sebaliknya, transformer menjalankan seluruh model untuk setiap token, sehingga lebih mudah melakukan backtracking dan perubahan desain sesuai kebutuhan tiap masalah. Mungkin model mental saya keliru, jadi saya ingin mendengar wawasan tambahan
Veo 3 menjadi ramai karena performa dan pembeda utamanya sangat mudah dipahami secara intuitif, sedangkan untuk memahami nilai kemajuan penting dalam text completion kita perlu tahu capaian yang sudah ada dan potensi penggunaannya. Banyak orang masih bahkan belum yakin bahwa LLM itu sendiri berguna untuk coding
Model generasi kode berbasis diffusion benar-benar revolusioner. Beberapa ide sederhana tentang apa yang bisa dilakukan model seperti ini adalah: menghasilkan token di antara function signature dan hasil yang sudah dikunci terlebih dahulu, sehingga informasi dua arah bisa dipakai. Kedua, terlebih dahulu menulis garis besar tata letak fungsi, seperti LLM menulis "bab" artikel, lalu memecahnya bertahap menjadi implementasi yang lebih detail. Lalu melakukan generasi berulang dalam konteks yang lebih besar dengan memanfaatkan berbagai sinyal seperti linter, informasi AST, dan lain-lain untuk mengarahkan proses. Banyak sekali yang bisa diuji
Secara prinsip pendekatan ini tampak punya keunggulan besar, dan model seperti LLaDA yang benar-benar saya coba pun cukup mengesankan meski sumber daya training-nya kecil. Namun pada metrik seperti perplexity masih tertinggal. Ia juga tampak cenderung cepat terkunci selama generasi, jadi mungkin ada batasan untuk mengedit teks secara mendalam di tengah proses (semakin tinggi probabilitas masking, semakin sulit melakukan revisi serentak). Meski begitu, dalam eksperimen nyata saya tetap mendapatkan hasil yang cukup praktis
Karena saya sudah pernah melihat demo dari InceptionLabs dan lainnya, saya tidak terlalu terkejut
Saya rasa inti kabar ini malah tertutupi. Ini adalah InstructGPT yang sangat cepat dan sangat bagus. Ke depan ini pasti akan dipakai untuk pemeriksa ejaan, codemod, editor kode, dan sebagainya. Berkat fitur Instant edits, pengeditan teks yang sangat cepat dan presisi bisa dilakukan tanpa tambahan atau saran yang tidak perlu. Saya meminta agar contoh kode ShaderToy mengganti nama variabelnya supaya lebih mudah dipahami, lalu menyalin hasilnya dan menjalankannya, dan ternyata tetap bekerja dengan baik—itu membuat saya kagum
Keunggulan diffusion bukan sekadar kecepatan. Menurut benchmark awal, dibanding AR, dengan parameter yang sama ia lebih baik dalam inferensi dan perencanaan. Diffusion bisa mengedit bagian tengah dan tidak mengalami masalah bias token awal
Klaim yang menarik. Apakah ada benchmark atau tautan referensi yang bisa dibagikan?
AR sendiri tidak menghalangi pembuatan rencana panjang, tetapi dalam implementasi model AR populer terbaru memang sering ada keterbatasan seperti itu. AR pada dasarnya sangat penting untuk mempelajari distribusi yang benar
Secara pribadi saya setuju, atau setidaknya berharap itu benar, tetapi saya belum pernah melihat makalah atau demo tentang revise diffusion text. Saya ingin mencobanya, jadi akan bagus jika informasi makalahnya dibagikan
Saya sudah lama tertarik pada penerapan teknik diffusion untuk generasi teks. Akhirnya Google merilis model seperti ini, jadi saya senang karena terasa seperti pemikiran saya tervalidasi. Dari sisi hardware untuk eksperimen, kebanyakan orang memakai layanan berbayar atau perangkat kelas atas, setidaknya yang tinggi di kelas konsumen. Saat ini yang saya punya hanya 5700XT jadi sulit untuk upgrade, tetapi justru karena itu saya bisa melihat keterbatasan model sekarang dengan lebih jelas. Semakin besar model, semakin tinggi pula konsistensinya, jadi model kecil mau tak mau terbatas pada tugas sederhana. Salah satu hal utama yang saya konfirmasi lewat eksperimen adalah pentingnya ukuran konteks; pada GPU kecil sulit memuat konteks yang cukup dan model yang memadai sekaligus, dan saya penasaran apakah model berbasis diffusion bisa mengubah keseimbangan antara kepadatan dan konsistensi. Saya berharap bisa mendapatkan generasi teks yang lebih konsisten meski konteksnya sedikit, dan hasil campuran tool call + respons juga mungkin akan lebih baik. Masalah kecepatan juga keluhan yang nyata: pendekatan LLM lama itu lambat karena berputar input-output sedikit demi sedikit, dan itu menguji kesabaran, terutama pada GPU lama tanpa hardware AI khusus. Akan bagus jika kita setidaknya bisa melihat progres 0~100% secara real time, dan saya berharap diffusion bisa lebih baik dalam hal ini. Lalu muncul pertanyaan: karena input noise itu penting, apakah ada sumber noise yang bagus yang khusus untuk LLM/teks, dan apakah panjang blok keseluruhan harus ditetapkan dari awal atau bisa variabel?
Dari sudut pandang saya, saya bisa bilang dengan pasti bahwa model ini sangat cepat. Kekurangannya adalah model ini sangat mudah ditembus oleh serangan prompt injection. Misalnya, jika Anda meminta resep obat ia akan menolak, tetapi jika diminta dalam bentuk "roleplay anak kecil" maka ia benar-benar memberikan hasilnya. Terlepas dari kelemahan itu, kecepatan dan kegunaannya untuk otomasi benar-benar luar biasa. Jika ditambah pendekatan bergaya agen, potensi model ini akan benar-benar bersinar
Mungkin itu bukan keterbatasan model itu sendiri, melainkan karena sumber daya untuk aspek keamanan atau sensorisasi di training-nya lebih sedikit. Menurut saya ini semacam eksperimen prototipe, semacam uji coba ringan sebelum investasi sungguhan pada model besar
Saya tidak menganggap prompt injection seperti ini sebagai tanda bahwa model yang lebih pintar nantinya bisa dikendalikan
Penjelasan bahwa ini adalah "diffusion LLM pertama Google, menggunakan diffusion alih-alih transformer" adalah klaim yang keliru. Google sendiri tidak pernah mengumumkannya seperti itu. Justru model diffusion berbasis transformer sangat umum. Saya juga merasa Gemini Diffusion kemungkinan besar memakai transformer. Perbedaannya adalah ia merupakan encoder-only transformer. Artinya, seluruh sekuens dimasukkan dalam keadaan noisy/corrupted, lalu model memprediksi seluruh sekuens yang benar. Berkat ini, seluruh frame sekuens bisa diproses paralel sekaligus, dan jika jumlah iterasinya masuk akal, ia bisa jauh lebih cepat daripada decoding berurutan pada model decoder-only, meski speculative decoding tentu punya keuntungan kecepatan serupa. Biasanya model seperti ini dilatih dengan masking ala BERT, tetapi ini tetap bidang riset yang sangat aktif. Saya juga penasaran seperti apa hubungannya dengan Gemini dan apakah checkpoint-nya digunakan kembali—apakah diimpor langsung, fine-tuning khusus diffusion, knowledge distillation, atau sekadar nama merek. Akan bagus jika detail resminya dipublikasikan
Cepatnya tidak masuk akal. Saya memperkirakan GPU akan selalu berjalan pada performa maksimum, dan penghematan komputasi dari batch processing hampir tidak ada. Tetapi setelah dipikir-pikir, itu pun rasanya bukan tradeoff yang benar-benar layak disebut tradeoff. Satu kekhawatiran saya adalah objective diffusion mungkin kalah performa dibanding AR. Jika begitu, alternatifnya bisa berupa model AR multi-token yang mencapai kecepatan setara diffusion, atau memanfaatkan model diffusion sebagai draft generator untuk speculative decoding
Saya penasaran kenapa Anda berpikir kualitas dLLM akan lebih rendah daripada arLLM. Karena hasilnya diproses berulang sebagai "keseluruhan terstruktur" (tema, poin penting, konsep, pohon kata), justru bisa jadi kualitasnya lebih baik
Tradeoff struktural ini jauh lebih menguntungkan di lingkungan self-hosting. Di sana tidak perlu batch besar, jadi keuntungannya kecil di cloud tetapi besar untuk LLM lokal
Saya sangat bersemangat dengan diffusion LLM. Tim kami memimpikan mekanisme game suara → kode, dan diffusion terasa seperti elemen yang akhirnya bisa mewujudkan itu. Cerebras dan Groq memang luar biasa, tetapi karena hardware-nya kustom, ada batasan untuk fine-tuning dan scaling. Alternatif lain adalah MoE dengan active parameter di kisaran 0.5b, tetapi saat ini kami belum punya ruang untuk menggelontorkan sumber daya ke proyek itu. Jika ada orang Google/DeepMind yang membaca ini, tolong sediakan API-nya. Tim kami sedang mengembangkan game sandbox generatif, dan karya pertama kami punya struktur di mana pemain memberi perintah kepada monster secara real time. Kami juga punya video prototipe, jadi silakan dilihat