เปิดตัว DGX Spark: ประสิทธิภาพเหนือกว่า Mac Studio เกือบ 2 เท่า

พูดตามตรง ฉันประหลาดใจมาก ตอนที่ต่อ DGX Spark สองเครื่องเป็นคลัสเตอร์แล้วรัน DeepSeek-V4-Flash ผลลัพธ์คือ เร็วกว่า 1.78 เท่าในเวลาเจนเนอเรชันรวม (เวลาวอลล์คล็อกจริง) เมื่อเทียบกับ Mac Studio M3 Ultra ซึ่งหมายความว่ามันทำงานเสร็จในเวลาประมาณครึ่งเดียว และนี่คือการรันโมเดล FP8 ทางการบน DGX Spark โดยไม่มีการควอนไทซ์เพิ่มเติม

ระหว่างที่ทำเบนช์มาร์กนี้ ฉันรู้สึกว่า ประเด็นที่ฉันย้ำอยู่เสมอ ได้รับการสนับสนุนจากตัวเลขอีกครั้ง นั่นคือ:

ประสิทธิภาพของ LLM ไม่สามารถวัดได้จากดีโค้ดสปีด (token ต่อวินาที, TPS) โดยอาศัยแบนด์วิดท์หน่วยความจำเท่านั้น

พลังประมวลผล GPU, การสื่อสารระหว่างโหนด, ลำดับชั้นหน่วยความจำ, คุณภาพของการควอนไทซ์, ความยาวคอนเท็กซ์, การประมวลผลแบบขนาน และอื่นๆ — "ความสมดุล" ของปัจจัยทั้งหมดนี้กำหนดประสบการณ์ผู้ใช้จริง และ DGX Spark ก็มีความสมดุลที่ดีกว่า

เบนช์มาร์กที่ใช้: Coding Benchmark ของ shi3z

สำหรับการวัดผล ฉันใช้โค้ดดิ้งเบนช์มาร์กจาก shi3z's Japanese LLM Benchmark ภารกิจคือ "สร้างแชทแอปที่รันบน React ให้เสร็จสิ้นในการเจนเนอเรชันเดียว" โค้ดที่สร้างขึ้นจะถูกเริ่มต้นใน Docker และทดสอบอัตโนมัติด้วย Playwright สำหรับการล็อกอิน เพื่อน DM และอัปเดตแบบเรียลไทม์ โดยมีคะแนนฟังก์ชันการทำงานสูงสุด 80 คะแนน

ผลลัพธ์ของการรัน DeepSeek-V4-Flash Q4 (4-bit quantization) บน Mac Studio M3 Ultra ผ่าน ds4 inference engine ของ antirez ถูกระบุไว้ใน Repository ของ shi3z ตารางด้านล่างเปรียบเทียบผลลัพธ์เหล่านั้นกับผลลัพธ์ของคลัสเตอร์ DGX Spark 2 ยูนิต + FP8 ทางการในครั้งนี้

ผลลัพธ์เบนช์มาร์ก

ทำไมถึง "แพ้ที่ tok/s แต่ชนะที่ Wall-Clock Time"

ถ้าคุณดูตารางแล้วคิดว่า "เดี๋ยวก่อน Mac เร็วกว่าใน tok/s" คุณคิดถูกแล้ว ถ้าดูแค่ความเร็วชั่วขณะในการถ่ายโอนหนึ่ง token (decode TPS) แล้ว Mac Studio M3 Ultra เร็วกว่า 1.58 เท่า ซึ่งเป็นเพราะแบนด์วิดท์หน่วยความจำมหาศาลของ Apple Silicon

อย่างไรก็ตาม มีกับดักอยู่ตรงนี้ เพื่อสร้างแชทแอปที่ "คะแนนเต็ม 80/80" เดียวกัน Mac เขียน 8,036 tokens ในขณะที่ DGX Spark เขียน 2,866 tokens นั่นคือความแตกต่างประมาณ 2.8 เท่า

