การโฮสต์ Qwen บน Blackwell

แร็ค NVIDIA GB200 NVL72 ที่มี GPU NVIDIA Blackwell เชื่อมต่อถึงกันผ่าน NVLink 72 ทาง เหมาะอย่างยิ่งสำหรับการปรับใช้งานโมเดล mixture-of-experts (MoE) ขนาดใหญ่ ในบล็อกโพสต์นี้ เราจะอธิบายการตั้งค่าการอนุมานที่ให้บริการโมเดล Qwen3 235B ที่ผ่านการฝึกอบรมเพิ่มเติมแล้ว ซึ่งรองรับปริมาณการใช้งานส่วนหนึ่งของ Perplexity เราแสดงให้เห็นว่าเราปรับแต่งเอ็นจิ้นการอนุมานภายในของเราอย่างไรเพื่อใช้ประโยชน์จากเทนเซอร์คอร์ขั้นสูงและการเชื่อมต่อความเร็วสูงของ GPU NVIDIA Blackwell ด้วยฮาร์ดแวร์นี้ เราสามารถจัดการปริมาณการใช้งานได้มากขึ้นด้วยต้นทุนที่ต่ำลงโดยไม่ลดทอนความแม่นยำของโมเดลพื้นฐาน

การปรับใช้งานบน GB200 NVL72

แร็ค GB200 NVL72 ประกอบด้วยโหนด 18 โหนดที่มี CPU NVIDIA Grace ฐาน ARM 2 ตัว และ GPU ฐาน Blackwell 4 ตัว ซึ่งแต่ละตัวติดตั้ง HBM ขนาด 180GB GPU ทั้ง 72 ตัวเชื่อมต่อถึงกันผ่าน NVLink และ ASIC ของ NVLink Switch 18 ตัว ให้แบนด์วิดท์ 1800 GB/s ระหว่างคู่ใดๆ และแชร์หน่วยความจำเพียงพอที่จะโฮสต์โมเดลพารามิเตอร์นับล้านล้าน นอกจากนี้ อะแดปเตอร์ ConnectX-7 InfiniBand ยังมอบแบนด์วิดท์เพิ่มเติม 400 Gb/s ทั้งภายในโหนดของแร็คและข้ามแร็คข้างเคียง

เพื่อจัดการปริมาณการใช้งาน เราเลือกที่จะฝึกอบรมเพิ่มเติมและให้บริการโมเดล Qwen ในบล็อกโพสต์นี้ เรามุ่งเน้นไปที่ Qwen3 235B แต่เทคนิคการให้บริการและลักษณะประสิทธิภาพที่อภิปรายหลายประการมีความคล้ายคลึงกับโมเดล Qwen3.5 397B และ 122B ใหม่กว่าที่เรากำลังย้ายไปใช้ ในแง่ของความขนาน linear attention มีความคล้ายคลึงกับ full self attention และการใช้งานชั้น MoE ที่มีอยู่สามารถปรับเปลี่ยนได้ง่ายเพื่อรองรับคำศัพท์เกตใหม่ เพื่อรักษาอัตราการถอดรหัสให้สอดคล้องกันพร้อมทั้งเพิ่มปริมาณงานสูงสุด เราจึงเลือกที่จะแยก prefill ออกจาก decode โดยปรับใช้กลยุทธ์ความขนานที่แตกต่างกันสำหรับโหนดสองประเภท การสื่อสารระหว่าง prefiller กับ decoder จัดการผ่าน InfiniBand ในขณะที่แบนด์วิดท์ NVLink สงวนไว้สำหรับการสื่อสารภายใน prefiller และ decoder ลักษณะประสิทธิภาพของอุปกรณ์ Blackwell เมื่อทำการคูณเมทริกซ์และการสื่อสารระหว่างอุปกรณ์ ซึ่งสำรวจในบล็อกโพสต์นี้ จะเป็นตัวกำหนดกลยุทธ์การแบ่งส่วนที่ใช้ เมื่อเทียบกับ GPU NVIDIA Hopper เราเห็นการปรับปรุงทีละเคอร์เนลเนื่องจากจำนวนมัลติโปรเซสเซอร์สตรีมมิ่งที่สูงขึ้น แบนด์วิดท์หน่วยความจำที่เพิ่มขึ้น และความหน่วงแบบ peer-to-peer ที่ต่ำลง

ขยาย

