DiffusionGemma: 4 kat daha hızlı metin üretimi

 (blog.google)
3 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • DiffusionGemma, tüm metin bloklarını aynı anda üreten metin difüzyonu yaklaşımına sahip, Apache 2.0 lisanslı deneysel bir açık 26B MoE modelidir
  • Tipik otoregresif LLM’lerin sıralı token üretimi yerine 256 token paralel üretim kullanarak, özel GPU’larda en fazla 4 kat daha hızlı metin üretimi sunar
  • Çıkarım sırasında toplam 26B içinden yalnızca 3.8B parametre etkinleşir; kuantize edildiğinde 18GB VRAM sınırı içinde ileri seviye tüketici sınıfı özel GPU’lara uygun şekilde çalışır
  • Çift yönlü attention ve yinelemeli kendi kendini düzeltme sayesinde satır içi düzenleme, kod tamamlama, amino asit dizileri ve matematik grafikleri gibi doğrusal olmayan yapı içeren işlerde avantaj sağlar
  • Hız ve paralel yerleşim üretimini önceliklendiren deneysel bir model olduğundan, genel çıktı kalitesi standart Gemma 4’ten daha düşüktür; en yüksek kalitenin gerektiği uygulamalar için standart Gemma 4 dağıtımı önerilir

Geliştiriciler için yeni değer

  • DiffusionGemma, metin difüzyonunu araştıran deneysel bir açık modeldir ve tipik otoregresif LLM’lerin token token sıralı işlemesinin ötesine geçerek tüm metin bloklarını aynı anda üretir
  • Bu model, Apache 2.0 lisansı ile sunulan 26B Mixture of Experts (MoE) modelidir ve GPU’larda en fazla 4 kat daha hızlı metin üretimi sağlar
  • Gemma 4 ailesinin parametre başına zekâsı ile Gemini Diffusion research temel alınmış, üretim hızını en üst düzeye çıkarmak için yeni bir difüzyon head’i entegre edilmiştir
  • Otoregresif Gemma 4 modelleri, yüksek kaliteli üretim çıktıları için standart olmaya devam ederken DiffusionGemma, hızın kritik olduğu etkileşimli yerel iş akışlarını araştıran araştırmacılar ve geliştiriciler için tasarlanmıştır

  • Temel ödünleşimler

    • Hızlı çıkarım, çözümleme darboğazını bellek bant genişliğinden hesaplamaya kaydırarak özel GPU’larda token çıktısını en fazla 4 kat hızlandırır
    • Tek bir NVIDIA H100 üzerinde saniyede 1000’den fazla token, NVIDIA GeForce RTX 5090 üzerinde saniyede 700’den fazla token üretir
    • Donanım erişilebilirliği, toplam 26B MoE içinde çıkarım sırasında yalnızca 3.8B parametrenin etkinleştiği yapıdan gelir
    • Kuantize edildiğinde ileri seviye tüketici sınıfı özel GPU’ların 18GB VRAM sınırı içine sığar
    • Çift yönlü attention, her ileri geçişte 256 tokeni paralel üretir ve tüm tokenlerin birbirini referans alabilmesini sağlar
    • Satır içi düzenleme, kod tamamlama, amino asit dizileri ve matematik grafikleri gibi doğrusal olmayan alanlarda avantaj sağlar
    • Kendi kendini düzeltme, modelin tüm metin bloğunu tek seferde değerlendirerek hatalarını gerçek zamanlı olarak düzeltmek için çıktıyı yinelemeli biçimde rafine etmesidir
    • Deneysel durumu ve üretim önerisi nettir; hız ve paralel yerleşim üretimi önceliklendirildiği için genel çıktı kalitesi standart Gemma 4’ten düşüktür

  • İnce ayar örneği

    • Belirli görev performansı ince ayar ile geliştirilebilir
    • Unsloth, DiffusionGemma’yı sudoku çözmesi için ince ayar yaptı; sudoku, her tokenin gelecekteki tokenlere bağımlı olması nedeniyle otoregresif modellerin zorlandığı bir görevdir
    • DiffusionGemma’nın çift yönlü attention yapısı, sudoku gibi görevleri çok daha kolay hâle getirir

