5 posts tagged with "vllm"

เอาจริง ๆ จุดเด่นอย่างนึงของ 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 — รายละเอียดทั้งหมดอยู่ด้านล่าง

ผมตั้งค่า 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 แบบที่ผมเข้าใจ

อ้าว ผมเลยต้องกลับมานั่งคิดใหม่

Context​

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 เป็นเครื่องสำหรับนักพัฒนาที่ใช้เฉพาะทาง"

intro​

ผมรัน 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 ได้สะดวก โดยที่ยังคุมทุกอย่างได้