GPU को समझने का तरीका

 (jax-ml.github.io)
6 पॉइंट द्वारा GN⁺ 2025-08-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GPU आधुनिक मशीन लर्निंग में केंद्रीय भूमिका निभाता है, और इसकी संरचना में उच्च-गति matrix multiplication के लिए विशेषीकृत अनेक Streaming Multiprocessors(SMs) और HBM(High Bandwidth Memory) का संयोजन होता है
  • GPU का SM, Tensor Core (matrix multiplication) और CUDA Core (vector operations) में बंटा होता है, और बड़े पैमाने की parallel computation तथा flexible programming को सपोर्ट करता है
  • GPU और TPU में आंतरिक संरचना और नेटवर्क कॉन्फ़िगरेशन के स्तर पर अंतर होता है; GPU की general-purpose क्षमता और scalability अधिक होती है, लेकिन optimal performance पाने के लिए अधिक बातों पर ध्यान देना पड़ता है
  • Node के भीतर NVLink और NVSwitch के ज़रिये GPUs के बीच ultra-fast communication संभव है, और nodes के बीच InfiniBand जैसे नेटवर्क के माध्यम से कनेक्शन बनाकर large-scale distributed training को सपोर्ट किया जाता है
  • GPU पर collective operations (जैसे: AllReduce, AllGather आदि) का प्रदर्शन hardware structure और network hierarchy पर काफी निर्भर करता है, और यह अक्सर सैद्धांतिक bandwidth से व्यावहारिक रूप से कम रहता है

GPU क्या है?

  • नवीनतम ML(मशीन लर्निंग) GPU (जैसे: H100, B200) में matrix multiplication के लिए विशेषीकृत दर्जनों से सैकड़ों Streaming Multiprocessor(SM) और तेज़ HBM memory का संयोजन होता है
  • हर SM में Tensor Core (matrix multiplication), Warp Scheduler (vector operations), SMEM (on-chip cache) शामिल होते हैं
  • TPU के विपरीत, GPU 100 से अधिक SMs के माध्यम से अधिक flexible और बड़े पैमाने की parallel processing उपलब्ध कराता है

SM की विस्तृत संरचना

  • SM को 4 sub-partitions में बांटा जाता है, और हर sub-partition में अलग-अलग Tensor Core, CUDA Core (vector operations), Warp Scheduler, register file आदि होते हैं
  • CUDA Core vector arithmetic operations (SIMD/SIMT) संभालता है, जबकि Tensor Core matrix multiplication के लिए विशेषीकृत होता है
  • Tensor Core FLOPs बहुत अधिक होते हैं, और low-precision operations में processing speed और भी तेज़ हो जाती है
  • नवीनतम GPU (जैसे: B200) में बड़े TMEM की अतिरिक्त सुविधा है, जो बड़े Tensor Core inputs को सपोर्ट करती है

CUDA Core की लचीलापन

  • GPU का CUDA Core SIMT(Single Instruction Multiple Threads) मॉडल का उपयोग करता है, जिसमें एक instruction कई threads पर parallel execute होती है
  • हर thread के पास स्वतंत्र instruction pointer (program counter) होता है, जिससे conditional branching जैसी flexibility मिलती है; लेकिन warp के भीतर instruction divergence ज़्यादा होने पर performance घटती है
  • हर CUDA Core को individual state और memory access की स्वतंत्रता होती है (TPU केवल contiguous memory को संभाल सकता है)

Scheduling/Parallelism

  • SM अनेक warps (अधिकतम 64) को schedule करके एक साथ execute करता है, और हर warp scheduler एक समय में एक program चलाता है
  • इसी संरचना की वजह से GPU काफ़ी flexible होने के साथ-साथ high concurrency भी उपलब्ध कराता है

GPU memory structure

  • GPU में HBM सबसे बड़ी memory होती है, और इसके अलावा L2/L1(SMEM)/TMEM/registers जैसी memory hierarchy भी होती है

