หนึ่ง: การแตกหักของสถาปัตยกรรม: เมื่อ “ความคิดแบบชิปเดี่ยว” ปะทะกับ “ความเป็นจริงของชิปเล็ต”

สถาปัตยกรรม GPU สมัยใหม่ได้เปลี่ยนไปใช้การออกแบบแบบหลายชิป (Multi-chip) ที่ใช้ชิปเล็ต (Chiplet) เป็นพื้นฐาน เช่น AMD Instinct MI300X/MI350 และ NVIDIA Blackwell อย่างไรก็ตาม โมเดลการทำงานหลักอย่าง CUDA/HIP ยังไม่สามารถปรับตัวเข้ากับการเปลี่ยนแปลงทางสถาปัตยกรรมขั้นพื้นฐานนี้ได้อย่างสมบูรณ์ ปัญหาหลักประการหนึ่งคือ: โมเดลการเขียนโปรแกรมขาดวิธีการโดยตรงในการแสดงความสัมพันธ์เชิงข้อมูลระหว่างกลุ่มงาน (workgroup) หรือการจำกัดงานคำนวณให้อยู่ในลำดับชั้นหน่วยความจำของชิปเล็ตเฉพาะเจาะจง

ทีมวิจัยของ AMD ได้เปิดเผยความขัดแย้งนี้ในบทความวิจัยเรื่อง “Fleet: Hierarchical Task-based Abstraction for Megakernels on Multi-Die GPUs” เมื่อฮาร์ดแวร์ GPU เข้าสู่ยุค “สหพันธรัฐ” แบบหลายชิปเล็ต แต่โมเดลการเขียนโปรแกรมซอฟต์แวร์ยังคงติดอยู่ในตรรกะ “รวมศูนย์” แบบชิปเดี่ยว ส่งผลให้เกิดคอขวดด้านประสิทธิภาพอย่างเห็นได้ชัด

ยกตัวอย่าง AMD Instinct MI350 ซึ่งประกอบด้วย XCD (Accelerator Compute Die) 8 ตัว แต่ละ XCD มีแคช L2 ขนาด 4MB เป็นของตัวเอง และแคช L2 เหล่านี้ไม่มีการรักษาความสอดคล้องกัน (coherence) ผ่านฮาร์ดแวร์ XCD ทั้งหมดใช้แคชระดับสุดท้าย (MALL) และ HBM ร่วมกัน สถาปัตยกรรมแคช L2 แบบแบ่งส่วนที่ไม่สอดคล้องกันนี้คือความท้าทายหลักของโมเดลการเขียนโปรแกรมแบบดั้งเดิม: การขาดการจัดตารางงานที่รับรู้ถึงชิปเล็ตจะทำให้ข้อมูลน้ำหนัก (weight) ถูกโหลดซ้ำใน L2 ของ XCD ต่าง ๆ ส่งผลให้พื้นที่แคชอันมีค่าและแบนด์วิดท์ HBM ถูกใช้ไปอย่างสูญเปล่า

ข้อมูลการวิจัยได้วัดค่าความสูญเสียนี้: ในกระบวนการถอดรหัส LLM ทั่วไป การดำเนินการชั้นเชิงเส้น (linear layer) มีส่วนทำให้เกิดความล่าช้าถึง 95% แต่อัตราการเข้าถึงแคช L2 มีเพียง 16.4% เท่านั้น สาเหตุของปัญหานี้ไม่ใช่ความจุแคชที่ไม่เพียงพอ แต่คือการขาดการสร้างนามธรรม (abstraction) ในการเขียนโปรแกรมที่สามารถ “รับรู้” และ “ใช้ประโยชน์” จากขอบเขตของชิปเล็ตเพื่อการจัดตารางงานแบบร่วมมือ

วิธีแก้ปัญหาที่ Fleet เสนอคือการนำเสนอระดับงานใหม่ที่เรียกว่า Chiplet-task ระดับงานนี้จับคู่กับขอบเขตของ XCD อย่างแม่นยำ และผ่านรันไทม์ของเคอร์เนลแบบถาวร (Persistent Kernel) ทำให้สามารถดำเนินการงานแบบร่วมมือที่รับรู้ถึงชิปเล็ตได้ นี่ถือเป็นการเปลี่ยนแปลงที่สำคัญของกระบวนทัศน์การเขียนโปรแกรมจาก “ความคิดแบบชิปเดี่ยว” สู่ “ความเป็นจริงของชิปเล็ต”