ทั้งคู่ใช้ DeepSeek-V4-Flash โดยที่ไม่มีการลดคุณภาพอย่างเป็นทางการ แต่ก็ตีความได้ว่า ฝั่ง Mac ที่ถูกควอนไทซ์เป็น Q4 กลายเป็นเรื่องซ้ำซ้อน ในขณะที่ฝั่ง Spark ที่รัน FP8 คุณภาพเต็มรูปแบบนั้นกระชับกว่า มันเป็นปรากฏการณ์ทั่วไปที่ผลกระทบของการควอนไทซ์ต่อการกระจายเอาต์พุตไม่แสดงในดีโค้ดสปีด แต่ส่งผลต่อกลยุทธ์การสร้างอย่างเงียบๆ

ซึ่งผลลัพธ์ออกมาเป็นดังนี้:

เวลาวอลล์คล็อกจริง = (เอาต์พุต Tokens) ÷ (tok/s)

Mac: 8,036 ÷ 26.2 = 307 วินาที เรา: 2,866 ÷ 16.6 = 172 วินาที

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

การกำหนดค่าที่ใช้

• ฮาร์ดแวร์: DGX Spark × 2 (NVIDIA GB10, สถาปัตยกรรม Blackwell, หน่วยความจำรวม 128 GB ต่อเครื่อง)
• การเชื่อมต่อระหว่างโหนด: เชื่อมต่อโดยตรงผ่าน ConnectX-7 200 Gbps RoCE (Tensor Parallel = 2, PyTorch distributed backend)
• Inference Engine: สูตรของ Aiden ซึ่งรวม b12x (ชุดเคอร์เนล CuTe DSL เฉพาะสำหรับ GB10) เข้ากับ vLLM 0.21.1dev
• โมเดล: DeepSeek-V4-Flash FP8 ทางการ (154 GB, FP8 attention, MXFP4 MoE — นี่คือรูปแบบทางการที่ DeepSeek ปล่อยออกมา)
• คอนเท็กซ์: 524,288 tokens (512K), util 0.82, KV cache 19.85 GiB, concurrency 3.89×
• การทำนายหลาย Token (MTP): Speculative decoding ด้วยอัตราการยอมรับประมาณ 62% (เพิ่มความเร็วโดยไม่ลดคุณภาพเอาต์พุต)

เจาะลึกประสิทธิภาพ

นอกเหนือจากตัวเลขในเบนช์มาร์กนี้ ฉันวัดดีโค้ดและพรีฟิลสปีดแบบบริสุทธิ์แยกต่างหาก:

• ดีโค้ดสปีดบริสุทธิ์ (ข้อความสั้น ไม่รวม TTFT): คงที่ประมาณ 39 tok/s
• พรีฟิลสปีด (คอนเท็กซ์ขนาดใหญ่): 1,277 tok/s (ซึ่ง เร็วกว่าประมาณ 6.5 เท่า เมื่อเทียบกับ 196 tok/s ของการกำหนดค่าเก่าที่ไม่มี b12x kernels)
• ดีโค้ดด้วยคอนเท็กซ์ยาว: แม้จะเพิ่มจาก 8K → 64K → 128K → 256K → 512K → 768K ดีโค้ดสปีดก็ไม่ได้ลดลงอย่างรวดเร็ว ที่จริงแล้วกลับเร่งขึ้น (106 tok/s ที่ 768K) ทั้งนี้เนื่องจาก Sparse Attention (DSA) ของ DeepSeek ถูกใช้งานโดยตรงใน b12x kernels ทำให้การคำนวณ Attention แทบไม่ขึ้นอยู่กับความยาวคอนเท็กซ์

นี่คือผลลัพธ์ที่ "ไม่มีการควอนไทซ์ คุณภาพเต็ม"

