Mercury - Diffusion tabanlı ultra hızlı dil modeli

 (arxiv.org)
10 puan yazan GN⁺ 2025-07-08 | 1 yorum | WhatsApp'ta paylaş
  • Mercury, diffusion yaklaşımını kullanan yeni bir ticari büyük dil modeli (LLM)
  • Bu model, birden fazla token'ı paralel olarak tahmin etmesiyle öne çıkan Transformer yapısı üzerine kuruludur
  • Mercury Coder, ilk diffusion LLM seti olup kod yazımı için geliştirilmiştir ve Mini ile Small olmak üzere iki boyutta sunulur
  • NVIDIA H100 GPU üzerinde saniyede 1109 (Mini), 737 (Small) token işleme hacmine ulaşır ve aynı kalite düzeyinde mevcut hız odaklı modellere kıyasla 10 kata kadar daha hızlı performans gösterir
  • Gerçek kullanım benchmark'ları ve Copilot Arena gibi geliştirici değerlendirmelerinde de kalitede 2. sıra ve hızda en üst seviye sonuçlar elde etmiş olup, açık API ve playground da sunar

Genel Bakış

  • Mercury, diffusion tabanlı yeni bir büyük dil modeli serisi olup ticari ölçekte çalışan yeni nesil bir LLM'dir
  • Tüm modeller, Transformer mimarisi ile parametrize edilmiştir ve birden fazla token'ı paralel olarak tahmin edecek şekilde eğitilmiştir
  • Bu rapor, ağırlıklı olarak kod üretim uygulamaları için tasarlanan Mercury Coder'ın ilk ürün ailesini tanıtmaktadır
  • Mercury Coder şu anda Mini ve Small olmak üzere iki model boyutunda sunulmaktadır

Başlıca katkılar

  • Mercury Coder, hız ve kalite dengesi açısından yeni bir state-of-the-art seviyesine ulaşmaktadır
  • Harici değerlendirme kurumu Artificial Analysis ölçümlerine göre:
    • Mercury Coder Mini: saniyede 1109 token
    • Mercury Coder Small: NVIDIA H100 GPU üzerinde saniyede 737 token performansına ulaşmaktadır
    • En hızlı frontier modellere kıyasla benzer kaliteyle ortalama 10 kata kadar daha hızlıdır
  • Farklı programlama dilleri ve kullanım senaryolarındaki kod benchmark'ları için ek değerlendirme sonuçları da sunulmaktadır
  • Gerçek geliştirici ortamlarında (Copilot Arena) da
    • kalite sıralamasında 2.
    • hız sıralamasında genel 1. olmuştur
  • Herkesin kullanabileceği açık API ( platform.inceptionlabs.ai ) ve ücretsiz sohbet playground'u ( chat.inceptionlabs.ai ) desteklenmektedir

