Cara Memahami GPU

• GPU memainkan peran inti dalam machine learning modern, dengan arsitektur yang menggabungkan banyak Streaming Multiprocessors (SMs) yang dioptimalkan untuk operasi perkalian matriks berkecepatan tinggi serta HBM (memori bandwidth tinggi)
• SM pada GPU terbagi menjadi Tensor Core (perkalian matriks) dan CUDA Core (operasi vektor), yang mendukung komputasi paralel skala besar dan pemrograman yang fleksibel
• GPU dan TPU berbeda dalam hal struktur internal dan konfigurasi jaringan; GPU memiliki fleksibilitas umum dan skalabilitas yang tinggi, tetapi memerlukan lebih banyak pertimbangan untuk mencapai performa optimal
• Di dalam node, komunikasi antargpu berkecepatan sangat tinggi dimungkinkan melalui NVLink dan NVSwitch, sedangkan antar-node terhubung melalui jaringan seperti InfiniBand untuk mendukung pelatihan terdistribusi skala besar
• Operasi kolektif (Collectives) pada GPU (misalnya AllReduce, AllGather, dll.) sangat dipengaruhi oleh struktur hardware dan lapisan jaringan, dan dalam praktiknya cenderung lebih rendah daripada bandwidth teoretis

---

Apa itu GPU?

• GPU ML (machine learning) modern (misalnya H100, B200) terdiri dari puluhan hingga ratusan Streaming Multiprocessor (SM) yang dioptimalkan untuk operasi perkalian matriks, dipadukan dengan memori HBM yang cepat
• Setiap SM memiliki Tensor Core (perkalian matriks), Warp Scheduler (operasi vektor), dan SMEM (cache on-chip)
• Tidak seperti TPU, GPU memungkinkan pemrosesan paralel yang lebih fleksibel dan berskala besar melalui lebih dari 100 SM

Struktur detail SM

• SM dibagi menjadi 4 subpartisi, dan setiap subpartisi memiliki Tensor Core, CUDA Core (operasi vektor), Warp Scheduler, register file, dan komponen lainnya
• CUDA Core bertugas untuk operasi aritmetika vektor (SIMD/SIMT), sedangkan Tensor Core dioptimalkan untuk perkalian matriks
• FLOPs Tensor Core jauh lebih besar, dan pada komputasi dengan presisi lebih rendah, kecepatan pemrosesannya menjadi lebih tinggi lagi
• GPU terbaru (misalnya B200) menambahkan TMEM berukuran besar untuk mendukung input Tensor Core berkapasitas besar

Fleksibilitas CUDA Core

• CUDA Core pada GPU menggunakan model SIMT (Single Instruction Multiple Threads), yang mengeksekusi satu instruksi secara paralel pada banyak thread
• Setiap thread memiliki instruction pointer (program counter) yang independen sehingga memberikan fleksibilitas seperti percabangan kondisional, tetapi jika divergence instruksi di dalam warp terlalu banyak, performa akan menurun
• Setiap CUDA Core memiliki status individual dan dapat mengakses memori secara bebas (TPU hanya dapat menangani memori yang berurutan)

Penjadwalan/paralelisme

• SM menjadwalkan dan menjalankan banyak warp (hingga 64) secara bersamaan, dan setiap warp scheduler mengeksekusi satu program pada satu waktu
• Berkat struktur ini, GPU mampu memberikan fleksibilitas yang tinggi sekaligus pemrosesan serentak yang besar

Struktur memori GPU

• GPU memiliki HBM sebagai memori terbesar, dan juga mempunyai hierarki memori lain seperti L2/L1(SMEM)/TMEM/register

Ringkasan spesifikasi GPU modern

• Jumlah SM (Streaming Multiprocessor), clock, memori, FLOPs, bandwidth (BW), dan lainnya berbeda untuk tiap model
• Kapasitas memori (HBM), bandwidth, dan FLOPs (floating point/integer/presisi rendah) terus meningkat dari generasi ke generasi
• Dari tabel (dihilangkan), karakteristik utama: Blackwell (B200) memiliki HBM 192GB, HBM BW 8.0TB/s, FP8 FLOPs 4.5e15, dll.
• Pada tiap generasi, peningkatan hardware seperti kapasitas register dan cache on-chip (SMEM), serta penambahan TMEM, terlihat jelas

Perbandingan GPU/TPU