อีกประเด็นที่ฉันอยากเน้นคือฝั่ง DGX Spark ไม่ได้ใช้การควอนไทซ์เพิ่มเติมใดๆ กับโมเดล เราโหลดโมเดลทางการ 154 GB ที่แจกจ่ายบน HuggingFace ตามเดิมและรันมันในรูปแบบการควอนไทซ์ทางการที่ DeepSeek ออกแบบ: FP8 attention + MXFP4 MoE

ในโลกของ LLM ในเครื่องกลายเป็นสามัญสำนึกที่จะบีบอัดโมเดลขนาดใหญ่เป็น IQ2 (2-bit) หรือ Q4 เพื่อให้รันได้ แต่สิ่งเหล่านี้ลดทอนคุณภาพแน่นอน อันที่จริง ก่อนหน้านี้ฉันลองใช้ DeepSeek-V4-Flash เวอร์ชัน IQ2XXS (2-bit) และได้ผลลัพธ์ 55/80 + พฤติกรรมของเอเจนต์ล้มเหลวในเบนช์มาร์กเดียวกัน การควอนไทซ์ไม่ใช่ของฟรี

การกำหนดค่าที่สามารถมั่นใจได้ถึงหน่วยความจำรวม 256 GB ด้วย DGX Spark สองเครื่อง ทำให้ตัวเลือก "การรันโมเดลขนาดใหญ่ด้วยคุณภาพเต็ม" กลายเป็นจริงเป็นครั้งแรก ฉันคิดว่านี่เป็นความก้าวหน้าที่มีความหมายมากกว่าที่ตัวเลขบอก

ทำไม "ความสมดุล" ของ Spark ถึงได้ผล

สรุปองค์ประกอบทางเทคนิคที่สนับสนุนผลลัพธ์นี้:

• ชุดเคอร์เนล b12x: เคอร์เนลสี่ประเภท (NVFP4 fused MoE GEMM, NVFP4 dense GEMM, FP8 paged attention และ sparse MLA attention) ที่เขียนขึ้นสำหรับ GB10 / SM12.x โดยเฉพาะโดยใช้ CuTe DSL ซึ่งแตกต่างจากเส้นทาง MARLIN ใน vLLM ทั่วไป เคอร์เนลเหล่านี้คำนวณในโหมด fused โดยไม่ต้องดีควอนไทซ์
• การเชื่อมต่อโดยตรง 200 Gbps RoCE: แม้ว่า TP=2 all-reduce ระหว่างโหนดจะเกิดขึ้นสองครั้งต่อเลเยอร์ แต่การเชื่อมต่อโดยตรง 200 Gbps ทำให้เวลาแฝงที่มีประสิทธิภาพลดลง ดังนั้นจึงไม่เป็นคอขวดสำหรับการถอดรหัส
• หน่วยความจำรวม 128 GB × 2: ข้อได้เปรียบของ Grace Blackwell ที่ไม่แยก HBM และ DDR ช่วยให้โมเดล FP8 ทางการขนาด 154 GB ถูกแบ่งบนสองยูนิตตามเดิม โดยมีพื้นที่เพียงพอสำหรับ KV cache ขนาด 19.85 GiB สำหรับคอนเท็กซ์ 512K
• การทำงานโดยตรงของ DeepSeek Sparse Attention (DSA): b12x kernels จัดการการออกแบบที่ความซับซ้อนของ Attention ไม่ขึ้นอยู่กับความยาวคอนเท็กซ์ได้อย่างถูกต้อง โดยใช้การดำเนินการ sparse ดั้งเดิมของ GB10 ซึ่งนำไปสู่ผลลัพธ์ที่ดีโค้ดสปีดไม่ลดลงตามความยาวคอนเท็กซ์

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

อะไรจะเปลี่ยนแปลงไปในการใช้งานจริง?

เพื่อก้าวข้ามทฤษฎีนามธรรม นี่คือประโยชน์ที่เป็นรูปธรรม:

• การสรุปเอกสารขนาดใหญ่และการวิเคราะห์โค้ดเป็นไปได้จริง: ด้วยคอนเท็กซ์ 512K และพรีฟิลสปีด 1,277 tok/s คุณสามารถโหลดและสรุปหนังสือทั้งเล่ม (~300,000 tokens) ได้ในเวลาประมาณ 4 นาที
• Agent loops ไม่ติดขัด: ด้วย concurrency 3.89× คุณสามารถรันแชทและการสรุปแบบยาวพร้อมกัน (เช่น กับ Hermes Agent) ได้โดยที่ดีโค้ดไม่ล่ม
• ไม่มีปัญหา "Agent พูดอย่างเดียว" ที่เกิดจากความล้มเหลวของการควอนไทซ์: นี่คือกับดักที่ฉันตกหลายครั้งกับโมเดลซีรีส์ IQ2 ด้วยคุณภาพเต็ม ปัญหานี้ไม่เกิดขึ้น
• การแข่งขันกับ Mac ในเรื่องการใช้พลังงาน: การใช้พลังงานทั้งหมดของ GB10 สองเครื่องระหว่างการอนุมานอยู่ที่ประมาณ 100W–140W ซึ่งใกล้เคียงกับ Mac Studio M3 Ultra ที่บูสต์เต็มที่ เมื่อพิจารณาประสิทธิภาพที่เร็วกว่า 1.78 เท่า ประสิทธิภาพการใช้พลังงานก็ถือว่าไม่เลว

สรุป: ยุคที่ตัดสินประสิทธิภาพ LLM ด้วย TPS เพียงอย่างเดียวนั้นสิ้นสุดลงแล้ว

ความเร็วชั่วขณะในการถ่ายโอน token—decode TPS—เป็นเมตริกที่สำคัญแน่นอน แต่มันเหมือนกับ "ความเร็วสูงสุดของการวิ่ง 100 เมตร" สิ่งที่จำเป็นในทางปฏิบัติคือ "เวลาที่ใช้เพื่อไปถึงคำตอบที่ถูกต้องเดียวกัน" "คุณภาพของคำตอบ" "สามารถรันพร้อมกันได้กี่อัน" "สามารถจัดการคอนเท็กซ์ได้นานแค่ไหน" และ "Agent loops ทำงานหรือไม่" สิ่งเหล่านี้คือคะแนนรวม

สิ่งที่ผลลัพธ์นี้แสดงให้เห็นคือ DGX Spark กำลังเริ่มนำหน้าในคะแนนรวมนี้ เราได้เข้าสู่ยุคที่คุณสามารถรันโมเดลขนาดใหญ่ด้วยคุณภาพทางการ มีคอนเท็กซ์ยาว ในขณะที่รักษาความเข้ากันได้ของเอเจนต์ ด้วยความเร็ววอลล์คล็อกที่เร็วกว่า Mac Studio 1.78 เท่า เพียงแค่เชื่อมต่อสองเครื่องในคลัสเตอร์

ในช่วงสองสามปีที่ผ่านมา ผู้คนพูดว่า "LLM ทั้งหมดเกี่ยวกับแบนด์วิดท์หน่วยความจำ" และ "decode TPS คือทุกสิ่ง" แต่หลังจากรัน Spark จริง ฉันรู้สึกว่าข้อเรียกร้องของฉันที่ว่า "ความสมดุลคือประสิทธิภาพในทางปฏิบัติ" ได้รับการพิสูจน์ด้วยตัวเลขในที่สุด

RTX Spark ก็เปิดตัวแล้ว และมีความรู้สึกว่าสิ่งต่างๆ กำลังร้อนแรงเกินคาด (แม้ว่าบรรยากาศอาจจะเย็นลงเมื่อรู้ราคา...) ฉันมีความคาดหวังสูงว่าชุมชนจะเติบโตและการปรับแต่งและความรู้จะสะสมมากขึ้น!

Jensen น่าทึ่งจริงๆ... การครองราชย์ของเขาจะดำเนินต่อไปอีกนานไหม?

