Ask HN: ChatGPT 700 milyon kişiye hizmet verebiliyorsa, ben neden GPT-4’ün tek bir örneğini bile yerelde çalıştıramıyorum?

• Sam Altman, ChatGPT’nin haftalık yaklaşık 700 milyon kullanıcıya hizmet verdiğini açıkladı
• GPT-4 seviyesinde bir modeli yerelde çalıştırdığınızda VRAM yetersizliği ve hız düşüşü ciddi hale geliyor; OpenAI’nin bu kadar büyük kullanım hacmini nasıl düşük gecikme ve yüksek performansla işlediği merak ediliyor
• Basit bir GPU kümesinin ötesinde hangi model optimizasyonu, dağıtık işleme, özel donanım ve yük dengeleme tekniklerinin kullanıldığı öğrenilmek isteniyor

---

Temel yorumların özeti

1. Devasa dağıtık çıkarım yapısı

• Model Sharding
  • Parametreler birden fazla GPU’ya dağıtılarak saklanır
  • İstek geldiğinde her GPU, kendisine ait parametre bölümünde hesaplama yapar ve ardından sonuçlar birleştirilir
• Tensor Parallelism
  • Tek bir katmandaki hesaplamalar birden fazla GPU tarafından paralel yürütülür
• Pipeline Parallelism
  • Katmanlar birden fazla aşamaya bölünür ve bir boru hattı gibi sıralı ama eşzamanlı işlenir
• Karma paralel işleme ile GPU belleği ve hesaplama yükü optimize edilir

2. Bellek ve hız optimizasyonu

• Quantization: Parametreler daha düşük bit hassasiyetine dönüştürülerek VRAM kullanımı azaltılır
• Layer Offloading: Gerektiğinde bazı katmanlar CPU belleğine taşınır
• LoRA / Adapter Layers: Yalnızca belirli görevler fine-tuning ile ayarlanır; böylece tüm modelin yeniden yüklenmesi gerekmez
• KV Caching: Bağlam yeniden kullanılarak tekrar eden hesaplamalar ortadan kaldırılır

3. Özel donanım ve ağ yapısı

• En yeni NVIDIA H100, A100 ve bazı TPU sistemleri büyük ölçekte kullanılır
• GPU’lar arasında NVLink ve NVSwitch, kümeler arasında ise Infiniband ile ultra hızlı veri aktarımı sağlanır
• Veri merkezleri arasında küresel bir backbone network kurularak gecikme en aza indirilir

4. Coğrafi dağıtım ve yük dengeleme

• Dünyanın farklı bölgelerine GPU farm’lar yerleştirilir
• GeoDNS ile kullanıcı istekleri en yakın bölgeye yönlendirilir
• Trafik desenine göre GPU kümeleri dinamik olarak ölçeklendirilir
• Belirli bir bölgede yük yoğunlaştığında küresel trafik yeniden dağıtılır

5. İstek işleme optimizasyonu

• Batch Inference: Birden fazla kullanıcının isteği gruplanarak tek seferde çıkarım yapılır
• Ön işlemde küçük model kullanımı: Basit istekler küçük modellerle işlenir, yalnızca karmaşık isteklerde büyük model çağrılır
• Sonuç önbellekleme: Aynı prompt veya benzer isteklere ait sonuçlar önbellekten anında döndürülür
• Prompt engineering ile gereksiz token israfı önlenir

6. Operasyon ve maliyet optimizasyonu

• GPU kullanım izleme ve zamanlama ile atıl kaynaklar en aza indirilir
• Veri merkezlerinde güç verimliliği artırılır ve sıvı soğutma uygulanır
• Kuruma özel compiler ve runtime optimizasyonlarıyla çıkarım hızı artırılır
• Model güncelleme ve dağıtımı için otomatik pipeline’lar işletilir

Birleşik mimari akışına örnek

1. Kullanıcı isteğinin alınması → GeoDNS ile en yakın bölgeye yönlendirme
2. Ön işleme → Basit istekler küçük modele, karmaşık istekler ise büyük modele aktarılır
3. Dağıtık çıkarım işleme
   • Model sharding + tensor parallelism + pipeline parallelism uygulanır
   • GPU’lar arasında yüksek hızlı ağ üzerinden ara sonuçlar paylaşılır
4. Son işleme ve sonuç önbellekleme → Aynı veya benzer isteklere karşı önbellek kaydı tutulur
5. Yanıtın döndürülmesi → Sonuç 1~2 saniye içinde sağlanır

