GPT-4'ün deterministik olmamasının nedeni Sparse MoE

 (152334H.github.io)
1 puan yazan GN⁺ 2023-08-06 | 1 yorum | WhatsApp'ta paylaş
  • temperature=0 olsa bile GPT-4 ve GPT-3.5-turbo'nun aynı girdi için her seferinde farklı çıktılar üretmesi, mevcut dense decoder modellerinde görülmeyen sıra dışı bir davranış
  • Şimdiye kadar deterministik olmamanın nedeni CUDA kayan nokta işlemlerindeki kararsızlık ile açıklanıyordu, ancak bu tek başına yeterli değil
  • Sparse MoE mimarisinin batched inference yapısında, aynı batch içindeki farklı dizilerin token'ları expert buffer alanları için yarışırken deterministik olmama ortaya çıkıyor
  • 30 kez tekrarlanan çağrı deneyinde GPT-4, diğer modellere kıyasla ezici biçimde daha fazla benzersiz çıktı üreterek hipotezi deneysel olarak destekledi
  • Modelin dizi bazında değil, yalnızca batch bazında deterministik olması, GPT-4 API güvenilirliği sorununun temel nedeni

Sorunun ortaya konması — temperature=0 iken çıktı neden her seferinde farklı?

  • GPT-4/GPT-3.5-turbo'nun temperature=0.0 olsa bile deterministik olmaması zaten yaygın olarak bilinen bir durum
    • dense decoder-only modellerde temp=0, greedy sampling anlamına gelir ve bunun tamamen deterministik sonuç vermesi gerekir
    • çünkü bir sonraki token'ın logit'leri yalnızca giriş dizisi ve model ağırlıklarının saf bir fonksiyonudur
  • OpenAI World Tour geliştirici yuvarlak masa toplantısında teknik ekibin yanıtı
    • "Dürüst olmak gerekirse biz de kafamız karışık. Bu ya bir sistem hatası ya da optimize edilmiş kayan nokta hesaplamalarının deterministik olmaması olabilir" anlamına gelen bir açıklama yapıldı
  • Bu davranışın 2 yıl önce de dile getirilmiş olmasına rağmen hâlâ çözülememiş olması soru işaretleri yaratıyor
    • reliability'yi öne çıkaran OpenAI'nin bilerek deterministik olmamayı koruması için bir neden olmadığından, başlangıçta bunun çözülemeyen bir donanım sınırı olduğu en makul açıklama olarak görüldü

Yeni hipotez — Soft MoE makalesinde bulunan ipucu

  • Soft MoE makalesinin 2.2 bölümünde belirleyici bir bağlantı bulunuyor
    • kapasite kısıtları (capacity constraints) altında tüm Sparse MoE yöntemleri token'ları sabit boyutlu grup birimleri halinde yönlendirir ve grup içinde dengeyi zorunlu kılar ya da teşvik eder
    • gruplar farklı dizilere/girdilere ait token'lar içerdiğinde, bu token'lar expert buffer'daki boş yerler için birbirleriyle yarışır
    • bunun sonucunda model dizi bazında deterministik değildir, yalnızca batch bazında deterministiktir ve bazı giriş dizileri diğer girişlerin nihai tahminini etkiler
  • GPT-4'ün bir Mixture of Experts modeli olduğu zaten kamuya açık bir bilgi
    • GPT-4, 2022'nin 2. çeyreğinden önce eğitildi ve Sparse MoE bundan daha önce de vardı
  • Ortaya konan temel hipotez
    • GPT-4 API, batched inference yapan bir backend üzerinde barındırılıyor
    • başka etkenler de kısmen rol oynayabilir, ancak API'nin deterministik olmamasının büyük kısmı, Sparse MoE mimarisinin dizi başına deterministikliği zorlayamamasından kaynaklanıyor

