Bonsai 27B - โมเดลระดับ 27B ที่รันได้บนโทรศัพท์มือถือ

 (prismml.com)
4 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • โมเดล 27B เดิมนั้นแม้จะลดเหลือ 4 บิตก็ยังมีขนาดถึง 18GB แต่ PrismML ได้ปรับ Bonsai 27B ซึ่งอิงกับ Qwen3.6 27B ให้พอดีกับข้อจำกัดหน่วยความจำของ iPhone พร้อมรองรับการอนุมาน การเรียกใช้เครื่องมือ วิชัน และการใช้งานคอมพิวเตอร์
  • โมเดล Ternary ที่เน้นคุณภาพมีขนาด 5.9GB ที่ 1.71 บิตต่อน้ำหนัก ส่วนโมเดล 1-bit ที่เน้นขนาดมีขนาด 3.9GB ที่ 1.125 บิต โดยใช้การแทนค่าแบบบิตต่ำกับเครือข่ายภาษาทั้งหมด
  • ใน 15 เบนช์มาร์กของโหมดคิด โมเดล Ternary รักษาสมรรถนะได้ 95% ของเวอร์ชันความละเอียดเต็ม และโมเดล 1-bit รักษาได้ 90% โดยมีคะแนนรวม 80.5 และ 76.1 ตามลำดับ
  • ทำความเร็วได้สูงสุด 163 tok/s บน NVIDIA GeForce RTX 5090 และสูงสุด 87 tok/s บน M5 Max พร้อมรองรับ บริบท 262K โทเค็น, vision tower แบบ 4 บิต และ speculative decoding
  • การรันแบบโลคัลช่วยตัดทั้งค่าใช้จ่าย API รายขั้นตอนและการส่งข้อมูลของงานเอเจนต์แบบวนซ้ำ อีกทั้งยังเปิดทางให้ทำ การดีพลอยแบบไฮบริด ที่ประมวลผลงานอ่อนไหวบนอุปกรณ์ และส่งเฉพาะขั้นตอนที่ยากไปยังคลาวด์

วิธีใส่โมเดลระดับ 27B ลงในโทรศัพท์มือถือ

  • โมเดล 27B แบบเดิมใช้พื้นที่ราว 54GB ที่ความละเอียด 16 บิต และแม้แต่บิลด์ 4 บิตทั่วไปก็ยังกินพื้นที่ 18GB ทำให้ดีพลอยแบบโลคัลบนโทรศัพท์และโน้ตบุ๊กส่วนใหญ่ได้ยาก
  • Bonsai 27B ที่อิงกับ Qwen3.6 27B รองรับการอนุมานหลายขั้นตอน การเรียกใช้เครื่องมือแบบมีโครงสร้าง งานวิชัน และ ลูปเอเจนต์ใช้งานคอมพิวเตอร์ ที่รักษาความสม่ำเสมอข้ามหลายขั้นตอนได้
  • การตั้งค่าบิตต่ำสองแบบนี้มุ่งเป้าไปที่สภาพแวดล้อมการดีพลอยที่ต่างกัน
    • Ternary Bonsai 27B ใช้น้ำหนัก {−1, 0, +1} และการสเกลรายกลุ่มแบบ FP16 เพื่อให้ได้ค่าจริง 1.71 บิตต่อน้ำหนัก และขนาด 5.9GB
    • มุ่งคุณภาพระดับโน้ตบุ๊ก พร้อมความสามารถด้านการอนุมาน การเรียกใช้เครื่องมือ และฟังก์ชันเอเจนต์แบบครบถ้วน
    • 1-bit Bonsai 27B ใช้น้ำหนัก {−1, +1} และการสเกลรายกลุ่มแบบเดียวกัน เพื่อให้ได้ค่าจริง 1.125 บิตต่อน้ำหนัก และขนาด 3.9GB
    • เน้นขนาดระดับมือถือที่อยู่ภายในงบหน่วยความจำของ iPhone 17 Pro

