Cursor's MoK บรรลุการเพิ่มประสิทธิภาพ 2.37 เท่าบน NVIDIA GB300 NVL72

Cursor เปิดตัว MoK แบบโอเพ่นซอร์ส ซึ่งรวมการจัดการโทเค็น การสื่อสารข้าม GPU และการคำนวณผู้เชี่ยวชาญไว้ในเคอร์เนล GPU เดียวกัน โซลูชันนี้บรรลุการเพิ่มประสิทธิภาพสูงสุด 2.37 เท่าสำหรับการดำเนินการแบบฟอร์เวิร์ดและ 1.78 เท่าสำหรับการย้อนกลับใน GB300 NVL72 ด้วย MXFP8 และเพิ่มความเร็วในการฝึกด้วย GPU GB300 512 ตัวเป็น 41% ถึง 1070.2 tokens/s ความล่าช้าในการส่งสัญญาณลดลงจาก 103μs เป็น 18μs การวิเคราะห์ชี้ให้เห็นว่าในยุคที่แบนด์วิดธ์ NVLink 已达 130 TB/s แล้ว เวลาในการเข้าถึงข้อมูลของ GPU จึงกลายเป็นข้อจำกัดด้านประสิทธิภาพใหม่ การก้าวกระโดดนี้ถือเป็นจุดเริ่มต้นของยุคการแข่งขัน AI ที่เข้าสู่ “อธิปไตยแบบครบวงจร” โดยบริษัทใดที่สามารถทำให้โค้ดอยู่ใกล้หน่วยความจำและรีจิสเตอร์ของ GPU มากเท่าใด ก็จะมีอำนาจในการกำหนดราคาสูงขึ้นเท่านั้น

ผู้เขียนบทความ แหล่งที่มา: LeFeng.com

วันที่ 21 กรกฎาคม NVIDIA เปิดเผยผลลัพธ์ล่าสุดในการฝึก DeepSeek-V3 ด้วย GB300 NVL72: บน GPU 256 ตัว ประสิทธิภาพต่อการ์ดหนึ่งตัวอยู่ที่ 1,648 TFLOPS

ไม่ถึงสองสัปดาห์ต่อมา Cursor เปิดแหล่งที่มาของ Mixture-of-Kittens หรือ MoK แทนที่จะพยายามพัฒนาการคูณเมทริกซ์ที่เร็วขึ้น มันจึงเขียนใหม่ทั้งชั้นของการดำเนินการ MoE โดยรวมการจัดการโทเค็น การสื่อสารข้าม GPU และการคำนวณผู้เชี่ยวชาญไว้ในเคอร์เนล GPU เดียวกัน

เรื่องนี้ค่อนข้างขัดกับความเข้าใจทั่วไป เพราะ GB300 NVL72 ได้ใส่ GPU 72 ตัวไว้ใน NVLink Domain เดียวกัน ทำให้แบนด์วิธ NVLink ทั้งหมดของชั้นวางเครื่องถึง 130 TB/s ตามสเปกนี้ การส่งข้อมูลระหว่าง GPU ควรจะเร็วพอแล้ว

ในการฝึกโมเดล MoE ขนาดใหญ่ การสื่อสารยังคงเป็นข้อจำกัดต่อการคำนวณของผู้เชี่ยวชาญ

ปัญหาอยู่ที่กระแสข้อมูลของ MoE ตัว Router ต้องตัดสินใหม่ในแต่ละขั้นตอนว่า token ควรส่งไปยังผู้เชี่ยวชาญใด ขณะที่ผู้เชี่ยวชาญกระจายอยู่บน GPU ต่างกัน token ต้องถูกส่งข้ามการ์ดไปก่อน คำนวณเสร็จแล้วจึงส่งกลับมา; ก่อนส่งต้องจัดเรียงตำแหน่ง และหลังมาถึงต้องรอให้ข้อมูลครบถ้วน เมื่อ MXFP8 และ Blackwell Tensor Core ลดเวลาการคำนวณของผู้เชี่ยวชาญให้สั้นลงเรื่อยๆ การรอที่เคยซ่อนอยู่เบื้องหลังการคำนวณเริ่มเด่นชัดขึ้น

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

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

