BITCOS ทุบกำแพง 1.58 บิตของโมเดล ternary — พบว่าน้ำหนักเป็นศูนย์ถึง 51.5% เลยบีบเหลือ 1.485 บิตต่อน้ำหนัก และ decode เร็วขึ้นถึง 1.27 เท่า

มีเพดานหนึ่งที่วงการ quantization ยอมรับกันมานานว่าข้ามไม่ได้ — โมเดล ternary ที่เก็บน้ำหนักทุกตัวเป็นหนึ่งในสามสัญลักษณ์ {-1, 0, +1} มีต้นทุนขั้นต่ำเชิงทฤษฎีสารสนเทศที่ log₂3 ≈ 1.585 บิตต่อน้ำหนัก และรูปแบบที่ใช้จริงในการ deploy คือการอัดห้า trit ลงในหนึ่งไบต์ ซึ่งเมื่อบวกข้อจำกัดเรื่องขนาดกลุ่มที่ต้องเป็นกำลังสอง จะปัดขึ้นเป็น 1.625 บิตต่อน้ำหนัก

เปเปอร์ “Breaking the 1.58-bit Barrier for Ternary LLMs” โดย Evangelos Georganas, Alexander Heinecke และ Pradeep Dubey ที่ขึ้น arXiv เมื่อ 14 ก.ย. 2026 ชี้ให้เห็นสมมติฐานที่ซ่อนอยู่ในเลข 1.585 นั้น: มันคิดบนสมมติว่าสัญลักษณ์ทั้งสามมีโอกาสเกิดเท่ากัน ซึ่งในโมเดลจริง ไม่จริงเลย

ข้อค้นพบง่าย ๆ ที่ไม่มีใครไปวัด

ทีมวิจัยไปวัดการกระจายสัญลักษณ์จริงของ โมเดล ternary 29 ตัว ที่มีอยู่ในโลก แล้วพบว่าสัดส่วนของน้ำหนักที่เป็นศูนย์สูงมาก และสูงมากแบบไม่สม่ำเสมอ:

โมเดล	สัดส่วนศูนย์ (z)	BITCOS (บิต/น้ำหนัก)
CAT-Q Qwen3-1.7B	51.48%	1.485
CAT-Q Qwen3-32B	47.11%	1.529
ParetoQ 1.5B	47.10%	1.529
BitNet b1.58 2B4T	42.19%	1.578
Bonsai 1.7B	39.89%	1.601
CAT-Q Qwen3-30B-A3B	32.88%	1.671
Bonsai 27B	29.66%	1.703

จากข้อค้นพบนี้ พวกเขาเสนอ BITCOS ซึ่งเรียบง่ายอย่างน่าอาย: เก็บ bitmap แบบ dense ที่บอกว่าน้ำหนักตัวไหนไม่เป็นศูนย์ (1 บิตต่อน้ำหนัก) แล้วตามด้วย sign vector แบบอัดแน่น ที่เก็บเครื่องหมายของเฉพาะตัวที่ไม่เป็นศูนย์ ต้นทุนรวมจึงเป็น 2 − z บิตต่อน้ำหนัก เมื่อ z คือสัดส่วนศูนย์ — ยิ่งโมเดลมีศูนย์เยอะ ยิ่งประหยัด

ผลคือ BITCOS เก็บโมเดลได้กะทัดรัดกว่าการแพ็กแบบ five-trit ใน 26 จาก 29 โมเดล และลงไปแตะ 1.485 บิตต่อน้ำหนัก ในตัวที่เบาบางที่สุด ซึ่งต่ำกว่าเพดานทฤษฎี 1.585 ที่ทุกคนอ้างถึงมาตลอด

สามตัวที่แพ้ก็ควรพูดถึง — Bonsai 27B (0.96×), CAT-Q Qwen3-30B-A3B (0.97×) และ CAT-Q Qwen3-235B-A22B (0.98×) ล้วนเป็นโมเดลที่สัดส่วนศูนย์ต่ำกว่า 35% เมื่อ z ต่ำ สูตร 2−z จะแพ้ 1.625 ของ five-trit ตรง ๆ (คิดจากสูตรเอง เส้นแบ่งเฉพาะส่วนโค้ดอยู่ที่ z = 0.375)