Metinde neden difüzyon kullanılıyor?

  • Yapay zeka araştırma topluluğu yıllardır difüzyon tabanlı metin üretimini araştırıyor, ancak bunu büyük modellere uygulamak zorlu bir problem olarak kalıyordu
  • DiffusionGemma, modelin donanımı kullanma biçimini değiştirerek bu sorunu ele alıyor

  • Mevcut modellerle ödünleşimler

    • Çoğu dil modeli, daktilo gibi soldan sağa doğru her seferinde bir token üretir
    • Bulutta bu yaklaşım verimlidir, çünkü sunucular binlerce kullanıcı isteğini birlikte batch işleyerek donanım yükünü paylaşabilir
    • Tek bir kullanıcı yerelde çalıştırdığında, kelime kelime üretim özel GPU veya TPU’yu yeterince kullanamaz ve donanım bir sonraki “tuş vuruşunu” beklerken uzun süre boşta kalır
    • DiffusionGemma, 256 tokenlik bir paragrafın tamamını aynı anda taslak hâline getirerek bilgisayar işlemcisine tek seferde daha büyük iş parçaları verir
    • Bu yapı, model çıkarımını sıralı bir daktilodan tüm metin bloklarını aynı anda basan büyük bir matbaaya dönüştürür

  • Yerel ve düşük eşzamanlı çıkarım için hız artışı

    • DiffusionGemma’nın hız kazanımı, yerel çıkarım ve düşük eşzamanlı çıkarım için tasarlanmıştır
    • Yüksek QPS’li bulut sunumunda, otoregresif modeller de hesaplamayı verimli biçimde doyuracak şekilde dağıtılabilir
    • Yüksek QPS ortamlarında DiffusionGemma’nın paralel çözümleme avantajı azalır ve sunum maliyeti daha yüksek olabilir
    • İşleme hacmi avantajı, tek hızlandırıcıda düşükten orta batch boyutlarına kadar en güçlü durumdadır

Metin difüzyonu nasıl çalışır?

  • Metin difüzyonu, görsel gürültüden başlayıp net bir görüntüye yinelemeli olarak iyileşen yapay zeka görüntü üretimine benzer bir süreci metne uygular
  • İlk aşama olan tuvalde, model rastgele placeholder tokenlerden oluşan bir tuvalle başlar
  • Yinelemeli iyileştirme aşamasında model birden çok geçiş yapar, doğru tokenleri sabitler ve bunları geri kalan kısmı rafine etmek için bağlamsal ipuçları olarak kullanır
  • Son rötuş aşamasında metin yüksek kaliteli çıktıya yakınsar
  • Model üretim sırasında paragrafın tamamını işleyebildiği için karmaşık Markdown biçimlendirmesini doğru şekilde kapatma ya da kodu neredeyse gerçek zamanlı olarak üretip render etme gibi davranış kalıpları mümkün olur

Nasıl başlanır?

  • Deneysel model ağırlıkları, izin verici Apache 2.0 lisansıyla sunuluyor ve Hugging Face üzerinden erişilebiliyor
  • DiffusionGemma developer guide üzerinden entegrasyon yöntemleri görülebilir; A Visual Guide to DiffusionGemma ile iç mekanizmalar daha derinlemesine incelenebilir
  • Model sunumu MLX, vLLM, Hugging Face Transformers kullanılarak yapılabilir
  • vLLM entegrasyonu Red Hat tarafından desteklenmektedir
  • Hızlı deneyler için, birleştirilebilirlik odaklı modüler JAX araç kutusu Hackable Diffusion tabanlı ince ayar öğreticisi sunulmaktadır
  • İnce ayar ayrıca Unsloth ve NVIDIA NeMo ile de araştırılabilir
  • llama.cpp için resmî destek yakında sunulacaktır