नवीनतम GPU specifications का सारांश

  • SM(Streaming Multiprocessor) की संख्या, clock, memory, FLOPs, bandwidth(BW) आदि हर model के अनुसार अलग होते हैं
  • memory capacity(HBM), bandwidth, FLOPs (floating point/integer/low precision) आदि हर generation के साथ बढ़ते गए हैं
  • तालिका (हटाई गई) में मुख्य विशेषताएँ: Blackwell(B200) में HBM 192GB, HBM BW 8.0TB/s, FP8 FLOPs 4.5e15 आदि
  • हर generation में register और on-chip cache(SMEM) capacity, TMEM का जुड़ना आदि hardware advancement स्पष्ट रूप से दिखते हैं

GPU/TPU तुलना

  • GPU general-purpose होने के साथ कई छोटे SMs (parallel units) में modular होता है, और इसमें hardware control अधिक होने के कारण इसे समझना/optimize करना कठिन होता है
  • TPU कुछ बड़े Tensor Cores और कई vector ALU(VPU) से बना होता है, और single-thread control structure के कारण hardware को सरल बनाना और लागत कम करना संभव होता है
  • इसी वजह से TPU में compiler optimization अनिवार्य है, जबकि GPU कई kernels को स्वतंत्र रूप से execute कर सकता है, जिससे usability बढ़ती है
  • performance/price के लिहाज़ से हाल का H200 GPU, TPU v5p की तुलना में FLOPs/s में 2 गुना, HBM में 1.5 गुना, और कीमत में लगभग 2.5 गुना है
  • TPU में VMEM(on-chip cache) अधिक और तेज़ होता है, जिससे LLM model inference जैसे कार्यों में बड़ा लाभ मिल सकता है

GPU hardware quiz Q&A के मुख्य बिंदु

  • H100 के fp32 CUDA cores की कुल संख्या 16,896 (132 SM x 4 x 32) है, और B200 में 18,944 हैं
  • vector operation FLOPs, H100 के आधार पर अधिकतम 33.5TFLOPs/s के स्तर पर हैं, जो Tensor Core के matrix multiplication FLOPs (990TFLOPs/s) से 30 गुना कम हैं
  • H100 की L1/SMEM और registers की कुल capacity 66MB है, जबकि TPU VMEM 120MB है
  • Bandwidth और FLOPs का ratio (सैद्धांतिक arithmetic intensity) H100/B200 दोनों में लगभग 280-300 है, जो TPU के समान है

GPU networking (communication structure)

Node/cluster structure

  • GPU node आमतौर पर 8 GPUs के समूह में होता है, जिन्हें NVLink (ultra-fast) और NVSwitch (switch) के ज़रिये full bandwidth direct connection मिलता है
  • Nodes के बीच InfiniBand (या Ethernet आदि) का उपयोग करके scale-out किया जा सकता है
  • नवीनतम (Blackwell) GPU संरचना 72 nodes तक विस्तार योग्य है

Network hierarchy के अनुसार विशेषताएँ

  • node के भीतर (NVLink area): हर GPU के लिए egress 450GB/s(H100), 900GB/s(B200), और हर NVSwitch के लिए अधिकतम 1.6TB/s
  • node के ऊपर (InfiniBand Leaf/Spine): Leaf Switch(8) से Spine Switch(16) संरचना, और GPU-से-GPU के बीच सैद्धांतिक रूप से 400GB/s full bandwidth बरकरार
  • SuperPod जैसी बड़ी architecture में 1024 GPUs (128 nodes), GB200(72GPU Node) में 9 गुना बढ़ी हुई bandwidth (3600GB/s)

Network performance के मुख्य बिंदु

  • सैद्धांतिक रूप से network structure (Full Fat Tree) इस तरह डिज़ाइन की जाती है कि node-से-node के बीच भी अधिकतम bandwidth मिले
  • hardware port limitations आदि के कारण 1024~4096 GPU तक scale होने पर Spine/Core Switch को और जोड़ने वाली hierarchical पद्धति अपनाई जाती है
  • Node के भीतर bandwidth(450GB/s) → Node के बीच bandwidth(400GB/s) में बदलाव = collective operations में performance difference

