Qwen3.8-Flash-Next GGUF จาก Unsloth ใช้ Dynamic V3.1 ลดขนาดโมเดล 125B ให้รันบนเครื่องที่มีแรมจำกัดได้ง่ายขึ้น

โดย ลุงจุ้ยคุยเรื่องคอม · 5 พ.ย. 2026

Unsloth ปล่อย GGUF ชุดใหม่ของ Qwen3.8-Flash-Next เมื่อวันที่ 4 พฤศจิกายน 2026 โดยใช้อัลกอริทึม Unsloth Dynamic V3.1 (preview) ซึ่ง Unsloth ระบุว่าช่วยให้ quant ดีขึ้นในเบนช์มาร์กส่วนใหญ่ที่ทดสอบ และมีค่า KLD ดีกว่า quant รุ่น V3 เดิมของตัวเอง นอกจากนี้ยังมี MTP (Multi-Token Prediction) ที่ทำให้ถอดรหัสเร็วขึ้น และตัวเลือกให้เลือกความละเอียดของส่วน engram เองได้

ข่าวนี้น่าสนใจสำหรับคนที่มีเครื่องหน่วยความจำเยอะอยู่แล้ว เช่น Mac แบบ unified memory, DGX Spark หรือเวิร์คสเตชันที่มี RAM หลักร้อย GB เพราะโมเดลนี้ถูกออกแบบให้ทำงานจาก RAM ได้ใกล้เคียงกับ VRAM มากกว่าโมเดลทั่วไป แต่ก่อนจะตื่นเต้นกับตัวเลขที่ปรากฏในข่าว มีหลายจุดที่ต้องแยกให้ชัดว่าอะไรคือข้อมูลจากต้นทาง อะไรคือคำอ้างของผู้ผลิต

โมเดลต้นฉบับ: Qwen3.8-Flash-Next จาก Qwen

Qwen3.8-Flash-Next โมเดลต้นฉบับนั้นมาจากทีม Qwen ส่วน Unsloth เป็นผู้นำมาทำไฟล์ GGUF ที่ลดขนาดลง โดยทาง Unsloth ได้อธิบายว่าโมเดลต้นฉบับมีลักษณะดังนี้

เป็นโมเดลเปิด (open-weight) แบบ MoE ขนาด 125B parameters รองรับภาพ (multimodal)
สร้างบนสถาปัตยกรรม Qwen4 ใหม่
รองรับ context window สูงสุด 262,144 โทเคน (ราว 256K)
เป็นโมเดลแบบ hybrid thinking มีโหมดคิดและโหมดไม่คิด ปรับระดับการคิดได้ด้วย reasoning_effort (xhigh เป็นค่าเริ่มต้น) และมี Preserve Thinking
ไฟล์ต้นฉบับความละเอียด BF16 มีขนาด 355GB ซึ่งเป็นขนาดอ้างอิงที่ Unsloth ใช้เทียบทุกครั้ง

จุดที่ทำให้โมเดลนี้ต่างจาก MoE ทั่วไปคือสถาปัตยกรรมมีชั้น Ngram / PLE (per-layer embeddings) ซึ่ง Unsloth อธิบายว่าเหมือนตารางค้นหา (lookup table) ชั้นนี้ถูกเข้าถึงแบบสุ่ม จึงบีบอัดหนักไม่ได้ ผลคือไฟล์ 1-bit ของโมเดลนี้ใหญ่กว่าที่คนทั่วไปคาด

Unsloth ยังระบุว่า Qwen3.8-Flash-Next เหนือกว่า Claude-4.6-Opus (Max) นั่นทำให้หลายคนสนใจที่จะรันโมเดลนี้ในเครื่องของตัวเองมากขึ้น

Unsloth นำมาลดขนาดอย่างไร

สิ่งที่ Unsloth ทำคือแปลงโมเดลต้นฉบับเป็นไฟล์ GGUF แล้วทำ quantization หรือลดจำนวนบิตที่ใช้เก็บน้ำหนัก ด้วยอัลกอริทึมของตัวเองที่เรียกว่า Unsloth Dynamic ผลคือจากต้นฉบับ BF16 355GB เหลือ 1-bit ราว 72.5 ถึง 74.5GB หรือ เล็กลง 79% ตามที่ Unsloth ระบุ

