18 ก.ย. 2026 บริษัท PrismML ปล่อย Ternary Bonsai 2 27B โมเดลที่บีบน้ำหนักทุกตัวให้เหลือแค่ 3 ค่า (−1, 0, +1) จนไฟล์เหลือ 5.95 GB จากปกติ 54 GB พร้อมคำอ้างว่ายังทำคะแนนได้ 98.2% ของโมเดลต้นฉบับ ที่สำคัญคือมันสร้างจาก Qwen3.8-27B ตัวเดียวกับที่อยู่ในสินค้าของเรา เราจึงเอามาลองบน DGX Spark ทันที: วัดคุณภาพภาษาไทยด้วยชุดทดสอบของเราเอง และวัดความเร็วตอบจริงผ่าน API เทียบกับไฟล์ที่ลูกค้าใช้อยู่ ผลคือ เร็วจริง แต่ภาษาไทยพัง และเหตุผลที่พังนั้นน่าสนใจกว่าตัวเลขเสียอีก
ตอนที่ 1: ทำไมข่าวนี้ถึงน่าสนใจ
โมเดลภาษาขนาด 27B พารามิเตอร์ ถ้าเก็บแบบ 16 บิตต่อตัว จะใช้พื้นที่ราว 54 GB ปกติเราจึง “บีบอัด” (quantization) ลงมา สินค้าของเราใช้ Qwen3.8-27B สองแบบ:
| ไฟล์ | บิตต่อน้ำหนัก | ขนาด | จุดยืน |
|---|---|---|---|
| UD-Q4_K_XL | ~4.5 | 21 GB | คุณภาพสูงสุดที่คุ้ม |
| UD-Q2_K_XL | ~2.5 | 13 GB | เร็วสุดที่ยังใช้งานไทยได้ |
Bonsai 2 ไปไกลกว่านั้น: 1.75 บิตต่อน้ำหนัก ไฟล์ 5.95 GB ถ้าคุณภาพไม่ตก แปลว่าเครื่องเดียวโหลดโมเดลได้เยอะขึ้น 3 เท่า ตอบเร็วขึ้นเพราะอ่านหน่วยความจำน้อยลง และเครื่องที่แรมน้อยก็รันโมเดล 27B ได้
เทคนิคที่ใช้ต่างจาก UD ของเราโดยสิ้นเชิง:
- UD-Q2/Q4 = PTQ (Post-Training Quantization) เอาโมเดลที่เทรนเสร็จมาปัดเศษน้ำหนัก แล้วใช้ข้อมูลปรับเทียบ (calibration) เล็กน้อยช่วยเลือกว่าจะปัดชั้นไหนหยาบชั้นไหนละเอียด ไม่มีการเทรนซ้ำ
- Bonsai = QAT (Quantization-Aware Training) เทรนโมเดลต่ออีกรอบโดยบังคับให้น้ำหนักเป็น 3 ค่าตั้งแต่ตอนเทรน โมเดลจึง “เรียนรู้ที่จะอยู่กับข้อจำกัด” เอง
QAT ควรจะให้คุณภาพดีกว่า PTQ ที่บิตเท่ากันมาก และตัวเลข 98.2% ที่ PrismML อ้าง (เฉลี่ยจาก 14 benchmark) ก็สนับสนุนเรื่องนี้ แต่ benchmark ทั้ง 14 นั้นเป็นภาษาอังกฤษกับโค้ด ไม่มีภาษาไทยเลย และนี่คือคำถามที่เราอยากรู้คำตอบ
ตอนที่ 2: เราทดสอบยังไง
ทดสอบบน DGX Spark เครื่องเดียวกับที่ส่งลูกค้า (GB10, หน่วยความจำรวม 128 GB) ทั้งหมดทำในโฟลเดอร์แล็บ แยกจากระบบสินค้า
1. รันให้ได้ก่อน Bonsai ใช้รูปแบบไฟล์ GGUF แต่ชนิดข้อมูล ternary ใหม่ llama.cpp ตัวปกติปฏิเสธไฟล์ ต้องใช้ fork ของ PrismML (branch prism) เราคอมไพล์บน aarch64 + CUDA 13 ของ Spark ผ่านรอบเดียวใน 25 นาที ไม่ต้องแก้อะไร ถือว่าเรียบร้อยดี
2. วัดคุณภาพภาษาไทย ใช้ ThaiEval v3 ชุดทดสอบไทย 170 ข้อ 7 หมวดของเราเอง (ภาษา, ร้อยแก้ว, งานยาว, ความรู้ไทย, เหตุผล, ทำตามคำสั่ง, ความปลอดภัย) ให้ Claude Sonnet 5 เป็นกรรมการ ปิดโหมด thinking ทุกโมเดลเพื่อความยุติธรรม เทียบกับ UD-Q2 และ UD-Q4 ของเราที่วัดด้วยชุดเดียวกัน
3. วัดความเร็วอย่างที่ผู้ใช้รู้สึก ไม่ใช้ตัวเลขจาก llama-bench อย่างเดียว แต่ยิงผ่าน API แบบ streaming เหมือนแอปจริง วัดสองอย่าง: – TTFT (time to first token) รอนานแค่ไหนกว่าตัวอักษรแรกจะโผล่ ทดสอบทั้ง prompt สั้น 37 token และ prompt ยาว 2,124 token – decode tok/s พิมพ์ต่อเนื่องได้เร็วแค่ไหน
ทำกับ Bonsai 2 ตัว (PTQ1_0 และ PQ2_0 ซึ่งเป็นรุ่นละเอียดกว่าเล็กน้อย 7.2 GB) และไฟล์สินค้าของเรา UD-Q2/UD-Q4 ทั้งแบบเปล่าและแบบเปิด MTP (speculative decoding ที่ลูกค้าเปิดใช้อยู่)
ตอนที่ 3: ผลด้านคุณภาพ — ไทยตกไป 16 จุด
| หมวด | Bonsai 2 PTQ1_0 (1.75 บิต) | UD-Q2 (2.5 บิต) | UD-Q4 (4.5 บิต) |
|---|---|---|---|
| ภาษาไทย (LANG) | 0.58 | 0.78 | 0.79 |
| ร้อยแก้ว/สำนวน (PROS) | 0.12 | 0.30 | 0.43 |
| งานยาว (LONG) | 0.96 | 1.00 | 0.88 |
| ความรู้ไทย (KNOW) | 0.28 | 0.64 | 0.78 |
| เหตุผล (REAS) | 0.99 | 1.00 | 1.00 |
| ทำตามคำสั่ง (INST) | 0.88 | 0.97 | 0.98 |
| ความปลอดภัย (SAFE) | 0.93 | 0.99 | 0.98 |
| รวม | 0.709 | 0.840 | 0.869 |
ดูเป็นรายหมวดแล้วภาพชัดมาก: การใช้เหตุผล ทำตามคำสั่ง และงานยาวแทบไม่เสียหาย (ความสามารถพวกนี้ QAT รักษาไว้ได้ตามที่ PrismML อ้าง) แต่ ความรู้เกี่ยวกับไทยหายไปเกือบสองในสาม และการเขียนร้อยแก้วไทยพังเกือบหมด ในคำตอบมี token ภาษาจีนโผล่กลางประโยค (เช่น “权重” แทนคำว่าน้ำหนัก) และคำไทยที่สะกดเพี้ยน
ที่น่าคิดคือ UD-Q2 ของเราซึ่งเป็น PTQ ธรรมดาที่ 2.5 บิต ยังได้ 0.840 นำ Bonsai อยู่ 13 จุด ทั้งที่ทฤษฎีบอกว่า QAT ควรชนะ PTQ และรูปแบบการตกก็เหมือนกัน (PROS 0.30, KNOW 0.64 ตกจาก UD-Q4 เช่นกัน) แค่ Bonsai ตกแรงกว่ามาก
ตอนที่ 4: ผลด้านความเร็ว — decode เร็วจริง แต่ prefill ช้ากว่า
| โมเดล | ขนาด | TTFT prompt 2K | decode tok/s |
|---|---|---|---|
| Bonsai 2 PTQ1_0 (fork) | 5.95 GB | 4.83 s | 34.1 |
| Bonsai 2 PQ2_0 (fork) | 7.21 GB | 2.22 s | 29.2 |
| UD-Q2 | 13 GB | 2.74 s | 19.4 |
| UD-Q2 + MTP (ที่ลูกค้าใช้) | 13 GB | 2.86 s | 29–31 |
| UD-Q4 | 21 GB | 2.79 s | 11.4 |
| UD-Q4 + MTP | 21 GB | 2.96 s | 19–22 |
ภาษาไทย, ปิด thinking, ค่ามัธยฐาน 3 รอบ, ปิด prefix cache
อ่านผล:
- ความเร็วพิมพ์ (decode) ของ Bonsai ชนะ UD-Q2 เปล่า 1.75 เท่า สมเหตุสมผล เพราะ decode ถูกจำกัดด้วยแบนด์วิดท์หน่วยความจำ ไฟล์เล็กกว่าครึ่งก็อ่านเร็วกว่าครึ่ง
- แต่ลูกค้าของเราไม่ได้ใช้ UD-Q2 เปล่า เราเปิด MTP ให้ ซึ่งดัน UD-Q2 ไป 29–31 tok/s เท่ากับ Bonsai พอดี โดยไม่เสียคุณภาพ (Bonsai 2 ยังไม่มี MTP)
- prefill ของ Bonsai PTQ1_0 ช้าที่สุดในตาราง prompt 2,000 token ต้องรอ 4.8 วินาทีกว่าจะเริ่มตอบ เทียบกับ 2.7 ของ UD-Q2 เพราะ kernel คูณเมทริกซ์แบบ ternary ใน fork ยังไม่ถูก optimize สำหรับงาน batch ใหญ่ (รุ่น PQ2_0 ที่ใช้ kernel คนละแบบทำได้ 2.2 วินาที) งานสรุปเอกสาร/RAG ที่ prompt ยาวจะรู้สึกช้ากว่าเดิม
สรุปเชิงความเร็ว: ไม่มีเหตุผลให้สลับ
ตอนที่ 5: ทำไมภาษาไทยถึงพัง ทั้งที่ QAT ควรจะดีกว่า
นี่คือส่วนที่เราคิดว่ามีค่าที่สุดของการทดสอบ
ตอนบีบโมเดลไม่ว่าจะด้วย PTQ หรือ QAT เราต้อง “เลือกว่าจะรักษาอะไร” เพราะบิตมีไม่พอเก็บทุกอย่าง PTQ เลือกผ่านข้อมูล calibration (โมเดลถูกป้อนข้อความตัวอย่าง แล้วดูว่าน้ำหนักตัวไหนสำคัญ) ส่วน QAT เลือกผ่าน ข้อมูลที่ใช้เทรนซ้ำ: น้ำหนักที่ช่วยทำนายข้อมูลชุดนั้นจะถูกรักษา น้ำหนักที่ไม่ได้ช่วยจะถูกปัดทิ้งโดยไม่มีใครรู้
เมื่อข้อมูลเทรนซ้ำเป็นอังกฤษกับโค้ดล้วน ความรู้ไทยที่ฝังอยู่ในน้ำหนัก (ชื่อสถานที่ ประวัติศาสตร์ สำนวน วิธีสะกด) จึงเป็นสิ่งแรกที่ถูกทิ้ง ขณะที่ ความสามารถทั่วไปที่ไม่ผูกกับภาษา อย่างการให้เหตุผลหรือทำตามโครงสร้างคำสั่ง ยังอยู่ครบ นี่คือเหตุผลที่คะแนน REAS/INST ดี แต่ KNOW/PROS พัง และมันตรงกับที่เราเคยพิสูจน์กับ UD ของ Unsloth มาแล้ว ว่าชุด calibration ของเขามีไทย 0% (ดูบทความเรื่อง imatrix ก่อนหน้า)
ที่ QAT “หนักกว่า” PTQ ในเรื่องนี้ก็เพราะมันปัดได้ก้าวร้าวกว่า (1.75 บิต) และ การเทรนซ้ำจะดันโมเดลไปหาข้อมูลที่เห็น อย่างจริงจังกว่าการปัดเศษเฉยๆ อาการ token จีนหลุดก็สอดคล้อง: เมื่อความรู้ไทยจางลง โมเดล Qwen จะถอยกลับไปหาภาษาที่มันมั่นใจกว่า
บทเรียนคือประโยคเดียวที่เราพูดซ้ำมาตลอดปี: “base ต้องมีพื้นไทย” ไม่ว่าจะเทรน กลั่น หรือบีบ ถ้าขั้นตอนนั้นไม่เห็นข้อมูลไทย ผลลัพธ์จะเสียไทยก่อนสิ่งอื่นเสมอ
ตอนที่ 6: แล้วเราจะทำอะไรกับมัน
- ไม่เข้าสินค้า ทั้งเรื่องคุณภาพและความเร็วรวม (prefill) ยังไม่ชนะของเดิม และต้องใช้ llama.cpp คนละสาย
- เข้าคอร์ส Quantization เป็นกรณีศึกษาชั้นดี: QAT ternary ทำอะไรได้ (27B ในไฟล์ 6 GB วิ่ง 34 tok/s บนเครื่องเดียว) และล้มเหลวตรงไหนเมื่อภาษาเป้าหมายไม่อยู่ในข้อมูลเทรน พร้อมตัวเลขจริงจากเครื่องจริง
- ถ้า PrismML เปิดวิธี QAT ของเขา คำถามถัดไปที่น่าลองคือ: เอา Qwen3.8-27B มาทำ ternary QAT ด้วยข้อมูลผสมไทย 20–30% แล้ววัดใหม่ ถ้า KNOW/PROS กลับมาระดับ UD-Q2 ที่ขนาดไฟล์ครึ่งเดียว นั่นจะเป็นเรื่องใหญ่สำหรับ Spark และเครื่องเล็ก
- เทคนิค ที่ได้มาระหว่างทาง: สคริปต์วัด TTFT/decode ผ่าน API ที่ใช้ได้กับทุก engine และบทเรียนว่าต้องปิด prefix cache ก่อนวัด TTFT ไม่งั้น prompt ยาว 2K จะโชว์ 0.15 วินาทีหลอกตา (รอบแรกเราโดนมาแล้ว)
สรุปประโยคเดียว: Bonsai 2 พิสูจน์ว่า ternary QAT เป็นของจริงในแง่ขนาดและความเร็ว แต่ก็พิสูจน์อีกครั้งว่าโมเดลจะเก่งภาษาไหน ขึ้นกับว่าขั้นตอนสุดท้ายที่แตะน้ำหนักได้เห็นภาษานั้นหรือเปล่า
รายละเอียดการทดสอบ ไฟล์ผล และสคริปต์ทั้งหมดอยู่ในแล็บของเรา ทดสอบวันที่ 19–20 ก.ย. 2026 บน DGX Spark GB10 · โมเดล: prism-ml/Ternary-Bonsai-2-27B (Apache 2.0) · ชุดทดสอบ ThaiEval-2026 v3 (170 ข้อ, กรรมการ Claude Sonnet 5, ปิด thinking)