LLM çıkarımında belirlenimsizlik nasıl yenilir

 (thinkingmachines.ai)
2 puan yazan GN⁺ 2025-09-12 | 1 yorum | WhatsApp'ta paylaş
  • LLM (büyük dil modeli) çıkarımında, aynı girdi ve koşullarda bile sonuçların farklı çıkmasına yol açan belirlenimsizlik (nondeterminism) sorunu ortaya çıkar
  • Geleneksel olarak eşzamanlılık (concurrency) ve kayan nokta (floating-point) işlemlerinin birleşme özelliği taşımaması (non-associativity) belirlenimsizliğin başlıca nedenleri olarak görülüyordu
  • Gerçek belirleyici neden, batch boyutu (batch size) değişimine bağlı olarak kernel’in (hesaplama kodu) içindeki işlem sırasının değişmesidir
  • Kernel içindeki tüm işlemler batch değişmezliği (batch invariance) taşıyacak şekilde uygulanırsa tam yeniden üretilebilirlik (reproducibility) garanti edilebilir
  • Veri paralel işlemler, split reduction, sabit boyutlu split stratejisi gibi yöntemlerle başlıca işlemler (RMSNorm, matmul, attention) için batch değişmez kernel’ler üretmek mümkündür

Giriş ve sorunun özeti

  • Bilimsel ilerlemenin temel unsurlarından biri olan yeniden üretilebilirlik (reproducibility), LLM (büyük dil modeli) çıkarımında iyi korunmuyor
  • ChatGPT’ye aynı soru birkaç kez sorulduğunda birbirinden farklı yanıtlar üretilmesi sık görülür
  • Bunun nedeni, LLM’de sonuç üretiminin sampling sürecinde olasılık dağılımına dayalı olasılıksal seçim ile yapılmasıdır
  • Ancak temperature 0 olarak ayarlansa bile pratikte LLM API’leri mutlaka deterministik değildir; yani aynı girdi için sonuç her zaman aynı olmaz
  • Açık kaynak çıkarım kütüphanelerinde (vLLM, SGLang vb.) ve kendi donanımınızda çalıştırıldığında da belirlenimsizlik sorunu vardır

Mevcut hipotezler ve sınırları

  • Yaygın kabul gören hipotez: eşzamanlılık + kayan noktanın birleşmezliği nedeniyle belirlenimsizlik ortaya çıkıyor
    • GPU’daki kayan nokta işlemleri, işlem sırasına ve thread’lerin bitiş sırasına göre sonuçları çok küçük farklarla değiştirebilir
  • Ancak gerçekte aynı veri üzerinde aynı şekilde matris çarpımı tekrarlandığında her zaman aynı (bw=bitwise equal) sonuç elde edilir
  • Gerçek nedeni anlamak için daha derin bir analiz gerekir

LLM çıkarımındaki belirlenimsizliğin nedenine derinlemesine bakış

Kayan nokta birleşmezliğinin özü

  • Kayan nokta işlemleri için (a+b)+c ≠ a+(b+c) ilişkisi geçerlidir
  • Farklı büyüklükteki (exponent) değerler birlikte işlendiğinde hassasiyet kaybı ve bilgi kaybı yaşanır; işlem sırasına göre sonuç değişir
  • İşlem sırası değişebildiği için toplamlar rastgele biçimde tekrar tekrar yapıldığında farklı sonuçlar ortaya çıkar; bu durum deneysel olarak da doğrulanmıştır

Kernel içindeki işlem sırası değişimi ve eşzamanlılık

  • Genellikle belirlenimsizliğin ana nedeni olarak atomic add gibi işlemlerdeki eşzamanlılık sorunları gösterilir
  • Ancak LLM çıkarımında kullanılan kernel’lerin çoğu, özellikle forward pass, atomic add olmadan da çalışır
  • Uygun paralel stratejiler ve split (reduction) ile aynı işlem sırası korunabilir