หลักการของ Dynamic คือไม่บีบทุกส่วนเท่ากัน แต่เลือกระดับบิตตามความสำคัญของแต่ละส่วน (หลักการนี้ต้นทางหน้านี้ไม่ได้อธิบายละเอียด เป็นคำอธิบายทั่วไปของ Dynamic quant) สำหรับโมเดลนี้ มีรายละเอียดที่ต้นทางระบุไว้ชัดเจนสองข้อ

ชั้น Ngram / PLE ถูกจำกัดไม่ให้ต่ำกว่า 4-bit เพราะบีบหนักแล้วจะทำให้โมเดลเสียหาย ส่วนอื่นของโมเดลบีบได้หนักกว่านั้น
ผู้ใช้เลือกความละเอียดของ engram แยกจากตัวโมเดลได้ (BF16, Q8_0, Q5_1 หรือ IQ4_NL) ถ้ามีพื้นที่ดิสก์เหลือ

ชุดนี้ใช้อัลกอริทึมรุ่น V3.1 (preview) ที่ปรับปรุงจาก V3 เดิม และ Unsloth วัดผลด้วย top-1 และ KLD เทียบกับต้นฉบับ BF16 ซึ่งอธิบายในหัวข้อถัดไป

Dynamic V3.1 ดีขึ้นอย่างไร

Unsloth รัน benchmark ชุดใหญ่ ได้แก่ Terminal Bench 2.1, DeepSWE v1.1, Automation Bench v1.0.6, Aider Polyglot, LiveCodeBench v6, GPQA Diamond, MMLU-Pro, AIME25 และอื่น ๆ โดยระบุว่าใช้โทเคนรวม 26.2 พันล้านโทเคน (DeepSWE กินไป 18.1 พันล้าน, Terminal Bench 5.2 พันล้าน) ตั้งค่าเป็น temperature 1.0, top_p 0.95, top_k 20 เปิด preserve thinking และ reasoning ระดับ xhigh ใช้ context สูงสุด 256K ในชุดทดสอบที่เป็นงานยาว และ 128K ในชุดทดสอบทั่วไป รันซ้ำหลายรอบเพราะผลมีความผันผวน

สิ่งที่ต้นทางสรุปมีแค่นี้: V3.1 ดีขึ้นในเบนช์มาร์กส่วนใหญ่ เมื่อวัดเป็นเปอร์เซ็นต์ความแม่นยำที่คง (accuracy recovery) เทียบกับโมเดลต้นฉบับ และ ค่า KLD ดีขึ้นมาก เมื่อเทียบกับ quant V3 รุ่นก่อน

ต้นทางไม่ได้ระบุตัวเลขว่า “ดีขึ้น 15%” หรือ “เหนือกว่าโมเดลอื่น 15%” ที่ใดเลย ตัวเลข 15% ที่ผ่านตามสื่อบางแห่งจึงไม่มีที่มาจากหน้านี้ บทความนี้จึงไม่ใช้ตัวเลขดังกล่าว

อีกข้อที่ควรรู้คือ benchmark ทั้งหมดเป็นของ Unsloth เอง และผู้เผยแพร่ quant ชุดนี้ก็คือ Unsloth เช่นกัน ตัวเลขชุดนี้วัดว่า quant คงพฤติกรรมของโมเดลต้นฉบับได้แค่ไหน ไม่ใช่การเปรียบเทียบโมเดลนี้กับโมเดลอื่นโดยหน่วยงานอิสระ และ V3.1 ยังเป็นรุ่น preview

ตารางคุณภาพ: top-1 และ KLD คืออะไร

ตารางนี้อยู่ในหัวข้อ Quantization Analysis ของ Unsloth เทียบ quant แต่ละระดับกับโมเดลต้นฉบับ BF16 (ตัวเลขทั้งหมดเป็นผลของ Unsloth)

Quant	ขนาดไฟล์ (GB)	top-1 (%)	mean KLD
UD-IQ1_S	72.5	77.3	0.396
UD-IQ1_M	74.5	79.7	0.315
UD-Q2_K_XL	78.9	82.7	0.225
UD-IQ3_XXS	82.0	85.4	0.165
UD-Q3_K_XL	90.0	88.3	0.107
UD-IQ4_XS	93.7	89.6	0.084
UD-Q4_K_XL	111.3	92.3	0.047
UD-Q5_K_XL	158.3	93.7	0.030
UD-Q6_K_XL	169.2	94.1	0.027
Q8_0	188.2	94.1	0.027