[popkins]

OpenAI tarafında yalnızca NVIDIA donanımı değil, AMD'nin MI300X'i de çıkarım için kullanılıyor; eğitimde sadece NVIDIA var ama
çıkarım tarafında yatırım maliyetine kıyasla VRAM sağlamaya nasıl olursa olsun çalışıyorlar
Microsoft tarafında da benzer şekilde, çıkarımda NVIDIA ve AMD'yi karışık kullanıyorlar

[popkins]

Özellikle Asya tarafındaki Azure bölgelerinde OpenAI'nin kullandığı AMD oranı NVIDIA 8 / AMD 2 civarında.

[GN⁺]

Hacker News görüşü

• Google'da bu tür sistemlerle doğrudan çalışan bir iş yapıyorum (kişisel görüşüm) ve zeki insanların problemin tüm yönlerini ciddi biçimde düşündüğünü kesin olarak söyleyebilirim. Daha fazla ayrıntı veremem ama çalışma arkadaşlarımın hazırladığı bazı materyalleri paylaşmak isterim. Hızlandırıcı mimarisi ve yüksek performans için optimizasyon yöntemleri hakkında harika bir açıklama scaling book'ta var. Özellikle çıkarım kısmını merak ediyorsanız inference bölümü yardımcı olur. Ek olarak unsloth rehberini öneririm. Çeşitli modelleri derinlemesine inceleyip optimizasyonlar buluyor ve bunları iyi derlenmiş şekilde sunuyor. Gemma 3n rehberi dışında da birçok rehberleri var

  • Biraz daha gizemden arındırarak anlatırsak, çıkarım çoğunlukla durum bilgisiz bir iştir. Bu yüzden eğitimde olduğu gibi yüz binlerce makine arasında bellek tutarlılığı ya da makine arızalarıyla uğraşmanız gerekmez. Sadece az miktarda veriyi çok büyük makinelere düzgün şekilde iletmeniz gerekir. Çalıştığım yerdeki araştırma makineleri 8 GPU'lu ultra yüksek performanslı sistemlerdi ve model toplam VRAM'e sığıyorsa her türlü işi düzgün yapabiliyordu. Büyük ölçekli genişlemenin gizli malzemesi "muazzam miktarda sermaye" idi. NVIDIA'nın altın kaplama DGX makineleri gönderdiği bile oldu; bunlar çok yoğun değildi ve aşırı pahalıydı. Büyük şirketlerin çoğunun sağlam RPC ve orkestrasyon sistemleri var, bu yüzden gerçekten zor kısım mesaj iletimi değil, modeli elinizdeki donanıma sığdırmak oluyor (bu benim uzmanlık alanım değil)

  • Modern büyük çıkarım rafları, iyi bilinen RDMA ve düşük gecikmeli ağ teknikleri, güçlü MLA ve önbellek optimizasyonlarının gizemli teknoloji gibi sunulmasına gerek yok. Bunlar zaten kamuya açık biçimde iyi anlaşılmış şeyler ve hatta büyük şirketlerin çok özel bir şey yapması bazen geçmişe uyumluluk yüzünden yük bile olabiliyor. Gerçekten önemli olan, büyük sistemleri işletmek için gereken yapı ve süreçleri iyi kurmak. Buna ekipman tedariki, SRE eğitimi, hatta yeni TPU'lar için RTL'ye kadar pek çok alan dahil. Biri 10 kat ileride olsa bunu hemen anlardınız (10 yıldır TOP-5 şirketlerde büyük ölçekli çıkarım deneyimi olan biri olarak)

  • "Biz tüm problemleri gerçekten ciddiye alan zeki insanlarız" ifadesi için, aslında 1970'lerin ana bilgisayar tarzı zaman paylaşımlı sistemini yaptıklarını söyleyebilirsiniz

  • Google'ın TPU sayesinde kendi model çıkarımını, NVIDIA kart kiralamaya kıyasla çok daha kârlı yapabildiğini merak ediyorum. OpenAI'nin GPU'larının çoğunu Microsoft ortaklığı üzerinden sağladığını biliyorum. Hem bağlantıları hem de kitabı ilgiyle okudum

  • "Bugün 'küçük' modeller bile donanım sınırlarına çok yakın çalışıyor" cümlesi etkileyiciydi. Bu, 60'lar ve 70'lerdeki "küçük programlar bile donanım sınırlarına göre çalışır" ifadesine benziyor. Yazılım mühendisliğinde optimizasyon ve verimlilik kaybolmuş olsa bile, LLM geliştirmede hâlâ yaşıyor

