llama.cpp เพิ่มรองรับสถาปัตยกรรม Qwen3-Next — พา hybrid MoE 'active 3B' ตัวประหยัดของ Alibaba ลงเครื่อง local ผ่าน GGUF
โปรเจกต์ llama.cpp เพิ่มการรองรับสถาปัตยกรรม qwen3next เข้ามาใน build b9850 เมื่อ 30 มิถุนายน 2026 — เปิดทางให้ตระกูลโมเดล Qwen3-Next ของ Alibaba ซึ่งใช้สถาปัตยกรรม hybrid แบบใหม่ เข้าสู่ระบบนิเวศ GGUF ที่รันได้บน CPU และ GPU ผู้บริโภค
นี่เป็นข่าวเล็กในเชิงบรรทัดโค้ด แต่ผลกระทบต่อสาย local inference ไม่เล็ก: Qwen3-Next คือสถาปัตยกรรมที่ออกแบบมาเพื่อ throughput สูงด้วยต้นทุนคำนวณต่ำ การที่ llama.cpp รองรับมันได้แปลว่าคนที่รันโมเดลบนเครื่องตัวเองมีตัวเลือกที่เร็วและเบาขึ้นอีกทาง
Qwen3-Next: hybrid attention + MoE เบาบางสุดขั้ว
สิ่งที่ทำให้ Qwen3-Next ต่างจากโมเดล dense ทั่วไปคือมันผสมสองเทคนิคเข้าด้วยกัน:
- Gated DeltaNet — attention แบบ linear ที่ต้นทุนไม่พุ่งตามความยาวบริบทเหมือน attention มาตรฐาน เหมาะกับบริบทยาว
- MoE ที่เบาบางมาก (ultra-sparse) — เช่นรุ่น Qwen3-Next-80B-A3B ที่มีพารามิเตอร์รวม 80B แต่ active เพียง ~3B ต่อการ inference หนึ่งครั้ง
ผลคือโมเดลที่ “ใหญ่ในแง่ความรู้ แต่เบาในแง่การคำนวณจริง” — active parameter แค่ 3B หมายถึงความเร็ว/หน่วยความจำที่ใช้ตอนรันใกล้โมเดลเล็ก ทั้งที่คุณภาพมาจากคลังพารามิเตอร์ระดับ 80B การพา pattern นี้ลง GGUF จึงเป็นเรื่องน่าสนใจสำหรับคนที่อยากได้โมเดลแรงแต่รันบนเครื่องจำกัด
build ต่อเนื่องหลายตัวในไม่กี่วัน
b9850 เป็นส่วนหนึ่งของจังหวะพัฒนาที่ถี่มากของ llama.cpp — ในช่วง 30 มิ.ย.–1 ก.ค. มี build ทยอยออกต่อเนื่องถึง b9859 ครอบคลุมงานปรับแต่งอื่น ๆ เช่น CUDA restrict pointer, AVX2 สำหรับ nvfp4, OpenCL kernel และ Hexagon flash attention การรองรับ qwen3next ที่ลงใน b9850 จึงมาพร้อมสายงานเพิ่มประสิทธิภาพ backend หลายด้านในสัปดาห์เดียวกัน
หมายเหตุ: ตัวสถาปัตยกรรม Qwen3-Next ประกาศโดย Alibaba มาก่อนหน้านี้ — ข่าววันนี้คือฝั่ง llama.cpp เพิ่งเพิ่ม support ให้รันผ่าน GGUF ได้ ไม่ใช่การเปิดตัวโมเดลใหม่
มุมมอง AI Curator
การที่ llama.cpp ตามรองรับสถาปัตยกรรมใหม่ ๆ ได้เร็วขนาดนี้คือเหตุผลที่มันยังเป็น หัวใจของ local AI ในปี 2026 — โมเดลเปิดจะแรงแค่ไหนก็ไร้ความหมายสำหรับคนทั่วไปถ้ารันบนเครื่องตัวเองไม่ได้ และ llama.cpp คือชั้นที่แปลง “น้ำหนักบน Hugging Face” ให้กลายเป็น “โมเดลที่รันบนโน้ตบุ๊กได้จริง”
เทรนด์ที่ Qwen3-Next ตอกย้ำคือ สถาปัตยกรรมกำลังกลายเป็นสนามแข่งสำคัญพอ ๆ กับขนาดโมเดล — แทนที่จะแข่งกันเพิ่มพารามิเตอร์อย่างเดียว ทีมวิจัยหันมาออกแบบให้ active parameter ต่ำลงเพื่อความเร็ว/ต้นทุน (linear attention + sparse MoE) ซึ่งเป็นข่าวดีตรง ๆ กับผู้ใช้ปลายทางที่ฮาร์ดแวร์จำกัด
สำหรับนักพัฒนาไทยและสาย self-host ใน SEA ที่ต้นทุน GPU และค่าไฟเป็นข้อจำกัดจริง โมเดล “active 3B จาก 80B” ที่รันผ่าน GGUF ได้คือทิศทางที่คุ้มจับตาที่สุด — ได้คุณภาพจากคลังพารามิเตอร์ใหญ่โดยจ่ายต้นทุน inference เท่าโมเดลเล็ก ข้อควรระวังคือ support ที่เพิ่งลงในสัปดาห์นี้มักต้องรอ quant/GGUF ที่นิ่งและการทดสอบซ้ำอีกสักระยะ ก่อนจะวางใจใช้ในงานจริง — แนะนำให้ตามอัปเดต build ใหม่ ๆ และผล benchmark จากชุมชน r/LocalLLaMA ควบคู่ไปด้วย
แหล่งข่าว
อ่านเพิ่มในหมวด เครื่องมือนักพัฒนา
Betelgeuse รัน Qwen3.8 Flash Next ขนาด 68GB บน RTX 3060 กับแรม 16GB ส่วน Basalt วัดให้เห็นว่าเอนจินที่เร่งด้วยแฟล็กลัดทำให้โมเดลลืมของ
Betelgeuse ฟอร์ก llama.cpp ที่เปิดเมื่อ 31 ต.ค. ดึง expert จาก NVMe เข้า VRAM ตามต้องการ อ้าง 22 tok/s แบบไม่ทิ้ง expert แต่ README เตือนเองว่ายังทดลองและตัวเลขมาจากคนละรอบ วันเดียวกันผู้พัฒนา Basalt เผยผลวัดว่าแฟล็กเร่งความเร็วทำคุณภาพ Q8 ตกไปใกล้ Q2
กฎห้ามโคลนเกมของ Claude Code เริ่มกระทบงานจริง บริษัทรับทำเกมกระดานร้องงานลูกค้าหยุด แต่รายงานหลายชิ้นปนกับตัวกรองไซเบอร์คนละเรื่อง
ต่อจากที่เราพบกฎนี้ในไบนารี Claude Code ผู้ใช้เริ่มรายงานว่างานเชิงพาณิชย์ถูกปฏิเสธ และ Tom's Hardware กับ Mashable หยิบไปรายงาน แต่เมื่อไล่ issue ที่อ้างถึง พบว่าหลายรายการเกิดก่อนกฎจะมา จึงน่าจะเป็นตัวกรองด้านไซเบอร์ ส่วน Anthropic ยังไม่ชี้แจง
Claude Code ส่ง transcript ของ background agent ให้โมเดลทุก ~30 วินาทีเพื่อเขียนสถานะ 3–5 คำ ผู้วัดรายงานกินราว 16% และยังปิดแบบทางการไม่ได้
รายงานอิสระพบว่าฟีเจอร์ agent_summary ของ Claude Code ส่ง transcript เต็มของ background agent ไปถามสถานะทุก ~30 วินาที คิดเป็น 16.4% ของค่าใช้จ่ายในระบบของผู้วัด Issue เปิดมาตั้งแต่ ส.ค. ยังไม่มีสวิตช์ปิดที่รองรับ เราตรวจพบโค้ดนี้ใน 2.1.314 และพบกฎใหม่เรื่องเกมที่ไม่อยู่ใน changelog