วิธีทำความเข้าใจ GPU

 (jax-ml.github.io)
6 คะแนน โดย GN⁺ 2025-08-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • GPU มีบทบาทสำคัญใน แมชชีนเลิร์นนิง สมัยใหม่ และเป็นสถาปัตยกรรมที่รวม Streaming Multiprocessors (SMs) จำนวนมากซึ่งออกแบบมาสำหรับการคำนวณเมทริกซ์คูณความเร็วสูง เข้ากับ HBM (หน่วยความจำแบนด์วิดท์สูง)
  • SM ของ GPU แบ่งเป็น Tensor Core (เมทริกซ์คูณ) และ CUDA Core (การคำนวณเวกเตอร์) รองรับทั้งการประมวลผลแบบขนานขนาดใหญ่และการเขียนโปรแกรมที่ยืดหยุ่น
  • GPU และ TPU ต่างกันทั้งในด้านโครงสร้างภายในและการจัดวางเครือข่าย โดย GPU มี ความเป็นอเนกประสงค์ และ ความสามารถในการขยายระบบ สูงกว่า แต่การดึงประสิทธิภาพสูงสุดออกมาต้องพิจารณาปัจจัยมากกว่า
  • ภายใน โหนด (Node) สามารถสื่อสารระหว่าง GPU ได้ด้วยความเร็วสูงมากผ่าน NVLink และ NVSwitch ส่วนระหว่างโหนดจะเชื่อมต่อผ่านเครือข่ายอย่าง InfiniBand เพื่อรองรับการฝึกแบบกระจายขนาดใหญ่
  • Collectives บน GPU (เช่น AllReduce, AllGather เป็นต้น) มีประสิทธิภาพที่แตกต่างกันมากตามโครงสร้างฮาร์ดแวร์และลำดับชั้นของเครือข่าย และในทางปฏิบัติมักได้ต่ำกว่าค่าแบนด์วิดท์เชิงทฤษฎี

GPU คืออะไร?

  • ML GPU สมัยใหม่ (เช่น H100, B200) ประกอบด้วย Streaming Multiprocessor (SM) ตั้งแต่หลายสิบถึงหลายร้อยตัวที่ออกแบบมาเพื่อการคำนวณเมทริกซ์คูณ พร้อมด้วย หน่วยความจำ HBM ความเร็วสูง
  • ในแต่ละ SM มี Tensor Core (เมทริกซ์คูณ), Warp Scheduler (การคำนวณเวกเตอร์) และ SMEM (แคชบนชิป)
  • ต่างจาก TPU ตรงที่ GPU สามารถประมวลผลแบบขนานขนาดใหญ่ได้อย่างยืดหยุ่นมากกว่าผ่าน SM มากกว่า 100 ตัว

โครงสร้างรายละเอียดของ SM

  • SM ถูกแบ่งเป็น 4 subpartition และในแต่ละ subpartition จะมี Tensor Core, CUDA Core (การคำนวณเวกเตอร์), Warp Scheduler, register file เป็นต้น
  • CUDA Core รับหน้าที่คำนวณเลขคณิตเวกเตอร์ (SIMD/SIMT) ส่วน Tensor Core ถูกออกแบบเฉพาะสำหรับเมทริกซ์คูณ
  • ค่า FLOPs ของ Tensor Core สูงกว่าอย่างมาก และจะประมวลผลได้เร็วยิ่งขึ้นเมื่อใช้ความละเอียดต่ำ
  • GPU รุ่นใหม่ (เช่น B200) เพิ่ม TMEM ขนาดใหญ่เพื่อรองรับอินพุตของ Tensor Core ปริมาณมาก

ความยืดหยุ่นของ CUDA Core

  • CUDA Core ของ GPU ใช้โมเดล SIMT (Single Instruction Multiple Threads) ทำให้สามารถรันคำสั่งเดียวกันแบบขนานบนหลายเธรดได้
  • แต่ละเธรดมี instruction pointer (program counter) แยกกัน จึงมีความยืดหยุ่น เช่น การแตกแขนงตามเงื่อนไข แต่หากมี instruction divergence มากภายใน warp จะทำให้ประสิทธิภาพลดลง
  • แต่ละ CUDA Core มีสถานะแยกของตนเองและเข้าถึงหน่วยความจำได้อย่างอิสระ (ขณะที่ TPU ประมวลผลได้เฉพาะหน่วยความจำที่ต่อเนื่องกัน)