Optimizasyon ve çalışma ortamı

  • NVIDIA ile iş birliği sayesinde donanım yığınının tamamında optimizasyon yapıldı; bu da hem tüketici ortamlarında hem de kurumsal sistemlerde uyumluluk ve performans sağlıyor
  • Tüketici ortamında GeForce RTX 5090 ve 4090 GPU’ları için kuantizasyon desteği bulunuyor
  • Kurumsal ortamda, gelişmiş NVFP4 kernel’leri kullanan Hopper ve Blackwell üzerinde yüksek performans sunuluyor
  • Yerel masaüstü dağıtımları için NVIDIA DGX Spark ve DGX Station ile, yapay zeka uzmanlarına yönelik RTX PRO da hedefler arasında yer alıyor
  • NVFP4 4 bit kayan nokta yerel desteği, hesaplama verimini hızlandırarak modelin daha yüksek hızda ve neredeyse kayıpsız doğrulukla çalışmasını sağlıyor
  • Çalıştırma seçenekleri arasında masaüstü özel GPU’lar, Gemini Enterprise Agent Platform Model Garden, NVIDIA NIM bulunuyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • Kısa süre önce OpenCode'a geçip ABD'nin önde gelen frontier araştırma laboratuvarları dışındaki pek çok modeli denedim; beklenmedik şekilde en çok hoşuma giden model Mercury oldu
    Bunun sebebi “daha zeki” olması değil, inanılmaz derecede hızlı olmasıydı. Prompt girip beklediğin güncel ajan tarzı deneyimden çok eşli programlamaya yakındı; yapay zekanın avantajlarını alırken yapay zeka öncesi kodlama hissinin bir kısmını da geri getirdiği için daha eğlenceliydi. Prompt girip beklerken yönün doğru çıkmasını umduğun bir slot makinesi gibi değildi; Gemini Flash Lite ya da GPT Mini/Nano gibi küçük modelleri de daha sık kullanır oldum. Açık ağırlıklı modelin çıkması heyecan verici, çıkar çıkmaz deneyeceğim

    • Testleri hızlı ve ucuza çalıştırabiliyor ve kötü ya da özensiz yazılmış kodu ayırt eden düşük maliyetli ölçütleri de hızlıca oluşturabiliyorsanız, zaman önemli olduğunda yavaş ama çok daha iyi bir modeldense hızlı ama biraz daha zayıf bir model daha iyi olabilir
      Döngüsel karmaşıklık değil gerçek karmaşıklığı ölçen bir ölçüt koyup, işlevselliğe kıyasla eklenen karmaşıklık makul aralığa girene kadar otomatik geri aldırdığımda, LLM kullanımında oldukça iyi sonuçlar aldım
    • Mercury-2 harika. llm-consortium'da hakem olarak sık kullanıyorum
      Bağlam penceresi görece küçük olduğu için daha büyük bir konsorsiyumda kullanmak isterseniz özyinelemeli bir meta-konsorsiyum gibi kurabilirsiniz:
      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
      Artık cns-meta-glm-kimi'ye prompt verdiğinizde, kimi ve glm içinden ayrı ayrı 5 adayın en iyisini seçip ardından iki kazanan yanıtı sentezliyor
    • Bunun kodlama için yerel modelleri ne kadar etkileyeceğini merak ediyorum. Qwen ya da Gemma 4'ten birkaç kat hızlı bir diffusion modeli kullanırsam yapay zeka öncesindeki gibi benim daha çok hazırlık yapmam gerekecek, ama bu aslında iyi bir şey olabilir ve yerelde çok hızlı, çok ucuz bir modelle çalışabilirim gibi geliyor
      Uzun ve ağır hesaplamalar yapmıyorsanız, yerel donanımda çalıştırmanın maliyeti de daha ucuz olmaz mı diye düşünüyorum
    • Ne demek istediğini tam olarak anlıyorum. Kişisel projemde Claude çok yavaş olduğu için bunaldım ve Google Antigravity ile Flash modellerine geçtim; hız farkı muazzam
      Akışa daha iyi giriyorum ve işe daha çok odaklanıyorum. Hızın bu kadar büyük fark yarattığını fark etmemiştim. Claude, çok karmaşık ve büyük kod tabanlarında yavaş yanıt süresine karşılık görev karmaşıklığını üstlenebildiği için hâlâ değerli olabilir; ama Antigravity ya da diğer hızlı modeller, küçük ve hafif biçimde kod yazma, çalıştırma ve hata ayıklamayı yinelemek istediğinizde çok daha uygun
    • Evet, kilit nokta hız. Boilerplate POJO'ları veya veri sınıflarını 300+ tok/s gibi çılgın bir hızla üretmesi harika; böyle olunca Flash-Lite, GPT-5.5'ten daha kullanışlı oluyor
      Fazla yavaş olursa o lanet olası asenkron bekleme döngüsüne hapsoluyorsun

  • Google gücünü göstermeye devam ediyor. Gemini'nin kod ya da ajan kullanımında Claude veya OpenAI modellerinden daha rekabetçi olmaması şaşırtıcı, ama Google'da hâlâ sektörün en üst düzey yapay zeka yeteneğinin bulunduğu açık
    Yine de Google, büyük düşünme odaklı LLM'lerden çok telefonda çalışan ya da neredeyse gerçek zamanlı kullanım senaryolarına odaklanıyor gibi görünüyor. Bu tür verimlilik iyileştirmeleri, gelecekte yapay zeka için çok önemli olabilir. Belirli ekosistemlere bağlamak için token'ları sübvansiyon gibi ucuza verme dönemi bitiyor; gerçek maliyetin ödenmesi gereken zaman geliyor. Gerçekten akıllı modelleri maliyet açısından verimli şekilde çalıştırmanın yolunu bulan şirket kazanacak. DeepSeek, GPT 5.5 ya da Opus 4.8'den tek haneli katlarla daha ucuz ve ikisinden de daha kötü olsa da felaket derecede kötü değil. En iyi kodlama modeli gerçekten insan zamanından yeterince tasarruf ettiriyorsa 10 kat fazla ödemeye razıyım; ama yakın dönem benchmark'larda GPT 5.5 Pro'nun DeepSeek'ten 200 kattan fazla, Opus 4.8'den ise yaklaşık 30 kat pahalı olduğu durumlar gibi 100 kat farkı kabul etmek zor

    • Fable, Opus'un iki katı maliyette ve GPT-Pro ile de epey rekabetçi görünüyor; aşırı hassas güvenlik önlemleri büyük sorun değilse fena bir seçenek olmayabilir
      Google'ın da bu alanda kendi “Deep Research” seçeneği var ve iyi çalışıyor gibi görünüyor. DeepSeek'in güzel yanı, API maliyeti olmadan yerel donanımda çalıştırılabilmesi. Buna önem veriyorsanız, Opus ya da GPT'den biraz daha zayıf olması büyük bir mesele değil
    • Sonunda Google kazanacak gibi geliyor. Watt başına performans ve dolar başına performans gibi kritik noktalara odaklanıyor
      Kendi çıkarım donanımını üretiyor ve gecikme ile hesaplama ek yükünü azaltan edge computing'e yöneliyor. Büyük LLM'ler hâlâ maliyet açısından verimli değil ve Google, rakiplerinin tüketiciye maliyetin altında “satmak” için yatırım parasını yakmasına izin veriyor. AI balonu patladıktan sonra bile Google gibi şirketler sapasağlam ayakta kalacaktır; bu balon da sanki bazı dev şirketlerin dış kabuğunu soymaya yarıyor gibi görünüyor

  • Bazı tepkiler difüzyon yaklaşımının avantajlarını gözden kaçırıyor. Telefon veya bilgisayar GPU'su gibi edge cihazlarda büyük etkisi olabilir.
    LLM'nin decoder'ı önceki tokenların tamamını hesaba katmak zorunda olduğu için tokenları tek tek hesaplar. Mevcut LLM decoder'ları, birden çok çıkarımı batch halinde gruplayacak kadar yük olduğunda iyi ölçeklenir ve o ortamda difüzyonun avantajı sınırlıdır. Edge tarafında durum farklıdır. Çıkarım hızlandırıcısı, RAM'den GB düzeyindeki ağırlıkları sürekli taşımak zorunda kaldığı için aç kalır. LPDDRx/GDDRx gibi tüketici tipi RAM'ler HBM'den daha düşük bant genişliğine sahiptir ve istekler seri olduğu için ortak ağırlık hesaplamaları batch halinde gruplanamaz. Difüzyon, tokenları paralel hesaplayabildiği için bellek bant genişliği darboğazını hafifletir.

    • Edge cihazlarda yalnızca bellek bant genişliği eksik değil, hesaplama performansı da çok sınırlı. Pratikte çok fazla batch olmasa bile kullanılabilir işlem miktarı hızla doyar ve belirgin ısı/güç sınırlarına takılır.
      Edge çıkarımında “istekler doğası gereği seri” demek de aslında doğru değil. Aynı anda birden fazla istek, yani birden fazla sohbet yürür; KV cache'i tutacak yeterli bellek kapasitesi varsa batch işleme uygulanabilir. Eğer difüzyon modeli daha fazla hesaplamayla daha düşük kalite üretiyor ve bellek bant genişliği tasarrufu da belirsiz kalıyorsa, bunun nasıl yardımcı olduğunu pek anlayamıyorum.
    • Genel olarak doğru, ama attention ile otoregresif/nedensel yapıyı birbirine karıştırıyor. Daha fazla hesaplama kullanılmasını gerçekten engelleyen sorun otoregresif/nedensel yapı.
      Difüzyonda da attention kullanılabilir ve bu model de gerçekten attention kullanıyor.

  • NVIDIA bu model için ücretsiz bir endpoint sunuyor. Ayrıntılar https://build.nvidia.com/google/diffusiongemma-26b-a4b-it adresinde; hesap açmak ve muhtemelen telefon numarası doğrulaması yapmak gerekiyor.
    Ona bir pelikan da çizdirdim: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...

    • Yeterince hızlı bir modelse animasyon kareleri istemek de mümkün olabilir. Örneğin 1. karede sağ ayak 12 yönünde, sol ayak 6 yönünde; 2. karede sağ ayak 3 yönünde, sol ayak 9 yönünde gibi.
      O zaman saniyedeki token sayısını değil, doğal olarak saniyedeki pelikan karesi sayısını raporlamak gerekir.
    • Birkaç hafta önce kaydoldum ama adımları izlememe rağmen hesabım hâlâ doğrulanmadı. Hesap doğrulanmazsa API kullanılamıyor.

  • DiffusionGemma gibi metin difüzyon modellerinin nasıl çalıştığını gösteren iyi bir görsel anlatım: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

  • Daha birkaç gün öncesine kadar Google'ın, 1 yıl önce I/O'da gösterdikten sonra difüzyon metin üretim modeli hakkında hiçbir şey söylemediğini düşünüyordum.
    Çalıştırmanın fazla pahalı olduğuna dair söylentiler vardı ama verilen grafikte olduğu gibi aynı 1x H100 donanımında DiffusionGemma ile normal Gemma karşılaştırılıyorsa öyle görünmüyor. Gemma'dan biraz daha zayıf olması dışında bu hızın dezavantajının ne olduğunu merak ediyorum.

    • “Bu hızın dezavantajının ne olduğunu merak ediyorum” sorusunun cevabı şu kısım gibi görünüyor:
      “DiffusionGemma'nın hız artışı, yerel ve düşük eşzamanlılıklı çıkarım için tasarlandı. Yüksek QPS'li cloud serving'de otoregresif modeller verimli biçimde batch'lenerek hesaplama doyurulabildiğinden, DiffusionGemma'nın paralel decoding avantajı azalır ve serving maliyeti daha yüksek olabilir.”
    • Standart bir otoregresif model ile örneğin 256 kullanıcı varken aynı anda 256 token üretilebilir. Bu yöntem tek bir kullanıcı için 256 token üretebilir ama bunun için birden çok forward pass adımı gerekir.
      Bu yüzden difüzyon süreci daha fazla GFLOPs kullanır ve kullanıcı sayısı yeterince fazlaysa bellek ile hesaplama arasında denge zaten kurulabilir.

  • “DiffusionGemma bu verimsizliği tersine çeviriyor. Kelimeleri sırayla tahmin etmek yerine, 256 tokenlık paragrafın tamamının taslağını aynı anda oluşturuyor. Bilgisayar işlemcisine tek seferde daha büyük iş parçaları vererek donanımdan azami fayda sağlıyor. Model çıkarımını harf harf yazan bir daktilodan, tüm metin bloklarını aynı anda basan dev bir matbaaya yükseltiyor.”
    “Çıkarım sırasında yalnızca 3.8B parametreyi etkinleştiren, toplam 26B boyutunda bir uzman karışımı (MoE) modeli olarak çalışıyor ve kuantize edildiğinde üst seviye tüketici tipi özel GPU'ların 18GB VRAM sınırına rahatça sığıyor.”
    Yani Gemma 4 26B, ollama ile benim 24GB GPU'mda çok hızlı çalışan bir MoE modeli. Bu kulağa speculative decoding gibi geliyor ama MoE modellerinde bunun çalışmadığını sanıyordum. Bunu işi olmayan biri için değişim hızı takip etmeyi zorlaştıracak kadar yüksek.

    • Bu, kafa karıştırıcı biçimde mevcut gemma4 MoE ile neredeyse aynı parametre sayısına sahip farklı bir model. Hızlıca göz atınca ikisinden birinin diğerinden nasıl eğitildiği net değil.
      Mekanizma speculative decoding ile aynı değil. Speculative decoding sıralı ilerler, genelde birkaç tokenlık adımlarla. Difüzyon ise böyle değil; metin bloğunu tek seferde ele alıyor. Belgeleri henüz okumadım ama difüzyon bloğunun tamamında belirli uzmanların tutarlı kalması için eğitilmiş olduğunu tahmin ediyorum.

  • Benim 3090 Ti üzerinde reklamı yapılan hızın yakınına bile çıkmıyor ama yanıtı “doldura doldura” oluşturmasını izlemek eğlenceli.
    Simon'ın “bisiklete binen SVG pelikan” testini denedim; sonuç oldukça minimalistti ama gereksinimleri karşıladı: https://gist.github.com/peterc/7672e74ec1437945e5fca5ce2c1c9... -- patch'lenmiş llama.cpp üzerinde Q4 kuantizasyonuyla çalıştırıldı. Simon'ın sonucunun ne kadar farklı olduğunu da merak ediyorum.

  • Difüzyon tabanlı muhakeme modeli nasıl bir şey olurdu? Önceden belirlenmiş uzunlukta bir [thinking] bloğunu uzun süre difüze edip, son çıktı bloğu da o thinking bloğunun içeriğini girdinin bir parçası olarak kullanmak gibi mi?
    Bir de difüzyon modeli en başta çıktı uzunluğunu nasıl belirliyor? Önceden belirlenmiş bir parametre mi, yoksa arada bir yerde [end] token’ını mı difüze ediyor, merak ediyorum.

  • Etkileyici ama yerel modeller, zaten fena olmasalar bile, en ucuz API’den bile hissedilir biçimde geri kalıyor; bu yüzden hız uğruna kaliteden biraz bile ödün verme fikri bana çok cazip gelmiyor.
    Bazı kullanım senaryolarında kesinlikle değeri vardır ama gerçekten prodüksiyona alınacak somut örneklerin neler olduğunu merak ediyorum.

    • Birim testi yazımı ya da bootstrap için uygun olabilir.
      Opus seviyesinde olmasa da yazabilir ve yinelemesi kolaydır.