สอง: การแตกหักระหว่างสถาปัตยกรรมและโมเดลการเขียนโปรแกรม: ฮาร์ดแวร์แบบชิปเล็ตกับซอฟต์แวร์แบบแบนราบ

ตารางที่ 1: การจับคู่ลำดับชั้นหน่วยความจำและโมเดลการเขียนโปรแกรมจาก GPU แบบชิปเดี่ยวสู่ GPU แบบชิปเล็ต Fleet เติมเต็มช่องว่างสำคัญระหว่างทรัพยากรฮาร์ดแวร์ระดับชิปเล็ตกับมุมมองซอฟต์แวร์ระดับอุปกรณ์โดยการนำเสนอการสร้างนามธรรม Chiplet-task

ในสถาปัตยกรรม GPU แบบชิปเดี่ยวแบบดั้งเดิม มีการจับคู่ที่ชัดเจนและสมมาตรระหว่างลำดับชั้นหน่วยความจำฮาร์ดแวร์กับการสร้างนามธรรมของโมเดลการเขียนโปรแกรม: เรจิสเตอร์สอดคล้องกับการทำงานแบบ SIMD หน่วยความจำร่วม (LDS) สอดคล้องกับ CU/SM และหน่วยความจำแบนด์วิดท์สูง (HBM) ทำหน้าที่เป็นหน่วยความจำส่วนกลางให้อุปกรณ์ทั้งหมดเข้าถึงได้ แคช L2 ซึ่งเป็นทรัพยากรระดับอุปกรณ์นั้นโปร่งใสสำหรับหน่วยประมวลผลทั้งหมด โปรแกรมเมอร์ไม่จำเป็นต้องกังวลเกี่ยวกับตำแหน่งที่แน่ชัดของข้อมูลใน L2

อย่างไรก็ตาม สถาปัตยกรรมแบบหลายชิปเล็ตได้ทำลายความสมมาตรนี้ ยกตัวอย่างสถาปัตยกรรม AMD CDNA3/CDNA4 ที่ใช้การออกแบบแบบชิปเล็ต ซึ่งประกอบด้วย XCD (Accelerator Compute Die) หลายตัว แต่ละ XCD มีแคช L2 เป็นของตัวเอง ในแง่ฮาร์ดแวร์ L2 ได้เปลี่ยนจากทรัพยากร “ระดับอุปกรณ์” เป็นทรัพยากร “ระดับชิปเล็ต” แต่โมเดลการเขียนโปรแกรมหลัก (เช่น HIP) ยังคงมองอุปกรณ์เป็นพื้นที่หน่วยความจำแบบแบนราบและรวมเป็นหนึ่งเดียว ส่งผลให้ตัวจัดตารางงานอาจจัดสรรกลุ่มงานต่าง ๆ ไปยัง XCD ที่แตกต่างกันแบบสุ่ม ทำให้ข้อมูลน้ำหนักเดียวกันถูกเก็บแคชซ้ำใน L2 ของ XCD ที่ต่างกัน สิ่งนี้ไม่เพียงแต่ทำให้พื้นที่แคชบนชิปอันมีค่าเสียไป แต่ยังสร้างการเข้าถึง HBM ที่ซ้ำซ้อนอีกด้วย

แผนภาพสถาปัตยกรรมของตัวเร่งความเร็วแบบหลายชิป AMD Instinct MI300X ประกอบด้วย XCD (Accelerator Compute Die) จำนวน 8 ตัว แต่ละตัวติดตั้งแคช L2 เป็นของตัวเอง เชื่อมต่อกันผ่าน Infinity Fabric ความเร็วสูงและเชื่อมต่อกับ HBM