การจัดตาราง/ความขนาน

  • SM จะจัดตาราง warp จำนวนมาก (สูงสุด 64 ตัว) ให้รันพร้อมกัน และแต่ละ warp scheduler จะรันได้หนึ่งโปรแกรมในแต่ละครั้ง
  • ด้วยโครงสร้างนี้ GPU จึงมีทั้งความยืดหยุ่นสูงและความสามารถในการประมวลผลพร้อมกันในระดับสูง

โครงสร้างหน่วยความจำของ GPU

  • GPU มี HBM เป็นหน่วยความจำที่ใหญ่ที่สุด และยังมีลำดับชั้นของหน่วยความจำอื่น ๆ เช่น L2/L1(SMEM)/TMEM/register

สรุปสเปกของ GPU รุ่นใหม่

  • จำนวน SM (Streaming Multiprocessor), ความถี่สัญญาณนาฬิกา, หน่วยความจำ, FLOPs, แบนด์วิดท์ (BW) แตกต่างกันไปในแต่ละรุ่น
  • ความจุหน่วยความจำ (HBM), แบนด์วิดท์, FLOPs (สำหรับเลขทศนิยม/จำนวนเต็ม/ความละเอียดต่ำ) เพิ่มขึ้นอย่างต่อเนื่องในแต่ละเจเนอเรชัน
  • คุณลักษณะสำคัญจากตาราง (ละไว้): Blackwell (B200) มี HBM 192GB, HBM BW 8.0TB/s, FP8 FLOPs 4.5e15 เป็นต้น
  • การพัฒนาฮาร์ดแวร์ในแต่ละเจเนอเรชันเห็นได้ชัดจากความจุ register และแคชบนชิป (SMEM) รวมถึงการเพิ่ม TMEM

เปรียบเทียบ GPU/TPU

  • GPU มีความเป็นอเนกประสงค์และถูกออกแบบแบบโมดูลาร์ด้วย SM ขนาดเล็กจำนวนมาก (หน่วยขนาน) พร้อมการควบคุมฮาร์ดแวร์จำนวนมาก ทำให้เข้าใจและปรับแต่งได้ยากกว่า
  • TPU ประกอบด้วย Tensor Core ขนาดใหญ่จำนวนน้อยและ vector ALU (VPU) จำนวนมาก ใช้วิธีควบคุมแบบ single-thread จึงทำให้ฮาร์ดแวร์เรียบง่ายและลดต้นทุนได้
  • ด้วยเหตุนี้ TPU จึงต้องพึ่งการปรับแต่งโดยคอมไพเลอร์อย่างมาก ขณะที่ GPU สามารถรันหลายเคอร์เนลแบบอิสระได้ จึงใช้งานได้สะดวกกว่า
  • ในแง่ ประสิทธิภาพ/ราคา ช่วงหลัง H200 GPU มี FLOPs/s มากกว่า TPU v5p ประมาณ 2 เท่า, HBM มากกว่า 1.5 เท่า และราคาสูงกว่าราว 2.5 เท่า
  • TPU มี VMEM (แคชบนชิป) มากและเร็วกว่า ซึ่งอาจเป็นข้อได้เปรียบอย่างมากในงานอย่างการอนุมานโมเดล LLM