วิธีอ่านตาราง: top-1 คือสัดส่วนที่ quant เลือกโทเคนถัดไปตัวเดียวกับโมเดลต้นฉบับ ยิ่งสูงยิ่งใกล้ต้นฉบับ KLD (KL divergence) วัดว่าการกระจายความน่าจะเป็นของโมเดลที่ถูกบีบอัดต่างจากต้นฉบับเท่าไร ยิ่งต่ำยิ่งดี ทั้งสองค่าไม่ใช่คะแนนความถูกต้องของคำตอบ และไม่ได้หมายถึงโมเดลตอบถูกกี่เปอร์เซ็นต์ (อ่านพื้นฐานเพิ่มได้ที่ quantization และ bpw)

Unsloth กล่าวว่าลงขนาดลง 79% แต่ยังได้ top-1 80% ตรงกับแถว 1-bit (72.5 ถึง 74.5GB เทียบกับ BF16 355GB) โดยตัวเลข 80% ใกล้กับ UD-IQ1_M (79.7%) ส่วน UD-IQ1_S อยู่ที่ 77.3%

สังเกตว่าเส้นโค้งแบนลงหลัง Q5 เป็นต้นไป Q6_K_XL กับ Q8_0 ได้ top-1 เท่ากัน (94.1) แต่ไฟล์ต่างกัน 19GB ถ้าหน่วยความจำจำกัด การกระโดดจาก 8-bit ลงมาที่ Q5 หรือ Q4 จึงเสียน้อยกว่าที่คาด

ต้องใช้หน่วยความจำเท่าไรกันแน่

ส่วนนี้ในเว็บ Unsloth เองมีตัวเลขที่ชวนสับสน ถ้าอ่านผิวเผินอาจเข้าใจผิดได้ จึงขอวางไว้เทียบกันดังนี้ครับ

ที่มา: ในเว็บ Unsloth	ตัวเลขที่ระบุ
ข้อความ Usage Guide	ต้องมี RAM หรือ unified memory อย่างน้อย 75GB
ตาราง Hardware requirements (หน่วยความจำรวม)	1-bit 32GB / 2-bit 42GB / 3-bit 50GB / 4-bit 64GB / 5-bit 80GB / 8-bit 128GB / BF16 355GB
ขนาดไฟล์จริงในตาราง Quantization Analysis	1-bit 72.5 ถึง 74.5GB / UD-Q4_K_XL 111.3GB / Q8_0 188.2GB
ตาราง MTP Hardware requirements	1-bit 76GB / 2-bit 80GB / 3-bit 91GB / 4-bit 97 ถึง 115GB / 5-bit 164GB / 8-bit 200GB

ตัวเลขเหล่านี้ไม่ขัดกันถ้าอ่านเงื่อนไขประกอบ: Unsloth บอกว่าชั้น PLE / Ngram ออฟโหลดไปไว้บน SSD แล้วใช้ mmap ได้ ซึ่งช่วยลด RAM/VRAM ที่ต้องใช้ ตัวเลข 32GB สำหรับ 1-bit จึงเป็นกรณีที่พึ่ง mmap และ SSD ไม่ใช่โหลดโมเดลทั้งหมดไปไว้ในหน่วยความจำ ไฟล์ 1-bit จริงมีขนาดราว 72 ถึง 75GB และตัวเลขในตาราง MTP (1-bit ที่ 76GB) ใกล้กับขนาดไฟล์มากกว่า ซึ่งสอดคล้องกับข้อมูลตาราง MTP ที่คิดแบบเก็บในหน่วยความจำเป็นหลัก (ข้อนี้เป็นข้อสังเกตของบทความนี้ ต้น Unsloth เองก็ไม่ได้อธิบายวิธีคำนวณตารางทั้งสองโดยละเอียด)

ถ้าอยากเข้าใจว่าทำไมโมเดลที่ใหญ่กว่า VRAM ยังรันได้ ลองอ่าน การใช้งาน VRAM และ GPU offload และเรื่องของโมเดลแบบ MoE กับ dense