TransferEngine ของเรา ซึ่งใช้งาน prefill แบบแยกส่วน จัดการการแบ่งส่วนตามอำเภอใจและอาจไม่ตรงกันทั่วทั้ง prefiller และ decoder แคช KV ถูกจัดเรียงในหน่วยความจำตามลำดับ HND โดยมีเฮดอยู่ในมิติหลักและโทเค็นที่เชื่อมต่อกัน เพื่อให้สามารถแบ่งแคช KV แบบแบ่งส่วนบน prefiller แยกย่อยเพิ่มเติมหรือต่อกันระหว่างการถ่ายโอนไปยังโหนด decoder

Prefiller

โหนด prefiller จะรับโทเค็นอินพุตของคำขอ เติมแคช KV และถ่ายโอนไปยัง decoder เพื่อดำเนินการสร้างข้อความต่อ การทำ prefill ใช้การคำนวณอย่างเข้มข้น เนื่องจากโทเค็นนับพันที่อยู่ในลำดับเดียวกันถูกประมวลผลพร้อมกัน

ดังนั้น เราจึงพบว่าการปรับใช้เทนเซอร์แบบขนานมีความเหมาะสม โดยโมเดลถูกแบ่งส่วนข้าม GPU 4 ตัวภายในโหนด GB200 เดี่ยว และการฉายภาพและผู้เชี่ยวชาญถูกแบ่งส่วน (TP=4, EP=4) เนื่องจากทั้ง attention และ MLP ถูกจำกัดด้วยการคำนวณ ทั้งคู่จึงได้รับประโยชน์จากความขนาน โดยกระจายผู้เชี่ยวชาญและเฮด attention ข้ามเรงก์ที่แยกจากกัน ความขนานที่มากกว่านี้จะให้ผลตอบแทนที่ลดลง เนื่องจากประสิทธิภาพปริมาณงานที่เพิ่มขึ้นจากการโฮสต์ผู้เชี่ยวชาญที่น้อยลงในแต่ละเรงก์ (16 เทียบกับ 32) จะไม่ชดเชยต้นทุนเพิ่มเติมของ all-reduce แบบ 8 ทางและโอเวอร์เฮดของการแบ่งโค้ดฝั่งโฮสต์ข้ามสองโหนด ซึ่งต้องมีการสื่อสารผ่านอีเธอร์เน็ต

Qwen3 235B มีคีย์-แวลูเฮดเพียง 4 ตัว ซึ่งกำหนดให้ต้องจำลองการฉายภาพ k และ v ข้ามคู่เรงก์หากใช้อุปกรณ์ 8 ตัว เราอาจพิจารณาการแบ่งส่วนที่ก้าวร้าวมากขึ้นเพื่อลดปริมาณหน่วยความจำที่ต้องใช้ในการจัดเก็บน้ำหนักบนแต่ละเรงก์ ซึ่งช่วยเพิ่มสเปซสำหรับโทเค็นเพิ่มเติมในแคช KV อย่างไรก็ตาม เราพบว่าการปรับใช้ที่กว้างขึ้นนั้นไม่คุ้มค่า

โดยสมมติว่าความยาวอินพุตอยู่ที่ประมาณ 6000 โทเค็น ผู้เชี่ยวชาญแต่ละคนจาก 128 คนจะมีโทเค็นที่ถูกกำหนดเส้นทางไปยังตัวเองประมาณ 6000 * 8 / 128 = 375 โทเค็น ซึ่งช่วยให้มั่นใจได้ว่าเป็นปัญหาที่มีความหนาแน่นสำหรับ MoE GEMM เนื่องจากสิ่งนี้อิ่มตัวปริมาณงานการคำนวณของอุปกรณ์อยู่แล้ว จึงไม่จำเป็นต้องใช้ความขนานของข้อมูลสำหรับการทำ prefill

แม้ต้นทุนของการคำนวณความสนใจจะเพิ่มขึ้นเป็นกำลังสอง แต่ prefiller ก็ยังให้ throughput ที่คงที่ ทำให้สามารถประเมินจำนวน input tokens โดยคร่าว ๆ ที่โหนดหนึ่งสามารถประมวลผลได้ในหนึ่งวินาทีได้ โดยอาศัยเมตริกที่ติดตามจำนวน input tokens ทั้งหมดจากคำขอ จึงสามารถปรับจำนวน prefiller nodes เพิ่มขึ้นเพื่อให้แน่ใจว่า throughput ของ prefill โดยรวมถูกกำหนดขนาดอย่างเหมาะสม เพื่อหลีกเลี่ยงการรอคิว จำนวน prefiller replicas จะถูกจับคู่กับจำนวน input tokens ทั้งหมดที่ได้รับ