• GPU bersifat umum dan dimodularisasi ke dalam banyak SM kecil (unit paralel), dengan kontrol hardware yang tinggi sehingga lebih sulit dipahami/dioptimalkan
• TPU terdiri dari sedikit Tensor Core besar dan banyak ALU vektor (VPU), dengan kontrol single-thread sehingga hardware bisa lebih sederhana dan biaya dapat ditekan
• Karena itu, TPU memerlukan optimisasi compiler, sementara GPU dapat menjalankan beberapa kernel secara independen, sehingga lebih mudah digunakan
• Dari sisi performa/harga, GPU H200 terbaru memiliki FLOPs/s 2 kali TPU v5p, HBM 1,5 kali, dan harga sekitar 2,5 kali lebih tinggi
• TPU memiliki VMEM (cache on-chip) yang lebih besar dan lebih cepat, yang bisa menjadi keunggulan besar pada inferensi model seperti LLM

Poin kuis Q&A hardware GPU

• CUDA core fp32 pada H100 berjumlah total 16.896 (132 SM x 4 x 32), sedangkan B200 memiliki 18.944
• FLOPs operasi vektor pada H100 mencapai maksimum sekitar 33,5TFLOPs/s, sekitar 30 kali lebih rendah dibanding FLOPs perkalian matriks Tensor Core (990TFLOPs/s)
• Total kapasitas L1/SMEM dan register pada H100 adalah 66MB, sedangkan TPU VMEM adalah 120MB
• Rasio bandwidth dan FLOPs (intensitas komputasi teoretis) pada H100/B200 sama-sama sekitar 280-300, mirip dengan TPU

Jaringan GPU (struktur komunikasi)

Struktur node/cluster

• Node GPU biasanya terdiri dari 8 GPU yang diikat bersama dengan NVLink (sangat cepat) dan NVSwitch (switch) untuk koneksi langsung full bandwidth
• Antar-node, scale-out dimungkinkan menggunakan InfiniBand (atau Ethernet, dll.)
• GPU terbaru (Blackwell) memiliki struktur yang dapat diperluas hingga 72 node

Karakteristik per lapisan jaringan

• Di dalam node (wilayah NVLink): egress per GPU 450GB/s (H100), 900GB/s (B200), dan hingga 1,6TB/s per NVSwitch
• Lapisan atas node (InfiniBand Leaf/Spine): struktur Leaf Switch (8 unit) hingga Spine Switch (16 unit), menjaga full bandwidth teoretis 400GB/s antargpu
• Pada arsitektur besar seperti SuperPod, 1024 GPU (128 node), dan GB200 (node 72 GPU) memiliki bandwidth yang ditingkatkan 9 kali lipat (3600GB/s)

Poin performa jaringan

• Secara teoretis, struktur jaringan (Full Fat Tree) dirancang untuk memberikan bandwidth maksimum bahkan antar-node
• Karena keterbatasan port hardware, saat diperluas ke 1024~4096 GPU digunakan pendekatan bertingkat dengan menambahkan lebih banyak Spine/Core Switch
• Peralihan dari bandwidth intra-node (450GB/s) ke bandwidth antar-node (400GB/s) = perbedaan performa pada operasi kolektif

Struktur operasi kolektif (Collectives)

• Mendukung operasi kolektif tingkat tinggi seperti AllGather, AllReduce (penjumlahan), AllToAll (distribusi)
• Di dalam node, koneksi langsung via NVLink memungkinkan performa optimal (BW teoretis), sementara antar-node melewati InfiniBand
• Memanfaatkan library NVIDIA NCCL dan NVSHMEM

Analisis performa operasi kolektif

• AllGather/ReduceScatter: diimplementasikan dengan metode ring pada B/W (450GB/s berdasarkan H100), dan untuk pesan kecil metode tree juga dimungkinkan
• AllToAll: setiap GPU mengirim langsung ke GPU tujuan, sehingga pada B/W dibagi dengan N dan secara teoretis 2 kali lebih cepat di dalam node
• Hasil pengukuran nyata menunjukkan AllReduce berada di kisaran 370GB/s, masih belum mencapai maksimum hardware
• Dibanding TPU, baru pada ukuran besar (puluhan MB hingga GB) performa mendekati peak bandwidth hardware

Ringkasan dan insight keseluruhan

• GPU unggul dalam fleksibilitas umum dan skalabilitas, tetapi tingkat kesulitan optimisasi performa dan observabilitas berdasarkan struktur hardware/jaringan lebih tinggi daripada TPU
• Jaringan (Intra-Node/NVLink/InfiniBand/Leaf/Spine, dll.) adalah kunci performa pelatihan skala besar, dan perlu mewaspadai perbedaan antara bandwidth aktual dan bandwidth teoretis
• Pemahaman tentang operasi kolektif dan struktur jaringan adalah elemen penting untuk pelatihan/serving model terdistribusi berukuran sangat besar
• Diperlukan proses untuk mengidentifikasi bottleneck performa dan kondisi optimal berdasarkan benchmark nyata serta pemahaman detail struktur hardware