• Tek bir H100 20.000 dolar ve 80GB VRAM'e sahip. 2U raf sunucusuna bu kartlardan 100.000 dolarlık koyduğunuzu hayal edebilirsiniz. Böyle ekipman bir rafı doldurduğunda, CPU, RAM ve soğutma dahil raf başına maliyet 1 milyon dolar seviyesine gelir (işletme giderleri ve bakım personeli maliyeti hariç). "Ucuz" ekipman bile çok büyük ölçekli hesaplarla konuşuluyor. Yapay zeka balonu söndüğünde iyi yerel modelleri gerçekçi biçimde çalıştırabileceğimizi umuyorum. 10 yıl sonra böyle 100.000 dolarlık sunucuların eBay'de 3.000 dolara satıldığını ve elektrikçilerin garajlara ya da doğaçlama sunucu odalarına 240V hat çekme talepleri aldığını görmek şaşırtıcı olmaz

  • 10 yıl beklemenize gerek yok; şu anda eBay'de 10.000 doların altında DGX-1 alabilirsiniz. 256GB VRAM (HBM2), NVLink, 512GB RAM, 40 çekirdekli CPU, 8TB SSD ve 100Gbit HBA içeriyor. NVIDIA dışı markalı ürünler 6.000 dolara bile bulunabiliyor. Ama çok ağır, hayal edebileceğinizden daha gürültülü ve tek bir makine neredeyse bir 240V 16A hattın tamamını kullanıyor. Aynı zamanda saatte 13.000 BTU ısı yayıyor

  • Yapay zeka balonu patlamasa bile, bu sunucuların 10 yıl sonra eBay'e düşmesi muhtemel. Sonuçta veri merkezleri donanımlarını yeniliyor ve ikinci eli üçüncü taraflara satıyor

  • Kişisel olarak açık modellerin düşündüğümüzden çok daha az hesaplama kullandığından şüpheleniyorum. Son Mixture of Experts modellerinde top-k sampling, yani yalnızca bazı uzmanların (parametrelerin) etkinleştirilip değerlendirilmesi sayesinde, SOTA model bile non-MoE 70-80B bir modele göre çok daha fazla hesaplama gerektirmiyor

  • Kurumsal ölçekte yapay zeka sunumunda asıl soru "kullanıcılara nasıl hizmet verileceği" değil, yatırımcıların bir gün ROI bekliyor olması. Gereken altyapı, yatırım geldiği sürece istenen kadar kurulabilir. Optimizasyon olmasa bile ihtiyaç kadar depo ve raf inşa edilip hizmet verilebilir

  • Amerikalı olmadığım için 240V kısmı komik geldi

• Sizin birkaç bin dolarınız varsa onların onlarca milyar doları var. Ölçek farkı 1.000 ile 10.000.000.000 arasında. Verimlilikleri de ölçek sayesinde bir iki büyüklük mertebesi daha iyi. Ayrıca MacBook'ta (24GB RAM) bile GPT-4'ün ilk çıktığı dönemki performansına yakın yerel modeller çalıştırabilirsiniz. Performans karşılaştırma bağlantısı

  • 700 milyon kullanıcıyı günlere ya da haftaya yayarsanız, gerçekte aynı anda yalnızca 10 milyon oturum etkin olabilir. Tek bir kullanıcı bir haftalık hesaplama kaynağını biriktirip tek seferde kullanamaz ama hizmet sağlayıcı yatay ölçekleme ile sadece zirveye göre kapasite planlar. Bu yüzden aynı performans hedefinde yerel kurulum çok daha fazla donanım gerektirir

• Tek bir GPU düğümü bile çok yüksek FLOPs ve bellek bant genişliği sağlar. Az sayıda istek işlerken çoğu zaman GPU'nun ağırlık verilerini RAM'den hesap birimlerine akıtmasını beklersiniz. İstekleri batch halinde toplarsanız bir ağırlık paketi okunurken birçok istek paralel işlenebilir ve verimlilik en üst düzeye çıkar. Ayrıca modeli 8 bit ya da daha düşük formatlara sıkıştırarak aktarılacak veri miktarını azaltabilirsiniz; modern GPU'lar da 8 bit/4 bit işlemleri destekler. Mixture of Experts modelleri her token için parametrelerin yalnızca bir kısmını kullandığından daha az ağırlık yüklenir. speculative decoding tekniğinde daha küçük bir model birçok tokenı önceden tahmin eder, ardından asıl model bunlardan kendi seçimiyle uyuşanları kabul eder. Tüm bu optimizasyonlar birleşince etkileyici verim ortaya çıkar (Databricks çıkarım ekibi direktörlüğü deneyimine dayanarak)