เพื่อทำความเข้าใจผลกระทบที่ชัดเจนจากการแตกหักนี้ จำเป็นต้องวิเคราะห์เส้นทางการเข้าถึงหน่วยความจำของชิป เมื่อหน่วยประมวลผลบน XCD ใด ๆ เริ่มคำขอโหลดหน่วยความจำส่วนกลาง มันจะตรวจสอบ L2 ในเครื่องของมันก่อน หากไม่พบข้อมูล (miss) คำขอจะต้องถูกส่งผ่านการเชื่อมต่อระหว่างชิป (Infinity Fabric) ไปยัง IO Die เพื่อเข้าถึง HBM หรือ XCD อื่นที่มีข้อมูล โปรโตคอลความสอดคล้องของแคช (cache coherence) ของ AMD ถูกควบคุมโดยบิตขอบเขต (scope bit) ในคำสั่งหน่วยความจำ ภายใต้การตั้งค่า “ขอบเขตเวฟฟรอนต์” (wavefront scope) เริ่มต้น บรรทัดแคช L2 จะถือเป็นของในเครื่องของ XCD และจะไม่เริ่มการตรวจสอบหรือการทำให้หมดอายุ (invalidation) ความสอดคล้องข้าม XCD นี่หมายความว่า หากหน่วยประมวลผลสองหน่วยที่อยู่บน XCD ที่ต่างกันอ่านข้อมูลน้ำหนักเดียวกัน ระบบจะดำเนินการโหลดแยกกันสองครั้งจาก HBM และเก็บสำเนาหนึ่งชุดไว้ในแต่ละพาร์ติชัน L2 ที่ร้ายแรงกว่านั้นคือ การซิงโครไนซ์แบบอุปกรณ์ระดับ (device-level synchronization barrier) (เช่น buffer_wbl2) ที่ดำเนินการที่ขอบเขตของเคอร์เนลจะบังคับให้รีเฟรชบรรทัดแคชสกปรก (dirty cache line) ทั้งหมดเพื่อให้แน่ใจว่าสามารถมองเห็นได้ข้าม XCD ส่งผลให้ข้อมูลน้ำหนักที่เก็บไว้ใน L2 ไม่สามารถคงอยู่ระหว่างเคอร์เนลได้ และแต่ละครั้งที่เรียกใช้โอเปอเรเตอร์จะต้องโหลดข้อมูลน้ำหนักทั้งหมดใหม่จาก HBM

การแตกหักระหว่าง “สถาปัตยกรรม-โมเดลการเขียนโปรแกรม” นี้ถูกขยายอย่างรวดเร็วในขั้นตอนการถอดรหัส (decoding) ของโมเดลภาษาขนาดใหญ่ (LLM) ยกตัวอย่างโมเดล Qwen3-8B ซึ่งมีขนาดเมทริกซ์น้ำหนักต่อชั้นประมาณ 368MB (รูปแบบ bf16) และเมื่อขนาดแบทช์ (batch size) เป็น 128 เมทริกซ์แอคติเวชันจะมีขนาดเพียงประมาณ 1MB เท่านั้น — การไหลของการเข้าถึงหน่วยความจำส่วนใหญ่ถูกกำหนดโดยการโหลดน้ำหนัก ระบบบริการหลักในปัจจุบัน (เช่น vLLM) เริ่มต้นเคอร์เนลแยกกันสำหรับแต่ละโอเปอเรเตอร์ การถอดรหัสโทเค็นเดียวข้าม 36 ชั้นต้องใช้การเรียกเคอร์เนลเกือบ 250 ครั้ง หลังจากแต่ละครั้งที่เรียกใช้เคอร์เนล เนื้อหาใน L2 จะถูกล้างเนื่องจากกระบวนการซิงโครไนซ์ บังคับให้โอเปอเรเตอร์ถัดไปต้องโหลดข้อมูลน้ำหนักทั้งหมดที่ต้องการใหม่จาก HBM

ตารางที่ 2: การวิเคราะห์ลักษณะประสิทธิภาพของการถอดรหัส LLM บนสถาปัตยกรรม MI350 เมื่อไม่มีจัดตารางงานที่รับรู้ถึงชิปเล็ต ข้อมูลแสดงให้เห็นว่าการดำเนินการชั้นเชิงเส้นใช้เวลาคำนวณส่วนใหญ่ แต่การใช้งานแคช L2 มีประสิทธิภาพต่ำมาก