โครงสร้างบิตต่ำและมัลติโหมดแบบครบวงจร

  • การแทนค่าแบบบิตต่ำถูกใช้กับ เครือข่ายภาษาทั้งหมด รวมถึง embedding, attention, MLP และ LM head โดยไม่ข้ามบางส่วนไปใช้ความละเอียดสูงกว่า
  • ทั้งสองโมเดลเป็นมัลติโหมด และ vision tower มาในรูปแบบ 4 บิตแบบบีบอัด เพื่อให้ประมวลผลสกรีนช็อต เอกสาร และอินพุตจากกล้องได้บนอุปกรณ์
  • รองรับ บริบทสูงสุด 262K โทเค็น
  • รองรับ speculative decoding ซึ่งเป็นวิธีเร่งความเร็วแบบไม่สูญเสียข้อมูล โดยสร้างร่างคำตอบก่อนแล้วจึงตรวจสอบ
  • น้ำหนักโมเดลเผยแพร่ภายใต้ Apache 2.0 License

สมรรถนะที่ยังรักษาไว้ใน 15 เบนช์มาร์ก

  • มีการประเมิน 15 เบนช์มาร์กที่ครอบคลุมความรู้ การให้เหตุผล คณิตศาสตร์ โค้ดดิ้ง การทำตามคำสั่ง การเรียกใช้เครื่องมือ และวิชัน ใน โหมดคิด ที่ใช้ความสามารถในการอนุมานทั้งหมดของโมเดล
  • คะแนนรวมของ Qwen3.6 27B แบบความละเอียดเต็มอยู่ที่ 85.0 ขณะที่ Ternary Bonsai 27B ได้ 80.5 และ 1-bit Bonsai 27B ได้ 76.1
    • โมเดล Ternary รักษาสมรรถนะได้ 95% เมื่อเทียบกับเวอร์ชันความละเอียดเต็ม
    • โมเดล 1-bit รักษาสมรรถนะได้ 90% ของค่ามาตรฐาน
  • คะแนนรายด้านมีดังนี้
    • คณิตศาสตร์ — GSM8K, MATH-500, AIME25, AIME26: ความละเอียดเต็ม 95.3, Ternary 93.4, 1-bit 91.7
    • โค้ดดิ้ง — HumanEval+, MBPP+, LiveCodeBench: ความละเอียดเต็ม 88.7, Ternary 86.0, 1-bit 81.9
    • เอเจนต์·การเรียกใช้เครื่องมือ — BFCL v3, TauBench: ความละเอียดเต็ม 80.0, Ternary 74.0, 1-bit 66.0
    • การทำตามคำสั่ง — IFEval, IFBench: ความละเอียดเต็ม 78.4, Ternary 71.8, 1-bit 65.8
    • ความรู้·STEM — MMLU-Redux, MuSR: ความละเอียดเต็ม 83.1, Ternary 77.0, 1-bit 73.4
    • วิชัน — MMMU Pro, OCRBench: ความละเอียดเต็ม 72.6, Ternary 65.2, 1-bit 59.6
  • ด้านคณิตศาสตร์และโค้ดดิ้งมีการลดลงของสมรรถนะค่อนข้างน้อย และสมรรถนะการเรียกใช้เครื่องมือของโมเดล Ternary ก็ยังใกล้เคียงกับความละเอียดเต็ม
  • บิลด์บิตต่ำทั่วไปที่ลดทอนหนักที่สุดซึ่งใช้กับโมเดลฐานเดียวกัน ใช้หน่วยความจำมากกว่า 1-bit Bonsai 27B ถึง 2.5 เท่า แต่กลับได้คะแนนต่ำกว่า

ความหนาแน่นของสติปัญญาต่อกิกะไบต์

  • 1-bit Bonsai 27B มอบ สมรรถนะระดับ 27B ในขนาดที่เล็กกว่าโมเดล 2B แบบความละเอียดเต็ม
  • ตามเกณฑ์ความหนาแน่นของสติปัญญาที่ PrismML นำมาใช้กับ 1-bit Bonsai 8B, 1-bit Bonsai 27B ทำได้ 0.53 ต่อ GB
    • สูงกว่าค่ามาตรฐานแบบความละเอียดเต็มมากกว่า 10 เท่า
    • สูงกว่าทางเลือกบิตต่ำชั้นนำที่ใช้งานได้จริงราว 2.7 เท่า
  • ในการแบ่งประเภทนี้ ความสามารถสัมบูรณ์ของโมเดลเป็นตัวกำหนดว่างานใดทำได้บ้าง ส่วน ความหนาแน่นของสติปัญญา เป็นตัวกำหนดว่าอุปกรณ์และสภาพแวดล้อมแบบใดจะสามารถรันงานนั้นได้

