บันทึก 26 มิถุนายน 2569 — ตี 2 — เรื่องของการ tune vLLM บน GB10
เมื่อวาน (2026-06-25) ผมรัน benchmark v2 ที่ gpu_mem=0.7 แล้ว RAM ขึ้นไป 99% เครื่องเกือบค้าง ส่วน v1 ที่ gpu_mem=0.5 ก็เจออาการเดียวกันตอนมี request stuck วันนี้เลยลอง tune ต่อจนมาถึง v5 ที่ gpu_mem=0.75 ซึ่งน่าจะเป็น sweet spot สำหรับ workload จริงที่ผมใช้
25 มิถุนายน 2569 — บันทึกการ tune Qwen3.6-35B-A3B-NVFP4 บน DGX Spark รอบที่สอง — ขยับแค่ 3 ค่า แต่ได้ +20% throughput ที่ concurrency 6
เอาจริง ๆ จุดเด่นอย่างนึงของ DGX Spark ที่อาจจะเหนือกว่าเครื่อง x86 และ GPU ค่ายอื่นก็คือ NVFP4 — รูปแบบข้อมูลเลขทศนิยมลอยตัวขนาด 4 บิต (Floating Point 4-bit) ที่พัฒนาโดย NVIDIA เพื่อใช้บนสถาปัตยกรรม GPU รุ่นใหม่อย่าง Blackwell มันคือเหตุผลที่ DGX Spark — ซูเปอร์คอมพิวเตอร์ AI ขนาดเดสก์ท็อป — สามารถรันโมเดลภาษาขนาดใหญ่ (LLM) ระดับร้อยพันล้านพารามิเตอร์ได้ภายในเครื่องเดียวอย่างมีประสิทธิภาพ
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 สำหรับงานต่างๆ
| 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 — รายละเอียดทั้งหมดอยู่ด้านล่าง
ผมตั้งค่า vLLM ที่ผ่านมาหลายครั้งด้วยสูตรเดียวตลอด — temperature: 0.6, top_p: 0.95, top_k: 20 แล้วก็ปล่อยให้ client ไป override เอาเอง ไม่ว่าจะเป็น trading bot, Hermes agent, code review — ใช้ค่าเดียวกันหมด
จนเมื่อวานนี้ผมเปิด Hugging Face model card ของ Qwen3.6-35B-A3B อ่านเล่น ๆ ในส่วน Sampling Parameters ถึงได้รู้ว่า — Qwen team แนะนำ sampling ตาม mode และ task type ไม่ใช่ตาม benchmark หรือ use case แบบที่ผมเข้าใจ
อ้าว ผมเลยต้องกลับมานั่งคิดใหม่
Qwen3.6-35B-A3B รันอยู่บน DGX Spark (port 8001, vLLM v0.23.0, 128K context)
ที่ผ่านมาใช้ temperature 0.6 ตาม --override-generation-config ของ recipe แต่พออ่าน HF model card ละเอียด ๆ เจอว่า Qwen team เองใช้ค่า ต่างกัน ในแต่ละ benchmark category
เลยรวบรวมมาเป็น note สั้น ๆ เพื่อใช้อ้างอิง
ตอน DGX Spark มาถึงบ้าน ผมตื่นเต้นมาก — GB10 chip, 128GB unified memory, Blackwell architecture ผมคิดว่า "แค่เสียบปลั๊ก ติดตั้ง vLLM ก็ให้บริการ LLM ได้แรงๆ แล้ว" — แต่ความจริงหาเป็นแบบนั้นไม่
DGX Spark ไม่ใช่เครื่อง plug-and-play มันเป็นเครื่องสำหรับคนที่พร้อมจะเรียนรู้ - เรียนรู้เรื่อง serving engines, โครงสร้างของ model, รูปแบบ quantization และอีกหลายเรื่อง ก่อนที่จะดึงพลังออกมาได้เต็มที่
การเดินทางนี้กินเวลาหลายวัน ผมต้องศึกษา vLLM, llama.cpp, ความแตกต่างระหว่าง MoE กับ Dense, quantization ทุกแบบ (FP4, FP8, BF16, NVFP4) จนในที่สุดก็เข้าใจว่าทำไมคนอื่นถึงบอกว่า "DGX เป็นเครื่องสำหรับนักพัฒนาที่ใช้เฉพาะทาง"
ผมรัน LLM เองบน homelab มาสักพัก
เริ่มจาก llama.cpp บนเครื่องสเปกต่ำ ถามอะไรก็ตอบได้
แล้วขยับมา vLLM ที่ throughput สูงกว่า รับ request พร้อมกันได้มากกว่า
ทุกอย่างดูดี จนกระทั่งวันหนึ่งเพื่อนร่วมงานถามว่า
"ขอใช้ด้วยได้ไหม?"
ผมก็เลยเปิด port ให้เพื่อนยิง request ตรงเข้ามา
ผ่านไปสักพัก ก็เริ่มเจอปัญหา
ไม่รู้ว่าใครใช้ไปเท่าไหร่ — ไม่มี log ไม่มี metric รู้แค่ GPU ทำงานหนักขึ้น
ไม่มี API key แยกคน — ทุกคนใช้ key เดียวกัน ถ้า key หลุดก็จบเลย
ไม่มี rate limit — มีคนส่ง request ต่อเนื่อง ทำให้คนอื่นรอคิวนาน
ไม่มี cache — คำถามซ้ำๆ ถูกส่งไป LLM ทุกครั้ง เสียทรัพยากรโดยไม่จำเป็น
backend ล่มที ทุกอย่างก็หยุดทำงาน — ไม่มี fallback ไม่มี retry
ถ้าจะเขียนระบบจัดการเองก็ทำได้ แต่ต้องมานั่งทำ auth, logging, rate limit, cache, dashboard...
ไม่ใช่งานที่ผมอยากทำ
แค่อยากให้ทีมใช้ LLM ได้สะดวก โดยที่ยังคุมทุกอย่างได้