Asıl kritik neden: "batch değişmezliği (batch invariance)" eksikliği

  • Tekil kernel’ler, girdi aynıysa her zaman aynı sonucu döndürür (run-to-run deterministic)
  • Ancak birden çok kullanıcının eşzamanlı isteği nedeniyle batch boyutu belirlenimsiz biçimde değiştiğinden, her bir istek için pratikte sonuç sabit kalmaz
  • Batch boyutuna göre içeride işlemler farklı biçimde bölünür veya birleştirilir; bu da belirlenimsizliğe yol açar
  • Yani asıl neden, sunucu yükü ve paralellik düzeyinin (batch size) belirlenimsiz olmasıdır

Batch değişmez kernel tasarımı ve temel işlem örnekleri

RMSNorm

  • Veri paralelleştirme (data-parallel) stratejisi uygulanır: her batch öğesi bağımsız olarak tek bir çekirdek tarafından işlenir
  • Batch boyutu büyük olduğunda yeterli paralellik korunur; dolayısıyla paralel strateji sabit kalır ve batch değişmezliği sağlanır
  • Batch boyutu çok küçük olduğunda split reduction gibi alternatif stratejiler kullanılır; bu durumda batch değişmezliğinin bir kısmından ödün verilir

Matris çarpımı (matmul)

  • Tile bazlı paralelleştirme ile veri paralel stratejisi kullanılır
  • Tensor Core kullanımını optimize etmek için 2D tile bölmesi gerekir; çok küçük batch’lerde split-K gibi özel stratejilere ihtiyaç duyulur
  • split-K stratejisi kullanıldığında batch değişmezliği bozulabilir
  • Bir miktar performanstan vazgeçilse bile aynı kernel yapılandırması zorlanarak sabit ve yeniden üretilebilir bir işlem sırası elde edilebilir

Attention

  • FlashAttention2 gibi yapılarda query yönünde paralelleştirme ve Key/Value eşzamanlı reduction stratejileriyle batch değişmezliği sağlanır
  • Batch boyutu ve dizi bölme şekli (chunked prefill, prefix caching vb.) reduction sırasını değiştirirse değişmezlik bozulur
  • split-KV (FlashDecoding) gibi split-reduction stratejilerinde split boyutu sabitlenerek (fixed split-size) işlem sırası aynı tutulur
  • İç işleyişte key/value cache ile yeni token’lar ayrı ayrı ele alınmamalı; tüm işlemlerde key/value yerleşimi tutarlı kalmalıdır

Uygulama

  • vLLM ve torch.Library kullanılarak batch-invariant kernel uygulayan deterministik bir çıkarım demosu sunuluyor
  • İlgili işlemler için ikame kernel’ler GitHub deposunda incelenebilir: thinking-machines-lab/batch-invariant-ops

Deneyler ve performans

Belirlenimsizliği ölçen deney

  • Qwen/Qwen3-235B-A22B-Instruct-2507 modeliyle temperature 0 koşulunda aynı istem (“Tell me about Richard Feynman”) 1000 kez üretildi
  • 80 farklı tamamlama oluştu; yani aynı istemde belirlenimsizlik gözlendi
  • İlk 102 token’a kadar çıktı aynı kaldı, ilk ayrışma 103. token’da oldu (“Queens, New York” vs “New York City”)
  • Batch değişmez kernel kullanıldığında 1000 denemenin tamamında aynı sonuç elde edildi ve tam yeniden üretilebilirlik sağlandı

Performans değerlendirmesi

  • Tek GPU üzerinde Qwen-3-8B çalıştırılarak, uzunluğu 90~110 arasında değişen 1000 dizi isteği test edildi
    • vLLM varsayılan: 26 saniye
    • optimize edilmemiş deterministic vLLM: 55 saniye
    • iyileştirilmiş attention kernel uygulandığında: 42 saniye
  • Optimizasyon eksik olsa da pratikte kullanılabilir bir performans düzeyi korunuyor