collective operations की संरचना

  • AllGather, AllReduce (sum reduction), AllToAll (distribution) जैसी high-level collective operations का समर्थन
  • node के भीतर NVLink के ज़रिये direct connection होने से optimal performance संभव है (सैद्धांतिक B/W), जबकि node-से-node के बीच InfiniBand के माध्यम से संचार होता है
  • NVIDIA की NCCL, NVSHMEM libraries का उपयोग किया जाता है

collective operations performance analysis

  • AllGather/ReduceScatter: B/W (H100 के लिए 450GB/s) पर ring method से implement, छोटे message में tree method भी संभव
  • AllToAll: हर GPU सीधे target GPU को data भेजता है; यह B/W को N से विभाजित करने वाली संरचना है, इसलिए node के भीतर सैद्धांतिक रूप से 2 गुना तेज़
  • वास्तविक measurement में AllReduce लगभग 370GB/s के स्तर पर दिखता है, जो hardware maximum तक नहीं पहुँचता
  • TPU की तुलना में बड़े आकार (दर्जनों MB ~ GB) पर ही hardware peak bandwidth के करीब पहुँचा जाता है

समग्र सारांश और insights

  • GPU की ताकत general-purpose क्षमता और scalability है, लेकिन hardware/network structure के कारण performance optimization की कठिनाई और observability, TPU की तुलना में अधिक हो सकती है
  • networking (Intra-Node/NVLink/InfiniBand/Leaf/Spine आदि) large-scale training performance की कुंजी है, और वास्तविक bandwidth तथा सैद्धांतिक bandwidth के अंतर पर ध्यान देना ज़रूरी है
  • collective operations और network structure की समझ ultra-large distributed model training/serving में अनिवार्य तत्व है
  • वास्तविक benchmark और hardware की detailed structure की समझ के आधार पर performance bottleneck और optimal conditions की पहचान करने वाली प्रक्रिया आवश्यक है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-21