การเปิดแหล่งที่มาของ MoK ไม่เพียงแต่เป็นชัยชนะของเคอร์เนลเท่านั้น แต่ยังเป็นจุดเริ่มต้นของยุคที่ “แอปพลิเคชันกำหนดตัวดำเนินการ”: เพื่อผลิตกำลังการประมวลผลสุดท้าย 30% บริษัทสตาร์ทอัพด้าน AI กำลังเริ่มต้นสงครามชิงอำนาจจากพื้นฐาน

อย่างไรก็ตาม เพื่อเข้าใจว่าทำไมการออกแบบของ Cursor จึงมีประสิทธิภาพ ก่อนอื่นต้องมองให้เห็นชัดว่า MoE นั้นต้องจ่าย “ภาษีการสื่อสาร” ที่จุดใด

01

ภาษีการสื่อสารของ MoE

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

รอบแรกเรียกว่า Dispatch ซึ่งส่ง token ไปยัง GPU ที่ผู้เชี่ยวชาญอยู่ เมื่อผู้เชี่ยวชาญคำนวณเสร็จแล้ว จะส่งผลลัพธ์กลับไปยังตำแหน่งเดิมของ token ผ่าน Combine การฝึกอบรมยังมีการแพร่ย้อนกลับ ซึ่งจะดำเนินการสื่อสารสองรอบในทิศทางตรงข้าม

หากคุณแค่ย้ายข้อมูลต่อเนื่องขนาดใหญ่จาก A ไปยัง B NVLink ก็เร็วเพียงพอ ปัญหาของ MoE คือ การแจกแจงข้อมูลที่ Router ให้ในแต่ละขั้นตอนนั้นแตกต่างกัน

ผู้เชี่ยวชาญบางคนอาจได้รับโทเค็นจำนวนมากในขั้นตอนนี้ แต่ในขั้นตอนถัดไปกลับได้น้อยมาก ระบบต้องนับจำนวนโทเค็นที่แต่ละผู้เชี่ยวชาญมีก่อน แล้วจึงตัดสินใจว่าจะวางโทเค็นเหล่านี้ไว้ที่ตำแหน่งใดบน GPU เป้าหมาย และควรจัดเรียงข้อมูลของผู้เชี่ยวชาญเดียวกันให้อยู่ใกล้กันให้มากที่สุด เพื่อให้ Grouped GEMM ได้รับข้อมูลที่เรียบง่ายและสามารถส่งต่อให้ Tensor Core อย่างมีประสิทธิภาพ

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

ดังนั้น ในขั้นตอนหนึ่งของการ “สื่อสาร” จึงมีหลายอย่างปนกัน เช่น การย้ายข้อมูล การสร้างโครงสร้าง การซิงโครไนซ์ และความไม่สมดุลของโหลด ค่า 130 TB/s แสดงถึงแบนด์วิธสูงสุดที่ชั้นวางทั้งหมดสามารถให้ได้ แต่ไม่ได้หมายความว่าการสื่อสาร MoE แบบไดนามิกและกระจัดกระจายแต่ละครั้งจะสามารถใช้งานเส้นทางเหล่านี้ได้เต็มที่พร้อมกัน

DeepEP ได้เร่งกระบวนการถ่ายโอนข้อมูลอย่างมาก มันเป็นไลบรารีการสื่อสารประสิทธิภาพสูงที่ออกแบบมาเฉพาะสำหรับ Expert Parallel โดยมีเคอร์เนล Dispatch และ Combine ที่ออกแบบมาเฉพาะ รองรับ FP8 และอนุญาตให้ควบคุมจำนวน SM ที่ใช้สำหรับการสื่อสาร รุ่นล่าสุดยังสามารถรักษาปริมาณการส่งข้อมูลการสื่อสารที่สูงด้วยจำนวน SM น้อยกว่าอย่างชัดเจน

โมดูล MoE ยังคงต้องส่งต่อข้อมูลระหว่างการจัดส่ง, GEMM แบบจัดกลุ่ม และการรวมกันอย่างต่อเนื่อง

