Skip to main content

Qwen3.8-Flash-Next เปิดตัวแล้ว — 125B MoE + 51B n-gram, 6B active แต่ชนะ Claude Opus 4.6 หลาย agentic benchmark

· 13 min read

บันทึก — 26 สิงหาคม 2569 — Qwen ปล่อย Qwen3.8-Flash-Next จริงตามที่ teaser ไว้เมื่อวาน — เป็น Qwen4 architecture preview แรกที่มี n-gram embedding (PLE) เป็น native component

Qwen ปล่อย Qwen3.8-Flash-Next บน Hugging Face เมื่อเช้าตามเวลาไทย — บทความนี้คือการรวบ spec, benchmark, quant ที่ออกแล้ว, และ feasibility บน DGX Spark (GB10) ที่ผมมีอยู่ 1 node

ตัวเลขที่ทำให้หยุดอ่าน: 6B active params แต่ agentic coding (DeepSWE 1.1) ทำได้ 58.7 — Qwen3.8-27B ทำได้ 42.2, Qwen3.7-Plus ทำได้แค่ 16.5, และ DeepSeek-V4-Flash ทำได้ 54.4

TL;DR​

  • สถาปัตยกรรม: Qwen4 preview — Hybrid attention (Gated DeltaNet + Qwen Sparse Attention), Gated Residual, N-gram Embedding (PLE), Muon+AdamW training recipe
  • ขนาดจริง: 125B main + 51B n-gram + 4B MTP = 180B total · 6B activated/token · 48 layers · 512 experts (10 routed + 1 shared)
  • Context: 262K native, extensible ถึง 1M
  • License: Qwen Community License 1.0 (ไม่ใช่ Apache 2.0 — MAU ≥ 100M หรือ revenue ≥ $20M/mo ต้องขอ license แยกสำหรับ hosted/MaaS)
  • NVFP4 quant: RadixArk/Qwen3.8-Flash-Next-NVFP4 — 360 GB → 135 GB (~2.7×) — GSM8K/AIME ≈ BF16
  • Benchmark เด่น: ชนะ Claude Opus 4.6 Max ใน DeepSWE 1.1, JobBench, Toolathlon, CoWorkBench, SWE-bench Multilingual, GPQA Diamond, LiveCodeBench v6
  • Day-0 support: Unsloth GGUF, SGLang recipe, vLLM recipe — llama.cpp เป็น PR/fork ก่อน merge master
  • DGX Spark GB10 (128 GB unified): NVFP4 135 GB เกินอยู่ ~7 GB — แต่ offload MTP (4B ≈ 8 GB) + บางส่วนของ n-gram ลง NVMe น่าจะพอดี

ที่มาของข้อมูล​

หนนี้ตามตั้งแต่ เมื่อวาน (25 ส.ค.) ที่มีคน post ใน r/LocalLLaMA ว่า "Qwen3.8-Flash-Next tomorrow" — ตอนแรกผมก็เฉยๆ เพราะ Qwen ชอบเลื่อน แต่พอเช็ค ModelScope ก็เจอ readme ที่ระบุสถาปัตยกรรมชัดเจน — วันนี้เช้าเปิด HF มี weights ครบแล้ว

แหล่งหลักๆ ที่ใช้:

Spec ทางการ​

Componentค่า
TypeCausal LM + Vision encoder
TrainingPre-training + Post-training
Main params125B
Activated params6B (10 routed + 1 shared จาก 512 experts)
N-gram embedding51B (20M bigrams/trigrams, layer 2)
MTP4B (1 layer, multi-step training)
Hidden dim2560
Token embedding248,320 (padded)
Layers48
Hidden layout12 × (3 × (Gated DeltaNet → MoE) → 1 × (QSA → MoE))
Gated DeltaNet48V heads + 16 QK heads, head dim 128
Qwen Sparse Attention24 Q + 2 KV heads, head dim 256, RoPE 64
QSA indexerMQA, 4 query heads + 1 shared key head, head dim 128
QSA budget512 blocks or 2048 tokens
MoE experts512 routed, intermediate dim 640
Gated Residual4 branches, bottleneck rank 320
Context262,144 native → 1,000,000 extensible

