GPT-OSS-120B'yi NVIDIA GPU'larda Saniyede 500+ Token Hızında Çalıştırma

• OpenAI'nin açık kaynak LLM'i olan GPT-OSS-120B, NVIDIA GPU ortamında saniyede 500'den fazla token işleme performansı için optimize edildi.
• TensorRT-LLM, vLLM, SGLang gibi çeşitli inference frameworkler paralel olarak test edilerek hem Hopper hem de Blackwell mimarileri desteklendi.
• Uyumluluk hataları giderildi, Harmony gibi yeni yanıt formatları entegre edildi, KV cache-aware routing ve Eagle tabanlı speculative decoding gibi optimizasyonlar uygulandı.
• Tensor paralelleştirme ile uzman paralelleştirme karşılaştırıldı; düşük gecikme için tensor paralelleştirme tercih edildi ve Blackwell'de TensorRT-LLM MoE backend kullanıldı.
• Gelecekte performansı artırmak için küçük draft modeller kullanan speculative decoding de dahil olmak üzere ek optimizasyonlar planlanıyor.

---

Genel Bakış

• OpenAI'nin yeni açık kaynak büyük dil modeli GPT-OSS-120B yayınlandığında, Baseten en yüksek performansı hedefleyerek optimizasyon çalışmalarına başladı.
  • Baseten, OpenAI'nin resmi launch partneridir.
• OpenRouter'da paylaşılan gerçek kullanıcı verileriyle, NVIDIA GPU tabanlı ortamda rakiplerin önüne geçen bir performansın kanıtlandığı gösterildi.
• Baseten'in esnek inference stack'i ve model mühendisleri uzmanlığıyla saatlik aralıklarla optimizasyon yamaları hızla uygulandı.
• Yazının ilk yayınlanmasından yalnızca birkaç saat sonra bile saniyede 100 ek token artış sağlandı ve %100 uptime korunabildi.

Performans Optimizasyonu Çabaları

• TensorRT-LLM, vLLM, SGLang gibi farklı inference framework'lerinde kapsamlı test ve benchmark çalışmaları gerçekleştirildi.
• Hopper ve Blackwell GPU mimarileri ile uyumluluk eşzamanlı olarak sağlandı.
• Baseten'in Flexible Inference Stack'i ile NVIDIA Dynamo dahil olmak üzere kritik bileşenler entegre edildi.
• KV cache-aware routing ve Speculative decoding (Eagle tabanlı) gibi doğrulanmış performans optimizasyon teknikleri sürekli olarak uygulandı.

Aşağıda SOTA performansla tam bağlam penceresi (context window) desteğini aynı anda hedeflemek için atılan ana adımlar yer alıyor.

Adım 1: İlk Çıkarım