ในขณะนี้จะพบกับความขัดแย้งที่เป็นรูปธรรม: หากรอให้โทเค็นเพียงพอครบถ้วนก่อนจึงคำนวณ แมทริกซ์จะใหญ่และ Tensor Core จะทำงานได้อย่างมีประสิทธิภาพ แต่การคำนวณจะเริ่มช้า; หากคำนวณทันทีที่มีโทเค็นมาแม้เพียงเล็กน้อย การสื่อสารและการคำนวณจะสามารถทับซ้อนกันได้เร็วขึ้น แต่แมทริกซ์จะเล็กเกินไป ทำให้ SM จำนวนมากบน GPU ไม่มีงานเพียงพอ

การใช้ CUDA Stream หลายตัวสามารถทำให้การสื่อสารและการคำนวณทำงานพร้อมกันได้ แต่ยากที่จะรับประกันได้เสมอว่าทั้งสองฝ่ายจะได้รับทรัพยากร GPU ที่เหมาะสม

การออกแบบหลัง MoK ส่วนใหญ่จัดการกับปัญหา “จังหวะ” นี้

02

หนึ่งในการเปลี่ยนแปลงที่น่าสนใจที่สุดของ MoK คือการเปลี่ยนการส่งแบบก่อนหน้าจาก Push เป็น Pull

Push แบบดั้งเดิมตรงไปตรงมา: เมื่อ GPU ต้นทางมี token ก็จะส่งมันไปเขียนลงใน GPU เป้าหมาย ปัญหาเกิดขึ้นที่ที่อยู่เป้าหมาย เพราะ GPU หนึ่งตัวจะรับ token จาก GPU อื่นๆ จำนวนมากพร้อมกัน

แต่ละผู้ส่งต้องรู้ล่วงหน้าว่าควรเขียนลงในส่วนใด เพื่อไม่ให้ทับซ้อนกัน; token ของผู้เชี่ยวชาญเดียวกันควรจัดเรียงติดกัน หากไม่เช่นนั้น GEMM ด้านหลังจะต้องจัดเรียงใหม่อีกครั้ง

เมื่อมี GPU เข้าร่วมมากขึ้น กระบวนการจัดตารางนี้จะหนักขึ้นเรื่อยๆ Pull เปลี่ยนวิธีการใหม่: บันทึก GPU เป้าหมายของผู้เชี่ยวชาญเพื่อให้ตนเองดึง token ที่ต้องการ แค่รู้ว่า token อยู่บน GPU ต้นทางใดและอยู่ที่ตำแหน่งใดในข้อมูลต้นทาง การจัดเก็บในท้องถิ่นจะเป็นหน้าที่ของตัวมันเอง

สิ่งนี้ช่วยลดความซับซ้อนในการประสานงานระหว่างผู้ส่งหลายรายไปยังที่อยู่เป้าหมาย ข้อมูลที่ได้รับสามารถจัดเรียงตามผู้เชี่ยวชาญท้องถิ่นได้ทันที

ที่น่าสนใจคือ Pull ไม่ได้ส่งข้อมูลน้อยลง ในการทดสอบประสิทธิภาพของ Cursor สำหรับบล็อกข้อมูล BF16 ขนาด 256×256 เดียวกัน Push ย้ายข้อมูลประมาณ 159.6 KB ผ่าน NVLink แต่ Pull กลับสูงถึง 172.0 KB เนื่องจากการอ่านต้องส่งคำขอเพิ่มเติม

จุดแข็งของ Pull อยู่ที่อีกเรื่องหนึ่ง: การสื่อสารของ MoE แยกเป็นชิ้นเล็กๆ และโหลดไม่สมดุล NVLink มีช่องทางแยกสำหรับสองทิศทาง ทำให้ Pull สามารถใช้ประโยชน์จากทั้งคำขอและการส่งกลับข้อมูลพร้อมกัน ในการทดสอบที่โหลดผู้เชี่ยวชาญไม่สมดุล Cursor พบการเพิ่มขึ้นสูงสุดถึง 29% ในการใช้งาน NVLink