On-policy RL açısından değeri

  • Daha önce training ile inference arasındaki küçük sayısal farklar nedeniyle on-policy RL tam olarak uygulanamıyordu
  • Deterministik çıkarım mümkün olduğunda sampling ve training bitwise identical hale getirilebilir ve gerçek bir on-policy RL uygulanabilir
  • KL-divergence, reward gibi başlıca metric’lerde tam olarak eşleşen sonuçlar doğrulandı

Sonuç

  • LLM çıkarım sistemlerinde belirlenimsizlik ve sayısal hatalar kolayca göz ardı edilebilir; ancak bu sorunun temel nedeni olan batch değişmezliği eksikliği anlaşılır ve giderilirse tam yeniden üretilebilirlik ve determinizm elde edilebilir
  • Bu çalışma, LLM çıkarımındaki belirlenimsizlik sorununu çözmeye yönelik yolu ortaya koyarak geliştiricilerin kendi sistemlerinde tam yeniden üretilebilirlik sağlamasına yardımcı oluyor

Atıf bilgisi

  • Bu çalışmaya atıf yaparken aşağıdaki bilgileri kullanın
He, Horace and Thinking Machines Lab, "Defeating Nondeterminism in LLM Inference", 
Thinking Machines Lab: Connectionism, Sep 2025.

veya

