Yüzde 0.005'lik ağırlık farkı benchmark skorlarını 1.4 puan oynattı; geri alma geldi

Yuvarlama düzeyinde bir ağırlık değişimi 1.4 puanlık fark doğurdu

Küçük bir geliştirici laboratuvarı, değerlendirme sürecinin gerçek kazanımları sayısal gürültüden ayırt edemediğini fark ettikten sonra bir model iyileştirme iddiasını kamuya açık biçimde geri çekti. dev.to üzerindeki bir yazıda vidraft_lab, 4B sınıfı bir modelin iki dosyasını 400 çoktan seçmeli akıl yürütme sorusu üzerinde karşılaştırdığını anlattı; yanıtlar temperature 0 ile üretilip 8.192 token sınırıyla puanlandı. Dosyalar kabaca 4,66 milyar ağırlığın yalnızca yaklaşık 230.000'inde farklıydı — yüzde 0.005 civarı — ve en büyük görece fark tek bir bf16 yuvarlama adımının yaklaşık 1/25'ideydi; bu da kasıtlı bir değişiklik değil, dosyaları üreten araçların bir artefaktıydı.\n Buna rağmen iki dosya 0.7744 ve 0.7889 puan aldı; ekip bu yaklaşık 1.4 puanlık farkı 3.9 standart sapma olarak hesapladı. Aynı dosyayı üç kez çalıştırmak 0.17 puan içinde skorlar üretmiş, bu da istikrarı işaret etmişti. Ancak yalnızca yuvarlama düzeyinde farklılaşan dosyalar yaklaşık 1.2 puan yayıldı. Yazarların sonuçlandırdığı gibi, tek bir dosyayı tekrarlamak, neredeyse özdeş dosyalar arasındaki değişkenliği yaklaşık yedi kat düşük gösteriyor.

Neredeyse özdeş ağırlıklar neden ayrışabilir

Yazıya göre iki etki üst üste biniyor. Inference sunucuları genelde batch-invariant değil: yazarlar, Thinking Machines Lab'ın Eylül 2025 tarihli yazısına atıf yapıyor; orada tek bir prompt, Qwen3-235B üzerinde temperature 0 ile 1.000 kez çalıştırıldığında 80 farklı çıktı üretmiş, en yaygın olanı yalnızca 78 kez görünmüştü; çünkü kernel çıktıları batch boyutuna bağlıdır ve batch boyutu sunucu yüküyle değişir. Thinking Machines Lab, batch-invariant kernel'lerin bu ayrışmayı giderdiğini ama gecikme (latency) maliyetiyle raporlamıştı.

Uzun üretimler ayrışmayı daha da büyütüyor. Son bitteki bir logit farkı erken bir token'ı çevirirse, akıl yürütme zincirinin geri kalanı dallanır. Ekip aynı kurulumun farklı çalıştırmalarında yüzde 16.75, 16.25 ve 18.00 oranlarında kesme (truncation) oranları gözlemledi. Yazarlar bunun, kendilerinin ölçtüğü nedensel bir ayrıştırma değil, önceki çalışmalara ve gözleme dayanan bir açıklama olduğunu belirtiyor.

Baseline tuzağı

Bu istikrarsızlığın somut bir maliyeti oldu. Bir aday, orijinal dosyanın 1.06 puan üzerinde raporlanmıştı. Ancak her aday yukarıda açıklanan yuvarlama artefaktını bırakan bir araçla üretilmişken, baseline o aracından geçmemişti. Ekip baseline'ı aynı araçla yeniden oluşturduğunda 0.7889 puan aldı ve adayın üstünlüğü -0.39 puona düştü; hiçbir aday iyileşme göstermedi ve rapor geri çekildi. Ekibin çıkardığı kural — baseline'ları adayları üretmek için kullanılan araçla oluşturun — model merge'leri, checkpoint seçimini ve quantization karşılaştırmalarına da uygulanır; quantization özünde yuvarlamadır.

Yetenek değil, kesme

İkinci bir sorun geç ortaya çıktı. Beş model genelinde üretim puanları kesme oranlarını neredeyse tam olarak izledi ve token sınırında kesilen yanıtlar yanlış sayıldı. Soruların yüzde 47.2'sinde kesilen D modeli, tamamladığı sorularda 0.948, kesilen sorularda 0.249 puan aldı. 1.198 soru üzerinde deterministik log-olasılık puanlamasıyla — soru başına tek forward pass, üretim yok, kesme yok — yeniden ölçüldüğünde D modeli ekibin adayından 2.34 puan öne çıktı (kesin McNemar p=0.0078) ve üretim puanlamasındaki 15 puanlık gerilemeyi tersine çevirdi. Yazarların yazdığına göre adayın gerçek kazanımı daha kısa yanıtlama alışkanlığıydı; bu, sıkı çıktı sınırlarında kullanışlıdır ama ek bilgi veya akıl yürütme değildir. Aday ile A modeli arasındaki karşılaştırma ise istatistiksel olarak ayırt edilemezdi (p=0.5966).

Çözüm: deterministik puanlama

Ekip artık neredeyse özdeş modelleri deterministik olarak karşılaştırıyor; prompt'tan sonra hangi seçenek harfinin en yüksek log-olasılığa sahip olduğunu, üretilmiş bir akıl yürütme zinciri olmadan kontrol ediyor. 498 soru üzerinde tekrarlanan çalıştırmalar ondalık altı basamağa kadar eşleşti, değişen tahmin sıfırdı ve puanlama, 400 üretimli soruya karşı 62 saniye sürdü (400 üretimli soru için 400 saniyeye karşı). Bu bir yerine koyma değil, yardımcı bir araç: chain-of-thought'u bırakmak skorları keskin biçimde düşürüyor (aynı modelde 0.775'e karşı 0.437), dolayısıyla iki ölçek doğrudan karşılaştırılamaz.

Neden önemli

Liderlik tablolarındaki bir-iki puanlık farklar rutin biçimde yetenek farkı olarak okunuyor. Tamamen kendi ölçümüne dayanan, hiçbir dış taraf tarafından yeniden puanlanmamış, küçük örneklemli ve modelleri A'dan E'ye anonimleştirilmiş bu rapor, bu tür farkların dosya araçlarını, sunucu batch'lemesini ve token sınırlarını yansıtabileceğini gösteriyor. Benzer modelleri karşılaştıran herkes için pratik çıkarımlar: skorların yanında kesme oranlarını raporlayın, gürültüyü tek bir dosyanın tekrarlı çalıştırmalarından değil yuvarlama farkı olan kopyalardan tahmin edin, baseline'ları adaylarla aynı süreçle oluşturun ve birkaç yüz eşleştirilmiş sorunun bir puanlık farkları hiçbir şekilde çözemediğini unutmayın.