Decoder

โหนด decoder รับแคช KV จาก prefiller และสร้างโทเค็นทีละรายการ การถอดรหัสโดยทั่วไปจะถูกจำกัดด้วยหน่วยความจำ: ด้วยโทเค็นอินพุตเพียงเล็กน้อย การคูณเมทริกซ์จะถูกจำกัดโดยต้นทุนการโหลดน้ำหนักจาก HBM เข้าสู่เทนเซอร์คอร์ทั้งหมด นอกเหนือจากการใช้กลยุทธ์การแบ่งส่วนที่แตกต่างกันแล้ว เคอร์เนลหลายตัวยังต้องได้รับการปรับแต่งเพื่อให้การคำนวณและการเข้าถึงหน่วยความจำมีความขนานกันมากขึ้น

ต่างจากการทำ prefill การแบ่งส่วน attention จะไม่มีประโยชน์อีกต่อไป: การแยกเฮด attention ข้ามอุปกรณ์หลายตัวหมายความว่าจะมีโอกาสน้อยลงสำหรับความขนานภายในอุปกรณ์เครื่องเดียว ดังนั้น จึงใช้เพียงความขนานของข้อมูลและความขนานของผู้เชี่ยวชาญเท่านั้น: ผู้เชี่ยวชาญจะถูกแบ่งส่วนข้ามอุปกรณ์หลายตัว แต่อุปกรณ์แต่ละตัวจะจัดการแคช KV และคำขอของตนเอง หากไม่มีเทนเซอร์แบบขนาน ขนาดแคช KV ต่อโทเค็นบนอุปกรณ์จะมีขนาดใหญ่ขึ้น อย่างไรก็ตาม สเปซในหน่วยความจำจะว่างขึ้นโดยการวางผู้เชี่ยวชาญจำนวนน้อยลงบนโหนดเดียว ต่างจาก Hopper ซึ่งเราจำกัดเทนเซอร์แบบขนานภายในโดเมน NVLink เดี่ยวในโหนด 8-GPU บน Blackwell เราพบว่าการขยายข้ามหลายโหนดภายในโดเมนโดยใช้อุปกรณ์สูงสุด 16 ตัวนั้นมีประโยชน์

เพื่อเพิ่มปริมาณงานสูงสุด decoder จะประมวลผลคำขอจำนวนมากขึ้นพร้อมกัน แม้ว่าคำขอเพิ่มเติมจะมีโอเวอร์เฮดเพียงเล็กน้อยในชั้น MoE และการฉายภาพอื่นๆ แต่คำขอเหล่านี้จะเพิ่มต้นทุนของ attention อย่างไม่สมส่วน เพื่อรักษาความเร็วในการถอดรหัสขั้นต่ำที่เหมาะสม จำนวนโหนด decoder จะถูกปรับขนาดเพื่อให้ขนาดแบตช์ต่อ decoder ต่ำกว่าเกณฑ์ที่กำหนด

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

การสื่อสารภายในโหนดและระหว่างโหนด

ความแตกต่างหลักระหว่าง GB200 NVL72 และโหนด Hopper ก่อนหน้าคือโดเมน NVLink ขนาดใหญ่ ซึ่งช่วยให้สามารถสื่อสารแบบ peer-to-peer เกินขีดจำกัดเดิมที่ 8 อุปกรณ์ แม้ว่าอุปกรณ์ Blackwell จะถูกปรับใช้ในโหนด 8-GPU แต่ก็มีคุณค่าอย่างมากในการปรับขนาดข้ามหลายโหนดผ่าน NVLink เมื่อเทียบกับเครือข่าย InfiniBand ที่ช้ากว่า

