- Google'ın duyurduğu Gemini Diffusion, transformer yerine diffusion yaklaşımını kullanan ilk LLM'dir
- Imagen veya Stable Diffusion gibi görüntü modellerinde kullanılan yönteme benzer
- Bu model, mevcut otoregresif yaklaşım yerine, gürültüyü aşamalı olarak arındıran bir diffusion süreciyle metin üretir
- Sonuç olarak yanıt hızı çok yüksektir ve deneylerde saniyede 857 token düzeyinde performans göstermiştir
- Kesin benchmark verileri henüz yetersiz olsa da Google, Gemini 2.0 Flash-Lite'a kıyasla 5 kat daha hızlı olduğunu iddia ediyor
Gemini Diffusion'a genel bakış
- Gemini Diffusion, Google'ın yeni tanıttığı büyük dil modelidir (LLM)
- Mevcut transformer tabanlı LLM'lerin otoregresif (autoregressive) yöntemi yerine, diffusion yaklaşımını benimser
- Bu diffusion yöntemi, görüntü üretim modelleri (Imagen, Stable Diffusion vb.) gibi çalışsa da metin üretimine uygulanmıştır
- Öne çıkan özellikleri arasında hızlı yanıt süresi ve üretim sürecinde hataları verimli biçimde düzeltebilme yeteneği yer alır
- Kullanım örneklerinde "Build a simulated chat app" istemine birkaç saniye içinde HTML+JavaScript çıktısı veriyor ve saniyede en fazla 857 token üretim hızına ulaşıyor
Diffusion dil modeli nasıl çalışıyor
- Geleneksel otoregresif dil modelleri, token'ları tek tek sıralı biçimde ürettiği için yavaştır ve çıktının tutarlılığı açısından da sınırlamalara sahiptir
- Buna karşılık diffusion modelleri, gürültüden başlayıp sonucu kademeli olarak iyileştirir; tüm cümleyi veya paragrafı birden çok aşamada topluca işler
- Bu sayede paralel token üretimi mümkün olur ve çok hızlı sonuç üretimi sağlanır
- Metin düzenleme, matematik, kod gibi anlık geri bildirimin önemli olduğu alanlarda etkili olur
Benzer modeller ve performans karşılaştırması
- Daha önce ticari diffusion LLM neredeyse yoktu; ilk örnek olarak 2024 Şubat'ta Inception Mercury projesi ortaya çıktı
- Hız ve performans açısından Gemini Diffusion, Google'a göre Gemini 2.0 Flash-Lite ile benzer düzeyde olsa da yaklaşık 5 kat daha hızlıdır
- Cerebras Coder'a benzer şekilde yüksek üretim hızı gösteriyor; gelecekte nesnel benchmark verilerinin eklenmesi bekleniyor
Ek açıklamalar ve düzeltmeler
- Diffusion dil modelleri, transformer mimarisinin tamamen yerini almak yerine, otoregresif yöntem yerine diffusion tabanlı bir metin üretim yapısı kullanır
- Mercury ve Gemini Diffusion her ikisi de transformer tabanlıdır; ancak tüm girdiyi tek seferde işler ve üretim yöntemi farklıdır
- Mevcut BERT tarzı maskeleme ve geri getirme yaklaşımının gelişmiş bir biçimi olarak, maskeleme oranını giderek artırır ve tüm token'ların maskelendiği durumda bile sonucu aşamalı olarak tamamlar
- Diffusion yaklaşımı, birden çok aşamada yalnızca bazı token'ları final hale getirir; tekrar tekrar kesinleşen token oranını artırarak tüm diziyi tamamlar
- Bu tür diffusion LLM'lerin temel fikri, aşamalı geri getirme ve paralel üretimdir
Sonuç
- Gemini Diffusion, hız ve üretim kalitesi açısından yenilikçi özellikler sunan yeni bir LLM'dir
- Görüntü üretiminde kanıtlanmış diffusion modelinin avantajlarını metin üretimi alanına başarıyla genişletir
- Farklı gerçek dünya kullanım senaryolarındaki değeri ve ileride açıklanacak benchmark sonuçları için beklenti yükseliyor
1 yorum
Hacker News görüşleri
Google içinde bunun gerçekte nasıl çalıştığını çok bilmiyorum ama son dönemde RWKV tarafında dikkat çekici bir gelişme vardı. Mevcut attention mekanizmasını tamamen WKV'ye (lineer attention) çeviren bir deney yaptılar ve tüm bu süreci yalnızca post-training ile başardılar. Bunun ima ettiği şey, faydalı bilginin büyük kısmının aslında FFN'de (feedforward network) bulunduğu ve attention'ın sanıldığı kadar benzersiz ya da önemli bir unsur olmayabileceği. İlgili bağlantılara da bakarsanız ilginç olabilir. Öte yandan, hâlihazırda eğitilmiş attention'ı kullanıp GPT-2 hızında eğitimde sadece FFN'in tek başına ne kadar hızlı olduğunu denemek de kurallara aykırı olsa da ilginç bir girişim olurdu; bunu makale olarak okumak isterdim. Dün okuduklarımdan birinde, belli bir noktada tüm modellerin embedding'lerinin (çok) benzer hâle geldiği, bu yüzden basit bir dönüştürücü eğitilebildiği ve eğer bu iki şey de doğruysa embedding ile attention'ı paylaşarak toplam eğitimi çok daha hızlı hâle getirmenin mümkün olabileceği söyleniyordu
Attention dediğimiz şey, araştırmacılara en büyük saygımı sunarak söylüyorum, ağın geçmişteki tüm bilgisini alıp bunu reverse-MoE sinir ağına vermek gibi geliyor. Burada uzman, ağın bir parçasını değil girdinin bir parçasını çalıştırmak üzere seçiyor. Bu yaklaşımın işe yarayacağını herkes biliyordu ama o kadar verimsizdi ki R ya da Python kullanıcıları bile çalıştırmayı düşünmüyordu. Eğitimin kendisi yavaş olduğundan pratikte denemesi bile zordu
Attention'ın gerçekten gerekli olduğunu söyleyen 'Attention is all you need' ifadesi aslında başka bir anlamda da yorumlanabilir gibi geliyor
Model embedding'lerinin birbirine (çok) benzeyip basit bir dönüştürücüyle eşlenebildiği fikri buradan geliyor
Bence attention, ağı bölerek paralel eğitimi mümkün kılan tamamen keyfi bir yöntem. Başarıya asıl katkı veren şey katmanlar arasındaki 'shortcut connection'. Bu, eğitim sırasında ilk katmanlara daha fazla etki gücü veriyor
Günümüz transformer'larında kullanılan SDPA attention'ın göreli önemsizliği zaten biliniyor. FFN, normalizasyon ve residual bağlantılar kesinlikle vazgeçilmez ama attention, token'lar arasında bilgi paylaşan başka herhangi bir katmanla da kolayca değiştirilebilir: pooling, convolution, rastgele mixing vb.
Gerçekten inanılmaz derecede hızlı. Bana göre şimdiye kadar modellerin en iyi kullanım alanı tamamen yeni kod yazmak ve hızlı prototipleme oldu. Zaten defalarca yinelemeyle geliştirilmiş büyük kod tabanlarını iyileştirmede ise o kadar güçlü olduklarını düşünmüyorum. Bunun sebeplerinden biri, tanım gereği modelin kod tabanına 'dahil olmayan' şeyleri bilememesi. Bir şeyin kodda 'olmaması' da anlamlı bir sinyal taşıyor ama bunu ifade etmek oldukça zor. Model ne kadar zeki olursa olsun, burada 'iç bağlam ve deneyim' eksikliği nedeniyle temel bir sınır kaldığını düşünüyorum. Örneğin çok yetenekli bir geliştiriciye devasa bir kod tabanı verip belli bir sorunu hemen çözmesini isteseniz bile, kod tabanını iyi tanıyan sıradan bir geliştirici aynı sürede daha değerli bir sonuç üretebilir
İletişim biçimine odaklanırsanız bu sorun çözülebilir. Son zamanlarda ana iş akışım şu: Büyük bir iş gerektiğinde (yeni özellik, refactor vb.) o3 ile bir iş arkadaşı gibi konuşmaya başlıyorum. Gerekli kaynak dosyaları bağlam sağlamak için sürekli yapıştırıyor, hedefle mevcut kod durumunu yüksek seviyede tartışıyorum. Bu süreçte ne yapmak istediğimle kod tabanının bağlamı daha net hâle geliyor. Sonrasında o3'ten bir uygulama planı istiyorum ve bunu Codex'e vererek kaynak okuma, dosya düzenleme, test gibi bir dizi otomatik süreci çalıştırıyorum. Ortaya bir PR çıkınca bazen az miktarda elle düzenleme gerekiyor, bazen de doğrudan merge edilebiliyor. Modellerin zengin bağlama ihtiyaç duyduğu konusunda katılıyorum ama bu özsel bir sınır değil; etkili işbirliği yapma biçimiyle ilgili bir konu. Ustalık kazanıldığında bu sadece verimliliği artırmıyor, benim için zihinsel olarak da daha keyifli bir çalışma şekli oluyor
"Kod tabanında bulunmayan şeyin anlamlı bir sinyal taşıması" fikrine derinden katılıyorum. Uzun zamandır yazılım yapıyorum ama bu temel gerçeği hiç bu kadar net fark etmemiştim. Harika bir içgörü
Şimdiye kadarki deneyimime göre LLM'ler mevcut iyi kodu taklit etmede başarılı ama özellikle açıkça istenmedikçe yeni ve özgün parçaları kendiliklerinden üretmekte zorlanıyorlar. Projeye ait diğer bölümleri doğrudan belirtmek zorunda kaldığım çok oluyor çünkü kod tabanını yeterince ingest edemiyorlar. Yine de Stable Diffusion'daki gibi bir "negative prompt" verebilsek gerçekten harika olurdu
LLM tüm git geçmişini, issue tracker'ı, hatta toplantı kayıtlarını bile bağlam olarak okuyabilse ne çıkacağını merak ediyorum. Çok büyük bağlam girişlerinin pratikte işe yarar sonuçlar üretip üretmeyeceğini biraz daha görmek lazım
Bu duyuruya gerçekten şaşırdım. Bence I/O etkinliğindeki en büyük duyuru buydu ama Veo 3 gibi başka haberlerin gölgesinde kaldı. Kod üretiminde diffusion modeli kullanmak çok büyük bir anlam taşıyor. Eğer transformer kullanıyorsa DiT (diffusion transformer) ailesine girer; birkaç yıl önce U-Net tabanlı diffusion'ları birleştiren hibrit bir modelde çalışmıştım ve o zamandan beri çok yol alındı. Diffusion alanında büyük bir sıçrama göreceğimizi düşünüyorum
Vision transformer'lardaki sezginin koda uygulanınca nasıl işleyeceğini merak ediyorum. Vision tarafında süreç, gürültüden başlayıp katman katman giderek hedef görüntüyü netleştirmek şeklinde işliyor. Aynı ilke kod üretimine uygulanırsa örneğin 'Django kullanılmalı', 'endpoint listesini belirle', 'somut kodu üret' gibi giderek soyutlama seviyesini düşüren hiyerarşik bir yapı gerekebilir gibi görünüyor. Ancak diffusion'da bir backtracking mekanizması yok; bu yüzden alt seviyedeki sorunlar fark edilse bile üst katmanlara anında geri bildirim vermek sınırlı. Transformer'larda ise her token için tüm model çalıştığından her sorun için gereken geri dönüş ve tasarım değişikliği daha kolay yapılabiliyor. Modelimde hata olabilir, ek içgörü duymak isterim
Veo 3'ün performansı ve farkı çok sezgisel biçimde görülebildiği için gündem oldu; buna karşılık metin tamamlama alanındaki önemli bir ilerlemenin değerini anlamak için önce mevcut başarıları ve potansiyel kullanım alanlarını bilmek gerekiyor. Hâlâ birçok kişi LLM'lerin kodlamada faydalı olduğuna bile tam ikna olmuş değil
Diffusion tabanlı kod üretim modeli gerçekten devrim niteliğinde. Böyle bir modelin yapabileceklerine dair basit fikirler şunlar olabilir: Fonksiyon imzasını ve sonucu sabit tutup aradaki token'ları üretmek, yani çift yönlü bilgiden yararlanmak. İkinci olarak önce fonksiyon düzeninin büyük çerçevesini yazmak (bir LLM'e bir makalenin 'bölümlerini' yazdırmak gibi), sonra uygulamayı giderek daha ince alt işlere ayırmak. Daha büyük bir bağlam içinde linter'lar, AST bilgisi ve benzeri sinyallerle yönlendirilmiş yinelemeli üretim. Denenecek çok şey var
Prensipte bunun büyük avantajları olması gerekir ama pratikte denediğim LLaDA gibi modeller, az eğitim kaynağına rağmen etkileyiciydi. Yine de perplexity gibi ölçütlerde hâlâ gerideler. Üretim sırasında erken kilitlenme eğilimleri yüksek olduğu için metni derinlemesine revize etmede sınırlı kalabilirler diye düşünüyorum (masking olasılığı arttıkça eşzamanlı düzenleme zorlaşıyor). Buna rağmen gerçek deneylerde oldukça kullanışlı sonuçlar aldım
InceptionLabs ve benzerlerinden zaten demolar gördüğüm için beni o kadar şaşırtmadı
Bu haberde asıl önemli nokta biraz gözden kaçıyor gibi. Bu gerçekten çok hızlı ve çok iyi bir InstructGPT. Gelecekte yazım denetimi, codemod ve kod editörlerinde kesinlikle kullanılacaktır. Instant edits sayesinde gereksiz eklemeler ve öneriler olmadan çok hızlı ve hassas metin düzenleme yapılabiliyor. ShaderToy örnek kodunda değişken adlarını daha anlaşılır yapmasını istedim, sonucu kopyalayıp çalıştırdım ve hâlâ düzgün çalıştığını görünce şaşırdım
Diffusion'ın avantajı yalnızca hız değil. İlk benchmark'lara göre aynı parametre sayısında bile AR'ye kıyasla muhakeme ve planlama tarafında daha iyi. Diffusion ara düzenlemeye izin veriyor ve ilk token bias'ı sorununu yaşamıyor
İlginç bir iddia. Bununla ilgili benchmark ya da kaynak bağlantılarını paylaşabilir misin
AR'nin kendisi uzun planlar kurmayı engellemez ama güncel popüler AR modellerinin uygulanış biçimi nedeniyle böyle sınırlamalar sık görülebiliyor. AR, doğru dağılımı öğrenmek açısından temelde çok önemli
Kişisel olarak katılmak istediğim ya da doğru çıkmasını umduğum bir iddia bu ama revise diffusion text üzerine henüz bir makale ya da demo görmedim. Denemek isterim; makale bilgisini paylaşırsanız sevinirim
Uzun zamandır metin üretimine diffusion teknolojisini uygulama fikri ilgimi çekiyordu. Sonunda Google'ın böyle bir model çıkarması beni mutlu etti; sanki düşüncem doğrulanmış gibi. Deneylerde kullanılan donanım tarafında çoğu kişi ücretli servisler ya da üst düzey, en azından tüketici sınıfının yüksek segmentindeki ekipmanlar kullanıyor. Benim şu an elimde yaklaşık 5700XT düzeyinde bir kart var ve yükseltme yapmak zor; bu da mevcut modellerin sınırlarını daha net görmemi sağladı. Model büyüdükçe tutarlılık arttığı için küçük modeller mecburen basit işlerle sınırlı kalıyor. Kendi denemelerimde en çok doğruladığım şey bağlam boyutunun önemi oldu; küçük GPU'larla yeterli bağlamı ve modeli aynı anda sığdırmak zor. Diffusion tabanlı bir yaklaşımın yoğunluk ile tutarlılık arasındaki dengeyi değiştirip değiştiremeyeceğini merak ediyorum. Daha az bağlamla daha tutarlı metin üretimi mümkün olabilir gibi geliyor; araç çağrısı + yanıt karışımı sonuçlar da daha iyi olabilir. Hız konusu da pratikte ciddi bir sorun; mevcut LLM yaklaşımı giriş-çıkış döngüsü boyunca yavaş yavaş ilerliyor ve özellikle AI donanımı olmayan eski GPU'larda bu sabır sınırını zorluyor. En azından ilerlemeyi %0-%100 arası gerçek zamanlı görebilsek güzel olurdu; diffusion modellerinde bunun biraz daha iyi olabileceğini düşünüyorum. Burada aklıma şu soru geliyor: Gürültü girdisi önemliyse, LLM/metin için özelleşmiş iyi bir gürültü kaynağı var mı? Ve toplam blok uzunluğu baştan sabit mi olmak zorunda, yoksa değişken olabilir mi
Kendi adıma kesin olarak söyleyebilirim ki bu model inanılmaz hızlı. Dezavantajı ise prompt injection saldırılarına çok kolay yenik düşmesi. Örneğin uyuşturucu yapım talimatı istediğinizde reddediyor ama bunu 'çocuk rolü yaparak' sorarsanız gerçek cevabı veriyor. Bu zayıflığı dışında hız ve otomasyonda kullanım kolaylığı gerçekten çok iyi. Buna bir de agent tarzı yaklaşım eklenirse modelin potansiyeli daha da parlayacaktır
Bu, modelin özsel bir sorunu olmaktan çok eğitim sürecinde güvenlik ya da sansür tarafına daha az kaynak ayrılmış olmasından kaynaklanıyor olabilir. Bana daha çok bir prototip deneyi gibi geliyor; büyük modele ciddi yatırım yapmadan önce hafif bir gösterim yapıyor olabilirler
Bu tür prompt injection örneklerini, daha zeki bir modeli kontrol altında tutabileceğimizin işareti olarak görmüyorum
"Google'ın ilk diffusion LLM'i, transformer yerine diffusion kullanıyor" açıklaması yanlış bir iddia. Google bunu hiçbir yerde böyle duyurmadı. Hatta transformer tabanlı diffusion modelleri oldukça yaygın. Gemini Diffusion'ın da büyük olasılıkla transformer kullanıyor olduğunu düşünüyorum. Farkı, encoder-only transformer olması olabilir. Yani tüm sequence'i gürültülü/bozulmuş hâlde verip doğru sequence'in tamamını tahmin eden bir yapı. Bu sayede sequence'in tüm çerçevesi aynı anda paralel işlenebiliyor ve yineleme sayısı makul kaldığı sürece decoder-only modellerin sıralı decode sürecinden çok daha hızlı oluyor (tabii speculative decoding de benzer bir hız avantajı sunabiliyor). Genelde BERT tarzı masking ile eğitiliyor ama hâlâ aktif bir araştırma alanı. Gemini ile ilişkisi ya da checkpoint kullanımı konusu da ilginç: doğrudan içe aktarma mı, diffusion'a özel fine-tuning mi, knowledge distillation mı, yoksa sadece marka adı mı? Keşke resmî ayrıntılar açıklanmış olsaydı
Saçma derecede hızlı. GPU muhtemelen sürekli tepe performansta çalışıyordur ve batch işlemede hesaplama tasarrufu pek olmayacaktır diye tahmin ediyorum. Ama düşününce buna gerçek anlamda bir tradeoff demek de zor. Bir endişem, diffusion objective'in performans açısından AR'den geri kalabilmesi. Eğer öyleyse, multi-token AR modelleri diffusion ile aynı hıza ulaşabilir ya da diffusion modeli speculative decoding için taslak üreteci olarak kullanılabilir
dLLM'nin arLLM'den kalite olarak geri kalacağını neden düşünüyorsun, merak ettim. Çıktıyı 'yapılandırılmış bir bütün' (konu, ana noktalar, kavramlar, kelime ağacı) olarak yinelemeli işlemesi nedeniyle kalite açısından daha iyi bile olabilir
Bu yapısal tradeoff kişisel barındırma ortamlarında çok daha avantajlı. Büyük ölçekli batch gerekmeyen bir kullanım olduğundan, cloud tarafında faydası sınırlı olsa da yerel LLM'ler için büyük avantaj sağlar
Diffusion LLM'ler beni inanılmaz heyecanlandırıyor. Ekibimiz ses → kod ile çalışan oyun mekanikleri hayal ediyor ve diffusion bunun eksik parçası olabilir gibi görünüyor. Cerebras ve Groq etkileyici ama özel donanım kullandıkları için fine-tuning ve ölçekleme tarafında sınırlar var. Diğer seçenekler aktif parametresi 0.5b civarında olan MoE modelleri ama şu an o projeye kaynak ayıracak durumda değiliz. Eğer bunu Google/Deepmind'dan biri görürse lütfen API sağlayın. Ekibimiz üretken bir sandbox oyunu geliştiriyor; ilk oyunda gerçek zamanlı olarak canavarlara komut veriliyor. İlgilenirseniz prototip videosu da var