Doğrulama — bunun donanım sorunu olmadığını gösterme

  • Hipotezi test etmek için GPT-4'ten doğrudan bir test betiği yazması istendi
    • chat modelleri (gpt-4, gpt-3.5-turbo) ve completion modelleri (text-davinci-003/001, davinci-instruct-beta, davinci) üzerinde aynı prompt temperature=0 ile tekrar tekrar çağrıldı ve benzersiz çıktı sayısı hesaplandı
  • Betik yazımı sırasında ortaya çıkan sorunlar
    • OpenAI API yanıtları çok yavaştı; 3.5 turbo çağrılarında bile neredeyse 10 saniyelik gecikme görüldü, bunun yerel bir hata olmadığını doğrulamak için zaman damgası kaydı eklendi
    • bazı completion modelleri yanıtı erken kesiyordu; bunu düzeltmek için EOS token'ına logit bias uygulandı
    • chat modelinin <|im_end|> token'ına (100265) eşdeğer bir bias uygulanamadı; API, en büyük değer olan 100257'yi aşan anahtar için hata döndürdü
      • completion'ların çoğu zaten max token uzunluğuna ulaşıyordu ve chat modelleri çok daha deterministik değildi; bu yüzden bu kısıtın kritik olmadığı düşünüldü

Deneysel sonuçlar

  • 3 deneme, N=30, max_tokens=128 koşullarında benzersiz çıktılar (ortalama/30)
    • gpt-4: 12, 11, 12 — ortalama 11.67
    • gpt-3.5-turbo: 4, 4, 3 — ortalama 3.67
    • text-davinci-003: 3, 2, 4 — ortalama 3.00
    • text-davinci-001: 2, 2, 2 — ortalama 2.00
    • davinci-instruct-beta: 1, 1, 1 — deterministik, çıktı tekrar döngüsüne çöküyor
    • davinci: 1, 1, 1 — deterministik, çıktı tekrar döngüsüne çöküyor
  • logit_bias sorunu fark edilmeden önceki max_tokens=256 koşulu sonuçları
    • gpt-4: 30, gpt-3.5-turbo: 9, text-davinci-003: 5, text-davinci-001: 2

Sonuçların yorumu

  • GPT-4'ün benzersiz çıktı sayısı olağan dışı derecede yüksek; uzun çıktılarda pratikte neredeyse her zaman deterministik değil
  • tekrar döngüsüne çökmeyen diğer modeller de belli ölçüde deterministik olmama gösteriyor; bu da GPU hesaplama kararsızlığının rastgeleliğin bir kısmını açıkladığı yönündeki kamuya açık iddialarla uyumlu
  • Geriye kalan soru işaretleri
    • text-davinci-001'den gpt-3.5-turbo'ya doğru rastgeleliğin neden kademeli olarak arttığına dair net bir açıklama yok
    • GPT-4'ün güçlü deterministik olmamasının MoE yerine yalnızca parametre sayısından kaynaklanma ihtimali de tamamen dışlanamıyor; ancak daha hızlı olan Turbo'nun davinci'den daha deterministik olmaması bu açıklamayla çelişiyor

Çıkarımlar

Fazla gerideyiz

  • Eğer deterministik olmama, Sparse MoE'nin batched inference yapısına içkin bir özellikse, bu alanın içindeki kişiler için zaten açık olması gerekirdi
  • GPT-4 kullanıcılarının büyük bölümünün API kararsızlığının nedenini bilmiyor olması, ya hipotezin yanlış olduğunu ya da MoE modellerini anlayan insan sayısının bu açıklamanın yaygınlaşmasına yetmeyecek kadar az olduğunu düşündürüyor
  • Google Deepmind bunu biliyordu ve makalede geçerken tek cümleyle değinecek kadar önemsiz gördü; bu da yalnızca dense modellerle çalışan diğer organizasyonlara kıyasla Deepmind konusunda daha iyimser olmak için bir neden sunuyor

GPT-3.5-Turbo da MoE olabilir

  • 3.5-turbo'nun GPT-4 ile aynı mimariyi paylaşıp yalnızca çok daha az parametreye sahip olduğu yönünde söylentiler var
  • Bugün Turbo düzeyinde performansa ulaşmak için 70B parametre gerektiği düşünülürse, OpenAI'nin işlediği trafik ve hız dikkate alındığında bunu tek bir dense modelle açıklamak zor
  • Turbo, API'de logprobs erişimi kapalı olan tek diğer model
    • önceki açıklama bunun distillation doğruluğunu artırmayı önlemek olduğu yönündeydi, ancak Orca gibi örnekler bu savı zayıflatıyor
    • OpenAI'nin ChatCompletions'a logprobs entegre etmek üzerinde çalıştığını açıkça duyurmuş olması, "distillation'ı önleme" açıklamasından çok, "özünde fazla rastgele olduğu için istikrarlı mühendislik zor" yorumunu daha güçlü kılıyor