• OpenAI'nin gizli soslarından biri milyarlarca dolarlık zarar. 2024'te 5 milyar dolar kaybetti. İlgili haber

  • Son zamanlarda agentic yaklaşım ortaya çıktığı için durum çok değişti. Eskiden 1 istek başına 1 işlem vardı, şimdi ise tek bir görev için yüzlerce işlem aynı anda yürütülüyor. Bu paralellik sayesinde OAI/Azure yerel modellere göre avantajlı

  • Eğer Ar-Ge'yi kapatıp sadece mevcut modelleri sunsalar başa baş noktasını yakalayabilirler gibi görünüyor

  • Esas noktayı yakalamışsınız. Microsoft'un 10 milyar dolara kadar çıkan yatırımı ön eğitim, Ar-Ge ve çıkarım maliyetlerini karşılasa da yine de milyarlarca dolar zarar edildi. Bu, VC tarzı büyüme odaklı kapitalizm

• Büyük ölçekli çıkarımda istekleri toplu işlemek, kişisel ortamdaki gibi kullanıcı başına GPU ayırmaya göre çok daha verimlidir. Orta seviye mühendislik hilelerini görmek isterseniz ekibimizin Fin AI blogunda yazdığı yazıya bakabilirsiniz. (OpenAI gibi şirketler muhtemelen burada olmayan özel teknikler de kullanıyordur.) İlgili yazı

  • Gerçek ana cevap bu. Yukarıdaki pek çok tartışmadan daha önemli olan, maliyeti gerçekten büyük ölçüde düşüren şey batch işleme. Örneğin tek bir isteği işlemek 50.000 dolara mal oluyorsa, batch sayesinde aynı 50.000 dolarla neredeyse kayıpsız şekilde 100 isteği aynı anda işleyebilirsiniz. Bir donanımın kaç kullanıcıyı kaldırabildiğini tam bilmiyorum ama muhtemelen yüzlerce kişiden söz ediyoruz. Yani maliyeti fiilen 50.000 dolardan 500 dolara indirebilirsiniz, tabii yeterli sayıda kullanıcı varsa. LLM işlemede darboğaz çoğu zaman ağırlıkları GPU'ya yükleme süresi olduğundan, her isteği ayrı ayrı çalıştırmak yerine birçok isteğin hesaplamasını birlikte işleyerek verim en üst düzeye çıkarılır. Mesela GPU önbelleğine 3 ağırlık kümesi (A, B, C) sığıyor ve 2 istek (1, 2) var diyelim. Olağan yaklaşım her istek için ağırlıkları tekrar yüklemektir, batch yaklaşımında ise ağırlıkları bir kez yükleyip birçok isteği hesaplarsınız. Ağırlık yükleme süresi ile hesaplama süresini karşılaştırdığınızda, batch öncesi ve sonrası hız farkı çok belirgin olur. Gerçekte ağırlık yükleme hesaplamadan çok daha yavaştır; dolayısıyla kullanıcı sayısı arttıkça fark büyür. Elbette daha fazla kullanıcıyı desteklemek için etkin durum belleği de gerekir, bu yüzden GPU kümesi başına kaç kullanıcı alınacağı dengelenmelidir. Sonuç olarak LLM sunum donanımı çok pahalıdır ama zaten elinizdeyse, yüzlerce kullanıcıya aynı anda neredeyse hiç performans düşüşü olmadan hizmet verebilir