ข้อมูลในตารางที่ 2 ได้วัดค่าความรุนแรงของปัญหา: การดำเนินการชั้นเชิงเส้นใช้เวลาถอดรหัสถึง 95% แต่ในกรณีที่ขาดการจัดตารางงานแบบร่วมมือ แคช L2 ขนาด 4MB บน XCD สามารถบรรลุอัตราการเข้าถึงได้เพียงประมาณ 16.4% เท่านั้น นี่เผยให้เห็นคอขวดที่สำคัญ: แม้จะมีแบนด์วิดท์ HBM สูงถึง 5.3TB/s การใช้ประโยชน์ L2 ที่ไม่มีประสิทธิภาพยังคงทำให้ประสิทธิภาพจริงต่ำกว่าศักยภาพของฮาร์ดแวร์อย่างมาก หน่วยประมวลผลใช้เวลาส่วนใหญ่ในการรอข้อมูลโหลดจาก HBM

สาม: โมเดลงานของ Fleet: “ตัดเย็บให้พอดี” กับลำดับชั้นหน่วยความจำ

หนึ่งในนวัตกรรมหลักของกระบวนทัศน์การเขียนโปรแกรม Fleet คือการเสนอโมเดลงานหลายระดับที่จับคู่กับลำดับชั้นฮาร์ดแวร์ของ GPU แบบหลายชิปเล็ตได้อย่างแม่นยำ ปรัชญาการออกแบบคือ: งานควรถูกกำหนดและจัดตารางบนระดับความละเอียดของฮาร์ดแวร์ที่สอดคล้องกับความต้องการทรัพยากรของมัน

ตารางที่ 3: โครงสร้างลำดับชั้นงานสี่ระดับของ Fleet แต่ละระดับจับคู่กับขอบเขตทรัพยากรฮาร์ดแวร์เฉพาะและขอบเขตหน่วยความจำของมัน

โมเดลงานของ Fleet ทำลายรูปแบบการจัดตารางกริด (grid) เดี่ยวแบบดั้งเดิมในการเขียนโปรแกรม GPU และคืนการควบคุมให้กับโปรแกรมเมอร์ ทำให้สามารถแมปการคำนวณไปยังขอบเขตหน่วยความจำเฉพาะเจาะจงได้อย่างชัดเจน จากละเอียดไปหาหยาบ งานสี่ระดับมีดังนี้:

• งานเวฟฟรอนต์ (Wavefront Task): ดำเนินการภายในเธรด 64 ตัว ใช้เรจิสเตอร์และ LDS สำหรับการดำเนินการระดับองค์ประกอบแบบละเอียด
• งาน CU (CU Task): ครอบครองหน่วยประมวลผลเดียว ใช้ LDS สำหรับการสื่อสารระหว่างเธรดภายในบล็อก
• งานชิปเล็ต (Chiplet Task): นี่คือการสร้างนามธรรมที่เป็นนวัตกรรมหลักของ Fleet มันจัดกลุ่มหน่วยประมวลผลทั้งหมดบน XCD หนึ่งตัว (เช่น 31 CU) ให้เป็นหน่วยดำเนินการแบบรวมหนึ่งเดียว และกำหนดให้แคช L2 ส่วนตัวของ XCD นั้น (เช่น 4MB) เป็นชุดข้อมูลทำงานร่วมกันที่สามารถจัดการได้อย่างชัดเจน
• งานอุปกรณ์ (Device Task): ประสานงานงานชิปเล็ตหลายงาน (เช่น 8 งาน) เพื่อรวบรวมและซิงโครไนซ์ผลลัพธ์ในระดับ HBM ส่วนกลาง

การออกแบบแบบแบ่งชั้นนี้ไม่เพียงแต่กู้คืนข้อมูลโทโพโลยีหน่วยความจำฮาร์ดแวร์ที่ถูกซ่อนไว้โดยโมเดลการเขียนโปรแกรมแบบแบนราบ แต่ยังให้กรอบพื้นฐานสำหรับการปรับแต่งเค้าโครงข้อมูลและการจัดตารางงานแบบร่วมมือในภายหลัง

