Betelgeuse รัน Qwen3.8 Flash Next ขนาด 68GB บน RTX 3060 กับแรม 16GB ส่วน Basalt วัดให้เห็นว่าเอนจินที่เร่งด้วยแฟล็กลัดทำให้โมเดลลืมของ

เมื่อ 31 ต.ค. 2026 ชุมชน local LLM ได้ของสองชิ้นที่ควรอ่านคู่กัน ชิ้นแรกคือ Betelgeuse ฟอร์ก llama.cpp ใบอนุญาต MIT ที่ตั้งเป้ารัน Qwen3.8-Flash-Next แพ็กขนาดราว 68GB บน RTX 3060 12GB กับแรม 16GB โดยอ้างว่าไม่ทิ้ง expert แม้แต่ตัวเดียวและผลลัพธ์ตรงกับ llama.cpp ทุกไบต์ ชิ้นที่สองคือผลทดลองจากผู้พัฒนาเอนจิน Basalt ที่วัดราคาของแฟล็กเร่งความเร็วแบบที่เอนจินอื่นใช้เป็นค่าเริ่มต้น

สองงานตอบคำถามเดียวกันจากคนละด้าน: ความเร็วบนการ์ดเล็กมาจากวิศวกรรมจริง หรือมาจากการแอบรันโมเดลที่ไม่ใช่ตัวที่คุณดาวน์โหลดมา

Betelgeuse ทำอะไร

แนวคิดคือแยกส่วน dense ออกจาก expert ไฟล์ dense ขนาดราว 3.77GB อยู่บน GPU ส่วน experts.bin ขนาด 35.48GB เก็บไบต์เดิมที่ไม่ถูกตัดหรือ requantize ไว้บน NVMe แล้วดึง expert ที่ router เลือกจริงเข้า slot ใน VRAM ที่มีจำนวนจำกัด expert ที่ถูกไล่ออกจะพักในแรมเป็น victim cache ก่อน และส่วนที่พลาดจึงอ่านจาก NVMe ด้วย io_uring ยังต้องใช้ไฟล์ PLE อีก 26.82GiB ชุดเต็มจึงกินพื้นที่ราว 68GB

โมเดลที่ทดสอบมี 48 เลเยอร์ เลเยอร์ละ 512 expert และ route ทีละ 10 ตัว แนวทางเดียวกันถูกเสนอเข้า llama.cpp ใน PR #31469 ซึ่งเปิดเมื่อ 31 ต.ค. ในฐานะ RFC ใช้แฟล็กที่ค่าเริ่มต้นปิด และยังไม่ถูก merge

ตัวเลขใน README เบากว่าคำโฆษณา

พาดหัวในชุมชนคือ 22 tok/s แต่ README เองเขียนไว้ระมัดระวังกว่ามาก จึงควรยึด README เป็นหลัก

ตัวเลข	tok/s	README บอกว่า
llama.cpp ต้นทาง	0.9	ผู้ใช้รายงาน ไม่ใช่ benchmark ควบคุม
Strata	8	ผู้ใช้รายงาน ไม่ใช่ benchmark ควบคุม
Betelgeuse คำขอแรก	16.80	จ่ายค่า warmup ตอนเริ่มแยกไปแล้ว
Betelgeuse คำขอซ้ำ	22.03	คนละรอบวัด งานซ้ำเดิม

README ย้ำว่า 16.80 กับ 22.03 ไม่ใช่ benchmark จับคู่ ตัวเลขเหล่านี้เก่ากว่า bundle ปัจจุบัน และไม่รับรองประสิทธิภาพของมัน นอกจากนี้ยังติดป้ายตัวหนาว่า “Experimental and partly broken” และรองรับเฉพาะ Linux x86-64 CUDA sm_86 RTX 3060 12GB กับ NVMe ภายในเครื่อง ตัวเลข baseline ก็ไม่ตรงกับที่ผู้พัฒนาโพสต์ในชุมชนซึ่งระบุ 1.47 และ 8.11 tok/s

