โมเดล 3.5GB แทนที่ 35B Daily Driver ได้จริงไหม? (Bonsai 27B 1-Bit Deep Dive)
คลิปนี้ทดลองนำ Bonsai 27B จาก PrismML ซึ่งเป็นโมเดล Dense ขนาด 27 พันล้านพารามิเตอร์ที่ถูกเทรนแบบ Native 1-bit (-1/+1 ขนาด 3.5GB) และ Ternary 2-bit (-1/0/+1 ขนาด 7GB) ตั้งแต่วันแรก มาทดสอบชนกับ Daily Driver ตัวจริงคือ Qwen 3.6 35B MoE (21GB) และ Gemma 4 12B บนการ์ดจอ RTX 3060 12GB ใบเดียว ผลการทดสอบกว่า 30 รอบชี้ชัดว่า Ternary Q2_0 มีความฉลาดด้าน Logic เทียบเคียง MoE ได้อย่างน่าทึ่ง แต่ความเร็วในการ Gen โทเค็นของ MoE ยังเร็วกว่าเนื่องจากจำนวน Active Parameters ที่น้อยกว่า
การวิเคราะห์เจาะลึกเชิงเทคนิค (In-Depth Technical Analysis)
Native 1-Bit Training vs Post Quantization
โมเดลทั่วไปถูกเทรนด้วย FP16 หรือ BF16 แล้วนำมาบีบอัดเป็น 4-bit (Q4_K) หรือ 2-bit ทีหลัง ทำให้สูญเสียความแม่นยำ (Perplexity Degradation) อย่างรุนแรงเมื่อต่ำกว่า 3-bit
แต่ Bonsai 27B (PrismML) ใช้เทคนิค Trained-from-scratch 1-bit/2-bit โดยบังคับค่าน้ำหนักเป็น -1/+1 (Binary Q1_0) หรือ -1/0/+1 (Ternary Q2_0) ในกระบวนการ Forward/Backward Pass ทำให้ไม่มี Quantization Loss แฝง และคงความสามารถของโมเดลขนาด 27B ไว้อย่างสมบูรณ์ในขนาดไฟล์เพียง 3.5GB - 7.0GB
ทำไมโมเดล 21GB ถึงเร็วกว่า 7GB ถึง 2 เท่า?
หลายคนเข้าใจผิดว่า "ไฟล์เล็กกว่า = ประมวลผลเร็วกว่าเสมอ" แต่ผลการทดสอบแสดงว่า:
- Qwen 3.6 35B-A3B (MoE 21GB): 47.9 tokens/s
- Bonsai 27B Q1_0 (3.5GB): 34.7 tokens/s
- Bonsai 27B Q2_0 (7.0GB): 21.6 tokens/s
สาเหตุเพราะ MoE (Mixture of Experts) มีพารามิเตอร์รวม 35B แต่เปิดทำงานจริงเพียง 3B Active Parameters (A3B) ต่อโทเค็น ทำให้การคำนวณ FLOPS น้อยกว่า Dense 27B ที่ต้องคำนวณครบทุกเลเยอร์
The Number Nobody Quotes: Total Footprint
สเปกชีตทั่วไปบอกเพียงขนาด Model Weight แต่ในการทำงานจริง Memory Footprint รวมประกอบด้วย:
Total Memory = Model Weights + KV Cache (q8_0) + CUDA Context + Scratch Buffer
ในการทดสอบ context ลึก: MoE กินรวม ~21.1GB (10.5GB VRAM + 10.6GB RAM offload), Ternary กินรวม 8.8GB VRAM (ใส่การ์ด 12GB สบาย), Binary กินรวม 5.3GB VRAM (รันบนการ์ด 6GB-8GB ได้แบบ 100% VRAM)
ผลการทดสอบ 3 ด่านหิน: Logic, Debugging, Coding
1. Web Design Test: Bonsai Ternary (Q2_0) และ Qwen 35B MoE ให้โค้ดระดับ Tier 1 ถูกต้องตามหลัก Semantic & CSS Grid ส่วน Binary Q1_0 และ Gemma 12B อยู่ระดับ Tier 2 มีข้อผิดพลาดเล็กน้อย
2. Server Trap Test: เมื่อเจอดักปัญหา Background daemon ที่แอบ spawn 프로세สหลังรีสตาร์ท Gemma 12B ติด Loop แก้ไม่หลุด แต่ Bonsai Q2_0 และ MoE สามารถไล่ trace pid จนเจอและแก้ได้เด็ดขาด
| พารามิเตอร์ / หัวข้อ | ค่าที่บันทึกได้ / รายละเอียด |
|---|---|
| Test GPU | Nvidia GeForce RTX 3060 (12GB VRAM) |
| Inference Engine | llama.cpp built from PR #25707 (CUDA Q2_0) |
| KV Cache Setting | q8_0 (8-bit Quantized KV Cache) |
| Reasoning Effort | Medium (Consistent across runs) |
| Server Task Wall Clock | MoE: 56s | Ternary: 114s | Binary: 134s |
- Bonsai 27B Ternary (7GB) ให้ความฉลาดระดับ Dense 27B แท้ๆ บนการ์ดจอ VRAM เพียง 8GB - 12GB
- Native 1-bit / 2-bit ลบข้อจำกัดเรื่อง Quantization Perplexity Loss ได้อย่างชัดเจน
- Binary Q1_0 (3.5GB) สามารถรัน Local AI ฉลาดๆ บนการ์ดราคาประหยัดหรือ Laptop VRAM 6GB ได้ทันที
- Dense Model 27B ต้องคำนวณพารามิเตอร์ครบทุกตัว ทำให้ความเร็ว (t/s) ช้ากว่า MoE ที่เป็น Sparse Routing
- Bonsai Binary Q1_0 ยังคงมี Degradation ในงานออกแบบและ Syntax โค้ดยากๆ เมื่อเทียบกับ Ternary Q2_0
- ต้องใช้ llama.cpp เวอร์ชันที่มี Patch รองรับ Q1_0 / Q2_0 CUDA Kernel ล่าสุด