3.1 Chiplet-task: ความหมายเชิงลึกของการสร้างนามธรรมระดับชิปเล็ต

คุณค่าของ Chiplet-task ไม่ได้จำกัดอยู่แค่การเพิ่มระดับงานขึ้นมาอีกหนึ่งระดับ ความสามารถสำคัญที่มันปลดล็อกคือ: อนุญาตให้โปรแกรมเมอร์ระบุโหมดการทำงานร่วมกันของเธรดงานทั้งหมดภายใน XCD หนึ่งตัวในแคช L2 ได้อย่างแม่นยำ

ยกตัวอย่างการคูณเมทริกซ์ (GEMM) [M,K] × [K,N] Fleet สามารถแบ่งเมทริกซ์ผลลัพธ์ตามคอลัมน์ออกเป็นเมทริกซ์ย่อยอิสระ 8 ตัว งานชิปเล็ตแต่ละงานรับผิดชอบในการคำนวณหนึ่งในสไลซ์ [M,K] × [K, N/8] = [M, N/8] นี้ กลยุทธ์การแบ่งส่วนนี้บรรลุการปรับแต่งหลายประการ:

1. การแยกการคำนวณ (Computation Isolation): แต่ละชิปเล็ตประมวลผลพาร์ติชันคอลัมน์น้ำหนักที่แยกจากกัน สามารถคำนวณเสร็จโดยไม่ต้องซิงโครไนซ์ข้าม XCD
2. การทำงานร่วมกันของแคช (Cache Collaboration): เธรดงานทั้งหมดภายในชิปเล็ตเข้าถึงพาร์ติชันน้ำหนักเดียวกัน หลังจากที่เธรดแรกโหลดบล็อกน้ำหนักจาก HBM ไปยัง L2 แล้ว เธรดต่อ ๆ ไปสามารถเข้าถึงได้โดยตรงจาก L2 (hit) ซึ่งเพิ่มอัตราการใช้แคชซ้ำได้อย่างมาก
3. การกำจัดสัญญาณรบกวน (Interference Elimination): แคช L2 ระหว่างชิปเล็ตต่าง ๆ แยกจากกันโดยสมบูรณ์ หลีกเลี่ยงการแชร์ปลอม (false sharing) และค่าใช้จ่ายที่ไม่จำเป็นจากโปรโตคอลความสอดคล้อง

การออกแบบนี้แก้ปัญหาสำคัญสามประการพร้อมกัน:
* ผ่านการแบ่งส่วนตามมิติผลลัพธ์ (คอลัมน์) ทำให้การพึ่งพาการสื่อสารข้ามชิปเล็ตหายไปโดยธรรมชาติ
* ผ่านการเข้าถึงแบบร่วมมือของเธรดภายในชิปเล็ต ทำให้ “ความต้องการความจุแคช” ของเธรดหลายตัวถูกรวมเข้าด้วยกัน ขยายความสามารถในการใช้งานของ L2 ได้อย่างมีประสิทธิภาพ
* การยกระดับหน่วยจัดตารางงานจาก CU แบบละเอียดไปเป็น XCD แบบหยาบ ลดค่าใช้จ่ายในการกระจายและจัดการงานได้อย่างมีนัยสำคัญ

นอกจากนี้ Fleet ใช้อีเวนต์ (event) เพื่อแสดงความสัมพันธ์การพึ่งพาของงาน งานชิปเล็ตหนึ่งงานต้องการเพียงอีเวนต์เดียวเพื่อแสดงสถานะความสำเร็จของเธรดงานทั้งหมดบน XCD นั้น เมื่อเทียบกับโมเดลแบบดั้งเดิมที่ต้องจัดการอีเวนต์สำหรับแต่ละเธรดงานหรือกลุ่มงาน จำนวนอีเวนต์ซิงโครไนซ์ข้ามชิปเล็ตลดลงหลายสิบเท่า (เช่น 31 เท

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

SCAN TO PAY WITH ANY BANK