İçindekiler yapısı açıklaması

  • Introduction(Giriş)
    • Contributions(Başlıca katkılar)
  • Inception Mercury Model Family(model ailesinin açıklaması)
    • Training(Eğitim süreci)
    • Inference(çıkarım yöntemi)
  • Capabilities(model yetenekleri)
    • Baselines(temel karşılaştırmalar)
    • Coding Capabilities(kod üretim yetenekleri)
      • Evaluation Benchmarks(değerlendirme benchmark'ları)

Özet

  • Mercury, yenilikçi diffusion tabanlı LLM tasarımı ile paralel tahmin yapısını birleştirerek kod üretimi alanında ezici hız ve yüksek kalite sunar
  • Farklı model boyutları, güçlü gerçek hizmet benchmark'ları ve kolay erişilebilirliğiyle hem ticari hem de geliştirme ortamları için rekabetçi bir seçenek sunar

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-08
Hacker News görüşleri

  • LLM ajanlarının devreye girmesiyle test performansının daha da ciddi bir CPU darboğazına dönüşeceği, zaten şu anda da tüm ekiplerin CI hızı nedeniyle darboğaz yaşadığı vurgulanıyor
    Ajanlar insanlardan 100 kat hızlı kod yazsa bile, testler bir saat sürüyorsa bunun bir anlamı yok
    Çalıştığım birçok projede değişikliklerin yansımasını beklerken çok fazla geliştirici zamanı boşa gidiyordu ve birçok çalıştırma I/O veya yetersiz worker sayısı nedeniyle tıkanıyordu
    Kodlama ajanları basit ticket'ları hızla PR'a çevirip test başarısızlıklarına anlık tepki vererek düzeltme yaparken, CI darboğazı daha da kötüleşecek
    Çoğu projenin test ortamında iyileştirme için büyük alan var ama pratikte yıllardır kayda değer ilerleme olmadan yavaş CI ve yüksek maliyet kanıksanmış durumda
    Build'leri tamamen izole etmek için cache'i kapatmak ya da on-premise ortamdan yavaş cloud VM'lere geçmek yüzünden CI daha da yavaşlıyor
    Mercury'nin hızı inanılmaz derecede yüksek ve birkaç denememde kod kalitesi de harika, doğru sonuçlar veriyordu; ama şimdi asıl mesele test çalıştırmayı da bu hıza yetiştirmek

    • Çalıştığım projelerin çoğunda PR onayı beklerken geliştirici zamanının boşa gittiği fikri bana çok ikna edici gelmiyor
      Şirket açısından geliştirici zamanı makine zamanından çok daha pahalıdır; geliştiriciler şikayet ediyorsa CI worker sayısını iki katına çıkarmak çözülebilir bir meseledir
      Google'da test kararsızlığını debug ederken nadir görülen hataları bulmak için 10 bin makinede testleri 10 bin kez çalıştırdıkları oluyordu
      Şu anki iş yerim de benzer bir yaklaşım sunuyor; tek komutla tüm testleri 1000 worker üzerinde paralel çalıştırabiliyor, böylece 1M LOC'lik projede bile 5 dakika içinde geri bildirim almayı hedefliyor
      Build'i tamamen izole etmek ile cache kullanmamak aynı şey değil; build'i tamamen izole ederken bile mümkün olan tüm cache'lerden yararlanmak gerekir

    • Uygulama hızı artarsa darboğazın PM tarafına kayması beklenebilir ve bu durumda değişiklikler daha seri değil daha sıralı işlendiği için çakışmalar büyük ölçüde azalabilir
      Spesifikasyon tanım dillerinin (TLA+ vb.) yeniden canlanma ihtimali de var; ajanlar bunları hızla yazıp doğrulayabildiği için toplam entegrasyon testi sayısı azalabilir
      Arka plan ajanları yinelenen kodu temizlerken yinelenen testleri de temizleyebilir
      Yapay zeka, insan mühendis ekiplerinden farklı olarak monolitik yapıda daha verimli çalışıyor gibi görünüyor; bu da lokalde çalıştırılabilen test kapsamını artırarak flaky testleri azaltabilir ve CI yükünü düşürebilir
      Yapay zeka verimliliği artırsa bile buna paralel olarak daha fazla kod, daha hızlı kod üretimi ve çalıştırma nedeniyle yeni sorunlar ortaya çıkacak; insan mühendislerin çözmesi gereken yeni problemler sürekli doğacaktır

    • LLM'ler 100 satırdan kısa hızlı düzeltmeler ya da rubber duck rolü için fena değil ama büyük proje CI pipeline'ına LLM'i doğrudan sokmak yüzlerce saatlik üretkenlik kaybına yol açabilir
      Gerçekte kod yazma becerisini geliştirmeye ayrılması gereken zamanda prompt tuning ve context ayarıyla uğraşılacaksa bunun anlamı yok
      LLM tooling konusundaki özgüvenin fazla yüksek olduğunu düşünüyorum ve bunların karmaşık sistemlere iyi uygulanamadığı kanaatindeyim
      Önemli bir repository'ye LLM'i gözetimsiz şekilde sokmak, "silah zoruyla olmadıkça" yapılacak bir şey değil diyecek kadar güvensizlik var
      Sonuçta LLM çıktısını yarı yarıya yeniden düzenlemek gerekiyor; o zaman da doğrudan kendin yapmak daha iyi

    • Otomobilden önce yakıt, yağ ve bakım için neredeyse hiç para harcanmıyordu; ama sistemler geliştikçe buna uygun ek altyapı ve maliyetler de beraberinde geliyor
      Yapay zeka ile darboğazları çözmek veya daha fazla özellik üretip geliri maksimize etmek, sonra da bu ek gelirle daha fazla CI kaynağı sağlamak gibi döngüsel bir yapı var
      AI kullanmak, ekibe 10 geliştirici daha katmış olmak gibi; dolayısıyla destek maliyetlerinin artması da doğal
      Verimlilik argümanını mantıklı şekilde ortaya koyup daha fazla CI kaynağı alıp alamayacağını ya da optimizasyon için yol gösterip gösteremeyeceğini yeniden düşünmek gerektiği görüşü
      CI kaynağı başına maliyetin ne kadar olduğu merak ediliyor

    • Bir Python uygulamasında astral.sh araç zinciri ve uv paket kurulumu + cache kullanımıyla CI hızını ciddi biçimde artırmış olma deneyimi
      Yakında mypy yerine astral'ın type checker'ına geçmeyi planlıyor; bunun daha da hızlı olması bekleniyor
      Frontend'i olan uygulamalarda en yavaş kısım muhtemelen Playwright testleri olur ama başka uygulamalarda bu bile geçerli değil
      (Not: Mike doğru kişiyse, onu 2000'lerin başında Google Maps'te birlikte çalıştığım SRE olarak hatırlıyorum; bu yüzden görüşüne güveniyorum)

  • Mercury playground'da bir regex pattern istediğimde modelin kendi kendine plan yapıp pattern'i yazdıktan sonra testler üretmeye başladığını gördüm
    Ama testleri sonsuza dek artırmaya devam etti ve sonunda context sınırına ulaşınca yanıt kesildi
    Yaklaşık 30 taneden sonra test sonuçları için yanlış yorumlar yazmaya başladı, 120'yi geçince ise test girdilerinin kendisi bozuldu ve rastgele karakterler çıkmaya başladı
    Pattern'in kendisi de zaten doğru değildi ama bu "sonsuz döngü" davranışı daha ilginç bir meseleydi

    • Bu arada, çok kısa süre öncesine kadar genel amaçlı LLM'ler de böyle "neredeyse sonsuz döngü" gibi görünen tekrar eden çıktılar veriyordu diye hatırlıyorum
      Çıktının sadece çok az değiştiği kalıplara sıkışıp kalıyorlardı

    • Bence bu örnek, "yalnızca token tahminiyle kod doğru şekilde üretilemez" iddiasının tipik bir kanıtı
      LLM'ler zaten baştan kod üzerine düşünmeye uygun tasarlanmış sistemler değil

  • Teknik raporu okuduğumda Mercury'nin Lou et al. 2023, SEDD makalesine dayandığını doğruladım
    SEDD'yi from-scratch yeniden uygulayan ilk kişi muhtemelen bendim; kodu da açık
    Karmaşık denoising yöntemini de doğrudan uyguladım
    Bunu mevcut SEDD'ye göre daha temiz ve okunabilir olacak şekilde tasarladım; tek bir GPU üzerinde oyuncak veri kümesiyle birkaç saat içinde çalıştırılabiliyor

  • Bu arada DeepMind'ın da diffusion tabanlı bir Gemini modeli var (bağlantı)
    Bizzat denediğimde Mercury gibi çok hızlıydı ama yanıt kalitesi diğer Gemini modellerine göre belirgin biçimde daha düşüktü

    • Kısaca denediğim kadarıyla hız etkileyici ama doğruluk oranı gerçekten epey düşük, buna katılıyorum

    • Gemini Diffusion demosunun ücretsiz olup olmadığı merak ediliyor
      Birkaç gündür waiting list'teyim, o yüzden henüz gerçekten deneme fırsatı bulamadım

  • Kişisel olarak bu tür ilerlemeler beni çok heyecanlandırıyor
    Yakın zamanda bir game jam sırasında AI ile basit bir oyun kodladım ve sürenin yarısından fazlası sonuç beklemekle geçti
    Her prompt başına sonuç almak 1-2 dakika sürüyorsa ama bu 10 saniyeye inerse, eskiden bir kez test edebildiğim sürede beş-on deneme yapılabilir
    Mercury henüz pratik kullanım için yeterince olgun değil ama Claude 3.0 da bir yıl önce yetersizdi; bundan sonra daha iyi hale geleceği düşünülüyor
    Gerçekten heyecan verici bir dönem

  • Mercury playground'u denedim; hızı gerçekten olağanüstü
    Diffusion mode görselleştirmesi de ilginç ama pratikte, görselleştirilen çizgisel gürültüden giderek daha doğru bir duruma rafine olunan süreci gösteriyor gibi
    Aslında bunun, rastgele bir vektör uzayından giderek daha belirgin token'lara yakınsama süreci olduğu düşünülüyor

    • Bazı metin diffusion modelleri sürekli bir latent space kullanıyor ama performansları pek iyi değil
      Son dönemde çoğu yaklaşım doğrudan gerçek token çıktısını tahmin etmeye odaklanıyor ve önceki değerleri adım adım düzelterek nihai sonuca yakınsıyor
      Yazdığım metin diffusion nasıl çalışır açıklaması faydalı olabilir

    • Bağlantı: https://chat.inceptionlabs.ai/

    • Gerçekten akıl almaz derecede hızlı

  • GPU'ya yakın kodların çoğunda performans optimizasyonu için çok büyük alan var
    Ama arXiv makalesinin gerçek araştırmadan çok pazarlamaya yakın olduğu yönünde şüphe var
    Farklı görüşlere açık

    • Çok yanlış bir nokta değil ama arXiv'de bunun gibi örnekleri ilk kez görmüyoruz

  • Mercury modelinin fiyatlandırması
    1 milyon output token başına 1 dolar, 1 milyon input token başına 0.25 dolar
    Ayrıntılı fiyatlandırma için buraya bakılabilir

    • Fiyat biraz yüksek
      Performansa duyarlı senaryolarda Mercury ile Groq'u (Llama 3.1 8b, Llama 4 Scout) karşılaştırınca performanslar benzerdi ama fiyat tarafında Groq çok daha avantajlıydı
      Diffusion modellerinin open source olarak çıkmasını umuyorum, ilgiyle takip ediyorum

  • Playground kodunda ve API yanıtlarında gpt-3.5-turbo ile "openai": true alanları görünüyor; gerçekten kendi dLLM'leri yerine OpenAI mı çağrılıyor diye merak ediliyor
    Sağ üstteki diffusion effect özelliği de sadece animasyon efekti gibi görünüyor

    • Gerçek zamanlıya yakın hızda olduğu için bunun gerçekten OpenAI backend'i kullandığına inanmak zor

  • Her şey kulağa harika geliyor ama
    Hizmete kullanıcı gönderisi gönderildiğinde, dünya çapında münhasır olmayan, kalıcı, telifsiz, ücretsiz ve tamamen devredilebilir bir lisans Inception'a verilmiş oluyor
    Yani kullanıcı içeriği AI model eğitimi amacıyla kullanılabiliyor
    (Ancak OpenRouter üzerinden gelen kullanımların eğitime dahil edilmediğine dair bir istisna maddesi var)