GPU’yu Anlamanın Yolları
(jax-ml.github.io)- GPU, modern makine öğreniminde merkezi bir rol oynar ve yüksek hızlı matris çarpımı işlemlerine özelleşmiş çok sayıda Streaming Multiprocessor(SM) ile HBM (yüksek bant genişlikli bellek) birleşiminden oluşan bir yapıya sahiptir
- GPU’nun SM’leri, Tensor Core (matris çarpımı) ve CUDA Core (vektör işlemleri) olarak ayrılır; büyük ölçekli paralel hesaplama ve esnek programlamayı destekler
- GPU ile TPU, iç mimari ve ağ yapısı açısından farklılık gösterir; GPU genel amaçlı kullanım ve ölçeklenebilirlik açısından güçlüdür, ancak en iyi performansa ulaşmak için daha fazla değerlendirme gerektirir
- Bir düğüm (Node) içinde NVLink ve NVSwitch ile GPU’lar arasında ultra yüksek hızlı iletişim mümkündür; düğümler arasında ise InfiniBand gibi ağlarla bağlanarak büyük ölçekli dağıtık eğitime yanıt verir
- GPU’daki kolektif işlemler (Collectives) (ör. AllReduce, AllGather vb.), donanım mimarisi ve ağ katmanına göre performans açısından büyük farklılık gösterir ve pratikte teorik bant genişliğinin altında kalma eğilimindedir
GPU nedir?
- En yeni ML (makine öğrenimi) GPU’ları (ör. H100, B200), matris çarpımı işlemlerine özelleşmiş onlarca ila yüzlerce Streaming Multiprocessor(SM) ile hızlı HBM belleğin birleştiği bir yapıya sahiptir
- Her SM içinde Tensor Core (matris çarpımı), Warp Scheduler (vektör işlemleri), SMEM (çip içi önbellek) bulunur
- TPU’dan farklı olarak GPU, 100’den fazla SM üzerinden daha esnek ve büyük ölçekli paralel işlem yapabilir
SM ayrıntılı yapısı
- SM, 4 adet alt bölüme ayrılır ve her alt bölümde sırasıyla Tensor Core, CUDA Core (vektör işlemleri), Warp Scheduler, register file gibi bileşenler bulunur
- CUDA Core vektör aritmetik işlemlerinden (SIMD/SIMT), Tensor Core ise matris çarpımından sorumludur
- Tensor Core FLOPs değeri ezici biçimde yüksektir ve düşük hassasiyetli işlemlerde işlem hızı daha da artar
- En yeni GPU’larda (ör. B200), büyük kapasiteli TMEM eklenerek geniş Tensor Core girdileri desteklenir
CUDA Core’un esnekliği
- GPU’nun CUDA Core yapısı SIMT (Single Instruction Multiple Threads) modelini kullanır; tek bir komut birden çok thread üzerinde paralel yürütülür
- Her thread bağımsız bir komut işaretçisine (program counter) sahip olduğundan koşullu dallanma gibi esneklikler sağlar; ancak warp içi komut ayrışması (divergence) fazlaysa performans düşer
- Her CUDA Core, bağımsız durum ve bellek erişimi açısından serbesttir (TPU ise yalnızca ardışık belleği işleyebilir)
Zamanlama/paralellik
- SM, çok sayıda warp’ı (en fazla 64) zamanlayarak eşzamanlı yürütür; her warp scheduler aynı anda tek bir programı çalıştırır
- Bu yapı sayesinde GPU, oldukça esnek olmasının yanında yüksek eşzamanlı işlem kapasitesi de sunar
GPU bellek yapısı
- GPU’da en büyük bellek HBM’dir; bunun dışında L2/L1(SMEM)/TMEM/register gibi bir bellek hiyerarşisi bulunur
En yeni GPU özelliklerinin özeti
- SM (Streaming Multiprocessor) sayısı, saat hızı, bellek, FLOPs, bant genişliği (BW) gibi değerler modele göre değişir
- Bellek kapasitesi (HBM), bant genişliği ve FLOPs (floating point/tamsayı/düşük hassasiyet) gibi ölçütler nesiller ilerledikçe artar
- Tabloda (atlanmış) öne çıkan özellikler: Blackwell(B200) için HBM 192GB, HBM BW 8.0TB/s, FP8 FLOPs 4.5e15 vb.
- Her nesilde register ve çip içi önbellek (SMEM) kapasitesindeki artışlar ile TMEM eklenmesi gibi donanım gelişmeleri açıkça görülür
GPU/TPU karşılaştırması
- GPU, genel amaçlı olup çok sayıda küçük SM (paralel birim) halinde modülerdir; donanım kontrolü fazla olduğu için anlamak/optimize etmek daha zordur
- TPU, az sayıda büyük Tensor Core ve çok sayıda vektör ALU(VPU) ile kurulur; tek iş parçacıklı kontrol yapısı sayesinde donanım sadeleşir ve maliyet düşebilir
- Bu nedenle TPU’da derleyici optimizasyonu zorunludur; GPU’da ise birden çok kernel bağımsız çalıştırılabildiği için kullanım kolaylığı daha yüksektir
- Performans/fiyat açısından son dönemde H200 GPU, TPU v5p’ye göre FLOPs/s bakımından 2 kat, HBM açısından 1.5 kat, fiyat olarak ise yaklaşık 2.5 kat düzeyindedir
- TPU, VMEM (çip içi önbellek) bakımından daha büyük ve daha hızlıdır; bu da LLM model çıkarımı gibi senaryolarda önemli avantaj sağlayabilir
GPU donanım quiz’i Soru-Cevap özeti
- H100’ün fp32 CUDA core sayısı toplam 16,896’dır (132 SM x 4 x 32), B200’de ise 18,944’tür
- Vektör işlem FLOPs değeri H100 için en fazla 33.5TFLOPs/s düzeyindedir; bu, Tensor Core’un matris çarpımı FLOPs değeriyle (990TFLOPs/s) karşılaştırıldığında 30 kat daha düşüktür
- H100’ün L1/SMEM ve register toplam kapasitesi 66MB, TPU VMEM ise 120MB’dir
- Bandwidth (bant genişliği) ile FLOPs oranı (teorik işlem yoğunluğu) H100/B200 için yaklaşık 280-300 olup TPU’ya benzerdir
GPU ağ yapısı (iletişim mimarisi)
Düğüm/cluster yapısı
- GPU düğümleri genellikle 8 GPU’dan oluşur ve NVLink (ultra hızlı) ile NVSwitch (switch) üzerinden tam bant genişliğiyle doğrudan bağlanır
- Düğümler arasında ölçek büyütmek için InfiniBand (Ethernet vb.) kullanılır
- En yeni (Blackwell) GPU’lar, 72 Node’a kadar genişleyebilen bir yapıya sahiptir
Ağ katmanlarına göre özellikler
- Düğüm içi (NVLink alanı): GPU başına çıkış bant genişliği 450GB/s (H100), 900GB/s (B200); NVSwitch başına en fazla 1.6TB/s
- Düğüm üstü (InfiniBand Leaf/Spine): Leaf Switch (8 adet) ~ Spine Switch (16 adet) yapısı; GPU~GPU arasında teorik olarak 400GB/s tam bant genişliği korunur
- SuperPod gibi büyük mimarilerde 1024 GPU (128 düğüm), GB200 (72GPU Node) ise 9 kat artırılmış bant genişliğiyle (3600GB/s) öne çıkar
Ağ performansı özeti
- Teorik olarak ağ yapısı (Full Fat Tree), düğümden düğüme de azami bant genişliği sağlayacak şekilde tasarlanır
- Donanım port kısıtları vb. nedenlerle 1024~4096 GPU ölçeğine çıkıldığında Spine/Core Switch eklenerek katmanlı yapı kullanılır
- Düğüm içi bant genişliğinden (450GB/s) düğümler arası bant genişliğine (400GB/s) geçiş = kolektif işlemlerde performans farkı
Kolektif işlemler (Collectives) yapısı
- AllGather, AllReduce (toplama), AllToAll (dağıtım) gibi yüksek seviyeli kolektif işlemler desteklenir
- Düğüm içinde NVLink ile doğrudan bağlı oldukları için en iyi performans elde edilebilir (teorik B/W); düğümden düğüme ise InfiniBand üzerinden iletişim kurulur
- NVIDIA’nın NCCL, NVSHMEM kütüphaneleri kullanılır
Kolektif işlem performans analizi
- AllGather/ReduceScatter: B/W (H100 için 450GB/s) düzeyinde ring yöntemiyle uygulanır; küçük mesajlarda tree yöntemi de mümkündür
- AllToAll: Her GPU veriyi doğrudan hedef GPU’ya gönderir; B/W’nin N’e bölünmesi yaklaşımı kullanıldığından düğüm içinde teorik olarak 2 kat daha hızlıdır
- Gerçek ölçümlerde AllReduce yaklaşık 370GB/s seviyesindedir; yani donanımın azami değerine ulaşamaz
- TPU’ya kıyasla ancak büyük hacimlerde (onlarca MB ~ GB) donanımın peak bandwidth düzeyine yaklaşılır
Genel özet ve içgörüler
- GPU’nun güçlü yönleri genel amaçlı kullanım ve ölçeklenebilirliktir; ancak donanım/ağ yapısına bağlı olarak performans optimizasyonunun zorluğu ve gözlemlenebilirliği TPU’ya göre daha yüksektir
- Ağ yapısı (Intra-Node/NVLink/InfiniBand/Leaf/Spine vb.), büyük ölçekli eğitim performansının anahtarıdır; pratik bant genişliği ile teorik bant genişliği arasındaki farka dikkat etmek gerekir
- Kolektif işlemler ve ağ yapısının anlaşılması, çok büyük dağıtık model eğitimi/servis sunumu için temel gerekliliktir
- Pratik benchmark’lar ve donanımın ayrıntılı yapısının anlaşılması temelinde, performans darboğazlarını ve en uygun koşulları saptayan bir süreç gereklidir
1 yorum
Hacker News yorumu
Bu yazının ve çeşitli belgelerin biraz belirsiz olduğunu düşündüm; özellikle GPU anlatılırken terimler sık sık muğlak kullanılıyor. Örneğin ilk görselde “Warp Scheduler”, TPU’nun VPU’suna benzer bir SIMD vektör birimi gibi açıklanırken 32 adet “CUDA Core” olduğu söyleniyor, ama burada “CUDA core”un ne olduğu net biçimde açıklanmadığı için anlatımın asıl konusu doğru aktarılmıyor. Bu tür birleşik hatalar yüzünden yeni başlayanlar ya da kavramları öğrenmeye çalışan okurlar için hâlâ anlamak zor, buna karşılık konuya zaten biraz hakim olanlar için de bunlar bildikleri şeyler. Taslak aşamasındaki bir içerik bile yayımlanırken terimler tek tek cerrahi hassasiyetle ele alınmalı, terimler karıştırılmamalı ya da birbirinin yerine kullanılmamalı. Analoji kullanılacaksa da dikkatli olunmalı. Ayrıca MXU (matris işlem birimi) gibi terimlerin ek açıklama ya da bağlantılarla kolayca bulunabilir olması gerektiğini düşünüyorum. Bugünlerde bu görevi yapay zekaya da verebiliyoruz ama bu biraz üzücü bir durum.
Yazar olarak doğrudan yanıt veriyorum; eleştirilerin çoğuna katılıyorum. Açıklamalarda doğruluğu artırmaya çalıştıkça bunun “ahlaki gerçek” ile dengesini kurmak konusunda hep zorlanıyorum. Mesela “NVIDIA’nın CUDA Core adını verdiği 32 SIMD (tek komut-çoklu veri) vektör birimi (ALU) içeren, TPU VPU’suna benzer birim” diye yazabilirim ama bu kez cümle uzuyor ve vektör birimi gibi başka terimlerin tanımı yine eksik kalabiliyor. Dipnot kullanmaya çalışıyorum ama okurun her birine tıklamasını beklemek de zor; kenar notlarını HTML’de uygulamak da kolay değil. MXU gibi terimleri önceki bölümde tanımlamıştım ama herkesin tüm bölümleri okuyacağını varsaymak da gerçekçi değil. “Warp Scheduler” terimi de aslında kendi başına muğlak; çünkü birden fazla rolü aynı anda ifade ediyor olabilir (zamanlayıcı, dispatch unit, SIMD ALU). Bunun nedeni de NVIDIA’nın bu birleşik birime ayrı bir ad vermemesi. İleride daha da iyileştirmeye çalışacağım; kolay bir denge değil.
LLM’ler bu tür terim bağlantısı zorluklarını aşmak için epey iyi bir araç. Bir terimi aradığınızda peş peşe bilmediğiniz başka terimler çıkıyorsa, nereden başlamanız gerektiği konusunda iyi yönlendirme yapabiliyor.
Neredeyse her şey Google TPU sistem mimarisi belgesinde yer alıyor.
Ciddi ciddi sormak istiyorum: bilgisayar mimarisi konusunda uygun arka plan bilgisi düzeyi sizce ne olmalı? SIMD kavramının kendisi bile 50 yılı aşkın süredir var. İlgili materyalin girişinde LLM ve Transformer mimarisini anlamanın temel kabul edildiği görülüyor ama bilgisayarın nasıl çalıştığını bilmenin gerekmediği söyleniyor; yine de CPU’nun temel çalışma mantığını bilmek gerekmiyor mu diye düşünüyorum.
Bu içerik, makine öğrenmesi alanında çalışanlara yönelik yazılmış bir kitabın bir bölümü.
Bir şey açık kaynak değilse ya da birden çok tedarikçi arasında çapraz kullanılabilen bir teknoloji değilse, ona yatırılan zamanı gerekçelendirmek bana çok zor geliyor. Nvidia çiplerini iyi kullanabilme işini, geçmişteki SAP ABAP danışmanlığına benzetiyorum. Elbette bu alanda çok para kazanılabiliyor ama tarihsel olarak bakınca bu tür uzmanlıkların pek de büyük fayda getirdiğini düşünmüyorum.
Ben de 10 yıl önce üniversitedeyken CUDA dersini bilerek atlamış ve aynı şeyi düşünmüştüm.
CUDA’nın iki yönü var: donanım mimarisi ve buna yönelik yazılım yığını. Yazılım yığını kapalı; düşük seviyede doğrudan optimizasyon yapmayı planlamıyorsanız bununla çok ilgilenmeniz şart değil. Ama donanım yapısını öğrenmek kesinlikle değerli. Bütün GPU’lar temelde benzer şekilde çalışıyor (CUDA mimarisinin temel felsefesi 2007’den beri aynı) ve bu mimari, shader dilleri ile GPU soyutlama biçimlerini ciddi şekilde etkiliyor. Thread scheduling, warp’lar, private/shared memory yapısı gibi ayrıntıları anlarsanız, algoritmalarınızı donanımın yürütme modeline daha iyi uydurup çok büyük hesaplama performansından yararlanabilirsiniz.
Paralel hesaplamanın ilkeleri ile bunun donanım ve sürücü seviyesinde nasıl çalıştığı büyük ölçüde genellenebilir; bunu vurgulamak isterim. Bazı kısımlar belli platformlara özgü olsa da önemli bir bölümü geniş biçimde uygulanabilir. Yalnızca genellenebilir olana aşırı odaklanmak bazen zarar da verebilir. Açık kaynak olup olmaması ile genel amaçlı/özelleşmiş olma meselesi de birbirinden ayrı düşünülebilir; daha geniş bakmak gerekiyor.
Geçiş çok da zor değil. Zaten OpenMP ya da MPI kodu yazmış biri için CUDA’ya giriş yapmak kolaydı. CUDA’da performans optimizasyonu öğrenmek CPU paralel kodunu da hızlandırıyor; yani özünde mevcut hesaplama modelinin bir evrimi.
Ben de küçükken IBM PC/MS-DOS üzerinde programlama öğrendim; ikisi de açık kaynak değildi ama bugün bile bana büyük faydası var.
“Quiz 2: GPU nodes” bölümündeki hesaplamanın hatalı olduğunu düşünüyorum. Gerçekte her GPU’nun ya da switch’in port sayısı sınırlı olduğu için teoride mümkün görünen 450GB/s kesin biçimde sağlanmıyor; bu yüzden büyük bulut sağlayıcılarında ya da referans sistemlerde 3.2TB/s sunuluyor. Eğer 3.6TB/s mümkün olsaydı, dağıtık ring iş yüklerinde darboğaz oluşurdu. Bu arada iş arıyorum.
Bu serinin tamamı gerçekten çok iyiydi. Modern yapay zeka iş yüklerinin teorik sınırlarını açıklarken mimari, paralelleştirme gibi teknik ilkeleri anlaşılır şekilde açıyor. TPU merkezli olsa da genel olarak başka alanlara da uygulanabiliyor, bu yüzden oldukça kullanışlı.
Sıralama bence şu olmalı: önce tipleri kesin olan bir dilde sayısal olarak yoğun kodu olabildiğince optimize edin; hâlâ daha hızlı olması gerekiyorsa GPU seçeneğini değerlendirin. Benim deneyimimde GPU yaklaşık 8 kat hızlanma sağlıyor. Web yanıt süresini 4 saniyeden 0.5 saniyeye indirmek muazzam bir değişim. Ama pratikte websocket ile gecikme göstergesi (spinner) koymak ya da arka planda cache kullanmak çoğu zaman daha kolay oluyor. Bir de bulutta GPU çalıştırmanın pahalı olduğunu hesaba katmak lazım.
nvshmem’in ML alanında bu kadar öne çıkması ilginç. Buna karşılık aynı işleve sahip MPI, eski bilimsel simülasyon dünyasında pek tatmin edici değildi. Ben daha çok birden fazla düğüme yayılan uzun menzilli kuvvet hesaplamaları gibi zor işlerle uğraşıyordum.
Nvidia neden kendi TPU’sunu geliştirmedi, merak ediyorum.
Buna ihtiyaçları yok. Donanımda ve programlama modeli pazarında zaten baskın konumdalar; ayrıca TPU’yu programlamak daha da zor.
Aslında bu yazıda anlatıldığı gibi Nvidia GPU performansının %90’ı matris işlem birimlerinden geliyor; yani yapı olarak zaten TPU’ya çok benziyor. Bir miktar performanstan vazgeçip çok daha esnek bir derleyici ekosistemi elde ediyorlar.
Nvidia’nın bugüne kadar bu seviyede resmî kaynak sunmamış olması şaşırtıcı. Sonuçta üçüncü taraflar donanımı tersine mühendislikle çözerek gerçekten kullanılabilir kavramsal diyagramlar üretmek zorunda kalıyor. Nvidia’nın asıl motivasyonunu merak ediyorum. Eğer tek dertleri pazarlamaysa başarılı olmuşlar demektir ama mühendislik kültürleri konusunda soru işaretlerim var.
Gerçek zamanlı rendering mühendisi olarak bakınca bu hep böyleydi. NV, nesiller arasındaki değişimleri rakiplerin fark etmesini zorlaştırmak için bilgilerin çoğunu sıkı şekilde saklıyor. Diğer üreticiler de çok farklı değil. Oyun tarafında NDA imzalarsanız daha ayrıntılı mimari bilgileri verebiliyorlar ama onun dışında Intel hariç tamamen açık örnek pek görmedim.
Nvidia’nın resmî belgeleri aslında rakiplerine göre gerçekten oldukça iyi.
Neden böyle düşündüğünü merak ediyorum; çünkü bu yazıdaki bilgilerin büyük kısmı aslında neredeyse doğrudan Nvidia’nın resmî belgelerinden alınmış gibi görünüyor. Örneğin H100 diyagramı aslında H100 whitepaper içinden kaynak belirtilmeden kopyalanmış. Hesaplama miktarı ve bant genişliği bilgileri de tamamen resmî whitepaper’larda ve CUDA C++ guide 5, 6 ve 7. bölümlerde zaten ele alınıyor. Dışarıdan daha kısa özetler ve yorumlar eklemek elbette değerli ama Nvidia’nın resmî materyalleri olmasa böyle bir yazı zaten zor olurdu; o yüzden temelsiz kuşku ve ima biraz fazla geliyor.
Nvidia yalnızca ortalama seviyede belge yayımlayarak cuBLAS, cuDNN gibi kapalı kütüphanelerin daha hızlı kalmasını sağlıyor ve böylece vendor lock-in’i güçlendiriyor. Bu sayede diğer şirketlerin tersine mühendislikle yetişmesi de zorlaşıyor.
Çeşitli işaretlere bakınca Nvidia’nın NDA imzalayanlara ve VIP’lere özel uyarlanmış materyaller sunduğu, halka açık resmî kılavuzları ise bilinçli olarak ikinci plana attığı anlaşılıyor. Ticari olarak işlerine geldiği için böyle yapıyor gibiler. API belgelerine bile bariyer koyarsanız sıradan geliştiricilerin erişimi zorlaşıyor ama onlar yapay zeka, GPU’nun kendisi, yazılım ve VIP belgeleri dahil tüm ekosistemi satmaya odaklandığından genel geliştiricilere daha az önem veriyorlar.
Yapı diyagramlarına bakarken bunların gerçek donanımı kusursuz biçimde yansıtmadığını mutlaka akılda tutmalıyız. Nvidia, diyagramlardaki blokların ya da bileşenlerin gerçek hayatta bire bir var olduğunu garanti etmiyor; bunları yalnızca GPU ve SM yapısını düşünürken kullanılacak zihinsel modeller olarak sunuyor. Örneğin gerçek bir SM’de kaç işlev birimi bulunduğu, “tensor core”un başlı başına bağımsız bir donanım olup olmadığı yoksa birden çok birimin birleşiminden mi oluştuğu, warp altı ayrıntılı davranışların nasıl çalıştığı gibi şeyler resmî olarak bilinmiyor.
Gerçekten harika bir kaynak; sayenizde çok faydalı bilgiler edindim.