ตัวเลขที่ทำให้ต้องคิดใหม่คือ activation rate 4.8% (6B จาก 125B) — ต่ำกว่า Qwen3.6-35B-A3B (8.6%) และ Qwen3.5-122B-A10B (8.2%) — ในทางทฤษฎี inference ต่อ token ถูกกว่ารุ่นก่อนมาก

นวัตกรรมหลัก 4 อย่าง​

1. Qwen Sparse Attention (QSA)

Qwen3-Next ใช้ Gated DeltaNet + Gated Attention — รอบนี้เปลี่ยน Gated Attention เป็น QSA ที่ทำ sparse ที่ระดับ micro-block ไม่ใช่ token — คนใน r/LocalLLaMA คาดว่า KV cache ใช้พื้นที่ลดลง ~25% เทียบ dense attention (challis88ocarina)

2. Gated Residual

Residual stream แบบเดิมใช้ normalization + skip connection — รอบนี้มี element-wise data-dependent read gate + per-branch scalar write gate (4 branches, bottleneck rank 320) — เพิ่ม expressiveness โดยไม่ทำลาย training stability

ผลข้างเคียง ที่คนใน r/LocalLLaMA กังวล: abliterated finetune จะยากขึ้น เพราะ gating ทำให้ activation มี nonlinearity มากกว่า residual ปกติ (llama-impersonator)

3. N-gram Embedding (PLE)

คือ embedding table ขนาด 51B ที่ index ด้วย n-gram (bigram/trigram) แทน token เดี่ยว — wren6991 อธิบายว่า:

"ทำ lookup ของ sliding window → ได้ vector เดียว ราคาเท่ากัน (O(1)) แต่ semantic ที่กว้างกว่า — สำคัญกับ CJK ที่ tokenizer แตก character ออกเป็น bytes"

ในทางปฏิบัติ n-gram เป็น deterministic lookup จาก input tokens — Stunning_Energy_7028 สรุปว่ามันทำงานเหมือน KV cache:

  • Prefill ดึง n-grams ที่จำเป็น (fraction เล็กมากของ 51B) เข้า RAM/VRAM
  • Decode ใช้ซ้ำได้เรื่อยๆ
  • เลย offload ลง SSD ได้โดยไม่กระทบ performance — เป็น axis ใหม่ของ parameter scaling ที่ไม่ต้องเพิ่ม compute

4. Muon + AdamW Training Recipe

ใช้ Muon กับ weight category หนึ่ง, AdamW กับอีก category — และตัด warmup batch size ออก (refitted scaling laws) — ลด optimizer steps รวม ~30% และรองรับ learning rate สูงกว่าเดิม

Benchmark​

ผมเทียบ 5 โมเดล: Qwen3.8-Flash-Next, Qwen3.8-27B (dense), Qwen3.7-Plus (397B), DeepSeek-V4-Flash (284B), Claude Opus 4.6 (Max)

Language benchmarks​

Flash-Next27B3.7-PlusDS-V4-FlashOpus-4.6
# Params125B27B397B284B--
# Activated6B27B17B13B--
# N-gram51B--------
DeepSWE 1.158.742.216.554.4--
SWE-bench Pro62.561.755.856.053.4
SWE-bench Multilingual81.073.875.8--77.5
NL2Repo-Bench48.142.341.154.247.6
CoWorkBench73.970.765.145.168.2
JobBench55.733.427.641.336.6
Agents' Last Exam (Pass@1)24.320.413.225.2--
Agents' Last Exam (Score)51.242.933.6----
Toolathlon Verified73.567.150.670.3--
IFBench81.379.579.179.262.5
GPQA Diamond91.789.290.390.891.3
HLE35.930.834.733.840.0
LiveCodeBench v691.990.389.690.688.8