ประเด็นคำถาม-คำตอบเกี่ยวกับฮาร์ดแวร์ GPU

  • fp32 CUDA core ของ H100 มีทั้งหมด 16,896 คอร์ (132 SM x 4 x 32) ส่วน B200 มี 18,944 คอร์
  • FLOPs ของการคำนวณเวกเตอร์บน H100 อยู่สูงสุดราว 33.5TFLOPs/s ซึ่งต่ำกว่าค่า FLOPs ของเมทริกซ์คูณบน Tensor Core (990TFLOPs/s) ประมาณ 30 เท่า
  • ความจุรวมของ L1/SMEM และ register ของ H100 คือ 66MB ส่วน TPU VMEM คือ 120MB
  • อัตราส่วนระหว่าง bandwidth (แบนด์วิดท์) และ FLOPs (ความหนาแน่นการคำนวณเชิงทฤษฎี) ของทั้ง H100/B200 อยู่ที่ประมาณ 280-300 ใกล้เคียงกับ TPU

เครือข่ายของ GPU (โครงสร้างการสื่อสาร)

โครงสร้างโหนด/คลัสเตอร์

  • GPU node มักรวม GPU 8 ตัวเข้าด้วยกัน โดยเชื่อมต่อแบบแบนด์วิดท์เต็มโดยตรงผ่าน NVLink (ความเร็วสูงมาก) และ NVSwitch (สวิตช์)
  • ระหว่างโหนด สามารถสเกลเอาต์ได้ด้วย InfiniBand (หรือ Ethernet เป็นต้น)
  • GPU รุ่นล่าสุด (Blackwell) รองรับโครงสร้างที่ขยายได้ถึง 72 โหนด

คุณลักษณะตามลำดับชั้นของเครือข่าย

  • ภายในโหนด (ขอบเขต NVLink): egress ต่อ GPU เท่ากับ 450GB/s (H100), 900GB/s (B200) และ NVSwitch สูงสุด 1.6TB/s
  • ชั้นบนของโหนด (InfiniBand Leaf/Spine): โครงสร้าง Leaf Switch (8 ตัว) ~ Spine Switch (16 ตัว) โดยยังคงแบนด์วิดท์เต็มเชิงทฤษฎี 400GB/s ระหว่าง GPU ถึง GPU
  • ในสถาปัตยกรรมขนาดใหญ่อย่าง SuperPod มีได้ถึง 1024 GPU (128 โหนด) และ GB200 (โหนด 72 GPU) มีแบนด์วิดท์เพิ่มขึ้น 9 เท่า (3600GB/s)

ประเด็นด้านประสิทธิภาพเครือข่าย

  • ในทางทฤษฎี โครงสร้างเครือข่าย (Full Fat Tree) ถูกออกแบบให้ให้แบนด์วิดท์สูงสุดได้แม้กระทั่งระหว่างโหนดต่อโหนด
  • เมื่อขยายเป็น 1024~4096 GPU จะใช้วิธีจัดลำดับชั้นโดยเพิ่ม Spine/Core Switch มากขึ้น เนื่องจากข้อจำกัดของพอร์ตฮาร์ดแวร์
  • การเปลี่ยนจาก แบนด์วิดท์ภายในโหนด (450GB/s) ไปเป็น แบนด์วิดท์ระหว่างโหนด (400GB/s) ส่งผลให้ประสิทธิภาพของ collectives แตกต่างกัน

โครงสร้างของ Collectives

  • รองรับ collectives ระดับสูง เช่น AllGather, AllReduce (รวมผล), AllToAll (กระจาย)
  • ภายในโหนดจะเชื่อมต่อโดยตรงผ่าน NVLink จึงให้ประสิทธิภาพที่ดีที่สุดได้ (ตาม B/W เชิงทฤษฎี) ส่วนระหว่างโหนดจะผ่าน InfiniBand
  • ใช้ไลบรารี NCCL, NVSHMEM ของ NVIDIA

การวิเคราะห์ประสิทธิภาพของ Collectives

  • AllGather/ReduceScatter: ใช้การติดตั้งแบบ ring ตาม B/W (อิง H100 ที่ 450GB/s) และสำหรับข้อความขนาดเล็กอาจใช้แบบ tree ได้
  • AllToAll: แต่ละ GPU ส่งข้อมูลไปยัง GPU ปลายทางโดยตรง เป็นวิธีที่หารจาก B/W ด้วย N จึงเร็วกว่าในโหนดราว 2 เท่าในทางทฤษฎี
  • ผลการวัดจริงใน AllReduce อยู่ที่ราว 370GB/s ซึ่งยังไม่ถึงค่าสูงสุดของฮาร์ดแวร์
  • เมื่อเทียบกับ TPU ต้องเป็นงานข้อมูลขนาดใหญ่ (หลายสิบ MB ถึง GB) จึงจะเข้าใกล้ Peak Bandwidth ของฮาร์ดแวร์