บนโหนด prefiller เราอาศัยการสื่อสาร all-reduce ภายในชั้น attention และการลดทอนแบบขนานของผู้เชี่ยวชาญที่มีความคล้ายคลึงกับ all-reduce อย่างมาก ข้าม GPU 4 ตัว เราใช้ประโยชน์ทั้ง NVLink และ NVIDIA SHARP (Scalable Hierarchical Aggregation and Reduction Protocol): นอกเหนือจากแบนด์วิดท์ peer-to-peer แล้ว เรายังใช้ประโยชน์จากการลดทอนใน NVLink Switches เพื่อลดความหน่วงเพิ่มเติมและใช้งานการกระจายเสียงแบบเร็ว บนโหนด decoder มีการใช้การใช้งาน dispatch และ combine แบบ all-to-all แบบกำหนดเองผ่าน NVLink เคอร์เนลได้รับการพัฒนาภายในองค์กรโดยใช้ CuTeDSL และการแมป cuMem หรือการแมปมัลติคาสต์

All-Reduce

prefiller ดำเนินการปฏิบัติการ all-reduce ในการฉายภาพเอาต์พุตของชั้น attention โดยรวมการมีส่วนร่วมของเฮดที่แบ่งส่วนข้ามเรงก์ที่เข้าร่วม เทนเซอร์แบบขนานจะมีประสิทธิภาพก็ต่อเมื่อต้นทุนของโอเวอร์เฮด all-reduce ถูกชดเชยด้วยความหน่วงที่ลดลงของปัญหาการคูณเมทริกซ์ขนาดเล็ก สมมติฐานนี้มักจะเป็นจริงสำหรับการทำ prefill

บนระบบระดับศูนย์ข้อมูล NVIDIA HGX H200 และ GB200 NVL72 โดยทั่วไป GPU จะเชื่อมต่อผ่าน NVLink Switches นอกเหนือจากการกำหนดเส้นทางแล้ว สวิตช์ยังสามารถปฏิบัติการลดทอนข้ามอุปกรณ์ที่เชื่อมต่อผ่าน SHARP หลังจากสร้างการแมปหน่วยความจำและลงทะเบียนในกลุ่มมัลติคาสต์โดยใช้ CUDA API เคอร์เนลสามารถใช้ multicast.ld_reduce และ multicast.st เพื่อรวบรวมและกระจายค่าผ่านสวิตช์ เพื่อสร้างรากฐานและส่วนประกอบที่นำกลับมาใช้ใหม่ซึ่งสามารถรวมเข้ากับเคอร์เนลอื่น ๆ ได้ เราจึงบำรุงรักษาเคอร์เนล CuTeDSL all-reduce ภายในองค์กรโดยใช้พริมิทีฟเหล่านี้

ในระบบที่มี N GPU สำหรับการลดค่า B ไบต์ การติดตั้งแบบง่ายที่สุดคือให้ peer หนึ่งตัวอ่านค่าจาก peers อื่นทั้งหมด ซึ่งจะมีทราฟฟิกการอ่านรวม N * (N - 1) * B ไบต์ การติดตั้งที่มีประสิทธิภาพมากกว่าจะกระจายข้อมูลที่จะลดค่าระหว่าง peers โดยแต่ละตัวลดค่าข้อมูลเพียงส่วนหนึ่งของอินพุต จากนั้นจึงบรอดแคสต์ผลไปยังส่วนที่เหลือ ส่งผลให้มีการอ่านเข้า peer หนึ่งตัวและบรอดแคสต์ไปยังส่วนที่เหลือเป็น (N - 1) * (B / N) ไบต์ รวมเป็นการอ่านและเขียน (N - 1) * B * 2 ลดทราฟฟิกผ่านสวิตช์

ขยาย

ด้วย SHARP การลดทอนและการกระจายสามารถทำได้มีประสิทธิภาพมากขึ้น: แทนที่จะอ่านไบต์ (N - 1) * (B / N) เข้าสู่อุปกรณ์เพื่อสะสมภายใน จะมีการย้ายเพียง B / N จากสวิตช์ เนื่องจากสวิตช์ดำเนินการลดทอนด้วยตนเองโดยใช้ข้อมูลจาก peer สำหรับการกระจาย จะมีการปรับปรุงที่คล้ายกัน เนื่องจากจำนวนธุรกรรมระหว่าง GPU และสวิตช์ผ่านช่องสัญญาณ NVLink ลดลงอย่างมาก หากไม่มี SHARP อุปกรณ์สะสมจะดำเนินการธุรกรรม (N - 1) * (B / N) ผ่าน NVLink กับสวิตช์ โดยที่สวิตช์จะอ่านข้อมูลจำนวนเดียวกันจาก peer สำหรับธุรกรรมรวม 2 * (N - 1) * (B / N) ด้วย SHARP จะมีการดำเนินการธุรกรรม B / N ระหว่าง GPU และสวิตช์ และธุรกรรมเพิ่มเติม (N - 1) * (B / N) กับ peer สำหรับธุรกรรมรวม B