##

**

##

**

##

**

##

**

##

**

##

โบนัส

ผู้อ่านที่เฉียบคมอาจมีข้อวิจารณ์นี้:

"แล้วมันจะเป็นการเปรียบเทียบที่ยุติธรรมไหมถ้าคุณรัน FP8 ทางการดิบบน Mac Studio ด้วย?"

"การเปรียบเทียบนี้ไม่ยุติธรรมใช่ไหม? Mac Studio กลายเป็นเรื่องซ้ำซ้อนเพราะมันถูกควอนไทซ์เป็น Q4 เท่านั้น ถ้าคุณรัน FP8 ทางการดิบบน Mac Studio มันจะไม่อยู่ในสนามเดียวกันในแง่ของคุณภาพหรอกหรือ?" นี่เป็นคำถามที่มีเหตุผล

เพื่อตอบให้ตรงประเด็น: ปัจจุบันนี้ ไม่มีวิธีที่จะรัน 'FP8 ทางการดิบ + MXFP4 MoE' บน Mac Studio ด้วยความเร็วที่ใช้งานได้จริง

1. ประการแรก ไม่มี inference engine ที่เข้ากันได้

ดูเหมือนจะไม่มีเครื่องยนต์ที่รองรับรูปแบบทางการของ DeepSeek-V4-Flash (FP8 attention + MXFP4 MoE + Lightning Indexer + DSA Sparse Attention) บน Apple Silicon อย่างเต็มรูปแบบ (ตามการค้นหาของ Claude Code)

• MLX (เฟรมเวิร์ก LLM ทางการของ Apple สำหรับ Apple Silicon): ไม่มีการใช้งาน MXFP4 MoE fused GEMM โดยตรง, ไม่มี FP8 paged attention และไม่มีการใช้งาน DeepSeek's DSA Sparse Attention ใน MLX ถ้าพยายามรัน คุณอาจจะต้องอัปแคสต์เป็น bf16
• llama.cpp: ไม่สามารถโหลด MXFP4 ได้โดยตรง ดังนั้นจึงต้องรีควอนไทซ์เป็น GGUF = สุดท้ายแล้วมันจะถูกแปลงเป็น Q4 / Q5 / IQ2 เป็นต้น และไม่ใช่เวอร์ชัน "ทางการดิบ" อีกต่อไป
• vLLM: การรองรับ Apple Silicon มีจำกัดตั้งแต่แรก และเคอร์เนลเฉพาะของ GB10 เช่น b12x จะไม่รันบน Mac
• antirez/ds4: นี่คือเครื่องยนต์เฉพาะทางที่เขียนขึ้นบน MLX สำหรับ DeepSeek V4 Flash โดยเฉพาะโดยสมมติให้เป็น Q4 มันเป็นโซลูชันที่เหมาะสมที่สุดในปัจจุบันสำหรับการรันบน Mac Studio แต่มันไม่ได้สร้างมาเพื่อจัดการกับ "FP8 ดิบ"

ความจริงที่ว่า antirez เขียนเครื่องยนต์เฉพาะสำหรับ DeepSeek V4 Flash สำหรับ Q4 โดยเฉพาะ บ่งบอกถึงความเป็นจริงที่ว่าขณะนี้ไม่มีเส้นทางที่ใช้งานได้จริงในการรันคุณภาพทางการตามที่เป็นอยู่บน Apple Silicon

1. ถึงแม้จะรันด้วย bf16 upcasting แบนด์วิดท์ก็จะถูกใช้จนเกือบหมด

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