สรุปและข้อสังเกต

  • GPU มีจุดเด่นด้านความเป็นอเนกประสงค์และการขยายระบบ แต่ระดับความยากในการปรับแต่งประสิทธิภาพและการสังเกตพฤติกรรมตามโครงสร้างฮาร์ดแวร์/เครือข่ายนั้นสูงกว่า TPU
  • เครือข่าย (Intra-Node/NVLink/InfiniBand/Leaf/Spine ฯลฯ) คือหัวใจของประสิทธิภาพในการฝึกขนาดใหญ่ และต้องระวังความต่างระหว่างแบนด์วิดท์จริงกับแบนด์วิดท์เชิงทฤษฎี
  • ความเข้าใจเรื่อง collectives และโครงสร้างเครือข่ายเป็นองค์ประกอบสำคัญสำหรับการฝึก/ให้บริการ โมเดลแบบกระจายขนาดใหญ่มาก
  • กระบวนการวิเคราะห์คอขวดและเงื่อนไขที่เหมาะสมที่สุดจำเป็นต้องอาศัยทั้ง benchmark จริงและความเข้าใจในรายละเอียดโครงสร้างของฮาร์ดแวร์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-08-21
ความคิดเห็นใน Hacker News

  • ฉันรู้สึกว่าบทความนี้และเอกสารอีกหลายชิ้นยังค่อนข้างคลุมเครือ โดยเฉพาะเวลาที่อธิบาย GPU มักใช้คำศัพท์อย่างกำกวม ตัวอย่างเช่นในภาพแรกมีการอธิบายว่า ‘Warp Scheduler’ เป็น SIMD vector unit ที่คล้ายกับ VPU ของ TPU และบอกว่ามี ‘CUDA Core’ 32 ตัว แต่กลับไม่ได้อธิบายให้ชัดว่า ‘CUDA core’ คืออะไร ทำให้พลาดการสื่อสารแก่นสำคัญของคำอธิบาย ความผิดพลาดเชิงผสมแบบนี้ทำให้ผู้เริ่มต้นหรือผู้อ่านที่พยายามทำความเข้าใจแนวคิดยังคงเข้าใจยาก ขณะที่คนที่พอเข้าใจแนวคิดอยู่แล้วก็เป็นเรื่องที่รู้อยู่ก่อนแล้ว ต่อให้เป็นเนื้อหาร่าง พอเผยแพร่ก็ควรจัดการคำศัพท์แต่ละคำให้แม่นยำราวกับงานผ่าตัด ห้ามสับสนหรือปนการใช้คำกันเอง คำแนะนำคือควรระมัดระวังเวลาใช้อุปมาอุปไมย และคิดว่าคำอย่าง MXU (หน่วยคำนวณเมทริกซ์) ก็ควรทำให้ค้นหาคำอธิบายเพิ่มเติมได้ง่ายผ่านการอธิบายเสริมหรือไฮเปอร์ลิงก์ ทุกวันนี้อาจให้ AI ทำหน้าที่นี้แทนได้ ซึ่งก็เป็นเรื่องน่าเศร้านิดหน่อย

    • ขอตอบในฐานะผู้เขียนเอง โดยรวมเห็นด้วยกับข้อทักท้วงนี้ เวลาพยายามรักษาความแม่นยำในการอธิบายก็มักต้องชั่งน้ำหนักกับ ‘ความจริงเชิงศีลธรรม’ อยู่เสมอ เช่น อาจเขียนว่า “ยูนิตที่คล้ายกับ TPU VPU ซึ่งประกอบด้วย SIMD (single instruction-multiple data) vector unit 32 ตัว (ALU) ที่ NVIDIA เรียกว่า CUDA Core” แต่แบบนั้นประโยคจะยาวมาก และนิยามคำอย่าง vector unit ก็อาจยังหายไปอยู่ดี ผมพยายามใช้เชิงอรรถเยอะ แต่ก็ยากจะคาดหวังว่าผู้อ่านจะกดอ่านทีละอัน ส่วน sidenote ก็ทำใน HTML ได้ยาก คำอย่าง MXU นั้นนิยามไว้แล้วในบทก่อนหน้า แต่ผมก็คิดว่าไม่ควรตั้งสมมติฐานว่าผู้อ่านจะอ่านครบทุกบท คำว่า "Warp Scheduler" เองในความเป็นจริงก็คลุมหลายบทบาทพร้อมกันอยู่แล้ว เช่น scheduler, dispatch unit, SIMD ALU ความกำกวมนี้มาจากตัวศัพท์เองด้วย เพราะ NVIDIA ไม่ได้ตั้งชื่อแยกให้กับยูนิตแบบผสมเหล่านี้ ผมจะพยายามปรับปรุงต่อไป มันเป็นชุดของการประนีประนอมที่ไม่ง่ายเลย

    • LLM เป็นเครื่องมือที่ค่อนข้างดีมากสำหรับคลี่คลายอุปสรรคเรื่องการเชื่อมโยงคำศัพท์แบบนี้ พอค้นคำหนึ่งแล้วเจอคำที่ไม่รู้จักต่อเนื่องเป็นลูกโซ่ มันช่วยแนะนำได้ดีว่าควรเริ่มเรียนจากตรงไหน

    • เกือบทั้งหมดอยู่ใน เอกสารสถาปัตยกรรมระบบ Google TPU

    • อยากถามจริงจังว่าระดับความรู้พื้นฐานด้านสถาปัตยกรรมคอมพิวเตอร์ที่เหมาะสมนั้นควรอยู่แค่ไหน แนวคิด SIMD เองก็มีมานานเกิน 50 ปีแล้ว ตอนต้นของเนื้อหานั้นถือว่าผู้อ่านเข้าใจ LLM และสถาปัตยกรรม Transformer เป็นพื้นฐาน แต่บอกว่าไม่จำเป็นต้องเข้าใจหลักการทำงานของคอมพิวเตอร์ ผมเลยสงสัยว่าอย่างน้อยก็ควรรู้หลักการทำงานพื้นฐานของ CPU ไหม

    • เนื้อหาชิ้นนี้เป็นหนึ่งบทจากหนังสือที่เขียนสำหรับคนทำงานในสายแมชชีนเลิร์นนิง

  • ฉันรู้สึกว่าถ้าไม่ใช่โอเพนซอร์สหรือไม่ใช่เทคโนโลยีที่ใช้ข้ามผู้ขายหลายรายได้ ก็มักยากมากที่จะให้เหตุผลกับเวลาที่ลงทุนลงไป การเก่งเรื่องใช้ชิป Nvidia ให้คุ้มดูคล้ายกับการเป็นที่ปรึกษา SAP ABAP ในอดีต แน่นอนว่าในสายนี้ทำเงินได้มาก แต่ในเชิงประวัติศาสตร์แล้วผมคิดว่าความเชี่ยวชาญแบบนี้ไม่ได้เป็นผลดีนัก

    • ฉันเองก็เคยคิดแบบนี้เหมือนกัน ตอนเรียนมหาวิทยาลัยเมื่อ 10 ปีก่อนถึงขั้นตั้งใจข้ามวิชา CUDA ไปเลย

    • CUDA มีอยู่สองด้าน คือสถาปัตยกรรมฮาร์ดแวร์ และซอฟต์แวร์สแตกสำหรับมัน ตัวซอฟต์แวร์สแตกเป็นแบบปิด ดังนั้นถ้าไม่ได้วางแผนจะทำ low-level optimization เองก็ไม่จำเป็นต้องใส่ใจมากนัก แต่โครงสร้างฮาร์ดแวร์นั้นคุ้มค่าที่จะเรียนรู้ GPU ทุกตัวทำงานคล้ายกันในระดับพื้นฐานอยู่แล้ว (สถาปัตยกรรม CUDA เองก็รักษาปรัชญาพื้นฐานเดิมมาตั้งแต่ปี 2007) และสถาปัตยกรรมเหล่านี้มีอิทธิพลมากต่อ shader language และวิธีการ abstraction ของ GPU ถ้าเข้าใจรายละเอียดอย่าง thread scheduling, warp, โครงสร้างหน่วยความจำ private/shared ก็จะออกแบบอัลกอริทึมให้สอดคล้องกับโมเดลการรันของฮาร์ดแวร์ และดึงสมรรถนะการประมวลผลมหาศาลออกมาได้ดีขึ้น

    • อยากเน้นว่าหลักการของ parallel computing รวมถึงการทำงานในระดับฮาร์ดแวร์และไดรเวอร์นั้นมีส่วนที่ใช้ร่วมกันได้กว้างพอสมควร บางส่วนก็ผูกกับแพลตฟอร์มเฉพาะ แต่หลายอย่างประยุกต์ใช้ได้กว้าง ถ้ายึดติดกับความเป็นสากลเพียงอย่างเดียวมากเกินไป บางทีก็เสียประโยชน์ได้เหมือนกัน จะมองเรื่องโอเพนซอร์สกับความเป็นเทคโนโลยีทั่วไป/เฉพาะทางแยกกันก็ได้ ดังนั้นยังมีพื้นที่ให้สำรวจได้กว้างกว่านี้

    • การย้ายมาจับมันไม่ได้ยากขนาดนั้น ถ้าเคยเขียนโค้ด OpenMP หรือ MPI มาก่อน การเริ่มต้นกับ CUDA ก็ถือว่าง่ายอยู่แล้ว การเรียนรู้วิธี optimize ประสิทธิภาพใน CUDA ยังช่วยให้โค้ดขนานบน CPU เร็วขึ้นด้วย ดังนั้นโดยเนื้อแท้แล้วมันคือวิวัฒนาการของโมเดลการคำนวณเดิม

    • ตอนเด็กฉันก็เริ่มเขียนโปรแกรมบน IBM PC/MS-DOS ซึ่งทั้งคู่ก็ไม่ใช่โอเพนซอร์ส แต่จนถึงตอนนี้ก็ยังเป็นประโยชน์กับฉันมาก

  • ฉันคิดว่าการคำนวณในส่วน “Quiz 2: GPU nodes” ไม่แม่นยำ เพราะในความเป็นจริงแต่ละ GPU หรือสวิตช์มีจำนวนพอร์ตจำกัด จึงไม่ได้ให้ 450GB/s ตามทฤษฎีอย่างแน่นอน และนั่นเป็นเหตุผลที่คลาวด์ใหญ่ ๆ หรือระบบอ้างอิงหลักให้เพียง 3.2TB/s ถ้า 3.6TB/s ทำได้จริง เวิร์กโหลด distributed ring จะเกิดคอขวด ส่วนตัวกำลังหางานอยู่

    • ฉันเองก็เพิ่งกลับมาคิดเรื่องนี้หลังจากไม่ได้คิดมานาน เหตุผลที่ผู้ให้บริการคลาวด์โฆษณาแค่ 3.2Tbps ก็เพราะข้อจำกัดของการเชื่อมต่อเครือข่าย IB (InfiniBand) ของโหนด ตามสเปก DGX, H100 หนึ่งตัวจะมี Connect-X 7 NIC หนึ่งตัวที่ให้ได้ถึง 400Gbps ดังนั้น 8 GPU x 400Gbps = 3.2Tbps ใน Quiz 2 ถ้อยคำอาจทำให้งง แต่ผมคิดว่ามันน่าจะหมายถึงการเชื่อมต่อระหว่าง GPU ภายในโหนด ไม่ใช่เครือข่ายระหว่างโหนด

  • ซีรีส์นี้ทั้งชุดดีมากจริง ๆ อธิบายขีดจำกัดเชิงทฤษฎีของเวิร์กโหลด AI สมัยใหม่ พร้อมถ่ายทอดหลักการทางเทคนิคอย่างสถาปัตยกรรมและการทำ parallelization ให้อ่านเข้าใจง่าย แม้จะเน้น TPU เป็นหลัก แต่โดยมากก็ประยุกต์ใช้กับด้านอื่นได้ จึงมีประโยชน์สูง

  • ลำดับที่ควรทำคือ optimize โค้ดที่กินงานเชิงตัวเลขให้มากที่สุดในภาษาที่มี type ชัดเจน แล้วถ้ายังต้องการให้เร็วขึ้นอีกค่อยพิจารณาตัวเลือกอย่าง GPU จากประสบการณ์ของฉัน GPU ทำให้เร็วขึ้นราว 8 เท่า ถ้าลดเวลาตอบสนองบนเว็บจาก 4 วินาทีเหลือ 0.5 วินาทีได้ นั่นเปลี่ยนแปลงมหาศาล แต่ในทางปฏิบัติ การแสดงสถานะหน่วงด้วย websocket (spinner) หรือใช้ background cache มักง่ายกว่า และต้องไม่ลืมว่าการรัน GPU บนคลาวด์มีค่าใช้จ่ายสูงมากด้วย

  • น่าสนใจที่เห็นว่า nvshmem ได้รับความนิยมในวงการ ML มากขนาดนี้ ในขณะที่ MPI ซึ่งให้ความสามารถแบบเดียวกันกลับไม่ค่อยน่าพอใจนักในโลกของการจำลองทางวิทยาศาสตร์สมัยก่อน อนึ่ง ฉันเคยทำงานที่ยากมากเป็นหลัก เช่น การคำนวณแรงระยะไกลข้ามหลายโหนด

  • สงสัยว่าทำไม Nvidia ถึงไม่พัฒนา TPU ของตัวเอง

    • ก็ไม่จำเป็นนี่ เพราะพวกเขาครองตลาดทั้งฮาร์ดแวร์และโมเดลการเขียนโปรแกรมอยู่แล้ว แถม TPU ยังเขียนโปรแกรมยากกว่าอีก

    • อันที่จริงตามที่บทความนี้อธิบายไว้ สมรรถนะของ Nvidia GPU ถึง 90% ก็มาจากหน่วยคำนวณเมทริกซ์อยู่แล้ว จึงแทบมีโครงสร้างคล้าย TPU มาก ยอมเสียประสิทธิภาพไปเล็กน้อย แต่ได้ระบบนิเวศคอมไพเลอร์ที่ยืดหยุ่นกว่ามาก

  • น่าแปลกใจที่จนถึงตอนนี้ Nvidia ยังไม่ได้ให้ทรัพยากรทางการในระดับนี้ สุดท้ายเลยกลายเป็นว่าบุคคลที่สามต้องย้อนรอยฮาร์ดแวร์กันเองจนจัดทำเป็นแผนภาพเชิงแนวคิดที่ใช้งานได้จริง ผมสงสัยแรงจูงใจที่แท้จริงของ Nvidia ถ้าคิดแค่มุมการตลาดก็คงถือว่าประสบความสำเร็จ แต่ผมยังมีคำถามกับวัฒนธรรมทางวิศวกรรมของบริษัทอยู่

    • จากมุมมองของวิศวกรเรนเดอร์แบบเรียลไทม์ มันก็เป็นแบบนี้มาตลอด NV ปิดข้อมูลแน่นมากเพื่อไม่ให้คู่แข่งตามทันการเปลี่ยนแปลงระหว่างแต่ละเจเนอเรชัน ผู้ขายรายอื่นก็ไม่ได้ต่างกันมากนัก ในวงการเกมพอมี NDA ก็จะให้ข้อมูลสถาปัตยกรรมเชิงลึกมากขึ้น แต่ถ้านอกเหนือจากนั้น ผมแทบไม่เคยเห็นใครเปิดเผยหมดจดจริง ๆ ยกเว้น Intel

    • จริง ๆ แล้ว Nvidia มีเอกสารทางการที่ดีมากเมื่อเทียบกับบริษัทอื่น

    • อยากรู้เหมือนกันว่าทำไมถึงรู้สึกแบบนั้น เพราะจริง ๆ แล้วเนื้อหาส่วนใหญ่ในบทความนี้ดูเหมือนหยิบมาจากเอกสารทางการของ Nvidia แทบตรง ๆ ตัวอย่างเช่นไดอะแกรม H100 ก็จริง ๆ แล้วคัดลอกมาจาก H100 whitepaper โดยไม่ได้ใส่ที่มา ข้อมูลเรื่องปริมาณการคำนวณและแบนด์วิดท์ก็มีอยู่ใน whitepaper ทางการและ CUDA C++ guide บทที่ 5, 6, 7 ครบหมดแล้ว การที่คนนอกเอามาสรุปให้สั้นลงและเสริมการตีความก็มีคุณค่าอยู่ แต่ถ้าไม่มีข้อมูลทางการของ Nvidia บทความแบบนี้ก็คงเกิดขึ้นได้ยาก การคาดเดาหรือระแวงโดยไม่มีหลักฐานจึงดูเกินไปหน่อย

    • Nvidia เผยแพร่เอกสารในระดับธรรมดาเท่านั้น จึงกลายเป็นว่าเฉพาะไลบรารีปิดอย่าง cuBLAS, cuDNN เท่านั้นที่เร็ว และทำให้เกิด vendor lock-in หนักขึ้น อีกทั้งยังทำให้ผู้เล่นรายอื่นตามด้วยการย้อนรอยได้ยาก

    • เมื่อดูจากหลายบริบท Nvidia ดูมีแนวโน้มจะให้ข้อมูลแบบปรับแต่งเฉพาะกับคนที่เซ็น NDA และกลุ่ม VIP เท่านั้น ส่วนคู่มือทางการสาธารณะกลับปล่อยให้ขาด ๆ เกิน ๆ โดยตั้งใจ เพราะเป็นผลดีกับพวกเขาในเชิงพาณิชย์ ต่อให้เป็นเอกสาร API ทางการเอง ถ้าตั้งกำแพงไว้ คนพัฒนาทั่วไปก็เข้าถึงได้ยากอยู่ดี แต่บริษัทก็ดูจะโฟกัสกับการขายทั้ง ecosystem เช่น AI, ตัว GPU เอง, ซอฟต์แวร์, เอกสารสำหรับ VIP มากกว่า จึงแทบไม่ได้ใส่ใจกับนักพัฒนาทั่วไปนัก

  • เวลาเราดูไดอะแกรมสถาปัตยกรรม ต้องจำไว้เสมอว่ามันไม่ได้สะท้อนฮาร์ดแวร์จริงแบบครบถ้วน Nvidia ไม่ได้รับประกันว่าบล็อกหรือองค์ประกอบในไดอะแกรมเหล่านั้นมีอยู่จริงแบบนั้นทุกประการ มันเป็นเพียง mental model สำหรับใช้คิดเกี่ยวกับโครงสร้างของ GPU และ SM เท่านั้น ตัวอย่างเช่น ใน SM จริงมี functional unit กี่ตัวกันแน่ หรือ ‘tensor core’ นั้นเป็นฮาร์ดแวร์อิสระจริงหรือเป็นผลจากการประกอบกันของหลายยูนิต รวมถึงพฤติกรรมรายละเอียดในระดับต่ำกว่า warp เราก็ไม่มีทางรู้ได้จากข้อมูลทางการ

    • มุมมองนี้น่าสนใจ แต่ในทางปฏิบัติ การที่ SM ถูกบล็อกระหว่างทำงาน tensor core อาจตีความได้หรือไม่ว่า FPU ชุดเดียวกันนั้นเป็นตัวจัดการงาน tensor ด้วยทั้งหมด

  • เป็นทรัพยากรที่ยอดเยี่ยมมากจริง ๆ ได้ความรู้ดี ๆ ไปเยอะเลย