ย้ายงานเอเจนต์แบบต่อเนื่องมารันแบบโลคัล

  • งาน AI กำลังขยับจากการตอบกลับเพียงครั้งเดียว ไปสู่งาน แบบต่อเนื่อง เช่น ผู้ช่วยที่ใช้เครื่องมือจริง เวิร์กโฟลว์อัตโนมัติ และการวิจัยที่สังเคราะห์เอกสารหลายสิบฉบับ
  • เอเจนต์ไม่ได้เรียกโมเดลเพียงครั้งเดียว แต่เรียกหลายร้อยครั้ง โดยส่งต่อบริบทในแต่ละขั้นตอน สร้างเอาต์พุตแบบมีโครงสร้าง และนำไปใช้เป็นอินพุตของขั้นตอนถัดไป
  • Cloud API ยังคงเหมาะกับผลิตภัณฑ์จำนวนมาก แต่การรันงานเอเจนต์บนคลาวด์เพียงอย่างเดียวก่อให้เกิดข้อจำกัดเชิงโครงสร้าง
    • ทุกขั้นตอนต้องถูกประมวลผลเป็นคำขอระยะไกล
    • ต้นทุนโทเค็นสะสมเพิ่มขึ้นทุกครั้งที่ทำซ้ำ
    • ไม่ใช่แค่แผน การเรียกใช้เครื่องมือ และผลลัพธ์ระหว่างทางเท่านั้น แต่ยังรวมถึงไฟล์ส่วนตัว หน้าจอ และข้อมูลของผู้ใช้ที่ต้องผ่านเครือข่าย
  • หากรันโมเดลที่มีความสามารถเพียงพอบนอุปกรณ์ ก็สามารถวางเอเจนต์ไว้ภายในตัวผลิตภัณฑ์ได้
    • แม้เป็นลูป 100 ขั้นตอนก็ไม่เกิดค่าใช้จ่ายจากการเรียกโมเดลเพิ่ม
    • ข้อมูลผู้ใช้ไม่ต้องออกจากอุปกรณ์
    • ทำให้สร้างเอเจนต์ on-device แบบต่อเนื่อง ผู้ช่วยออฟไลน์ และผู้ช่วยที่ประมวลผลข้อมูลส่วนตัวแบบโลคัลได้โดยตรง
  • งานที่อ่อนไหวหรือไม่ต้องการสมรรถนะระดับแนวหน้าสามารถส่งให้โมเดลโลคัลทำได้ และมอบหมายเฉพาะขั้นตอนที่ยากที่สุดให้โมเดลคลาวด์ ผ่าน สถาปัตยกรรมแบบไฮบริด ที่ช่วยลดต้นทุนต่อหนึ่งงานของระบบเอเจนต์

ความเร็วในการรันและข้อจำกัดหน่วยความจำของโทรศัพท์

  • ความเร็วในการสร้างข้อความสูงสุดที่วัดได้บน NVIDIA GeForce RTX 5090 มีดังนี้
    • โมเดล 1-bit: 163 tok/s
    • โมเดล Ternary: 134 tok/s
  • ความเร็วในการสร้างข้อความสูงสุดที่วัดได้บน M5 Max มีดังนี้
    • โมเดล 1-bit: 87 tok/s
    • โมเดล Ternary: 58 tok/s
  • แอปบนโทรศัพท์ไม่สามารถใช้หน่วยความจำทั้งหมดของอุปกรณ์ได้ และแม้บน iPhone 12GB หน่วยความจำที่โมเดลใช้ได้ก็มีเพียงราว 6GB
  • งบหน่วยความจำนี้ต้องรองรับไม่เพียงน้ำหนักโมเดล แต่รวมถึง KV cache และ activation ด้วย ดังนั้นการลดแค่ขนาดไฟล์จัดเก็บจึงยังไม่เพียงพอ
  • 1-bit Bonsai 27B ที่มีขนาดราว 4GB ตอบโจทย์ข้อจำกัดหน่วยความจำนี้ พร้อมเหลือพื้นที่เผื่อสำหรับงานจริง
  • เดโมมัลติโหมดเอเจนต์บน iPhone 17 Pro Max รันในโหมดเดโมที่ใช้ cache และบริบทภาพที่ป้อนล่วงหน้า