[GN⁺]

Komentar Hacker News

• Saya merasa artikel ini dan beberapa dokumen lain agak kurang jelas, terutama saat menjelaskan GPU karena istilahnya sering dipakai secara ambigu. Misalnya pada gambar pertama, Warp Scheduler dijelaskan sebagai unit vektor SIMD yang mirip dengan VPU pada TPU, lalu disebut memiliki 32 CUDA Core, tetapi tidak dijelaskan dengan jelas apa yang dimaksud dengan CUDA core, sehingga objek utama yang ingin dijelaskan jadi tidak tersampaikan dengan baik. Karena gabungan kesalahan seperti ini, pembaca pemula atau yang sedang mencoba mempelajari konsepnya tetap akan kesulitan memahaminya, sementara bagi orang yang sudah cukup paham isinya kebanyakan sudah mereka ketahui. Walaupun ini awalnya sekadar draf, saat dipublikasikan istilah-istilahnya tetap harus diperlakukan dengan presisi seperti bedah, dan jangan sampai istilah yang berbeda tertukar atau dicampur. Kalau memakai analogi juga harus hati-hati. Saya juga merasa istilah seperti MXU (unit operasi matriks) sebaiknya dibuat mudah dicari lewat penjelasan tambahan atau hyperlink. Sekarang peran itu bahkan bisa diserahkan ke AI, dan itu agak menyedihkan.

  • Saya menjawab langsung sebagai penulis, dan secara umum setuju dengan kritik itu. Semakin saya berusaha menjaga akurasi penjelasan, semakin saya terus memikirkan keseimbangannya dengan “kebenaran moral”. Misalnya saya bisa saja menulis “unit yang mirip dengan VPU TPU, terdiri dari 32 SIMD (single instruction, multiple data) vector unit (ALU) yang oleh NVIDIA disebut CUDA Core”, tetapi kalimat seperti itu jadi panjang, dan definisi istilah seperti vector unit pun tetap bisa terlewat. Saya berusaha banyak memakai catatan kaki, tetapi sulit juga berharap pembaca akan mengklik semuanya satu per satu, dan sidenote juga cukup sulit diimplementasikan di HTML. Istilah seperti MXU sebenarnya sudah didefinisikan di bab sebelumnya, tetapi menurut saya tidak realistis mengasumsikan semua pembaca pasti membaca semua bab. Warp Scheduler sendiri juga ambigu sebagai istilah, karena dalam praktiknya bisa merujuk pada beberapa peran sekaligus (scheduler, dispatch unit, SIMD ALU), dan ini terjadi karena NVIDIA tidak memberi nama terpisah pada unit gabungan tersebut. Ke depan saya akan terus berusaha memperbaikinya; ini serangkaian kompromi yang tidak mudah.

  • LLM adalah alat yang cukup bagus untuk mengatasi kesulitan menghubungkan istilah-istilah seperti ini. Saat kita mencari satu istilah lalu muncul istilah lain yang juga belum dipahami, ia cukup pandai mengarahkan harus mulai belajar dari mana.

  • Hampir semuanya ada di dokumen arsitektur sistem Google TPU

  • Saya ingin bertanya serius, kira-kira tingkat pengetahuan latar belakang yang tepat tentang arsitektur komputer itu seharusnya sampai mana. Konsep SIMD sendiri sudah berusia lebih dari 50 tahun. Di pengantar materi tersebut, pemahaman tentang LLM dan arsitektur Transformer dianggap sebagai prasyarat dasar, tetapi pemahaman tentang cara kerja komputer dibilang tidak diperlukan. Namun saya justru merasa bukankah prinsip dasar cara kerja CPU setidaknya juga perlu diketahui?

  • Konten tersebut adalah satu bab dari buku yang ditulis untuk orang-orang yang bekerja di bidang machine learning.