เนื่องจากความเรียบง่าย SHARP จึงเป็นเครื่องมือที่มีค่า เนื่องจากมีการใช้งานฮาร์ดแวร์ตรงไปตรงมาสำหรับอัลกอริทึม แม้ว่าการถ่ายโอนจะลดลงตามเศษส่วนทางทฤษฎี N / (2 * (N - 1)) (ซึ่งเท่ากับ 33% ด้วย 4 peer) แต่ในทางปฏิบัติเราสังเกตเห็นการปรับปรุง 10% ในความหน่วงทั้ง prefill และ decode บนทั้งระบบ H200 และ GB200 NVL72

ขยาย

MoE Dispatch - Combine

สำหรับโมเดล MoE เคอร์เนล dispatch และ combine จะย้ายและจัดกลุ่มโทเค็นสำหรับปัญหา MoE GEMM ตามลำดับระหว่าง peer โดยดำเนินการสะสมแบบถ่วงน้ำหนักหลังจากนั้นใน combine เราได้ปรับ adaptation เคอร์เนล Dispatch และ Combine ที่มีอยู่ของเราให้เข้ากับ Blackwell โดยพอร์ตไปยัง CuTeDSL ปรับแต่งการจัดสรรบล็อก และเชี่ยวชาญเฉพาะทางอย่างเข้มงวดระหว่าง prefill และ decode

Expert Parallel

เคอร์เนล expert parallel (EP) ถูกใช้ใน prefiller เนื่องจากอินพุตของมันถูกจำลองข้ามเรงก์ทั้งหมด เคอร์เนล dispatch จึงเพียงแค่ต้องเลือกโทเค็นที่ถูกกำหนดเส้นทางไปยังผู้เชี่ยวชาญบนเรงก์ปัจจุบัน มันรวบรวมข้อมูลการกำหนดเส้นทางและเตรียมโทเค็นลงในบัฟเฟอร์ที่ใช้เป็นอินพุตสำหรับ MoE GEMM เคอร์เนล combine จะดำเนินการสะสมภายในระหว่างการมีส่วนร่วมของโทเค็นที่ถูกกำหนดเส้นทางไปยังผู้เชี่ยวชาญบนเรงก์ปัจจุบันก่อน จากนั้นจึงดำเนินการ all-reduce ข้ามเรงก์ทั้งหมด

สำหรับการถอดรหัส เคอร์เนลทั้งหมดจะถูกรวมเป็นหนึ่งเดียว เคอร์เนล prefill ถูกแบ่งออกเป็นหลายเคอร์เนล เนื่องจากการกำหนดเส้นทางและ all-reduce ต้องการบล็อกน้อยกว่าขั้นตอน combine ภายใน ด้วย CuTeDSL เราสามารถสร้างไลบรารีทั่วไปสำหรับทั้ง SHARP และ NVLink all-reduce และการซิงโครไนซ์ peer-to-peer โดยประกอบเข้ากับทั้งเคอร์เนล all-reduce และ expert parallel

ขยาย

ในแง่ของประสิทธิภาพ เราสังเกตว่า Blackwell เร็กว่า Hopper อย่างมาก เนื่องจากความเร็วในการถ่ายโอนที่ดีขึ้น แบนด์วิดท์หน่วยความจำที่สูงขึ้น และปริมาณงานการคำนวณที่ดีขึ้น เมื่อแบ่งส่วนข้ามอุปกรณ์ 8 ตัวและหลายโหนดบน GB200 (EP=8) เคอร์เนลจะเร็วขึ้นเนื่องจากการสะสมภายในทำงานบนโทเค็นที่น้อยกว่ามากบนอุปกรณ์แต่ละตัว และด้วย SHARP ต้นทุนการลดทอนข้ามเรงก์จำนวนมากขึ้นจะปรับขนาดได้ดีขึ้น อย่างไรก็ตาม ในทางปฏิบัติ เราจำกัดความขนานไว้ที่ 4 อุปกรณ์ เนื่องจากความเร็วดังกล่าวไม่ได้เป็นสากลในเคอร์เนลทั้งหมด