• Haftalık 700 milyon kullanıcı olması gerçek yük hakkında çok şey söylemez. ChatGPT kullanıcılarının çoğu günde bir saat, haftanın her günü kullansa bile zamanın %96'sında sistem boştadır. Birçoğu daha az karmaşık modeller kullanır. Özellikle "haftalık kullanıcı" denmesi, günlük aktif kullanıcılar arasında bile bir kısmının günde bir kez bile kullanmadığı anlamına gelir. Asıl zorluklar şunlardır: 1) modeli belleğe sığdıran ve tokenları yeterince hızlı işleyebilen sunucular kurmak, 2) zirvedeki toplam token işleme miktarını karşılayacak kadar sunucuya sahip olmak, 3) tüm istekleri sunucular arasında verimli şekilde dağıtmak. Ayrıntılar var ama son madde aslında bir arama motoru işletmeye de benziyor. Tüm durum bilgisi sohbet geçmişinde olduğundan aynı sohbetin mutlaka aynı sunucu tarafından işlenmesi gerekmiyor. "Thinking..." mesajını gördüğünüzde model gerçekten hesap yapıyor mu, yoksa kuyrukta sunucu mu bekliyor, bunu dışarıdan anlayamazsınız

• LLM'lerin büyük ölçekte iyi çalışmasının en önemli sırlarından biri "batch size". Güncel LLM'lerin çoğu "Mixture of Experts" mimarisi kullanıyor; yani toplam parametrelerin yalnızca bir kısmı anlık olarak etkinleşiyor. Bu sayede büyük batch'ler çok daha verimli oluyor. GPT-4'ü evde çalıştırmak isteseydiniz, modelin tamamını VRAM'e sığdırmanız gerekirdi; bu da H100 gibi birkaç GPU isterdi (kart başına yaklaşık 40.000 dolar). Ama bireysel kullanım böyle kartları düzgün değerlendiremez. Bu biraz da "Apple milyarlarca kişiye iPhone üretebiliyorsa ben neden garajımda bir tane bile yapamıyorum?" demek gibi

  • Kısacası, çıkarım yükü çok sayıda kullanıcıya yayıldığı için verimli çalışıyor

  • O zaman az kullanılan parçaları ana bellekte, sık kullanılan parçaları VRAM'de tutan bir yapı mümkün mü diye merak ediyorum

  • Benzetme çok yerinde

• Evde de uygulanabilen ve Cerebras performansında önemli rol oynayan bir numara speculative decoding. Bu yöntemde çok daha küçük bir taslak model tokenları çok daha düşük hesaplama ve bellek maliyetiyle tahmin eder, ardından ana model bunlardan kendi üreteceğiyle uyumlu olanları kabul eder. İyi kurulmuş bir sistemde 3 kata kadar hızlanma görülebilir. Ayrıca structured output için tahmin edilebilir tokenları atlayan "fast forwarding" uygulanabilir; örneğin JSON gibi çıktılarda başlangıç biçimi önceden doldurularak yine 3 kata kadar hız kazanılabilir

  • LM Studio'da gpt-oss-120b ile gpt-oss-20b'yi birleştirip speculative drafting deneyebilirsiniz. Ama hissedilen performans artışı bana çok yüksek gelmedi

• LLM çıkarımının özü matris-vektör çarpımıdır. Birden çok sorguyu aynı anda işlemek gerektiğinde, her sorgunun vektörlerini toplayıp bir matris oluşturabilir ve matris-matris çarpımıyla hepsini birlikte hesaplayabilirsiniz. Donanım açısından bakınca, matris-vektör çarpımını defalarca tekrar etmek yerine tek bir matris-matris çarpımı çok daha verimlidir. Batch işlemenin özü budur. İkinci numara speculative decoding'dir. Çıkarımda iki aşama vardır: istem işleme ve token üretimi; ikisi de aslında aynı yapıya sahip birer forward pass'tir. İstem işleme matris-matris çarpımı olarak paralelleştirilebilir ve sadece son çıktı token üretiminin başlangıcında kullanılır. Ama gelecekteki tokenları önceden bilemediğiniz için normalde bunu paralelleştiremezsiniz. Bu yüzden hızlı bir taslak modelle ileriye dönük N token tahmin edilir, bunlar giriş istemine eklenir ve ana model üzerinde paralel bir forward pass çalıştırılır. Üretilen N token içinden eşleşen ilk noktaya kadar olanların tamamı doğrudan geçerli token olarak alınabilir. Teoride bu, çıkarım hızında 2 ila 4 kat artış sağlayabilir. Bunu iş olarak bizzat uygulamadım ama ek olarak sorgu uzunluklarına göre paralel gruplama veya gerçek zamanlı yük dengeleme gibi tekniklerin de kullanıldığını tahmin ediyorum (çünkü tüm istekler aynı uzunlukta olmuyor ve kaynak dengesizliğini önlemek gerekiyor)