• Saya merasa sangat sulit membenarkan waktu yang diinvestasikan jika sesuatu itu bukan open source atau bukan teknologi yang bisa dipakai lintas vendor. Menjadi ahli dalam memanfaatkan chip Nvidia terasa seperti konsultan SAP ABAP zaman dulu. Memang bidang ini menghasilkan banyak uang, tetapi secara historis saya rasa keahlian seperti itu tidak terlalu menguntungkan dalam jangka panjang.

  • Saya juga dulu berpikir begitu dan sengaja melewatkan kelas CUDA waktu kuliah sekitar 10 tahun lalu.

  • CUDA punya dua sisi: arsitektur hardware dan software stack untuk arsitektur itu. Software stack-nya tertutup, jadi kalau Anda tidak berencana melakukan optimasi tingkat rendah secara langsung, Anda tidak perlu terlalu memikirkannya. Namun struktur hardwarenya tetap sangat layak dipelajari. Semua GPU pada dasarnya bekerja dengan cara yang mirip (filosofi dasar arsitektur CUDA praktis tetap sama sejak 2007), dan arsitektur semacam ini sangat memengaruhi bahasa shader maupun cara abstraksi GPU dibuat. Jika memahami detail seperti penjadwalan thread, warp, struktur memori privat/bersama, dan karakteristik sejenisnya, kita bisa menyesuaikan algoritme dengan model eksekusi hardware secara lebih tepat dan memanfaatkan performa komputasi yang sangat besar.

  • Saya ingin menekankan bahwa prinsip parallel computing serta cara kerjanya di level hardware dan driver punya banyak hal yang bersifat umum. Memang sebagian isinya spesifik ke platform tertentu, tetapi banyak juga yang bisa diterapkan lebih luas. Kalau terlalu memutlakkan hanya hal-hal yang umum, kadang justru bisa merugikan. Status open source dan apakah sesuatu itu umum atau spesifik juga bisa dilihat sebagai hal yang terpisah, jadi menurut saya perlu eksplorasi yang lebih luas.

  • Peralihannya tidak terlalu sulit. Kalau seseorang sudah pernah menulis kode OpenMP atau MPI, masuk ke CUDA sendiri cukup mudah. Mempelajari cara optimasi performa di CUDA juga membuat kode paralel CPU menjadi lebih cepat, jadi pada dasarnya ini merupakan evolusi dari model komputasi yang sudah ada.

  • Saya juga belajar pemrograman saat kecil dengan IBM PC/MS-DOS. Keduanya bukan open source, tetapi sampai sekarang tetap sangat membantu.

• Saya rasa perhitungan pada bagian “Quiz 2: GPU nodes” tidak akurat. Dalam praktiknya, tiap GPU atau switch punya keterbatasan jumlah port, jadi 450GB/s yang secara teori mungkin itu tidak benar-benar tersedia, dan itulah sebabnya cloud besar maupun sistem referensi justru menyediakan 3.2TB/s. Kalau 3.6TB/s benar-benar tersedia, bottleneck akan muncul pada workload ring terdistribusi. Kebetulan saya juga sedang mencari kerja.

  • Saya juga baru memikirkan lagi soal ini setelah lama. Alasan penyedia cloud hanya mengiklankan 3.2Tbps adalah keterbatasan koneksi jaringan IB (InfiniBand) pada node. Pada DGX, tiap H100 memiliki satu Connect-X 7 NIC yang menyediakan hingga 400Gbps, jadi 8 GPU x 400Gbps = 3.2Tbps. Quiz 2 memang ditulis dengan cara yang membingungkan, tetapi menurut saya yang dimaksud adalah koneksi antar-GPU di dalam node, bukan jaringan antar-node.

• Seluruh seri ini sangat bagus. Seri ini menjelaskan batas teoritis workload AI modern sambil menguraikan prinsip teknis seperti arsitektur dan paralelisasi dengan cara yang mudah dipahami. Memang berfokus pada TPU, tetapi sebagian besar tetap bisa diterapkan di bidang lain, jadi sangat berguna.

• Urutannya menurut saya adalah: optimalkan dulu semaksimal mungkin kode intensif numerik di bahasa yang bertipe kuat, lalu kalau masih perlu lebih cepat baru pertimbangkan opsi GPU. Dalam pengalaman saya, GPU memberi percepatan kira-kira 8x. Kalau respons web bisa dipangkas dari 4 detik menjadi 0,5 detik, itu perubahan yang luar biasa. Tetapi pada praktiknya, sering kali lebih mudah memakai websocket untuk menampilkan indikator jeda (spinner) atau memakai cache latar belakang. Dan tentu perlu diingat juga bahwa menjalankan GPU di cloud itu mahal.