Data Parallel และ Expert Parallel

เคอร์เนล data parallel และ expert parallel (DP-EP) ถูกใช้ใน decoder แบบ data parallel มันกระจายโทเค็นที่แตกต่างกันจากเรงก์ทั้งหมดไปยังผู้เชี่ยวชาญ โดยถ่ายโอนผลลัพธ์ไปยังเรงก์ต้นทางและสะสมผลลัพธ์เหล่านั้น เนื่องจากมันใช้งานปัญหาแบบ sparse all-to-all จึงพึ่งพา NVLink เพียงอย่างเดียว

บน Hopper เคอร์เนลนี้จำกัดไว้ที่ 8 อุปกรณ์ภายในโดเมน NVLink ของโหนดเดียว อย่างไรก็ตาม บนระบบ GB200 เราสามารถปรับขนาดข้ามแร็คทั้งหมดได้ โค้ดส่วนใหญ่ถูกนำกลับมาใช้ใหม่ ความแตกต่างเดียวคือการใช้แฮนเดิล fabric เพื่อแลกเปลี่ยนข้อมูล peer ผ่าน IMEX สำหรับการตั้งค่าเริ่มต้น

ขยาย

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

MoE GEMM

โมเดล MoE ได้ประโยชน์จาก expert parallel เนื่องจากต้นทุนในการคูณโทเค็นทั้งหมดกับผู้เชี่ยวชาญทั้งหมดสามารถทำให้อยู่ในรูปขนานข้ามอุปกรณ์หลายตัวได้อย่างง่ายดาย ด้วยเทนเซอร์แบบขนานบน prefiller ในปัญหาที่มีความหนาแน่น ประโยชน์นั้นค่อนข้างตรงไปตรงมา เนื่องจากเรงก์แต่ละเรงก์ต้องทำการคำนวณน้อยลง ในกรณีการถอดรหัส data parallel ให้ประโยชน์เพิ่มเติมทับ expert parallel เนื่องจากจำนวนคำขอแบบขนานที่มากขึ้นจะกำหนดเส้นทางโทเค็นไปยังผู้เชี่ยวชาญแต่ละคนมากขึ้น ทำให้ปัญหาหนาแน่นขึ้น

ในการใช้งานของเรา ปัจจุบันเราอาศัยเคอร์เนล CUTLASS CUDA/C++ สำหรับการคูณเมทริกซ์ เราได้ทำการประเมินประสิทธิภาพบนอินพุตการถอดรหัสแบบ sparse ด้วยรูปแบบการทำควอนตไทเซชันและระดับความขนานต่างๆ เพื่อตัดสินใจเลือกกลยุทธ์การแบ่งส่วนที่เหมาะสมที่สุดสำหรับ decoder ในการประเมินประสิทธิภาพด้านล่าง ผู้เชี่ยวชาญทั้งหมดจะถูกเปิดใช้งานด้วยโทเค็นเดียว

ขยาย

เราพบว่าการปรับขนาดผู้เชี่ยวชาญ 128 คนข้ามเรงก์มากกว่า 16 เรงก์ให้ผลตอบแทนที่ลดลงด้วย CUTLASS เนื่องจากต้นทุนในการคูณผู้เชี่ยวชาญ 2 คนไม่ได้ต่ำกว่าการคูณ 4 คนอย่างมีนัยสำคัญ มีการปรับปรุงที่ชัดเจนบน Blackwell เหนือ Hopper แม้กระทั่งในกลยุทธ์การปรับขนาดบล็อกที่เหมาะสมน้อยกว่า เนื่องจากความหน่วงที่เพิ่มขึ้นประมาณ 5 us ระหว่าง EP=8 และ EP=16 ของ dispatch/combine ถูกกลบด้วยการลดลงมากกว่า 10 us ในต้นทุนของ GEMM บนระบบ GB200 การแบ่งส่วน decoder ข้าม 16 เรงก์จึงเป็นสิ่งที่สมเหตุสมผล ดังที่ได้รับการยืนยันจากการประเมินประสิทธิภาพแบบ end-to-end เช่นกัน

Quantization