แพลตฟอร์มที่รองรับและวิธีดีพลอย

  • บนอุปกรณ์ Apple รันแบบเนทีฟบน Mac, iPhone และ iPad ผ่าน MLX
  • บน NVIDIA GPU ใช้ CUDA
  • ทั้งสองแพลตฟอร์มใช้เคอร์เนลบิตต่ำแบบกำหนดเองที่สร้างให้สอดคล้องกับสถาปัตยกรรม hybrid attention
  • มี Developer Preview API แบบฟรีให้ใช้ในช่วงเวลาจำกัด เพื่อให้นักพัฒนาทดลองโมเดลได้
  • รายละเอียดทางเทคนิคทั้งหมดของกระบวนการบีบอัด การประเมิน และการทำเบนช์มาร์ก ดูได้ใน Bonsai 27B whitepaper

โมเดลที่ใหญ่ขึ้นและสถาปัตยกรรมใหม่

  • Bonsai 27B ย่อขนาดความสามารถของโมเดลสมัยใหม่ ทั้งการคิด ความเข้าใจแบบมัลติโหมด วิชัน และการใช้เครื่องมือ ให้มาอยู่ในขนาดที่รันได้บนอุปกรณ์ที่ผู้ใช้ทั่วไปมีอยู่
  • วิธีการบีบอัดนี้ไม่ได้ผูกติดกับสถาปัตยกรรมเฉพาะ และ PrismML กำลังพัฒนา โมเดลที่ใหญ่ขึ้นและสถาปัตยกรรมใหม่
  • เมื่อความหนาแน่นของสติปัญญาสูงขึ้น ช่วงของอุปกรณ์ ผลิตภัณฑ์ และสภาพแวดล้อมที่สามารถรัน AI ขั้นสูงได้ก็จะขยายกว้างขึ้น ตั้งแต่โทรศัพท์มือถือไปจนถึงเซิร์ฟเวอร์ GPU เดี่ยว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นบน Hacker News

  • สิ่งที่อยากนำมาเทียบที่สุดคือ Gemma 4 12B เวอร์ชัน 4-bit QAT มีขนาดไม่ถึง 7GB จึงใหญ่กว่ารุ่นนี้เพียงเล็กน้อย และรันได้บนอุปกรณ์รุ่นใหม่ส่วนใหญ่ แถมฉลาดอย่างน่าทึ่งเมื่อเทียบกับขนาด
    มีความสามารถในการใช้เครื่องมือยอดเยี่ยม และประสิทธิภาพด้าน vision ก็ยอดมากเมื่อเทียบกับขนาด ตอนนี้ยังอยู่ระหว่างประเมินว่าเมื่อลด precision ลงทีละขั้น ประสิทธิภาพหายไปมากแค่ไหน แต่เวอร์ชัน QAT ของ Google ดูเหมือนจะแสดงให้เห็นว่าที่ 4-bit นั้นสูญเสีย น้อยมาก

    • หากนำตัวเลขที่เปิดเผยมาเทียบข้ามกับผลของ Gemma โมเดลนี้นำหน้า Gemma 4 12B อย่างมากในด้าน คณิตศาสตร์และการเขียนโค้ด ตามหลังเล็กน้อยด้านความรู้และ tool calling และด้อยกว่าพอสมควรในงาน vision
    • อยากให้ทำ Gemma 4 12B เวอร์ชันไบนารี 1-bit ด้วย ;)
    • ในตระกูลโมเดลจำนวนมาก 4-bit เป็นจุดแบ่งสำคัญ แต่ก็ขึ้นอยู่กับว่ากำลัง quantize อะไรเป็น 4-bit ระหว่าง weights, weights กับ activations หรือ KV cache นอกจากนี้ยังขึ้นกับขนาดโมเดลและงานด้วย ดังนั้น quantization มีรายละเอียดปลีกย่อยมากกว่าที่คิด
      เอกสารประเมินที่ดีจากปี 2024 คือ https://arxiv.org/pdf/2402.18158 ผมไม่ใช่ผู้เขียนต้นฉบับ แต่ตอนนี้กำลังเตรียมฉบับอัปเดตอยู่ และยังไม่ได้สำรวจวรรณกรรมอย่างจริงจัง จึงสงสัยว่ามีใครรู้จักเอกสารสำรวจลักษณะคล้ายกันบ้างไหม

  • จากมุมมองนักลงทุน นี่คือ การเปลี่ยนกระบวนทัศน์ อย่างแท้จริง สตาร์ทอัพยุโรปจำนวนมากที่ชูเรื่องความเป็นส่วนตัว แล้วนำโมเดลขนาดใหญ่ที่โฮสต์ไว้มาใส่แพ็กเกจให้บริการ อาจหายไปเป็นจำนวนมาก
    ถ้าสามารถรันทุกอย่างได้เองบนแล็ปท็อป ก็ไม่มีเหตุผลใดเลยที่จะใช้บริษัทแบบ ‘Privacy GPT™’ ธนาคารหรืออุตสาหกรรมที่ถูกกำกับดูแลอื่น ๆ ก็สามารถ โฮสต์เอง ได้ด้วยระดับสติปัญญาแบบนี้ จึงไม่จำเป็นต้องพึ่งพาบริษัทเหล่านั้นอีกต่อไป

  • ต้องการความช่วยเหลือในการทำความเข้าใจ ผมเข้าใจว่าประเด็นหลักตรงนี้คือการใช้ quantization ลดขนาดจาก 50GB เหลือ 4GB พร้อมรักษาความฉลาดส่วนใหญ่ไว้ภายในขอบเขต Pareto optimal และเทียบความฉลาดต่อขนาดกับโมเดล quantized อื่น ๆ อย่างไรก็ตาม ดูเหมือนว่า ประสิทธิภาพ tool calling ซึ่งเป็นปัญหาในโมเดลขนาดเล็กรุ่นอื่น ๆ เช่นกัน จะเสียหายมากที่สุด
    โมเดลนี้เป็นอย่างไรเมื่อเทียบกับโมเดล 4GB รุ่นอื่น ๆ ล่าสุด? เราจะรู้ได้อย่างไรว่ามันรักษาความฉลาดของโมเดลแม่ไว้จริง ๆ หรือแค่ fine-tune ให้เข้ากับ benchmark?
    ไม่ได้ตั้งใจจะดิสเครดิต แต่อยากให้เป็นผลลัพธ์ที่น่าทึ่งจริง ๆ เพียงแต่มองจากความรู้ที่จำกัดของผมแล้ว เหมือนจะขาดกราฟเปรียบเทียบที่เป็นธรรม และกราฟที่มีอยู่ก็ดูอาจทำให้เข้าใจผิดได้ หากผมเข้าใจผิดตรงไหน ช่วยอธิบายให้หน่อยได้ไหม

    • ผมเข้าใจว่า PrismML ไม่ได้ทำ quantization แบบทั่วไปที่ตัดบิตของโมเดลที่ฝึกด้วย FP16 เพื่อลด VRAM แต่เป็นการ ฝึกด้วย weights แบบ 1-bit ตั้งแต่ต้น
      ในบทความมีรายละเอียดมากกว่านี้ เช่น เทคนิคการใส่ weight แบบ FP16 หนึ่งตัวต่อบล็อกของ weights 1-bit จำนวน 128 ตัว เพื่อบรรจุข้อมูลได้มากขึ้น

  • มีข่าวว่า Apple กำลัง เจรจากับ PrismML: https://www.cnbc.com/2026/07/14/apple-prismml-ai-compression...

    • เรื่องนี้ Babak Hassibi ซีอีโอของ PrismML เป็นคนบอก CNBC โดยตรง ดังนั้นอาจเป็นเรื่องโกหก หรือไม่ก็เป็นการปล่อยข่าวการเจรจาจนทำให้ โอกาสปิดดีล จบลงด้วยตัวเองก็ได้

  • อาจเป็นการจับผิดเล็กน้อย แต่ในเดโม อาหารที่โมเดลแนะนำดูไม่น่าอร่อยเท่าไร และ การคำนวณสารอาหารหลัก ก็ดูผิดทั้งหมด ‘สปาเกตตี แครอต พริกหวาน กระเทียม สมุนไพร’ มีโปรตีน 25g เนี่ยนะ?

    • สปาเกตตีที่ดีมีสัดส่วนโปรตีน 15% หรือ 15g ต่อ 100g และแม้แต่สินค้าคุณภาพต่ำที่สุดก็ยังมีอย่างน้อย 12g ต่อ 100g
    • ส่วนตัวไม่ค่อยชอบแครอต แต่ก็ไม่ได้ดูไม่น่าอร่อย ถ้ามีซอสมะเขือเทศคงดีกว่านี้มาก แต่ในภาพที่ให้มาดูเหมือนไม่ได้มีเป็นตัวเลือก
      โปรตีน 25g อาจเป็นการสมมติว่าเป็น พาสต้าโปรตีนสูง อย่างพาสต้าถั่วชิกพี แต่ก็ยังดูเป็นตัวเลขที่ผิดอย่างชัดเจน
    • ในสปาเกตตี 200g มีโปรตีนจริง ๆ ประมาณ 25g
    • ไม่เข้าใจว่าทำไมคำถามธรรมดาแบบนี้ต้องให้ AI บนมือถือจัดการ เรื่องแบบนี้ไม่ต้องใช้ AI ด้วยซ้ำ ไม่ต้องพูดถึง local AI เพราะตั้งแต่ก่อนก็ใช้ Google Search พื้นฐานก็พอแล้ว
      หาก AI ขนาดเท่ามือถือจะมีประโยชน์ ก็ต้องจัดการ งานที่มีแต่ AI เท่านั้นที่ทำได้ รับเอกสารที่สแกนด้วยกล้องมือถือได้ไหม? แปลภาษาแบบเรียลไทม์ได้ไหม? คำแนะนำเรื่องสูตรอาหารมีวิธีอื่นแก้ปัญหาได้ล้นเหลืออยู่แล้ว จึงไม่มีเหตุผลต้องถามเลย

  • โมเดลถูกอัปโหลดไว้ที่ https://huggingface.co/prism-ml/models ของ Hugging Face
    ลองใช้ทั้งโมเดล GGUF และ MLX ใน LM Studio แล้ว แต่ทั้งคู่ไม่ทำงาน อาจเป็นไปได้ว่า LM Studio ต้องอัปเกรด llama.cpp หรือเอนจิน MLX ก่อน เลยสงสัยว่ามีใครรันสำเร็จแล้วบ้างไหม

    • โมเดลก่อนหน้านี้รันด้วย https://github.com/PrismML-Eng/llama.cpp ซึ่งเป็น custom fork ของ llama.cpp ของ PrismML ส่วนโมเดลรอบนี้ยังไม่ได้ลอง แต่ตั้งใจจะหาเวลาทำ benchmark ภายในสัปดาห์นี้
      เห็นว่ามีแพตช์สำหรับ backend ของ Metal และ CPU เข้า mainline llama.cpp แล้ว ดังนั้นถ้ามี Mac หรือ CPU กับหน่วยความจำที่เร็วพอ ก็น่าจะใช้แค่ llama.cpp เวอร์ชันล่าสุดได้
    • อาจต้องใช้ custom fork ขึ้นอยู่กับโมเดลที่ต้องการรัน รายละเอียดอยู่ที่ https://github.com/PrismML-Eng/Bonsai-demo/blob/main/README....
    • ไม่แน่ใจว่ามีวิธีรัน fork ของ llama.cpp ของ PrismML ภายใน LM Studio หรือไม่
      ตัว fork เองรันได้ดี แต่ในการทดสอบง่าย ๆ ครั้งหนึ่ง โมเดล ติดลูปการอนุมานอย่างหนัก อาจเป็นปัญหาเดียวกับที่เกิดเมื่อตั้งค่าระดับ reasoning ไว้สูง
      บน M1 Max ยังดูเหมือนว่า MoE Qwen 3.6 และ Gemma 4 เป็นตัวเลือกที่ดีที่สุด ผมก็ยังไม่มั่นใจกับข้ออ้างว่า 35B แย่กว่าจริง ๆ และในสภาพแวดล้อมการใช้งานของผม มันติดลูปการอนุมานน้อยกว่า 27B มาก
    • ดาวน์โหลดโมเดลทางการสองตัวใน LM Studio และทั้งคู่มีขนาด 3.6GB แต่โหลดไม่ได้เลยสักตัว
    • ใน Unsloth ก็ยังใช้ไม่ได้เช่นกัน แต่เมื่อชุดอัปเดตถัดไปออกมา มีโอกาสสูงว่าจะ แก้ได้ภายในหนึ่งหรือสองวัน

  • เจ๋งมาก! รอให้ ขยายขนาดโมเดล ternary มานานกว่าหนึ่งปีแล้ว[1] Qwen 27B แบบปกติหนักเกินไปที่จะรันบนฮาร์ดแวร์โลคัลด้วยความเร็วที่พอเหมาะ เลยตื่นเต้นที่จะได้ลองใช้เอง
    [1] https://jackson.dev/post/dont-sleep-on-bitnet/

    • ผมก็เหมือนกัน เป็นโมเดลที่อาจพอใช้งานได้บน แล็ปท็อป 16GB เลยคาดหวังอยู่

  • การทำให้ โมเดล 1 บิตได้ประสิทธิภาพ 90% นี่อย่างแรกเลยถือว่าน่าทึ่งมาก
    แต่ในช่วง 2 สัปดาห์ที่ผ่านมา นี่เป็นการประกาศผลิตภัณฑ์ครั้งที่ห้าแล้ว และแต่ละอันก็บอกว่าแนวทางการใช้ AI กำลังเปลี่ยนไป พร้อมประกาศว่าการประนีประนอมของตัวเองคือคำตอบที่สมบูรณ์แบบ การเปลี่ยน paradigm ไม่ได้เกิดขึ้นในประกาศเปิดตัวผลิตภัณฑ์
    ผมสงสัยว่านี่อาจเป็น สไตล์การเขียนเฉพาะตัวของ AI ที่ทำให้ทุกโพสต์เปิดตัวฟังดูเหมือนเป็นการเปลี่ยน paradigm

    • การประกาศเทคโนโลยีทุกอย่างก็เป็นแบบนี้แหละ ไม่เกี่ยวกับความเป็นจริง นักการตลาดก็ทำการตลาด ไปเท่านั้น

  • แม้ที่ความยาว context เต็ม ๆ การใช้หน่วยความจำของ KV cache ก็ดูน้อยจนน่าทึ่ง ด้วยเหตุนี้จึงอาจมีประโยชน์เป็นพิเศษกับ workflow การเขียนโค้ดแบบ multi-agent
    อยากให้การประกาศและเดโมโมเดลใหม่ ๆ พูดถึงการใช้หน่วยความจำของ KV cache และการปรับแต่งที่เกี่ยวข้องให้ชัดเจนกว่านี้

    • ถ้า quantize KV cache จะทำให้ ประสิทธิภาพด้าน attention และ recall แย่ลง และผลกระทบนั้นก็ทำให้งานที่มีข้อความยาวเสียหายไปด้วย แต่ละตระกูลโมเดลและแต่ละขนาดทนต่อการ quantize ในแต่ละส่วนได้ไม่เท่ากัน และยังขึ้นอยู่กับงานเป้าหมายด้วย

  • เรื่องที่เพิ่งรู้วันนี้: โมเดล 1 บิต จริง ๆ แล้วเป็น โมเดล 1.58 บิต ที่ใช้ค่าสามค่า คือ +1, 0, -1

    • ตรงนี้มีสองรูปแบบ พูดแบบขำ ๆ ก็คือกำหนดค่าของบิตให้ใหญ่มากนั่นเอง
      Ternary Bonsai 27B ใช้น้ำหนักแบบ ternary {-1, 0, +1} และ FP16 group-wise scaling ทำให้บิตเชิงผลต่อหนึ่งน้ำหนักอยู่ที่ 1.71 บิต ส่วน 1-bit Bonsai 27B ใช้น้ำหนักแบบ binary {-1, +1} และใช้ group-wise scaling แบบเดียวกัน ทำให้บิตเชิงผลต่อหนึ่งน้ำหนักอยู่ที่ 1.125 บิต
    • ถ้าคำนวณด้วยวิธีที่ใช้งานได้จริงที่สุดในการใส่เลข 3 สถานะจำนวน 5 ตัวลงใน 1 ไบต์ จะได้ 1.6 บิต แต่ในทางปฏิบัติมักจะมัดเลข 4 สถานะจำนวน 4 ตัวเข้าด้วยกัน
    • เป็นธรรมเนียมที่น่าเสียดายซึ่งเริ่มจากโมเดล ‘1 บิต’ รุ่นแรก ๆ อย่างไรก็ดี Bonsai มีทั้ง เวอร์ชัน ternary และเวอร์ชัน 1 บิตจริง