• DeepSeek-V4-Flash มีการกำหนดค่า MoE ที่มีพารามิเตอร์แอคทีฟประมาณ 30B
• ที่ Q4 (4-bit) พารามิเตอร์แอคทีฟใช้พื้นที่ประมาณ 15 GB และ ds4 บรรลุ 26.2 tok/s (วัดแล้ว)
• ถ้าโมเดลเดียวกันถูกเก็บที่ FP8 (8-bit) พารามิเตอร์แอคทีฟใช้พื้นที่ประมาณ 30 GB = ความต้องการแบนด์วิดท์เพิ่มขึ้น 2 เท่า = ตามทฤษฎีแล้ว ~13 tok/s บนเครื่องยนต์เดียวกัน
• ยิ่งไปกว่านั้น การอัปแคสต์เป็น bf16 ใน MLX ใช้พื้นที่ประมาณ 60 GB สำหรับพารามิเตอร์แอคทีฟ = ความต้องการแบนด์วิดท์เพิ่มขึ้น 4 เท่า = ตามทฤษฎีแล้ว ~6.5 tok/s
• เนื่องจากแบนด์วิดท์หน่วยความจำที่มีประสิทธิภาพของ Mac Studio M3 Ultra อยู่ที่ประมาณ 800 GB/s การอ่าน 60 GB ทุก token จะถึงขีดจำกัดแบนด์วิดท์

กล่าวอีกนัยหนึ่ง การเลือก "ใช้คุณภาพดิบ" บน Apple Silicon ในปัจจุบันต้องแลกมาด้วย "การเสียสละความเร็วมากกว่าสองเท่า" การรันที่ 26.2 tok/s ด้วย ds4 + Q4 เป็นทางเลือกที่ใช้งานได้จริงมากกว่าการได้เพียง 6 tok/s ด้วย bf16 คุณภาพเต็ม

1. นี่คือจุดที่ข้อได้เปรียบเชิงโครงสร้างของ Spark เข้ามามีบทบาท

ในทางกลับกัน การกำหนดค่า DGX Spark นี้รัน "FP8 ทางการดิบ + MXFP4 MoE โดยตรง" สิ่งนี้ได้รับการสนับสนุนโดย:

• ชุดเคอร์เนล b12x ที่เฉพาะเจาะจงสำหรับ GB10 ซึ่งมีการใช้งานเพื่อรัน NVFP4 fused MoE GEMM และ FP8 paged attention "โดยไม่ต้องดีควอนไทซ์"
• สิ่งนี้ยังไม่ได้ถูกเขียนขึ้นสำหรับ Apple Silicon
• ดังนั้น ในปัจจุบัน Spark จึงเป็นโซลูชันที่สมจริงเพียงหนึ่งเดียวสำหรับการรัน "คุณภาพทางการตามที่เป็น" และ "ด้วยความเร็วที่ใช้งานได้จริง"

โดยสรุป ถ้าคุณดูแค่แบนด์วิดท์ฮาร์ดแวร์ ค่าสัมบูรณ์ของ Mac Studio สำหรับเครื่องเดี่ยวอยู่ในระดับใกล้เคียงกัน แต่ การมีหรือไม่มี "การใช้งานเคอร์เนลที่รันรูปแบบการควอนไทซ์ทางการโดยตรง" ทำให้เกิดความแตกต่างอย่างเด็ดขาด ข้อได้เปรียบของ Spark ไม่ได้มาจากชิปเพียงอย่างเดียว แต่มาจากการผสมผสานทั้งหมดกับสแต็กซอฟต์แวร์ที่เฉพาะเจาะจงสำหรับ GB10 เช่น b12x

หากในอนาคตมีคนเขียน MXFP4 fused MoE GEMM, FP8 paged attention และ DSA Sparse Attention สำหรับ Apple Silicon ใน MLX หลักการนี้จะพังทลาย ภูมิทัศน์จะเปลี่ยนไปตามการใช้งานของชุมชน สำหรับตอนนี้ ความจริงก็คือ Spark ก้าวไปข้างหน้าหนึ่งก้าวในการบรรลุการผสมผสานของ "คุณภาพทางการ × ความเร็วที่ใช้งานได้จริง"

นี่คือผลลัพธ์ของการวิเคราะห์ที่ Claude Code จัดทำ