Qwen3.6-35B บน DGX Spark — จาก FP8 สู่ NVFP4 + บทเรียนจาก Atlas
เอาจริง ๆ จุดเด่นอย่างนึงของ DGX Spark ที่อาจจะเหนือกว่าเครื่อง x86 และ GPU ค่ายอื่นก็คือ NVFP4 — รูปแบบข้อมูลเลขทศนิยมลอยตัวขนาด 4 บิต (Floating Point 4-bit) ที่พัฒนาโดย NVIDIA เพื่อใช้บนสถาปัตยกรรม GPU รุ่นใหม่อย่าง Blackwell มันคือเหตุผลที่ DGX Spark — ซูเปอร์คอมพิวเตอร์ AI ขนาดเดสก์ท็อป — สามารถรันโมเดลภาษาขนาดใหญ่ (LLM) ระดับร้อยพันล้านพารามิเตอร์ได้ภายในเครื่องเดียวอย่างมีประสิทธิภาพ
NVFP4 คืออะไร และทำไมถึงต่างจาก INT4 ทั่วไป?
NVFP4 ใช้โครงสร้าง E2M1 — 1 sign bit, 2 exponent bits, 1 mantissa bit — ครอบคลุมค่าในช่วงประมาณ -6 ถึง +6 แต่สิ่งที่ทำให้มันแตกต่างจาก INT4 ทั่วไปคือ two-level micro-block scaling: ใช้ scaling factor แบบ E4M3 FP8 บนทุก ๆ 16-value micro-block พร้อม per-tensor FP32 scalar ระดับบนสุด ช่วยลด quantization error ได้อย่างมีนัยสำคัญ เมื่อเทียบกับ MXFP4 ที่ใช้ block ขนาด 32 ค่า NVFP4 ลดขนาด block ลงครึ่งหนึ่ง ทำให้ scale ได้ละเอียดขึ้น และ preserve ค่าเล็ก ๆ ที่สำคัญใน model weights ได้ดีกว่า
พูดง่าย ๆ คือ — แทนที่จะบีบทุกค่าใน tensor ให้ใช้ scale factor ตัวเดียวกัน NVFP4 แบ่งเป็น block เล็ก ๆ และหา scale factor ที่เหมาะสมให้แต่ละ block ทำให้ค่าที่ได้ใกล้เคียงของจริงมากที่สุด
สถาปัตยกรรมนี้ทำงานบน fifth-generation Tensor Cores ของ GB10 Grace Blackwell Superchip ใน DGX Spark ซึ่งสามารถจัดการ microscaled FP4 data ได้โดยตรง ทั้ง grouping, dynamic scaling และ 4-bit matrix operations — สิ่งที่ GPU รุ่นก่อนอย่าง Hopper หรือ Ampere ทำไม่ได้เพราะขาด dedicated datapath สำหรับ FP4
แต่เรื่องก็ไม่ได้สวยงามขนาดนั้น
อ่านเพิ่ม: DGX Spark: 5 Red Flags — Red Flag #1: NVFP4 ยังไม่ทำงานเต็มประสิทธิภาพ
ในความเป็นจริง chip GB10 ใน DGX Spark ใช้ compute capability SM121 ซึ่ง vLLM ตั้งต้นใช้ Marlin fallback — dequant FP4 กลับเป็น BF16 ก่อนคำนวณ แทนที่จะใช้ native FP4 tensor cores NVIDIA clarify ภายหลัง ว่า instruction มีอยู่จริงบน GB10 แต่ต้อง compile ด้วย sm_121a target ไม่ใช่ sm_121 — ปัญหาคือ toolchain ไม่ใช่ transistor ขาด
พูดง่าย ๆ คือ NVFP4 บน DGX Spark ตอนนี้ทำงานผ่าน fallback path ไม่ใช่ native FP4 compute
แล้วมันใช้ได้ไหม?
แม้จะมีดราม่าเรื่องนี้ แต่ก็ไม่ได้แปลว่า NVFP4 ใช้ไม่ได้ — ผมใช้ Qwen3.6-35B-A3B-FP8 บน DGX Spark มาเดือนกว่า ผ่าน vLLM v0.23.0 recipe ของตัวเอง throughput อยู่ที่ ~290 tok/s ที่ 12 parallel ก็ถือว่าใช้ได้ ไม่ได้แย่ แต่พอไปเจอ claim ใน Discord ว่า "NVFP4 + vLLM nightly ได้ 236.97 tok/s ที่ 10 concurrency" ก็เริ่มสนใจ
คำถามคือ — ทำไม NVFP4 ถึงเร็วกว่า? ทำไม nightly ถึงดีกว่า stable? และที่สำคัญที่สุด — NVFP4 แลกกับ quality เท่าไหร่?
บทความนี้เป็นบันทึกการทดสอบจริง ตั้งแต่ FP8 เดิม → ลอง Atlas (Rust engine) → กลับมาใช้ vLLM + NVFP4 — พร้อมบทเรียนเรื่อง architecture mismatch ที่เจอตอนลอง Atlas
บทความก่อนหน้า: Qwen3.6-35B Sampling Guide — พื้นฐานการเลือก temperature/top_p สำหรับงานต่างๆ
สรุปความเร็ว — เทียบทุก config ที่วัดจริง
| Concurrency | vLLM FP8 (เดิม) | vLLM NVFP4 (ใหม่) | Atlas NVFP4 | ที่ดีที่สุด |
|---|---|---|---|---|
| 1 (single) | 55.4 tok/s | 58.4 tok/s | 78.4 tok/s | Atlas +41.5% |
| 3 | 106.0 | 106.7 | 63.5 | vLLM NVFP4 |
| 6 | 177.2 | 169.0 | 65.6 | vLLM FP8 |
| 12 | 292.8 | 335.8 tok/s | 81.4 | vLLM NVFP4 +14.7% |
นอกจากความเร็ว ยังได้ฟรี: memory ลด 75% (30-50 GB → 7.94 GB), context 2x (128K → 256K), reasoning 7/7 — รายละเอียดทั้งหมดอยู่ด้านล่าง