Mix N Match Engrams: เลือกความละเอียดของตารางเอง

อีกฟีเจอร์ใหม่คือให้ดาวน์โหลดส่วน engram แยกและสลับความละเอียดได้ ถ้ามีพื้นที่ดิสก์เหลือก็เลือกความละเอียดสูงขึ้นได้ ตามตารางของ Unsloth

ชนิด engram	ขนาด (GB)	relative RMSE เทียบ BF16
BF16	102.4	0
Q8_0	54.4	0.0053
Q5_1	38.4	0.0376
IQ4_NL	28.8	0.0757

การสลับต้องแก้ค่า split.no และ split.count ในหัวไฟล์ให้ตรงตำแหน่งของ shard ด้วยสคริปต์ set_split.py ที่ Unsloth แจกใน repo บน Hugging Face (ขั้นตอนเต็มอยู่ในหน้าต้นทาง) ผู้ใช้ทั่วไปที่ไม่ได้อยากจุกจิกไม่จำเป็นต้องทำส่วนนี้ ใช้ quant ที่ดาวน์โหลดมาตามปกติได้เลย

MTP: เร็วขึ้น 1.3 ถึง 1.7 เท่า

MTP (Multi-Token Prediction) ให้โมเดลเดาหลายโทเคนล่วงหน้าในรอบเดียว แทนการสร้างทีละโทเคน (เป็นเทคนิคในกลุ่ม speculative decoding) Unsloth ระบุว่าเร็วขึ้น 1.3 ถึง 1.7 เท่า โดยไม่เสียความแม่นยำ ตัวอย่างที่ให้คือบน RTX 6000 PRO หนึ่งใบ ได้ 170 tok/s เทียบกับ 100 tok/s ตอนไม่ใช้ MTP

ข้อควรรู้ของตัวเลขนี้:

เป็นผลจากการ์ดระดับเวิร์คสเตชัน ไม่ใช่การ์ดจอทั่วไป และเป็นตัวเลขของ Unsloth เอง
Unsloth ระบุเองว่า ประโยชน์จะน้อยลงบนเครื่องที่ memory bandwidth ต่ำ เช่น Mac รุ่นเก่า ๆ
MTP กินหน่วยความจำเพิ่มราว 1 ถึง 2GB (ใช้โมดูลแบบ shared ช่วยประหยัดได้ เช่น Q8_0 จาก 4.14GB เหลือ 2.79GB)
Unsloth Desktop เปิด MTP ให้เองโดยอัตโนมัติ ส่วนใน llama.cpp ต้องใช้ fork ของ Daniel Han (branch qwen4exp/mtp) ไม่ใช่ llama.cpp รุ่นหลักที่ติดตั้งตามปกติ จึงควรถือเป็นของทดลอง

ตัวอย่างการใช้งาน

วิธีที่ง่ายสุดตามที่ Unsloth แนะนำคือติดตั้ง Unsloth Desktop (macOS, Windows, Linux) แล้วค้นหา Qwen3.8-Flash แอปจะตั้งค่า sampling ให้ รองรับออฟโหลดลง RAM และตรวจจับหลาย GPU เอง หรือใช้คำสั่งตามนี้

unsloth run --model unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL

ถ้าใช้ llama.cpp ดาวน์โหลดไฟล์ด้วย Hugging Face CLI

pip install -U "huggingface_hub[cli]"
hf download unsloth/Qwen3.8-Flash-Next-GGUF \
    --local-dir unsloth/Qwen3.8-Flash-Next-GGUF \
    --include "*UD-Q4_K_XL*"

แล้วรัน (ตัวอย่างนี้แก้พาธให้ตรงกับโฟลเดอร์ UD-Q4_K_XL เพราะในหน้าต้นทางตัวอย่าง llama-cli ระบุโฟลเดอร์ UD-IQ1_S แต่ชื่อไฟล์เป็น UD-Q4_K_XL ซึ่งไม่ตรงกัน)

./llama.cpp/llama-cli \
    --model unsloth/Qwen3.8-Flash-Next-GGUF/UD-Q4_K_XL/Qwen3.8-Flash-Next-UD-Q4_K_XL-00001-of-00004.gguf \
    --temp 1.0 \
    --top-p 0.95 \
    --top-k 20 \
    --min-p 0.0