• Ne olursa olsun, hızlıca bir başlangıç çıkarımı (baseline inference) çalıştırmak ilk adım oldu.
• Aynı anda birden fazla mühendis, GPU üzerinde vLLM, SGLang ve TensorRT-LLM testlerini paralel yürüttü.
• En iyi performansı gösteren TensorRT-LLM’in hızlı çalıştırılması sağlandı.
• Hopper (en fazla H100 GPU'nun bulunduğu mimari) ve Blackwell (B200 GPU ile daha yüksek hız sunan mimari) tarafında TensorRT-LLM desteği sağlandı.
• Baseten Inference Runtime'un esnekliği sayesinde yeni mimari modellere uyum ve stack içindeki araçların hızlı değişimi kolaylaştı.

Adım 2: Uyumluluk Hata Düzeltmeleri

• Yeni model mimarileri devreye girdiğinde, framework entegrasyonunda sıkça hata çıkıyor.
• GPT-OSS'ta Harmony gibi yeni yanıt formatları eklendiği için mevcut framework'lerle entegrasyonda uyumluluk hataları görüldü.
• Hız ve doğruluk hedefleri birlikte tutulması için yinelenen düzeltme ve test döngüleri uygulandı; etkili düzenlemeler açık kaynağa katkı olarak eklendi.
• Küresel açık kaynak topluluğunun iş birliğiyle, farklı optimizasyon yolları ve hata düzeltmeleri hızlıca ilerliyor.

Adım 3: Model Yapılandırma Optimizasyonu

• OpenAI, GPT-OSS-120B'nin tek bir H100 üzerinde çalışabileceğini belirtse de, pratikte performans için 4-8 GPU paralelleştirme daha avantajlı oldu.
• Tensor Parallelism gecikmede (latency), Expert Parallelism ise sistem throughput'u konusunda güçlü.
  • Baseten için hedef gecikmeyi optimize etmek olduğu için Tensor Parallelism seçildi.
• Blackwell'de, önceki Triton backend'ine kıyasla CUDA kernel performansını artıran TensorRT-LLM MoE Backend uygulandı.
• Hopper ve Blackwell için ayrı ayrı optimize edilmiş ayarlar yayınlandı; Model API'de Blackwell tabanlı ayarlar benimsendi.

Ek Performans Optimizasyonları

• Sadece ilk optimizasyon turuyla SOTA düzeyinde throughput ve gecikme yakalanmasına rağmen, geliştirme payı hâlâ büyük.
• Yaklaşan ana güncelleme, Speculative Decoding'in devreye alınması.
  • Bu yöntemde daha hızlı küçük bir “draft” model, tahmini tokenları üretir; ana model bunları doğrular.
  • Baseten, Eagle 3'ü öneriyor ancak çıkarım stack'inde 10'dan fazla algoritmayı duruma göre esnek biçimde çalıştırıyor.
• Speculative decoding, tek seferde birden fazla tokeni çıkararak daha verimli hız artışı sağlar.

[jjw951215]

Keşke bana da yalnızca küçük bir tane, sevimli bir H100 verilseydi...

[GN⁺]

Hacker News Yorumları

• yaygınca erişilebilir H100 GPU'lar

  Bunu görünce evdeki parçalarımı taradım ama ne kadar arasam da 25.000 dolarlık bir H100 GPU'nun neden bulunmadığını merak ettim.

  • NVIDIA'nın ürün sayfasında H100'ün gerçekten bir GPU olarak sınıflandırıldığını doğruladım. Artık “oyun odaklı kullanılsa da LLM çıkarımını yalnızca çok sınırlı biçimde yapabilen tüketici sınıfı donanım” ile “AI eğitimi veya LLM çıkarımı birincil amaçlı, iş odaklı profesyonel donanım” ayrımını daha net yapacak bir adlandırmaya ihtiyaç olduğuna inanıyorum.
  • Ollama ile 20B modelini 8 adet TitanX kartında (2015 modeli) koşturdum. Ollama, toplam 15 GB VRAM'i sekiz karta eşit biçimde dağıttı ve token hızı okumadan daha yüksekti.
  • Bu tür GPU'ları kiralamak gerçekten çok kolay. Uzun süre boyunca 24/7 GPU çalıştırmayacaksanız, doğrudan satın almaktan barındırma kiralamak çok daha ekonomik. Kişisel kullanım için en yeni veri merkezi sınıfı kartları kullanma ihtiyacım da pek olmaz; böyle durumlarda Mac Studio ya da Strix Halo yeterli olur ama hız biraz daha düşüktür.
  • Bu yorum bugünümün keyfini kaçırmadı tam tersine güzelleştirdi. Kesinlikle veri merkezi perspektifinden bahsediliyor; benim kasamdaki en hızlı donanım muhtemelen eski bir iPhone 8.
  • “Evinizde 25.000 $'lık bir GPU yok” demek, gerçekten de böyle bir şeyin satın alınabileceği anlamına gelir. Yani yalnızca stokta bulunduğu ya da temin edilebildiği anlamındadır; bu, onu almak için bu kadar para biriktirdiğin anlamı taşımaz.

• MacBook Pro (M4, 128 GB RAM) ile Atlantik’i geçen bir uçakta GPT-OSS-120B kullandım.
  Bağlam penceresi küçük ve toplam token sayısı azsa hızlıdı. 10.000 tokeni aşınca hemen her şey yavaşladı ve kuyrukta birikti.
  MCP'ler, web araması ve URL patch gibi şeyler artık LLM kullanım deneyiminde çok kritik. Bu özellikler yoksa LLM'in pratik faydası da ciddi oranda düşüyor.
  Önceden çevrimdışı kullanım için ayarlanmış CLI/TUI kodlama araçları (opencode vb.) modelle birlikte güvenilir şekilde çalışmadı.
  OSS modellerin, önceki yorumlarda çokça bahsedilenlerin dışında da dikkat çeken şeyleri var:

  • Eskiden bile Vikipedi'yi yerel olarak saklayıp kullanabiliyorduk; bu yüzden yakında çok fazla verinin MCP ile açılıp yapay zekâların tıpkı “web araması” gibi yerel olarak arama yapacağını düşünüyorum. Web aramalarının %99'u aynı 100-1000 site içinde gerçekleşiyor. Özetle yalnızca birkaç GB saklamak bile çoğu şeyi kapsayabildiğinden telif hakkı sorunları kalır.
  • Ollama, LMStudio ve llama.cpp'den hangisinin kullanıldığını merak ediyorum ggerganov tweeti
  • iogpu.wired_limit_mb ayarını nasıl yaptınız merak ediyorum. Varsayılanda RAM'in yaklaşık %70'i, yani 90 GB civarı GPU çekirdeği tarafından kullanılabiliyor. Daha verimli kullanmak için bu ayarın değiştirilmesi gerekiyor.
  • Bunu M2 Max işlemci ile yaptım. Kısa konuşmada saniyede 60'tan fazla token gördüm ama uzadığında 30'a kadar düştü. Bu hız düşüşünün nedenini merak ediyorum. Isı yönetimi sorunu gibi görünmüyordu.
  • Bunu compute-bound prefill (CPU bant genişliği/hesap oranı yüksekken) ve decode farkı olarak düşünüyorum. 10k bağlamda bile ilk token'e kadar 0.5 saniyeden az sürüyor.

• Birkaç mühendis vLLM, SGLang ve TensorRT-LLM'i paralel denedi. TensorRT-LLM'in en hızlı olduğu söyleniyor ama genelde kurması en zor o; hem yeni mimarileri iyi yansıtmıyor hem de modeli üretim ile bire bir aynı donanım-sürücü-kütüphane yığınında doğrudan derlemeyi gerektiriyor, bu da oldukça zahmetli. Multimodal bir süre neredeyse mümkün değildi ve önde gelen bir Llama multimodal modeli bile düzgün çalışmıyordu. Bunun değerinin olup olmadığı tartışılır; örneğin GPT-OSS-120B'yi H100'de vLLM ile çalıştırırsanız düzgün çalışır ve token başına tutarlı şekilde 130~140t/s üretir. Başlığa bakınca tek bir GPU'da 500t/s beklenebilir sanılıyor ama gerçekte tensör paralel kurulum kullanılıyor. GPT-OSS için TRT-LLM'i ayrıca paketlemiş olmaları da biraz komik; TRT-LLM zaten biraz kafa karıştırıcı bir araç.

  • TRT-LLM deneyiminde DX açısından da çözülmesi gereken çok şey var. Multimodal çalışırken halen vLLM kullanıyoruz. Ama bizdeki gibi yüksek hacimli, düşük gecikmeli trafiklerde benchmarklarda TRT-LLM hep daha iyi çıktığı için bu tarafa çok yatırım yaptık.

• GPT-OSS 20B'nin kurulumu gerçekten kolaydı. Llama sayesinde Mac'imde 5 dakikada çalıştırabildim.

  • CPU kaynağı yeterliyse 120B de zor olmadan çalışıyor. Evdeki LLM CPU inference sunucusuna GGUF dosyası indirebilir, git pull yapıp yalnızca llama-server'ı yeniden derlersiniz; 40t/s herhangi bir ayar olmadan, 50t/s az biraz ayarlama ile alındı. Ne yazık ki 120B için zaten daha iyi modeller çıktı, bu yüzden çalıştırmak bir zorunluluk değil. ggerganov ve llama.cpp ekibinin kişisel hesaplama ortamlarında da LLM kullanımını demokratikleştirmesi çok kıymetli.
  • LLM ayarı zor denir ama modelden ayar yaptırmak mümkün değil mi? Bu kadar basit bir şeyi bile yapamıyorsa LLM ne anlama gelir, diye düşünüyorum.
  • Dünden beri test ettim, tüm oturumlarda yanlış gerçeğe dair bilgiler çıktı. Hız iyi, kullanım kolaylığı da iyi ama doğruluk kaybedilirse bunların anlamı yok.
  • Bellek yeterliyse 120B gerçekten çok kolay çalışır.

• Okurken anladım ki modeli düzgün çalıştırmak için ciddi bir ön işleme ve tuning gerekir, bu da benim farkında olmadığım bir şeydi. Sadece varsayılan ayarla iyi gideceğini sanıyordum.

  • Bence büyük şirketler, LLM lansmanı öncesinde popüler inference engine geliştiricileriyle daha yakın çalışıp kendi LLM'lerinin desteklenmesini sağlamalı. Hâlâ her şey deneysel olsa da geliştiriciler ucuz donanımlarda bile LLM yüklenmesi için gerçekten çok çalışıyor.

• ABD AI Action Plan'da “açık kaynak ve açık ağırlık yapay zekâ teşviki”nin “frontier AI'nın ifade özgürlüğünü ve Amerikan değerlerini koruması”nın hemen ardından geldiğini gördüm. Mantıklı olmasa da OpenAI OSS modellerini bu anda okumak biraz ürpertici. Yine de OSS model geliştiricisinin donanım konuşması iyi; çoğu geliştirici için donanım giriş bariyeri olduğu için bu yönde konuşulması sevindirici.

  • “Frontier AI’nın ifade özgürlüğünü ve Amerikan değerlerini korumalı” maddesi de vardı. Düşüncelerimi henüz toplamakta olduğum için biraz anlayış rica ediyorum. Yapay zeka modellerinin bir dünya görüşü taşıması kaçınılmaz ve ben daha çok batı-merkezli bir dünya görüşünü tercih ederim. Bunun daha iyi bir toplum ürettiği örnekler de çok. En azından model kendi dünya görüşünü belgeleyip o doğrultuda çalışıyorsa, kullanıcıyı gizlice sosyal mühendislik ile düşünceyi değiştirmeye itmeye çalışmaması şart.

• OS ve GPU bazında hangi LLM modelinin iyi çalıştığını net gösteren bir site biliyor musunuz? VRAM tahmininde en güvenilir ampirik formül parametre sayısı × (Precision/8) × 1.2 idi (referans)

  • Benzer bir hesaplayıcı yapmaya çalıştım ama gerçekte değişkenler (eşzamanlı trafik gibi) çok fazla. O formül de kabaca doğru ama eşzamanlı trafik artarsa iki katını hesaplamak daha güvenli.
  • Hugging Face'e donanım/yazılım spesifikasyonu girerseniz, her model detay sayfasında ilgili modelin kullanılabilir olup olmadığını gösteren bir özellik var Hugging Face ayarları
  • İnternet hızım da iyi, bu yüzden model ağırlık dosyalarını indirip birçok runner (llama.cpp, LM Studio, vLLM, SGLang vb.) ile doğrudan çalıştırmak en hızlı yol oldu. Runner, implementasyon, donanım gibi değişkenlerin çok fazlalığı nedeniyle hiçbir hesaplayıcının gerçek deneyimle birebir uymadığını gördüm. Tek yöntem direkt deneyip görmek.
  • Görüşleriniz için teşekkür ederim. Hesaplama zor ise, runner, donanım, model, parametre, kuantizasyon, çalışıp çalışmaması, tokens/s gibi metrikleri herkesin deneyip paylaştığı bir topluluk veritabanı sitesi kursak nasıl olur? Donanım/runner kombinasyonuna göre filtreleyip doğrudan kullanılabilirse çok pratik olur.

• GPT-OSS-120B modelinin gerçek dizi boyutu gibi net rakam bulmanın beklenmedik şekilde zor olduğunu söylemek istiyorum. Statik tipli bir dilde olsaydı dizi boyutunu göze çarptığı gibi anlayabilirdim; asıl ilgi çekici olan gerçek verinin (ağırlıklar dışında) nasıl aktığı ve çıktı akışının ne kadar geniş olduğu. Gigabit Ethernet'te “token çıkışı” için maksimum bant genişliğinin kaç t/s olduğu konusunda merak ediyorum; bu yüzden GitHub deposu gpt-oss içinde arıyorum ama net görünmüyor.

  • Sürekli token akışı için logitleri stream etmek (token sampling'i protokole uygun şekilde yaparken) isteyen uygulama örneklerini merak ediyorum. Ayrıca normalde gramer gibi şeyleri düzeltmek için sampling öncesi logit işleme ve token geri dönüşü yapmak gerekiyor ki sonraki çıkarıma geçilebilsin.
  • Hugging Face model ayarları'na bakınca değeri 2880 olan bir değer görünüyor (dtype çarpımı).

• GPT-OSS fp4 desteğiyle Blackwell çiplerinde daha hızlı çalışıyor. Rust ile eğitim/inference engine geliştiriyoruz; bu yüzden cudarc ve candle'a fp8, fp4 desteği ekliyoruz. cudarc PR, candle PR, Mixlayer motorlarının bu modelleri desteklemesi için bu çalışma devam ediyor.

  • RTX Pro 6000 kullanıcısıyım; gpt-oss-120b inference'ın şu an çalışıp çalışmayacağını merak ediyorum. PR'lar zaten birleştirilmiş gibi görünüyor ama pratikte bunu çalıştırabilir miyiz merak ediyorum.