สังเกต:

  1. ชนะ Opus 4.6 Max เกือบทุก coding/agentic benchmark — DeepSWE 1.1 (Opus ไม่มีตัวเลข), SWE-bench Pro (62.5 vs 53.4), CoWorkBench (73.9 vs 68.2), JobBench (55.7 vs 36.6), Toolathlon (73.5 vs ไม่มี), IFBench (81.3 vs 62.5), LiveCodeBench (91.9 vs 88.8)
  2. แพ้ Opus แค่ HLE — 35.9 vs 40.0 — multidisciplinary reasoning
  3. แพ้ DeepSeek-V4-Flash แค่ NL2Repo-Bench — 48.1 vs 54.2 (เป็น repo-level generation ที่ DS ทำได้ดี)
  4. เกือบ 2 เท่าของ Qwen3.7-Plus ใน JobBench (55.7 vs 27.6) และ Toolathlon (73.5 vs 50.6) — แม้จะ active น้อยกว่า (6B vs 17B)

Vision-language​

Flash-Next27B3.7-PlusOpus-4.6
ClawEval-MM (Pass@3)64.457.457.452.5
ClawEval-MM (Avg)60.456.960.154.7
RecreationBench49.947.130.2--
AndroidWorld84.581.981.062.0
OSWorld 2.0 (Binary)19.419.42.8--
OSWorld 2.0 (Partial)52.348.021.5--
MathVision (w/o CI)90.690.090.365.5
MathVision (with CI)95.794.688.7--
ERQA72.365.569.840.8
LVBench76.672.476.263.0
RealWorldQA88.585.986.973.9

OSWorld 2.0 (computer use) — Flash-Next ทำ partial credit ได้ 52.3 vs 27B ทำได้ 48.0 และ 3.7-Plus ทำได้แค่ 21.5 — กระโดดจาก agent ที่ "ทำได้" เป็น agent ที่ "ทำได้เสถียร"

Rule of thumb ที่ยังใช้ได้​

ResidentPositive4122 ตั้งข้อสังเกตว่า sqrt(active × total) ≈ dense equivalent:

sqrt(125 × 6) = sqrt(750) = 27.39

ใกล้กับ Qwen3.8-27B (27B dense) — arch ใหม่ แต่ scaling law ของ dense vs MoE ยังถือ น่าจะเป็น heuristic ที่ใช้ประมาณ capability ของ MoE ใหม่ๆ ได้ในเบื้องต้น

Quant — RadixArk NVFP4​

RadixArk/Qwen3.8-Flash-Next-NVFP4 เป็น quant แรกที่ออกมา (ไม่ใช่ของทาง Qwen เอง — เป็น candidate release จาก RadixArk)

Scope การ quant:

ComponentStatus
Routed experts (48 layers)NVFP4 W4A4
Attention / QSA / GDNBF16
Shared experts, routers, embeddings, LM headBF16
Vision encoderBF16
MTP tensors (31 ตัว)BF16 byte-identical
N-gram (PLE) tablesFP8 จาก Qwen3.8-Flash-Next-FP8

ขนาด: 360 GB BF16 → 135 GB NVFP4 (~2.7× reduction)

Quality (vs BF16):

EvalBF16NVFP4
GSM8K (1319)97.12-97.5097.27
AIME26 (pass@1)10098.75
AIME26 (majority@8)--100

Quality drop ≈ 0 สำหรับ single-turn — แต่ RadixArk ระบุว่า long agentic generation อาจยาวกว่า BF16 เล็กน้อย (น่าจะเพราะ quant noise เพียน output distribution)