@article{he2025nondeterminism,
  author = {Horace He and Thinking Machines Lab},
  title = {Defeating Nondeterminism in LLM Inference},
  journal = {Thinking Machines Lab: Connectionism},
  year = {2025},
  note = {https://thinkingmachines.ai/blog/…},
  doi = {10.64434/tml.20250910}
}

İlgili okumalar

1 yorum

 
GN⁺ 2025-09-12
Hacker News görüşleri

  • "Teorik" nedensizliği tamamen kapalı tekil girdi-çıktı çiftlerinde çözseniz bile, gerçekte iki tür nedensizlik sorunu kalıyor: aynı girdinin önceki bağlama göre farklı sonuç üretmesi ve hafifçe değiştirilmiş bir girdinin doğru şekilde dönüştürülmüş bir sonuç üretememesi. Bu sorunlar çözülmedikçe, kapalı sistemlerdeki nedensizlik, aslında bir başvuru tablosunun da yeterli olduğu durumlar dışında pek yardımcı olmuyor. Test edilmemiş girdiler için "doğru" birim testleri ya da değerlendirme setleriyle bir şey kanıtlamak zor

    • "Tam olarak aynı girdi olmasına rağmen farklı önceki bağlama göre sonucun değişmesi" diye bir durum aslında yok. Önceki bağlamın kendisi de girdidir. Eğer belirli bir giriş promptundan her zaman aynı sonuç çıkıyorsa, bağlamın yok sayıldığını düşünebiliriz. Yani oturum içi durumdan bağımsız olarak her seferinde boş bağlamla başlamakla aynı şey. Bazı insanların istediği şey,

      • Anlam olarak aynı olan farklı prompt cümlelerinin (ör. "What is the capital of France" ve "What is France's capital") aynı yanıtı üretmesi gerektiği
      • Önceki bağlam soru ile hiçbir etkileşime girmediğinde sonucu etkilememesi gerektiği. Örneğin, "what is 2 + 2" promptunun her zaman aynı yanıtı vermesi ve bağlamda 2 + 2 = 5 diye belirtilmediği sürece değişmemesi gerektiği. Bu tür talepler, LLM denen şeyin ne olduğu konusunda bir yanlış anlamayı gösteriyor

    • 'Önceki bağlam'ın farklı sonuç üretmesi neden sorun olsun? Eğer bağlam sonucu etkilemiyorsa, bağlamı zaten atabilirsiniz. Böyle bir davranışı özellikle istemenin sebebi ne? Sonuçta bir araçsa, niyetime veya mod değişimine göre (ör. vim'de insert moduna geçince davranışın değişmesi gibi) farklı tepki vermesini beklerim. Zekânın da böyle çalışmasını isterim. Bağlamı yok saymak bana daha çok aşırı bir doğrulama yanlılığı gibi geliyor

    • Hataları yeniden üretirken çok faydalı

    • "Pek yardımcı değil" denilen noktaya kadar katılıyordum. Muhtemelen "sorunu tamamen çözmüyor" anlamında söylendi

  • Olasılıksal bir sistemde neden determinizme bu kadar önem verildiğini merak ediyorum. Kullanıcı açısından, "How do I X?" girdisine her zaman aynı deterministik cevabı vermesi, eğer "how do i x?", "how do I x", "how do I X??" gibi anlamca aynı girdilere bambaşka sonuçlar veriyorsa, pek anlamlı olmuyor. LLM'lerde gerçekten gereken şey, anlamsal olarak aynı girdiler için her zaman anlamsal olarak aynı çıktıları garanti edebilme yeteneği. Bu, algoritmalarda genelde determinizm derken kastettiğimiz şeyden tamamen farklı bir kavram

    • Tüm LLM tabanlı uygulamalar kullanıcıların doğaçlama sohbet ettiği arayüzlerden ibaret değil. Araç çağrılarını değerlendirme amacıyla 10 kez art arda çalıştırdığınız ya da DSPy Optimizer gibi araçlarla bağlantı promptları sürekli test ettiğiniz durumlarda, token düzeyindeki girdiyi tamamen ben kontrol edebiliyorsam öngörülemezliği azaltmak önemli. Böyle ortamlarda token seviyesindeki değişkenliği kaldırıp yalnızca girdinin kendi belirsizliğini bırakabilirseniz, sistemin davranışını çok daha güvenilir ağaç ve grafik yapılarına eşleyebilirsiniz

    • Dediğiniz yanlış değil ama bu düzeyde determinizmin faydasız olduğu anlamına gelmiyor. Aynı giriş tokenlarını verdiğinizde sonuç her seferinde değişiyorsa, sonuçları ekip arkadaşlarınızla yeniden üretip paylaşmak ya da LLM'nin çok nadir ve öngörülemez çıktılar verdiği durumları test etmek (ör. red teaming) zorlaşır

    • LLM çıktısına steganografi ile bilgi gömmeye yönelik bir proje üzerinde çalışıyorum: innocuous. Modelin üst 10 tokenı kadarını çıkarıp kullanıyoruz ve çoğunlukla CPU tabanlı 8B modellerde test yaptığımız için, donanım etkisiyle token sırasının değişmesi büyük bir endişe değil; ama küçük hassasiyet kayıplarının seçimi değiştirmemesi için eventually guard koşulları da eklemeyi düşünüyorum

    • Yapay zeka platformu müşterileri için çok faydalı olabilir. Promptu temperature 0 ile birkaç kez çalıştırıp sonucun hep aynı olup olmadığına bakarak, yapay zeka sağlayıcısının PRO modeli gizlice daha ucuz başka bir modelle değiştirip değiştirmediğini doğrulayabilirsiniz

    • "Bug" yeniden üretimi için kesinlikle gerekli. Aynı giriş stringini verdiğinizde aynı hatalı ya da tuhaf çıktıyı her seferinde yeniden oluşturabiliyorsanız hata ayıklama çok daha kolay olur. Sonuç 100 denemede bir farklılaşıyorsa iş çok daha zorlaşır

  • (JAX/XLA ile çalışma deneyimi) Bu oldukça bilinen bir şey. Ben de bu tür durumlarla (batch düzeyi değişkenlik) birkaç kez karşılaştım ve açıklamayı şu issue'larda gördüm: penzai issue #82, jax issue comment

    • Bunun en üstteki yorum olması gerektiğini düşünüyorum

  • Bazen nedensizliğin nedeni uygulama detaylarıdır. Örneğin GPT-2 kaynak kodunda, GUI'de temperature 0 olarak ayarlansa bile gerçekte sıfır olmayan bir "epsilon" (çok küçük bir sayı) değeri girilir. Bunun amacı division by zero hatasını önlemektir, dolayısıyla anlaşılır bir tercih. Nondeterminizm birçok uygulamada "işe yaramaz". Bu, LDA konu modellemede de eski bir sorun. Özellikle hukuk, finans ve regülasyon alanlarında deterministik olmayan yöntemler kullanmak yasa dışı bile olabilir. Ya da istenmeyen ek yükümlülükler doğurabilir (olan biteni sonradan tek tek yeniden kurabilmek için tüm ekran kayıtlarını saklamak gibi)

  • "Thinking Machines'te başkalarıyla birlikte çalışmak" meselesi geçiyor. Eskiden MIT AI Lab önünde kırmızı LED küplerin parladığı o makineyi bizzat görürken duyduğum heyecanı hatırladım. Richard Feynman gerçekten harika işler yapmıştı; bununla ilgili bir yazı da var: Feynman and the Connection Machine. ABD'de “THINKING MACHINES” ticari markası Hillis adına değil, kurduğu şirket adına tescil edilmişti ve 1998–1999'da iptal edildi. Şirket 1994'te iflas etti ve varlıkları Sun Microsystems'e (sonrasında Oracle) ve başkalarına geçti. Amira Murati'nin kurduğu Thinking Machines Lab Inc. ise 2025'te yeniden “THINKING MACHINES” ticari marka başvurusu yapıyor

    • Bu şirket adını her gördüğümde aynı kafa karışıklığını yaşıyorum

  • Son dönemde yüksek kaliteli, blog tarzı araştırma tartışmalarını görmek gerçekten sevindirici. Anthropic bu kültüre öncülük ediyor gibi ve bunun giderek yayılmasından umutluyum. Geçmişte RL araştırmalarının yoğun olduğu dönemde OpenAI de böyleydi

  • Doğal dilin kendisi belirsizlik taşır. Taşımak zorundadır. Burada yapılan, 'çemberi kare yapmaya çalışıp bunun neden gerekli olduğunu açıklamaya çalışma' yaklaşımının yanlış olduğunu düşünüyorum. Bu tür tartışmalar sonunda dili ya da rastgeleliğin doğasını daha iyi kabullenmeye ve dili QKV projection matrix gibi mini dilbilgisel alt örüntülerin ötesinde yorumlamaya götürecektir

    • Doğru. Ama determinizm belirsizlik değildir. Determinizm, "tam olarak bu girdiye tam olarak bu çıktıyı garanti etmek" demektir. Aynı modele aynı soruyu sorduğumda her seferinde aynı yanıtı vermesini beklerim. Elbette cümlesi biraz değiştirilmiş bir soruda biraz farklı bir yanıt gelmesini anlayışla karşılarım

  • Şirketin adı hâlâ hoşuma gitmiyor. Bu tür adlandırmaların neden tekrarlandığını merak ediyorum. Belki efsanevi bir kurumun havasının yeni girişime de geçmesini uman bir bağlam vardır. Ama bir sonraki startup'ın adını PARC koymak, ağ teknolojilerindeki yeniliklerin otomatik olarak size aktarılacağı anlamına gelmez diye düşünüyorum

    • 1994'te kapanan “Thinking Machines” şirketinden mi bahsediyorsunuz? Biraz araştırmadan bunu anlamak zordu ve sanıldığından daha az biliniyor, o yüzden böyle bir niyet olmayabilir. Bana sadece havalı ve sezgisel bir isim gibi geliyor

    • Sırf isim koyarak pazarlamanın bedavaya gelmesi, ticari marka sisteminin ortaya çıkış sebebiyle aynı şey zaten

  • Gerçekten ilginç. Bilmeyenler için söyleyeyim, bu şirket eski OpenAI CTO'su Mira Murati tarafından kuruldu