ความแตกต่างในการซิงโครไนซ์ชัดเจนยิ่งขึ้น หลังจาก Push เสร็จสิ้น เป้าหมาย GPU ต้องรอสัญญาณการเสร็จสิ้นจาก GPU อื่นๆ เมื่อขนาด Expert Parallel ใหญ่ หนึ่ง rank อาจเกี่ยวข้องกับเพื่อนร่วมงานสูงสุด 71 ตัว Pull เป็นการที่ GPU ท้องถิ่นเริ่มต้นการอ่านด้วยตนเอง หลังจากข้อมูลกลับมาแล้วสามารถใช้งานได้ทันที

ในแบบทดสอบไมโครของ Cursor ที่มีหลายโนด ความล่าช้าของการส่งสัญญาณนี้ลดลงจากประมาณ 103 ไมโครวินาทีของ Push เป็น 18 ไมโครวินาทีของ Pull

MoK ไม่ได้ใช้ Pull ทุกที่ ในทิศทางไปข้างหน้าใช้ Pull Dispatch และ Push Combine; ในทิศทางย้อนกลับใช้ Pull Reverse-Combine และ Push Reverse-Dispatch ในขั้นตอน Dispatch จำเป็นต้องจัดเรียง token จากแหล่งต่างๆ ให้เป็นอินพุตของผู้เชี่ยวชาญ การใช้ Pull ช่วยลดความซับซ้อนในการประสานงาน; ในขั้นตอน Combine รู้อยู่แล้วว่าผลลัพธ์แต่ละอันควรกลับไปที่ token ใด การส่งกลับโดยตรงด้วย Push จึงง่ายกว่า

หลังจากเปลี่ยนทิศทางการสื่อสาร MoK ยังคงรวมการสื่อสารและการคำนวณแบบผู้เชี่ยวชาญไว้ใน Megakernel เดียวกัน

มันแบ่ง SM ของ GPU ออกเป็นสองส่วน ส่วนหนึ่งรับผิดชอบการส่งคำสั่ง การรวมผลลัพธ์ และการจัดการสถานะ อีกส่วนหนึ่งใช้เฉพาะสำหรับการดำเนินการ Expert FFN เมื่อฝั่งการสื่อสารได้รับโทเค็นครบชุดแล้ว จะแจ้งให้ฝั่งการคำนวณผ่านตัวนับแบบท้องถิ่นของ GPU; เมื่อคำนวณเสร็จสิ้น จะแจ้งกลับไปยังฝั่งการสื่อสารเพื่อส่งผลลัพธ์กลับ

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

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

Cursor ใช้ wave เพื่อตรวจสอบขอบเขตนี้ โดย wave ที่สมบูรณ์หนึ่งชุดสามารถเข้าใจง่ายๆ ว่าเป็นการกระจายงานให้กับ SM ทั้งหมดแล้ว MoK ต้องการให้ minibatch หนึ่งชุดสามารถสร้าง wave ที่สมบูรณ์ได้อย่างน้อยสองชุด เพื่อให้ Tensor Core มีงานเพียงพอในการดำเนินการอย่างต่อเนื่อง

ผลจริงพูดได้ชัดเจนมาก ในรูปแบบของ Kimi 2.5 ที่มี Hidden Size เท่ากับ 7168 และมิติกลางของผู้เชี่ยวชาญเท่ากับ 2048 Cursor ประมาณการว่า minibatch ต้องการอย่างน้อยประมาณ 2368 token เมื่อใช้ 512 token เวลาในการดำเนินการแบบฟอร์เวิร์ดของ MoK คือ 5.981 ms; เมื่อเพิ่มเป็น 2560 token เวลาลดลงเหลือ 3.425 ms เมื่อเพิ่มต่อไปอีก ความเร็วไม่ได้ดีขึ้นอย่างมีนัยสำคัญ

กล่าวอีกนัยหนึ่ง การแบ่งการสื่อสารให้เล็กลงไม่ได้หมายความว่าจะเร็วขึ้นเสมอไป การซ้อนทับอย่างมีประสิทธิภาพจริงๆ ต้องส่งข้อมูลให้เร็วที่สุดเท่าที่จะเป็นไปได้ โดยไม่ต้องแบ่ง GEMM ออกเป็นชิ้นเล็กเกินไป