ค่าที่แนะนำ (ตาม Unsloth):

พารามิเตอร์	โหมดคิด (Thinking)	โหมดไม่คิด (Instruct)
temperature	1.0	0.7
top_p	0.95	0.80
top_k	20	20
min_p	0.0	0.0
presence_penalty	0.0	1.5
repetition_penalty	1.0	1.0

โมเดลเป็น hybrid thinking เปิดระดับ xhigh เป็นค่าเริ่มต้น ถ้าอยากให้คิดสั้นลงปรับ reasoning_effort ได้เป็น medium, low หรือปิด ผ่านตัวเลือกด้านล่าง การคิดระดับสูงใช้โทเคนมากขึ้น ซึ่งกินเวลาและหน่วยความจำของ context ด้วย (ดู KV cache)

--chat-template-kwargs '{"reasoning_effort":"medium"}'

ฟีเจอร์ Preserve Thinking จะเก็บ trace การคิดของรอบก่อนไว้ในบทสนทนา Unsloth ระบุว่าใช้โทเคนมากขึ้นแต่อาจช่วยความแม่นยำในบทสนทนาที่ต่อเนื่อง

การทดลองของผู้ใช้อื่น: Arc Pro B70 ใบเดียว

นอกจาก GGUF ของ Unsloth ยังมีโครงการจากชุมชนที่รันโมเดลเดียวกันบน Intel Arc Pro B70 32GB ใบเดียว โดยย้าย expert ส่วนที่เกิน VRAM ไปไว้บน RAM และ NVMe ใช้ SGLang กับ quant แบบ EXL3 3.05 bpw (ไม่ได้ใช้ไฟล์แบบ GGUF) ผู้ทำโครงการรายงานว่าได้ราว 29 tok/s (decode ผู้ใช้คนเดียว) ในโหมดที่ใช้ RAM 16GB (ผลทดสอบเมื่อวันที่ 8 ตุลาคม 2026)

ผู้ทำโครงการระบุเองว่าผลลัพธ์ไม่ตรงกับโมเดลต้นฉบับ 100% (เพราะ expert ที่ไม่อยู่ใน cache จะถูกข้ามในบางสเต็ป) และยังไม่ผ่านการทดสอบแชตพื้นฐานของเขาเอง เพราะโหมดคิดมีอาการวนไม่จบ ก็สามารถใช้เป็นข้อมูลศึกษาเพิ่มเติมได้ที่ sybil-solutions/qwen38-flash-next-b70-offload ที่สำคัญโครงการพวกนี้ก็จะมีการปรับปรุงแนวทางการใช้งานโมเดลอยู่เสมอใครใช้ Intel Arc Pro B70 อยู่ก็ติดตามได้ครับ

สรุป: ความน่าสนใจ

มี Mac unified memory 96GB ขึ้นไป, DGX Spark หรือเวิร์คสเตชัน RAM ร้อย GB: เป็นกลุ่มที่ได้ประโยชน์ตรงที่สุด 1-bit และ 2-bit เข้าเกณฑ์ ส่วน 4-bit (ไฟล์ 111.3GB) ต้องการหน่วยความจำมากกว่าตารางหลัก 64GB ที่ต้นทางระบุไว้ ถ้าไม่พึ่ง SSD
มี RAM 32GB: เปิดได้ในทางเทคนิค แต่ต้องพึ่งการทำงานของ SSD และ mmap ยังไม่มีตัวเลขความเร็วจาก Unsloth ควรลองเองและอย่าคาดหวังประสบการณ์เทียบเท่ารันใน VRAM + RAM
อยากได้ความเร็วเพิ่ม: ลอง MTP ใน Unsloth Desktop แต่ตัวเลข 1.3 ถึง 1.7 เท่ามาจากการ์ดระดับสูง เครื่องที่ bandwidth ต่ำจะได้น้อยกว่า
ติดตามโมเดลนี้ต่อ: V3.1 ยังเป็น preview benchmark เป็นของ Unsloth เอง

แหล่งข้อมูลอ้างอิง
หัวข้อที่มีชื่อว่า “แหล่งข้อมูลอ้างอิง”