Sonuç

  • OpenAI'nin GPT modellerinin temperature=0 iken deterministik olmaması herkesin bildiği bir gerçek
  • Genelde bunun nedeni CUDA'nın optimize edilmiş kayan nokta işlemlerindeki hatalar olarak gösteriliyor
  • Burada sunulan alternatif hipotez şu: Sparse MoE modellerinde batched inference, GPT-4 API'sinin deterministik olmamasının temel nedeni ve bu, mevcut açıklamadan daha temiz bir hipotez
  • GPT-4'ün (ve bazı 3.5 modellerinin) API çağrılarının diğer OpenAI modellerine göre çok daha fazla deterministik olmadığını deneysel olarak gösteriyor
  • Hız, deterministik olmama ve logprobs'un kaldırılmış olması temelinde GPT-3.5-turbo'nun da MoE olabileceği tahmin ediliyor

İlgili okumalar

1 yorum

 
GN⁺ 2023-08-06
Hacker News yorumları

  • Kayan nokta hataları genelde deterministiktir; aynı hesaplamayı iki kez çalıştırırsanız bit düzeyine kadar aynı sonucu vermesi gerekir.
    Sonucun ayrışması ancak tamponların düzgün biçimde sıfırla başlatılmaması, yarış durumu olması ya da yuvarlama modu bayraklarının tutarlı ayarlanmaması gibi başka bir durum veya entropi kaynağı olduğunda olur.
    AI/ML ekosisteminde alelacele yazılan kodların kalitesine bakınca bu üç şeyin de, hatta belki daha fazlasının da yaşandığını düşünüyorum.

    • GPU’larda öyle değil: https://www.twosigma.com/articles/a-workaround-for-non-deter...
      Bu durumda GPU paralelliği nedeniyle sayıların toplanma sırası deterministik değildir ve sonuç biraz farklılaşabilir.
      Pek bilmediğiniz sistemlerin üstüne yazılmış kodlar hakkında başkalarının kodunu küçümsemekten kaçınmak daha iyi olur.
      CPU’da da paralel işleme nedeniyle aynı şey olabilir; ancak CPU’nun tekil komutlarının çoğu deterministikken CUDA deterministik olmayan temel işlemler sunar.
      Bunlar deterministik muadillerinden daha hızlı olduğu için bu bilinçli bir tasarımdır; sorun, bunun kötü koddan kaynaklanan bir hata gibi sunulmasıdır.
    • Paralellik devreye girince bu ifade geçersiz kalabilir.
      Örneğin toplama veya çarpma gibi bazı kayan nokta işlemleri birleşme özelliğine sahip değildir; bu yüzden bir reduction’ın hangi yürütme sırasıyla tamamlandığına bağlı olarak sonuç değişir.
      Paralel durumda performans nedeniyle reduction sırasını deterministik olmayan hâle getiren uygulamalar da vardır; bu yüzden nihai sonuç da deterministik olmaz.
    • Matematiksel olarak hesaplama deterministiktir; ancak gerçek hesaplamayı yapan fiziksel aygıt, yazılım sonucunu zamanın bir fonksiyonu hâline getirebilecek çeşitli yollara sahiptir.
      Bunu yalnızca GetTimeOfDay() çağrısı bile yapabilir; işlemciler arasındaki saat frekansı kayması da buna yol açabilir.
    • Alhazen’in dairesel bilardo problemini n adım simüle edersek, birden fazla çalıştırmada sonucun aynı olup olmayacağını merak ediyorum.
      https://forumgeom.fau.edu/FG2012volume12/FG201216.pdf
    • Büyük ölçekte, iyi bir ECC bellek olmaması bile entropi yaratmak için yeterlidir.

  • Referans makaledeki alıntıyı doğru anlayıp anlamadığımdan emin değilim.
    Daha verimli çıkarımın bir kısmının, tamamen ayrı girdilerden gelen token’ları—örneğin başka kullanıcıların girdilerini—karıştırmaya dayandığı mı söyleniyor? Ve tesadüfen aynı gruba giren diğer girdilere bağlı olarak “uzman” atama oranı değişiyor, nihai tamamlama sonucu da farklılaşıyor mu?
    Öyleyse bu yalnızca deterministik olmamayı devreye sokmakla kalmaz; aynı uzman ataması için rekabet eden eşzamanlı istek sayısı da yanıt kalitesini etkileyebilir.
    Örneğin Hintçe çeviri/yorumlamada iyi olan sistem parçası, Hindistan’daki yoğun saatlerde aynı kapasite için aynı anda rekabet eden daha fazla girdi olduğu için daha kötü sonuçlar üretebilir.
    Zamanla kalitenin düştüğünü hissetmenin başka bir açıklaması da bu olabilir. Eskiden belirli bir test istikrarlı biçimde başarılı oluyordu ama ilgili uzmanlarda sıkışıklık azdı; şimdi eşzamanlı kullanım arttığı için aynı test o uzmanın çabasından yeterince pay alamıyor olabilir.
    Belirli bir alt uzman, belli bir alanda başlangıçta etkileyici derecede iyiyse o alanın kullanımı daha fazla yoğunlaşabilir; yeni sıkışıklık nedeniyle taklit amaçlı kullanımlar artık aynı uzman atamasını alamaz ve başlangıçtaki etkileyici performansın düştüğü bir bataklık oluşabilir.
    Etki güçlüyse ve OpenAI bunu bilmesine rağmen açıklamadıysa, başlangıçta sıkışık olmayan Mixture-of-Experts sisteminin temsili olmayan üstünlüğüyle kullanıcı çekip sonra daha sıkışık bir sistemin daha düşük kaliteli sonuçlarını sunan bir yem ürün gibi görülebilir.

    • Sonuç, 30 denemede esasen 12 benzersiz yanıt çıktığını gösteriyor; token’lar karıştırılıyorsa beklenen sonuç bu değil.
      Muhtemelen batch’leri farklı şekilde grupluyorlar. 10’luk bir batch’i 5’erli 2 gruba bölerken benim prompt’umun birinci gruba mı ikinci gruba mı düştüğüne göre yanıt değişiyor; batch içinde aynı konumdaysa aynı yanıtı almak gibi.
      Aynı batch, yani sekanslar ve sıralama aynıysa tüm batch deterministiktir; ama batch’i karıştırırsanız bu determinizmi kaybedersiniz.
    • Makul bir sonuç ve doğruysa OpenAI modelleri rakip modellere ya da açık kaynak modellere kıyasla ciddi darbe alabilir.
      Şu anda bile güvenilirlik, LLM’lerin birçok işin temel akışında yaygın benimsenmesinin önündeki başlıca engellerden biri.
      GPT-4’ün doğası gereği deterministik olmadığı ve kararsız olduğu söylentisi doğruysa, çoğu şirketin belirli bir alana göre benzer performanslı bir açık kaynak LLM’i ince ayar yapması daha iyi olur.
      Alan odaklı modeller her zaman genel amaçlı modellerden daha iyi performans gösterdiği için, o tarafta performans kazancı da daha büyüktür.

  • GPT-3.5 bir MoE modeli ise bu, açık kaynak tarafı için epey umut verici bir işaret değil mi?
    İyi bir açık kaynak MoE modeli çıkarsa, mevcut decoder modellerinin bir varyantı gibi bir biçimde olabilir ve çok daha az kaynakla çok daha fazla iş yapılabileceği anlamına gelir.
    MoE modelini sıfırdan eğitmek gerekip gerekmediğini bilmiyorum.

    • Katılıyorum ve Meta’nın bu yönde gerçekten bir şeyler yapmasını umuyorum.
      FLOPs:bellek oranını düşüren yaklaşımlar, örneğin Soft MoE, CPU’da ya da en azından Apple Silicon’da çıkarımı da daha anlamlı hâle getirebilir.
    • Tek bir tüketici sınıfı GPU ile çalışan çıkarım ortamları için kötü olabilir.

  • Batch içindeki sekanslar birbirlerinin yönlendirmesini etkileyebiliyorsa, garip ve uygulanması zor bir yan kanal saldırısı olasılığı doğuyor gibi geliyor.

    • Bence doğru. Ancak pratikte kötüye kullanılması çok zor olur gibi.

  • Gerçekten harika bir çalışma. Birçok nedenle MoE'ye şiddetle karşı çıkıyordum, ama Substack yazıları ya da söylentilerin tekrarı değil, ikna edici kanıt ilk kez görüyorum
    GPT-4'ün deterministik olmadığını hiç bilmiyordum; günde yaklaşık 2 saat kullanıyorum
    Neden üstünkörü bakınca fark etmenin zor olduğunu anlıyorum. Hafızada “hissiyatı” benzer ve benzer kelimeleri çok kullanıyor, ama biçim tamamen farklı; bazı anahtar kelimeler aynı kalırken eş anlamlı ifadeler gibi değişiyor

    • MoE araştırmaları uzmanı değilim, ama Soft MoE makalesinde yazanları görünce kontrol etmem gerektiğini hissettim
      Bağlantı verilen gist örneğine bakınca deterministik olmayan çıktılar gerçekten çok benziyor: https://gist.github.com/152334H/047827ad3740627f4d37826c867a...
      Rastlantısallığın sınırlı olması gerektiğinden bu kısım en azından şaşırtıcı değil
      OpenAI'ın bir gün bu rastlantısallığı azaltmanın bir yolunu bulacağını düşünüyorum. ChatCompletions'a logprobs'u yeniden ekleyeceklerine dair açık bir taahhütleri de var, bu yüzden daha da olası görünüyor
    • GPT-4 web sohbetini günde iki saat kullanıyorsan bu olabilir
      Aynı girdilerle API'yi tekrar tekrar çağırarak program geliştiriyorsan deterministik olmamayı kaçırmak zor
    • MoE'ye neden güçlü biçimde karşı çıktığını merak ediyorum
    • Ne için kullandığını merak ediyorum. Eklentileri çok kullanıp kullanmadığını da merak ediyorum
      Bu kadar çok kullanan birinin, bu hafta çıkan özellik paketi de dahil olmak üzere ne tür içgörüler edindiği ilgimi çekiyor

  • MoE, Mixture of Experts, yani uzmanlar karışımı anlamına gelir

    • Teşekkürler. Margin of Error sanmıştım
      Yazının ortalarına doğru kısaltmayı neredeyse tesadüfen açıyor; hedeflenen okur kitlesi uzmanlar karışımını bilenler gibi, ben de bunun içinde değilmişim

  • GPT-3.0'ın davinci-instruct-beta modelleri 2021'in başlarından itibaren zaten deterministik olmayan logprobs döndürüyordu
    Bu bir tahmin ve CUDA'nın kendisinde de sık sık determinizm dışı hatalar oluyor
    text-davinci-001 ve text-davinci-002, FeedMe ve SFT ile eğitilmişti; text-davinci-003 ise RLHF idi
    Modelin kendisi de yüksek sıcaklıklarda daha büyük varyansa sahip

    • Temel modeller, yani davinci ve code-davinci-002 için durum nasıl?

  • “Bu token'lar çoğu zaman uzman tamponundaki kullanılabilir yerler için birbiriyle yarışır” ise, uzun kod istediğimde ChatGPT'nin fonksiyonların yerine sık sık yalnızca placeholder koymasının nedeni de bu mu?

  • “Bu token'lar çoğu zaman uzman tamponundaki kullanılabilir yerler için birbiriyle yarışır” deniyor; o zaman yük yüksek olduğunda sonuçların değiştiği anlamına mı geliyor?
    Bazen çıktı kalitesinin değiştiği hissi de yüksek yük ile açıklanabilir mi?

  • MoE, Mixture of Experts anlamına gelir