ผู้พัฒนายังรายงานเพิ่มว่าแพ็ก IQ4_XS ทำได้ 24 tok/s บนแรม dual-channel และ 14 tok/s บน single-channel แต่ตัวเลขชุดนี้ยังไม่มีใครวัดซ้ำเป็นอิสระ ส่วน Hugging Face repo ของ bundle ระบุใบอนุญาตเป็น other ตามโมเดลต้นทาง จึงต้องอ่านเงื่อนไขก่อนนำไปใช้เชิงพาณิชย์

Basalt วัดราคาของแฟล็กเร่งความเร็ว

ผู้พัฒนา Basalt ซึ่งมีส่วนได้เสียในฐานะคนทำเอนจินคู่แข่ง และระบุเองว่าใช้ AI ขัดเกลาโพสต์ ทดสอบแฟล็กสองตัว ได้แก่ routing bias ที่ดันโมเดลไปหา expert ที่อยู่บน GPU อยู่แล้ว และ tail skip ที่ข้าม expert อันดับท้ายที่ไม่อยู่บน GPU ค่าที่ทดสอบคือ bias 1.5 กับ skip rank ≥ 7 ซึ่งผู้วัดระบุว่าเป็นค่าที่เอนจินอื่นเคยใช้เป็นค่าเริ่มต้นบนการ์ดเล็ก โดยไม่ได้ระบุชื่อเอนจิน

แพ็ก	KLD เฉลี่ย	ตรงกับ top-1 ของอ้างอิง
Q8_0 แบบตรงตัว	0.031	94.1%
NVFP4 แบบตรงตัว	0.068	91.4%
Q8_0 + แฟล็ก	0.401	79.4%
Q2_0 แบบตรงตัว	0.436	78.2%

สรุปคือ Q8 ขนาด 178GiB ที่เปิดแฟล็กมีคุณภาพเข้าไปใกล้ Q2 ขนาด 65GiB ในงานทดสอบจริงบนการ์ดใหญ่แทบไม่ได้ความเร็วเพิ่ม (272 เป็น 271 tok/s) แต่เสียราว 1.5 คะแนน บนการ์ดที่จำกัด VRAM 16GB ได้ความเร็วเพิ่ม 56% แต่คะแนนงานต่อเนื่องหลายขั้นตก 5.2 และคะแนนความรู้ตก 2.3 ความเสียหายอยู่ที่การให้เหตุผลหลายขั้นและการจำข้อเท็จจริง ซึ่งเป็นงานที่ทดสอบง่าย ๆ มองไม่เห็น

มุมมอง AI Curator

ปีนี้ตัวเลข tok/s ของ MoE บนการ์ดเล็กเริ่มเชื่อถือยากขึ้น เพราะมีทางลัดหลายแบบที่ทำให้ตัวเลขสวยโดยผลลัพธ์เปลี่ยน ที่น่าชื่นชมคือผู้พัฒนา Betelgeuse ยอมรับว่าโปรโตไทป์รุ่นก่อนใช้การตัด expert เพื่อให้ตัวเลขสูงแล้วทิ้งไป และครั้งนี้ตั้งเป้าที่ผลลัพธ์ตรงทุกไบต์แทน นี่ควรเป็นมาตรฐานใหม่ของเอนจิน local ทุกตัว: ประกาศ tok/s พร้อมผลเทียบกับเอนจินอ้างอิงเสมอ

สำหรับนักพัฒนาไทยที่ RTX 3060 12GB ยังเป็นการ์ดยอดนิยม นี่เป็นสัญญาณดีเรื่องทิศทางมากกว่าของที่ใช้ได้วันนี้ ถ้าจะลอง ให้ถือเป็นงานทดลอง เตรียมพื้นที่ NVMe ราว 68GB และวัดผลบนงานของตัวเองแทนการเชื่อตัวเลขในโพสต์ อีกข้อที่ใช้ได้ทันทีคือประโยคปิดท้ายของผู้วัด ถ้าเอนจินเร็วเกินกว่าที่ควรบนโมเดลที่ไม่พอดีการ์ด ให้เช็กก่อนว่ามันยังรันโมเดลที่คุณดาวน์โหลดมาอยู่ไหม

แหล่งข่าว

• Betelgeuse — GitHub
• llama.cpp PR #31469: out-of-core MoE expert streaming
• Alpha-Orionis-XS — Hugging Face
• Basalt — GitHub