แต่ MoE ยังมีปัญหาอีกประการหนึ่ง: ก่อนที่ Router จะทำงานเสร็จ ไม่มีทางรู้ได้เลยว่า GPU แต่ละตัวจะได้รับ token กี่ตัว

หากเตรียม buffer ตามสถานการณ์ที่เลวร้ายที่สุด จะทำให้สูญเสียหน่วยความจำ GPU จำนวนมาก หากปล่อยให้ GPU นับ token ก่อน แล้วจึงแจ้ง CPU ให้จัดสรรพื้นที่ที่เหมาะสม GPU ก็จะต้องหยุดรอ CPU

MoK ใช้ Ring Token Buffer ขนาดคงที่ พื้นที่หนึ่งจะถูกใช้เก็บ token ที่ถูกส่งเข้ามา ก่อนที่ผู้เชี่ยวชาญจะคำนวณเสร็จและ Combine จะส่งผลลัพธ์ออกไป พื้นที่นั้นจะถูกใช้ใหม่ทันทีสำหรับ token ชุดถัดไป การ Combine ของ macrobatch ก่อนหน้าสามารถทำควบคู่กับการ Dispatch ของ macrobatch ถัดไปได้

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

Cursor ยังได้รวมการควอนไทซ์ของ MXFP8 เข้าไปในเส้นทางข้อมูลของ Dispatch, Grouped GEMM และ SwiGLU ทำให้ลดการใช้ kernel ควอนไทซ์แบบแยกอิสระ และลดการอ่านเขียนข้อมูลกลางที่ต้องผ่าน HBM ไปมา

เมื่อรวม Pull, minibatch, SM partition และ Ring Buffer เข้าด้วยกัน MoK จึงกลายเป็นสายการผลิต MoE ที่ต่อเนื่องอย่างแท้จริง

03

การทดสอบประสิทธิภาพของ Cursor วัดทั้งชั้น MoE อย่างสมบูรณ์ รวมถึงการจัดตาราง การส่งข้อมูล ชั้น FFN ผู้เชี่ยวชาญ การรวมผล และการรวมน้ำหนักสุดท้าย โดยเปรียบเทียบกับ NCCL + PyTorch, DeepEP, TransformerEngine และ HybridEP + Megatron

บน GB300 NVL72 เมื่อเทียบกับฐานการเปรียบเทียบสาธารณะที่เร็วที่สุดสำหรับแต่ละสถานการณ์ MoK สามารถเพิ่มประสิทธิภาพสูงสุดได้ถึง 2.37 เท่าสำหรับการดำเนินการแบบฟอร์เวิร์ดด้วย MXFP8 และสูงสุด 1.78 เท่าสำหรับการดำเนินการแบบรีเวิร์ส; สำหรับ BF16 การเพิ่มประสิทธิภาพสูงสุดสำหรับการดำเนินการแบบฟอร์เวิร์ดและรีเวิร์สคือ 1.92 เท่าและ 1.58 เท่าตามลำดับ

ที่สำคัญกว่านั้นคือการฝึกแบบ end-to-end โซลูชันการผลิตเดิมของ Cursor ใช้ DeepEP อยู่แล้ว เมื่อเปลี่ยนเป็น MoK บน GPU GB300 จำนวน 512 ตัว ปริมาณการประมวลผลต่อการ์ดเพิ่มจาก 760.9 โทเค็นต่อวินาที เป็น 1070.2 โทเค็นต่อวินาที เพิ่มขึ้นประมาณ 41%

ผลชุดนี้ยังต้องพิจารณาขอบเขตให้ชัดเจน Cursor ไม่ได้เปิดเผยการลบแต่ละส่วนอย่างละเอียด จึงไม่สามารถระบุได้อย่างแม่นยำว่าในอัตราส่วน 2.37 เท่า มีส่วนใดมาจาก Pull, Megakernel หรือ Ring Buffer

สามารถยืนยันได้อย่างชัดเจนว่า Pull ช่วยปรับปรุงการใช้งาน NVLink และความล่าช้าในการส่งสัญญาณ ส่วนผลประโยชน์อื่นๆ ส่วนใหญ่มาจากการรวมกันของวิธีการดำเนินการทั้งหมด