Hacker News की राय

  • मुझे लगा कि यह लेख और कई दूसरे दस्तावेज़ कुछ हद तक अस्पष्ट हैं, खासकर GPU की व्याख्या करते समय शब्दों का इस्तेमाल अक्सर धुंधला रहता है। उदाहरण के लिए, पहली इमेज में ‘Warp Scheduler’ को TPU के VPU जैसा SIMD vector unit बताया गया है, और कहा गया है कि इसमें 32 ‘CUDA Core’ हैं, लेकिन यहाँ ‘CUDA core’ क्या है यह साफ़ नहीं किया गया, इसलिए व्याख्या जिस मुख्य चीज़ को समझानी चाहिए थी वही ठीक से सामने नहीं आती। ऐसी मिली-जुली गलतियों की वजह से शुरुआती पाठकों या अवधारणा सीखने वालों के लिए यह अब भी समझना कठिन रहता है, जबकि जिन्हें पहले से कुछ समझ है उनके लिए यह ज़्यादातर जाना-पहचाना ही है। भले ही यह ड्राफ्ट रहा हो, प्रकाशित करते समय हर शब्द को सर्जिकल सटीकता से संभालना चाहिए और शब्दों को गड्डमड्ड करके नहीं लिखना चाहिए। analogies का इस्तेमाल भी सावधानी से होना चाहिए। और MXU (matrix computation unit) जैसे शब्दों को अतिरिक्त व्याख्या या hyperlink के साथ ऐसा होना चाहिए कि उन्हें आसानी से खोजा जा सके। आजकल यह काम AI से भी कराया जा सकता है, जो थोड़ा दुखद है।

    • लेखक के तौर पर मैं सीधे जवाब दे रहा हूँ। आपकी बातों से अधिकांशतः सहमत हूँ। व्याख्या में सटीकता बनाए रखने की कोशिश करते हुए ‘moral truth’ के साथ संतुलन का सवाल हमेशा रहता है। उदाहरण के लिए, मैं यह लिख सकता था कि “TPU VPU जैसा unit, जो 32 SIMD (single instruction-multiple data) vector units (ALU) से बना है, जिसे NVIDIA CUDA Core कहता है”, लेकिन तब वाक्य बहुत लंबा हो जाता और vector unit जैसे शब्दों की परिभाषा फिर भी छूट सकती थी। मैं footnotes काफ़ी देने की कोशिश करता हूँ, लेकिन यह मान लेना भी मुश्किल है कि पाठक हर लिंक पर क्लिक करेंगे। sidenotes को HTML में लागू करना भी आसान नहीं है। MXU जैसे शब्दों को मैंने पहले के अध्याय में परिभाषित किया था, लेकिन यह मानना भी ठीक नहीं कि पाठक हर अध्याय ज़रूर पढ़ेंगे। “Warp Scheduler” भी वास्तव में कई भूमिकाओं—scheduler, dispatch unit, SIMD ALU—का मिला-जुला संकेत है, यानी शब्द खुद ही कुछ हद तक अस्पष्ट है, और यह इसलिए भी है क्योंकि NVIDIA ने इस composite unit के लिए अलग नाम नहीं दिया। आगे और सुधार करने की कोशिश करूँगा; यह आसान समझौता नहीं है, बल्कि लगातार संतुलन बनाने की प्रक्रिया है।

    • LLM ऐसे terminology connections की कठिनाई सुलझाने के लिए काफ़ी अच्छा tool है। एक शब्द खोजने पर जब उससे जुड़े कई अनजाने शब्द सामने आते हैं, तो यह अच्छी तरह मार्गदर्शन कर देता है कि पढ़ाई कहाँ से शुरू करनी चाहिए।

    • लगभग सब कुछ Google TPU system architecture document में है।

    • मैं गंभीरता से पूछना चाहता हूँ: computer architecture की कितनी background knowledge उचित मानी जानी चाहिए? SIMD की अवधारणा खुद 50 साल से भी पुरानी है। उस सामग्री की शुरुआत में LLM और Transformer architecture की समझ को baseline माना गया है, लेकिन यह भी कहा गया है कि कंप्यूटर कैसे काम करता है इसकी समझ ज़रूरी नहीं। फिर भी मुझे लगता है कि कम-से-कम CPU के बुनियादी working principles तो पता होने चाहिए, नहीं?

    • यह सामग्री मशीन लर्निंग क्षेत्र में काम करने वाले लोगों के लिए लिखी गई किताब का एक chapter है।

  • मुझे लगता है कि अगर कोई चीज़ open source नहीं है या ऐसी technology नहीं है जिसे कई vendors के बीच interoperable ढंग से इस्तेमाल किया जा सके, तो उस पर लगाया गया समय justify करना बहुत मुश्किल है। Nvidia chips का अच्छा उपयोग करना मुझे पुराने SAP ABAP consultant जैसा लगता है। हाँ, इस क्षेत्र में पैसा बहुत है, लेकिन ऐतिहासिक रूप से ऐसी expertise अक्सर उतनी फ़ायदेमंद नहीं रही।

    • मैंने भी 10 साल पहले कॉलेज में CUDA की class जानबूझकर छोड़ी थी, बिल्कुल इसी सोच के साथ।

    • CUDA के दो पहलू हैं: hardware architecture और उसके लिए software stack। software stack closed है, इसलिए अगर आप खुद low-level optimization करने की योजना नहीं बना रहे हैं, तो उस पर ज़्यादा ध्यान देने की ज़रूरत नहीं। लेकिन hardware structure सीखना पूरी तरह worthwhile है। सभी GPU मूलतः काफ़ी समान तरीके से काम करते हैं (CUDA architecture की बुनियादी philosophy 2007 से लगभग वैसी ही है), और यही architecture shader languages और GPU abstractions के तरीकों पर गहरा असर डालती है। thread scheduling, warp, private/shared memory structure जैसी बारीक बातें समझ लेने पर आप algorithms को hardware execution model के हिसाब से बेहतर ढाल सकते हैं और भारी compute performance का लाभ उठा सकते हैं।

    • मैं यह ज़ोर देकर कहना चाहता हूँ कि parallel computing के सिद्धांत, और hardware तथा driver level पर उसका संचालन, काफ़ी हद तक सामान्य रूप से लागू होने वाली बातें हैं। कुछ चीज़ें platform-specific हैं, लेकिन बहुत कुछ व्यापक रूप से उपयोगी है। अगर आप केवल generality को ही सब कुछ मान लें तो उल्टा नुकसान भी हो सकता है। open source होना और general-purpose/specialized होना अलग-अलग सवाल हैं, इसलिए और व्यापक दृष्टि से देखना चाहिए।

    • transition इतना कठिन नहीं है। जिसने पहले OpenMP या MPI code लिखा हो, उसके लिए CUDA में शुरुआत करना अपने आप में आसान था। CUDA में performance optimization सीखने से CPU parallel code भी तेज़ होता है, इसलिए यह मूलतः पुराने computing models का evolved form है।

    • मैंने भी बचपन में IBM PC/MS-DOS पर programming सीखी थी। दोनों open source नहीं थे, लेकिन आज भी वह अनुभव काफ़ी काम आता है।

  • मुझे लगता है कि “Quiz 2: GPU nodes” सेक्शन की गणना सटीक नहीं है। वास्तव में हर GPU या switch पर ports की सीमा होती है, इसलिए सैद्धांतिक 450GB/s निश्चित रूप से उपलब्ध नहीं होता। इसी वजह से बड़े cloud providers या reference systems में 3.2TB/s दिया जाता है। अगर 3.6TB/s संभव होता, तो distributed ring workloads में bottleneck आ जाता। वैसे, मैं नौकरी की तलाश में हूँ।

    • मैंने भी इस हिस्से पर काफ़ी समय बाद फिर सोचा। cloud providers 3.2Tbps ही advertise करते हैं क्योंकि node की IB (InfiniBand) network connectivity की सीमा वही है। DGX के हिसाब से हर H100 पर एक Connect-X 7 NIC होता है जो 400Gbps तक देता है। 8 GPU x 400Gbps = 3.2Tbps। Quiz 2 की wording थोड़ी confusing है, लेकिन मेरे हिसाब से वह node के अंदर GPUs के बीच की connectivity की बात कर रहा है, node-to-node network की नहीं।

  • पूरी series वाकई बहुत अच्छी थी। इसने modern AI workloads की theoretical limits समझाते हुए architecture, parallelization और दूसरे technical principles को आसानी से समझाया। यह TPU-केंद्रित है, लेकिन अधिकतर बातें दूसरे क्षेत्रों में भी लागू हो सकती हैं, इसलिए यह काफ़ी उपयोगी है।

  • पहले strongly typed language में numerical-intensive code को जितना हो सके optimize करें, और अगर तब भी speed चाहिए तो GPU विकल्प देखें। मेरे अनुभव में GPU से लगभग 8x speedup मिलता है। अगर web response 4 सेकंड से 0.5 सेकंड पर आ जाए, तो यह बहुत बड़ा बदलाव है। लेकिन व्यवहार में websocket के ज़रिए delay indicator (spinner) दिखाना या background cache का उपयोग करना ज़्यादा आसान हो सकता है। और cloud में GPU चलाने की लागत भी काफ़ी ज़्यादा होती है, यह भी ध्यान रखना चाहिए।

  • यह दिलचस्प है कि nvshmem को ML क्षेत्र में इतनी अहमियत मिल रही है, जबकि इसी तरह की functionality वाला MPI पहले वैज्ञानिक simulation की दुनिया में उतना संतोषजनक नहीं था। संदर्भ के लिए, मैं कई nodes में फैले long-range force calculations जैसे काफ़ी कठिन काम किया करता था।

  • मैं सोचता हूँ कि Nvidia ने अपना TPU क्यों नहीं बनाया।

    • इसकी ज़रूरत ही नहीं है। hardware और programming model, दोनों बाज़ारों में इसकी पहले से dominant position है, और TPU तो उल्टा programming के लिहाज़ से और कठिन है।

    • व्यवहार में, जैसा इस लेख में समझाया गया है, Nvidia GPU का 90% performance matrix compute units से आता है, इसलिए इसकी संरचना लगभग TPU जैसी ही है। थोड़ा performance trade-off करके यह कहीं ज़्यादा flexible compiler ecosystem हासिल करता है।

  • मुझे अब भी हैरानी है कि Nvidia ने आधिकारिक रूप से इस स्तर का resource उपलब्ध नहीं कराया। नतीजा यह है कि 3rd party लोग hardware की reverse engineering करके उसे सचमुच उपयोगी conceptual diagrams तक ले आते हैं। Nvidia की असली motivation क्या है, यह जानने की जिज्ञासा है। अगर उद्देश्य सिर्फ marketing है, तो वे सफल रहे हैं, लेकिन उनकी engineering culture को लेकर मेरे मन में सवाल हैं।

    • real-time rendering engineer के नज़रिए से, यह हमेशा से ऐसा ही रहा है। NV ज़्यादातर जानकारी छिपाकर रखता है ताकि competitors generation-to-generation बदलावों को ठीक से समझ न सकें। दूसरे vendors भी बहुत अलग नहीं हैं। games में NDA के तहत detailed architecture information ज़्यादा मिल जाती है, लेकिन उसके बाहर Intel को छोड़कर मैंने पूरी तरह खुला disclosure शायद ही देखा है।

    • Nvidia के पास वास्तव में दूसरी कंपनियों की तुलना में काफ़ी बेहतर official documentation है।

    • मुझे जानना है कि आपको ऐसा क्यों लगा। दरअसल इस लेख की ज़्यादातर सामग्री लगभग सीधे Nvidia की official documentation से ही ली गई लगती है। उदाहरण के लिए, H100 diagram भी वास्तव में H100 whitepaper से बिना attribution के कॉपी किया गया है। compute throughput और bandwidth की जानकारी भी official whitepaper और CUDA C++ guide के chapters 5, 6, 7 में पहले से मौजूद है। बाहर के लोग इसे और संक्षेप में व्यवस्थित कर दें और कुछ interpretation जोड़ दें, इसमें value है, लेकिन Nvidia की आधिकारिक सामग्री के बिना ऐसा लेख बनाना ही मुश्किल होता, इसलिए बिना ठोस आधार के संदेह करना थोड़ा ज़्यादा है।

    • Nvidia सिर्फ औसत स्तर की documentation जारी करके ऐसी स्थिति बनाता है जहाँ cuBLAS, cuDNN जैसी closed libraries ही तेज़ चलती हैं, और इससे vendor lock-in और गहरा हो जाता है। इसी वजह से दूसरे vendors के लिए reverse engineering करके बराबरी तक पहुँचना भी कठिन हो जाता है।

    • तमाम संकेतों को देखकर लगता है कि Nvidia NDA sign करने वालों और VIPs को ही customized materials देता है, जबकि सार्वजनिक official manuals को जानबूझकर कमज़ोर रखता है। शायद यह उनके लिए commercially फ़ायदेमंद है। अगर वे API documentation पर भी barrier खड़ा करें, तो सामान्य developers के लिए पहुँचना कठिन हो जाता है, लेकिन उनका ध्यान AI, GPU hardware, software, और VIP-focused documentation सहित पूरे ecosystem को बेचने पर है, इसलिए आम developers पर वे अपेक्षाकृत कम ध्यान देते हैं।

  • जब हम architecture diagrams देखते हैं, तो यह ज़रूर याद रखना चाहिए कि वे वास्तविक hardware को पूरी तरह reflect नहीं करते। Nvidia यह guarantee नहीं देता कि diagram के blocks या components वास्तव में उसी रूप में मौजूद हैं; वे सिर्फ GPU और SM structure के बारे में सोचने के लिए mental model के तौर पर दिए जाते हैं। उदाहरण के लिए, असली SM में functional units कितनी हैं, ‘tensor core’ खुद एक स्वतंत्र hardware block है या कई units के संयोजन का परिणाम है, और warp से नीचे के स्तर पर details कैसे काम करती हैं—यह सब आधिकारिक रूप से स्पष्ट नहीं है।

    • दिलचस्प बात है। लेकिन क्या यह तथ्य कि वास्तविक SM tensor core operations के दौरान blocked रहता है, इस तरह पढ़ा जा सकता है कि वही FPU tensor operations भी संभाल रहा है?

  • यह सचमुच शानदार resource है, इससे मुझे बहुत अच्छा material मिला।