Toolchain:

  • NVIDIA Model Optimizer snapshot 87c9f8cf (v0.46.0)
  • Runtime: SGLang (ต้อง build ที่มี qwen4_exp model support)
  • Hardware validated: GB300, B300 (NVIDIA Blackwell)
  • Backend: --fp4-gemm-backend flashinfer_cutlass
  • Calibration: 128 articles จาก cnn_dailymail + GSM8K probe

Audit ที่มีให้:

  • 294,912 routed tensors + 1,562 unchanged + 31 MTP tensors (structural)
  • 221,184 finite positive scales, min 2.13e-05, max 448.0
  • 1,562 tensors / 118.4 GB byte-equality audit
  • Raw metrics: gsm8k_metrics.json, aime26_metrics.json
  • Reports: qualification-notes.md, validate_checkpoint_report.json, validate_scales_report.json

ปัจจุบันยังเป็น "private candidate release" — คาดว่ามี revision ใหม่ตามมา แต่ตัวนี้ก็ reproducible ดี audit ครบ

ลง DGX Spark GB10 ได้ไหม​

นี่คือคำถามที่ผมสนใจที่สุด — ผมมี DGX Spark 1 node (128 GB unified memory)

Memory budget​

ComponentSizeNote
NVFP4 radix expert weights~75 GBส่วน main
N-gram (FP8 จาก Qwen-FP8 revision)~26 GBoffloadable → SSD
MTP (BF16)~8 GBoffloadable → SSD
Attention/QSA/GDN (BF16)~26 GBต้องอยู่ใน unified mem
Total resident in unified~135 GBเกิน 128 GB อยู่ ~7 GB
Total resident (MTP → SSD)~127 GBใกล้เคียง 128 GB แต่เสี่ยง OOM
Realistic with KV cache + activations~150-160 GBoverflow แน่

ปัญหา: NVFP4 ของ RadixArk อยู่ที่ 135 GB แต่ตอน runtime ต้องมี KV cache + activations + workspace อีก — GB10 128 GB unified ไม่พอแน่ถ้าใช้ quant นี้

ทางเลือก​

A. รอ quants ที่เล็กกว่า — AWQ INT4 หรือ quants อื่นๆ ที่จะออกตามมา (ตอนนี้มี 4 quantized versions บน HF แล้ว) — น่าจะ fit ใน 128 GB unified ตรงๆ หรือเหลือพื้นที่ context เยอะ

B. Offload หนักขึ้น — ใช้ NVFP4 + offload ทั้ง n-gram บางส่วน + MTP + router weights ลง NVMe — อาจจะได้ throughput ที่ลดลงมาก แต่รันได้

C. Dual DGX Spark — TP=2 ตาม recipe ของ RadixArk — แต่ผมมีแค่ 1 node

D. ใช้ Qwen3.8-27B (NVFP4) ไปก่อน — ใช้ recipe เดิมที่ reproducible แล้ว (TysAIs/qwen38-sglang-dgx-spark) — ไม่มี n-gram แต่ใช้งานได้แน่

ตัวเลือก D น่าจะ work ที่สุดสำหรับคนที่อยากได้ Flash-Next experience บน hardware จำกัด — แต่ตัวเลือก A น่าจะมาเร็วๆ นี้ (Unsloth GGUF ออกแล้ว)

ความเสี่ยงของ NVFP4 บน GB10​

ไม่ใช่ทุก Blackwell เหมือนกัน — GB10 = Grace CPU + Blackwell GPU (SM_120) แต่ RadixArk validated แค่ GB300/B300

มี issue ที่ vLLM ว่า NVFP4 บน ARM64+GB10 เคย crash — ตอนนี้น่าจะแก้แล้ว (FlashInfer มี native NVFP4 kernels บน SM_120 แล้ว) แต่ก็ยังไม่เร็วเท่า Marlin INT4

Offloading tiers — ทำไมมันน่าสนใจ​

ReadyAndSalted ใน Megathread สรุป tier ที่เหมาะสม:

แต่ละ tier มี bandwidth requirement ต่างกัน — n-gram ใช้แค่ lookup (O(1) ไม่ผ่าน matmul) เลยเหมาะกับ SSD มาก

ส่วน Intel Optane ที่คนถามในเธรด — InsiderCrush บอกว่า "Optane is ideal for this" เพราะ latency ต่ำกว่า NVMe — แต่ Optane เลิกผลิตแล้ว ใช้ของเก่าก็ได้

เรื่อง License — ระวังไว้​

Qwen Community License 1.0 ไม่ใช่ Apache 2.0 เหมือน Qwen3.8-27B:

  • ถ้ามี ≥ 100M monthly active users หรือ ≥ $20M monthly revenue → ต้องแสดงชื่อ model ใน product
  • ถ้าทำ Model-as-a-Service / AI Work Assistant business → ต้องขอ license แยก

coder543 ตั้งข้อสังเกตว่า:

"limit ไม่ใช่ $20M — มันคือ $0 ถ้า host ให้คนอื่นใช้" — เป็นปัญหากับการแข่งขัน

สำหรับ self-host ส่วนตัว → ไม่กระทบ แต่ถ้าจะเอาไปทำ product ต้องดู license ก่อน

แผนของผม​

ตอนนี้ผม ยังไม่ลงทันที — เก็บไว้ดูตอนว่างๆ

แผนที่คิดไว้:

  1. รอ Unsloth GGUF ออก Q4/Q5 ก่อน — fit 128 GB unified ตรงๆ น่าจะง่ายกว่า
  2. ลอง SGLang NVFP4 ผ่าน Docker ในช่วง weekend — มี recipe ชัดเจนจาก RadixArk — แต่เตรียม OOM plan ไว้ (offload MTP/n-gram ลง NVMe)
  3. ทดสอบ single-task performance เทียบกับ Qwen3.8-27B (NVFP4) เดิมที่ใช้อยู่ — ถ้า Flash-Next ดีกว่าแบบชัดเจนใน use case ของผม (agentic coding + RAG) ก็ย้าย
  4. Benchmark throughput เทียบ inference speed — activated 6B น่าจะเร็วกว่า 27B dense แต่ต้องวัดจริง

ถ้าผลออกมาน่าสนใจ จะเขียน follow-up blog ตอน tune เสร็จ

สรุป​

สรุปสั้นๆ สำหรับคนที่อ่านมาถึงตรงนี้:

  • ถ้ามี hardware 128 GB unified ขึ้นไป (GB10, Strix Halo, M2 Ultra) → รอ AWQ/GGUF quant ที่เล็กกว่า NVFP4 ก่อน แล้วค่อยลอง
  • ถ้ามี VRAM ≥ 96 GB → RadixArk NVFP4 น่าจะรันได้ผ่าน SGLang
  • ถ้ามีแค่ 64 GB VRAM → offload n-gram + MTP ลง SSD + ใช้ Q4 quant ของ Unsloth เมื่อออก
  • ถ้าใช้ API อย่างเดียว → ใช้ Qwen Cloud (qwencloud.com/models/Qwen3.8-Flash) ที่มี 1M context ในตัว ไม่ต้อง setup เอง
  • ถ้าทำ product → อ่าน license ก่อน — Qwen Community License 1.0 มีเงื่อนไข MaaS ที่ต้องขอแยก

ตัว Qwen4 architecture ที่นี่คือ preview ชัดเจน — Gated Residual + QSA + n-gram PLE จะกลายเป็น standard ใน Qwen4 series ที่จะออกปลายปี — ใคร tune quant/finetune บน arch นี้ตอนนี้จะได้เปรียบ

อ้างอิง​

แชร์บทความ
☕

เนื้อหานี้มีประโยชน์ไหม? ช่วยสนับสนุนค่ากาแฟให้ผู้เขียนสักแก้ว

Buy Me a Coffee
Loading...