MoK ยังพึ่งพาฮาร์ดแวร์อย่างมาก โดยมุ่งเน้นไปที่โดเมน NVLink ความเร็วสูงเช่น Blackwell และ NVL72 การอ่านข้อมูลจากระยะไกล การสื่อสาร และการคำนวณแบบละเอียดยิบย่อย ล้วนตั้งอยู่บนพื้นฐานที่ GPU สามารถเข้าถึงหน่วยความจำของกันและกันด้วยความล่าช้าต่ำ เมื่อขนาดซ่อนของโมเดล Top-k และขนาดผู้เชี่ยวชาญเปลี่ยนไป ขนาด minibatch ที่เหมาะสมและจำนวน SM สำหรับการสื่อสารก็จะเปลี่ยนตาม

นี่คือจุดที่ MoK น่าสนใจที่สุด ในอดีต การอภิปรายเกี่ยวกับการปรับปรุง MoE มักมุ่งเน้นที่ตัวเลขสองตัว: GEMM มี TFLOPS เท่าใด และ All-to-All มี GB/s เท่าใด แต่ในรุ่น GB300 การผลักดันตัวเลขสองตัวนี้ให้สูงขึ้นอีกไม่สามารถอธิบายประสิทธิภาพทั้งหมดได้อีกต่อไป

เมื่อใดที่โทเค็นจะมาถึง วิธีการจัดเรียงให้อยู่ในรูปแบบที่ผู้เชี่ยวชาญต้องการ สะสมเท่าใดจึงจะเริ่มคำนวณ รับ SM ได้เท่าใดในการสื่อสาร และเมื่อใดที่ buffer จะถูกปล่อยออก รายละเอียดการดำเนินการเหล่านี้เริ่มต้นกำหนดความเร็วในการฝึกอบรมโดยตรง

ชั้นวางที่มีแบนด์วิดธ์ NVLink 130 TB/s ยังคงต้องเขียนใหม่เคอร์เนล GPU สำหรับ MoE เพราะเหตุผลนี้เอง: ลิงก์นั้นเร็วอยู่แล้ว สิ่งที่ต้องประหยัดต่อไปคือเวลาที่ GPU รอข้อมูล

การเขียนทบทวนเคอร์เนล GPU โดย Cursor ถือเป็นการก้าวเข้าสู่ยุคใหม่ของการแข่งขันในยุค AI 2.0 ที่เรียกว่า “อำนาจนิยมทั้งหมดในสแต็ก”

ก่อนหน้านี้ เราเชื่อว่า “แต่ละงานมีผู้เชี่ยวชาญเฉพาะทาง” ถ้าทำแอปพลิเคชันก็ควรทำแอปพลิเคชัน (Cursor) ถ้าทำระดับพื้นฐานก็ควรทำระดับพื้นฐาน (NVIDIA) แต่การแข่งขันด้าน AI ในปัจจุบันได้ก้าวเข้าสู่ขั้นตอนใหม่ที่ “ตัดผู้ค้าปลีกออก” Cursor ไม่ได้ทำนิวเคลียสเพราะ “ต้องการจะทำ” แต่ทำเพราะ “จำเป็นต้องทำ”

DeepSeek ได้เปิดยุคใหม่ของการบีบอัดทางวิศวกรรม ขณะที่ Cursor ได้นำไฟนี้ลุกลามไปยังชั้นแอปพลิเคชัน แนวโน้มการตัดผู้ค้าปลีกออกจากระบบกำลังเปลี่ยนแปลงอำนาจการกำหนดราคาของ AI: ในอนาคต การประเมินมูลค่าของบริษัท AI จะไม่ขึ้นอยู่กับจำนวนโทเค็นที่มี แต่ขึ้นอยู่กับว่าโค้ดของมันอยู่ใกล้หน่วยความจำแสดงผลและรีจิสเตอร์เพียงใด

บริษัท AI ที่ไม่สามารถเจาะผ่านกล่องดำพื้นฐานจะสุดท้ายแล้วติดอยู่ในบ่อน้ำมูกของ "ภาษีความเฉยๆ"