และต้องอ่านตารางให้ครบ: ตัวเลข 1.485 เป็นการนับ เฉพาะโค้ด ternary เมื่อรวม scale แบบ 16 บิตที่วัดได้จริงเข้าไปด้วย CAT-Q Qwen3-1.7B จะอยู่ที่ 1.610 บิต เทียบกับ 1.750 ของ five-trit — ยังชนะ (1.09×) แต่ไม่ใช่ตัวเลขพาดหัว

ความเร็วจริง ไม่ใช่แค่ขนาดไฟล์

รูปแบบที่กินพื้นที่น้อยกว่าไม่ได้แปลว่าเร็วกว่าเสมอไป เพราะการคลายแพ็กอาจแพงขึ้น ทีมจึงเขียน unpacking sequence ที่ปรับแต่งสำหรับ AVX-512, AVX2 และ Intel Xe2 GPU แล้ววัดผลจริงผ่านทั้ง vLLM CPU/XPU backend และ fork llama.cpp ของ Prism ML

ผลลัพธ์แบบ end-to-end (decode ของคำขอเดียว 256 โทเคนออก) วัดบน 7 โมเดล:

• บน CPU: BITCOS ชนะเคอร์เนล 2-bit ระดับ SOTA ที่ 1.10–1.18× บน Xeon Platinum 8592+ (64 คอร์) และ 1.02–1.15× บน Core Ultra 9 285K เมื่อเทียบกับรูปแบบ five-trit TQ1_0 ของ llama.cpp ช่องว่างกว้างขึ้นเป็น 1.13–1.48× และ 1.46–1.74× ตามลำดับ
• บน GPU: ดีขึ้น 1.09–1.22× บน Arc 140V (iGPU) และ 1.02–1.27× บน Arc Pro B70 (dGPU) และเมื่อเทียบกับ Q2_0 บน Vulkan ของ llama.cpp ตัวเลขพุ่งเป็น 1.61–2.30× บน Arc Pro B70

แต่จุดที่ทำให้เปเปอร์นี้น่าเชื่อถือคือ มันรายงานเคสที่ตัวเองแพ้ — บน Core Ultra 7 258V (Lunar Lake) ซึ่งเป็นแพลตฟอร์มที่ติดคอขวดที่คำสั่ง ไม่ใช่ที่แบนด์วิดท์หน่วยความจำ BITCOS ไม่ให้ประโยชน์ใด ๆ เลย และเคอร์เนล 2-bit เดิมทำได้ดีกว่า ทีมวิเคราะห์ด้วย roofline model ล่วงหน้าแล้วว่าจะเป็นแบบนี้: การลดขนาด payload ช่วยเฉพาะเมื่อระบบติดหน่วยความจำ ถ้าติดที่คำสั่ง การคลายแพ็กที่แพงขึ้นจะกินกำไรทิ้งหมด

ข้อสังเกตเสริมที่มีค่ากับคนใช้ local runner: เปเปอร์วัดพบว่ารูปแบบ TQ1_0 (five-trit) ของ llama.cpp เร็วกว่า Q2_0 บนเครื่องไคลเอนต์ถึง 1.66–1.68× บน Arrow Lake และ 1.91–2.44× บน Lunar Lake แต่บนเซิร์ฟเวอร์สองรูปแบบต่างกันไม่ถึง 4% — และเคอร์เนล 2-bit ระดับ SOTA แม้จะขน data มากกว่า กลับเร็วกว่า TQ1_0 ของ llama.cpp ได้ถึง 1.78× ซึ่งบอกว่าคุณภาพของเคอร์เนลสำคัญกว่าจำนวนบิตบนกระดาษ

ข้อจำกัดที่ต้องระบุให้ชัด

หนึ่ง — ไม่มีการปล่อยโค้ด เปเปอร์อ้างอิงถึง libxsmm, llama.cpp ของ ggml-org และ fork ของ Prism ML แต่ไม่ได้ระบุ repo ของ BITCOS เอง ใครอยากใช้ต้องเขียนเองจากคำอธิบาย

สอง — ทุกแพลตฟอร์มที่วัดคือ Intel ทั้งหมด ทั้ง Xeon, Core Ultra, Arc 140V และ Arc Pro B70 ไม่มี NVIDIA, AMD หรือ Apple Silicon ในตารางเลย และเนื่องจากผลลัพธ์ขึ้นกับว่าแพลตฟอร์มติดหน่วยความจำหรือติดคำสั่ง การเอาไปคาดการณ์บน Apple M-series หรือ RTX จึงยังทำไม่ได้ — โดยเฉพาะ Apple Silicon ที่มี unified memory แบนด์วิดท์สูง ซึ่งอาจตกในโซนที่ BITCOS ไม่ช่วยเหมือน Lunar Lake