Blackwell นำเสนอการสนับสนุนฮาร์ดแวร์สำหรับรูปแบบการทำควอนตไทเซชัน 8 บิตและ 4 บิตใหม่ ต่างจาก Hopper ซึ่งอาศัยปัจจัยการปรับขนาดต่อเทนเซอร์หรือต่อบล็อก Blackwell จำเป็นต้องมีการปรับขนาดระดับจุลภาค (microscaling) เพื่อให้ได้ปริมาณงาน prefill และ decode ที่ดีที่สุด แม้ว่ากลยุทธ์การปรับขนาดบล็อกที่ใช้สำหรับโมเดลเช่น DeepSeek หรือ Kimi จะใช้งานได้ แต่การปรับขนาดระดับจุลภาคจะมีประสิทธิภาพมากกว่า

เราได้ปรับใช้งาน Qwen3 235B ด้วยรูปแบบการทำควอนตไทเซชัน MXFP8 โดยแปลงน้ำหนักแบบสถิตหลังจากปรับแต่งโมเดลอย่างละเอียดแล้ว ผลกระทบต่อความแม่นยำมีความคล้ายคลึงกับผลกระทบของการปรับขนาดบล็อกด้วยควอนตไทเซชันแบบสุ่ม แต่ประสิทธิภาพที่ได้นั้นดีขึ้นมาก ดังแสดงโดยไมโครเบนช์มาร์ก MoE GEMM นอกจากนี้ เรายังได้พิจารณารูปแบบการทำควอนตไทเซชัน MXFP4 และ NVFP4 แม้ว่าผลกระทบต่อความแม่นยำโดยไม่มีการฝึกอบรมที่คำนึงถึงควอนตไทเซชันจะสูงเกินไปสำหรับการเปลี่ยนผ่านครั้งแรกจาก Hopper ไปยัง Blackwell เราวางแผนที่จะสำรวจรูปแบบเหล่านี้ให้ละเอียดยิ่งขึ้นในงานในอนาคต

ประสิทธิภาพ End-to-End

เราได้ประเมินประสิทธิภาพ decoder ของการปรับใช้งาน Blackwell Qwen3 235B และเปรียบเทียบกับการปรับใช้งาน Hopper ก่อนหน้าของเรา ในการตั้งค่านี้ เราได้พิจารณาการปรับขนาดบล็อกข้ามการปรับใช้งานทั้งสองเพื่อมุ่งเน้นไปที่ผลกระทบของความขนาน prefiller TP=4 ถูกแยกออกสำหรับสถาปัตยกรรมทั้งสองเพื่อแยกประสิทธิภาพการถอดรหัส แผนภาพด้านล่างแสดงปริมาณงานการถอดรหัสโดยสมมติว่าอัตราการยอมรับฉบับร่างที่สมจริงซึ่งส่งมอบโดยชั้น MTP ของเรา

ขยาย

บน Hopper การแบ่งส่วนการปรับใช้งานข้าม GPU มากกว่า 8 ตัวนั้นไม่สามารถทำได้ เนื่องจากความหน่วงข้าม InfiniBand โดยเฉพาะบนอะแดปเตอร์ EFA ช้ากว่าอย่างมาก อย่างไรก็ตาม บน Blackwell เราบรรลุปริมาณงานที่สูงกว่าอย่างมาก ต้องขอบคุณโดเมน NVLink ที่ใหญ่ขึ้น

เราบรรลุการใช้งาน Blackwell เริ่มต้นโดยการทำให้เคอร์เนล Hopper ที่มีอยู่เป็นทั่วไปและผลักดันประสิทธิภาพของเคอร์เนลที่ใช้ NVLink เราจะลดต้นทุนในการให้บริการ Qwen เพิ่มเติมโดยการปรับปรุงการทำควอนตไทเซชันและปรับแต่งประสิทธิภาพการถอดรหัสและปริมาณงาน prefill ของเคอร์เนลอื่นๆ ในไปป์ไลน์

ข้อมูลอ้างอิง

บล็อกโพสต์ Transfer Engine

บล็อกโพสต์ CuTeDSL

บล็อกโพสต์ Prefill-Disagg

บล็อกโพสต์ Speculative Decoding

CUTLASS

NVLink

การอ้างอิง

@online{perplexity2026HostingQwenOnBlackwell,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Bex Brooker and Erin McKnight},
  title = {{Hosting Qwen on Blackwell}},
  date = {2026-05-12},
  url = {https://www.perplexity.ai/hub/blog/hosting-qwen-on-blackwell}
}