• Menarik bahwa nvshmem begitu dipuja di bidang ML, sementara MPI dengan fungsi yang setara dulu tidak terlalu memuaskan di dunia simulasi ilmiah. Sebagai konteks, saya dulu banyak mengerjakan tugas yang sulit seperti perhitungan gaya jarak jauh lintas banyak node.

• Saya penasaran kenapa Nvidia tidak mengembangkan TPU sendiri.

  • Mereka tidak perlu. Mereka sudah berada di posisi dominan baik di pasar hardware maupun model pemrogramannya, dan TPU justru lebih sulit diprogram.

  • Praktis seperti yang dijelaskan artikel ini, 90% performa GPU Nvidia berasal dari unit operasi matriks, jadi secara struktur sudah sangat mirip dengan TPU. Mereka mengorbankan sedikit performa, tetapi mendapatkan ekosistem compiler yang jauh lebih fleksibel.

• Saya masih heran mengapa Nvidia sampai sekarang belum pernah menyediakan sumber daya resmi pada level seperti ini. Akhirnya pihak ketiga harus melakukan reverse engineering pada hardware lalu menyusunnya menjadi diagram konseptual yang benar-benar berguna. Saya penasaran apa motivasi sebenarnya dari Nvidia. Kalau tujuan mereka semata pemasaran, ya bisa dibilang berhasil, tetapi saya masih mempertanyakan budaya engineering mereka.

  • Dari sudut pandang engineer rendering real-time, memang selalu seperti itu. NV menyembunyikan hampir semua informasi agar pesaing tidak mudah menangkap perubahan antar-generasi. Vendor lain pun tidak jauh berbeda. Di dunia game, mereka memang memberi informasi arsitektur lebih rinci lewat NDA, tetapi selain itu saya hampir tidak pernah melihat keterbukaan penuh kecuali dari Intel.

  • Nvidia sebenarnya punya dokumentasi resmi yang sangat bagus dibanding perusahaan lain.

  • Saya penasaran kenapa Anda merasa begitu. Sebenarnya kebanyakan isi artikel ini tampak hampir langsung diambil dari dokumentasi resmi Nvidia. Misalnya diagram H100 itu sebenarnya disalin begitu saja tanpa atribusi dari whitepaper H100. Informasi tentang throughput komputasi dan bandwidth juga semuanya sudah dibahas di whitepaper resmi dan bab 5, 6, 7 dari panduan CUDA C++. Tentu ada nilai tambah saat pihak luar merangkum dengan lebih ringkas dan menambahkan interpretasi, tetapi tanpa materi resmi Nvidia artikel seperti ini pun akan sulit dibuat, jadi menurut saya spekulasi atau kecurigaan yang tidak berdasar itu agak berlebihan.

  • Nvidia sengaja hanya merilis dokumentasi pada tingkat yang biasa-biasa saja, sehingga yang benar-benar cepat hanya library tertutup seperti cuBLAS dan cuDNN, dan akibatnya vendor lock-in jadi makin kuat. Ini juga membuat vendor lain sulit mengejar lewat reverse engineering.

  • Dari berbagai tanda yang ada, Nvidia tampaknya cenderung menyediakan materi khusus hanya untuk penandatangan NDA dan VIP, sementara publikasi manual resmi untuk umum sengaja kurang diprioritaskan. Kemungkinan karena itu lebih menguntungkan mereka secara bisnis. Bahkan kalau dokumentasi resmi API pun dibuat sulit diakses, developer biasa tetap akan kesulitan, tetapi mereka tampaknya lebih fokus menjual keseluruhan ekosistem AI, GPU, software, dan dokumentasi untuk kalangan VIP, sehingga perhatian untuk developer umum menjadi lebih kecil.

• Saat melihat diagram struktur, kita harus selalu ingat bahwa diagram tersebut tidak sepenuhnya mencerminkan hardware yang sebenarnya. Nvidia tidak menjamin bahwa blok atau komponen dalam diagram benar-benar ada seperti yang digambarkan; itu hanya disediakan sebagai model mental untuk membantu memikirkan struktur GPU dan SM. Misalnya, secara resmi kita tidak tahu persis berapa banyak unit fungsional yang benar-benar ada di dalam SM, apakah tensor core itu hardware mandiri atau hasil gabungan beberapa unit, atau bagaimana detail perilaku pada level di bawah warp.

  • Pendapat yang menarik. Tetapi bukankah fakta bahwa SM diblok saat operasi tensor core berlangsung bisa ditafsirkan bahwa FPU yang sama sebenarnya menangani juga operasi tensor?

• Ini benar-benar sumber daya yang luar biasa, saya jadi mendapat banyak hal bagus darinya.