สาม — นี่เป็นงานด้านเลย์เอาต์และเคอร์เนล ไม่ใช่ด้านคุณภาพโมเดล BITCOS ไม่เปลี่ยนค่าน้ำหนักใด ๆ เป็น lossless ต่อโมเดลที่ถูก quantize มาแล้ว เปเปอร์จึงไม่มีตัวเลข perplexity หรือ benchmark ความแม่นยำ และไม่จำเป็นต้องมี

สี่ — ยังเป็น preprint ยังไม่ผ่าน peer review และไม่มีหมายเหตุระบุว่าจะส่งไปงานประชุมใด

มุมมอง AI Curator

สิ่งที่ผมชอบเป็นพิเศษในงานนี้คือมันเป็นตัวอย่างชั้นดีของ การตั้งคำถามกับสมมติฐานที่ไม่มีใครตรวจ ตัวเลข log₂3 = 1.585 ถูกอ้างซ้ำในเปเปอร์ ternary แทบทุกฉบับมาหลายปี ราวกับเป็นกฎธรรมชาติ ทั้งที่มันเป็นเพียงขอบเขตของกรณีที่สัญลักษณ์กระจายเท่ากัน — ซึ่งไม่มีโมเดลจริงตัวไหนเป็นแบบนั้น ไม่มีใครต้องใช้คณิตศาสตร์ระดับสูงเพื่อค้นพบเรื่องนี้ แค่ต้องมีคนยอมโหลด weight ของโมเดล 29 ตัวมานับศูนย์ นี่เป็นงานวิจัยประเภทที่ทีมเล็กทำได้ และเป็นประเภทที่ทีมไทยควรมองหา

ในทางปฏิบัติ ผลกระทบต่อคนไทยที่รันโมเดลบนเครื่องตัวเองนั้นยัง อ้อม อยู่พอสมควร โมเดล ternary ยังเป็นตลาดเฉพาะ — BitNet, Bonsai, TriLM, ParetoQ, CAT-Q ไม่ใช่ชื่อที่คนส่วนใหญ่รันจริงบน Ollama หรือ LM Studio ซึ่งยังเป็นโลกของ Q4_K_M เสียมากกว่า ประโยชน์ที่จับต้องได้จะมาก็ต่อเมื่อ llama.cpp upstream รับแนวคิดนี้เข้าไป และเนื่องจากทีมไม่ได้ปล่อยโค้ด เส้นทางนั้นจะไม่สั้น

แต่ทิศทางที่เปเปอร์นี้ชี้ให้เห็นสำคัญกว่าตัวเลข 1.485 — การประหยัดรอบต่อไปของ local inference จะไม่ได้มาจากการลดจำนวนบิต แต่จะมาจากการทำให้เลย์เอาต์เข้ากับสถิติจริงของน้ำหนัก ในบริบทไทยที่ฮาร์ดแวร์เป็นข้อจำกัดหลัก และคนจำนวนมากรันโมเดลบนโน้ตบุ๊กหรือ GPU ระดับผู้บริโภค ทุกเปอร์เซ็นต์ของแบนด์วิดท์หน่วยความจำที่ประหยัดได้แปลเป็นโทเคนต่อวินาทีที่รู้สึกได้จริง

บทเรียนสุดท้ายที่ควรจำคือตารางที่แสดงว่า Lunar Lake ไม่ได้ประโยชน์เลย: “บีบให้เล็กลง” ไม่ได้แปลว่า “เร็วขึ้น” เสมอไป ก่อนจะลงแรงกับ quantization ที่ก้าวร้าวขึ้น ควรวัดก่อนว่าเครื่องของคุณติดที่แบนด์วิดท์หน่วยความจำหรือติดที่ความเร็วในการคลายแพ็ก — คำตอบนั้นกำหนดว่างานทั้งหมดจะคุ้มหรือเสียเปล่า

แหล่งข่าว

• Breaking the 1.58-bit Barrier for Ternary LLMs — arXiv:2609.16338, 14 ก.ย. 2026
• ไฟล์ PDF ฉบับเต็ม (12 หน้า)
• การอภิปรายบน Hacker News (16 ก.ย. 2026)
• llama.cpp — ggml-org (รูปแบบ TQ1_0 ที่ถูกนำมาเทียบ)