Ternary Bonsai 2 27B: อะไรที่พอดีใน 5.9 GB และสิ่งที่ 98.2% ไม่ได้บอกคุณ

Ternary Bonsai 2 27B เป็นโมเดลภาษาหลายรูปแบบขนาด 27.36 พันล้านพารามิเตอร์ที่ Prism ML ประกาศเมื่อวันที่ 17 กันยายน 2026 และสิ่งที่ต้องเข้าใจเกี่ยวกับมันก็คือ น้ำหนักภาษาของมันมีค่าได้เพียงหนึ่งในสามค่าที่แน่นอน โมเดลฐานของมันคือ Qwen3.8 27B — โมเดลแบบ hybrid-attention ขนาด 27B — และ Bonsai ยังคงสถาปัตยกรรม การฝึก และรูปทรงนั้นไว้ พร้อมแทนที่เมทริกซ์น้ำหนักของโมเดลภาษาด้วยการแทนค่าแบบไตรภาค ไฟล์ที่แจกจ่ายมีขนาด 5.93 GB เวอร์ชันอ้างอิงแบบความแม่นยำเต็มมีขนาด 53.81 GB ข้ออ้างหลักของผู้ขายคือมันยังคงรักษาค่าเฉลี่ย benchmark ของต้นฉบับไว้ได้ 98.2%

เริ่มจากส่วนที่สื่อส่วนใหญ่จะพูดผ่านไป: ตัวเลข 98.2% นั้นเป็นตัวเลขของ Prism ML เอง วัดบนชุดเบนช์มาร์ก 20 รายการของ Prism ML เอง ด้วยฮาร์เนสของ Prism ML เอง และยังไม่มีใครนอกบริษัททำซ้ำได้ นั่นไม่ใช่การกล่าวหา — มันคือสภาวะปกติหนึ่งวันหลังการเปิดตัว และเป็นสถานะที่คุณควรกำหนดให้กับมันอย่างถูกต้อง สิ่งที่คุณตรวจสอบได้อย่างอิสระในวันนี้คือไฟล์: API ของ Hugging Face แสดง Ternary-Bonsai-2-27B-PTQ1_0.gguf ที่ 5.947 GB เทียบกับไฟล์อ้างอิง FP16 ที่ 53.808 GB ซึ่งเป็นการลดลง 9.05 เท่า และตรงกับคำกล่าวของผู้ขายที่ว่า "ราว 9 เท่า" โดยไม่ต้องเชื่อใครเลย ขนาดเป็นข้อเท็จจริง การรักษาคุณภาพเป็นผลวัดของผู้ขาย ส่วนที่น่าสนใจอยู่ตรงกลาง — การแยกตามหมวดหมู่ ซึ่งแสดงให้เห็นชัดเจนว่าการบีบอัดนั้นได้มาฟรีตรงไหน และไม่ได้มาฟรีตรงไหน

การเปิดตัวครั้งนี้ยังมีอีกด้านหนึ่งด้วย เมื่อวันที่ 18 กันยายน หนึ่งวันหลังจากการประกาศ OrcaRouter ได้เผยแพร่เวอร์ชัน runtime-abliterated ของโมเดลเดียวกัน — OrcaRouter Ternary Bonsai 2 27B Uncensored — ซึ่งลบทิศทางการปฏิเสธที่เรียนรู้ไว้ออกในเวลาอนุมาน และคงน้ำหนักให้เหมือนเดิมทุกบิต มันถูกกล่าวถึงในส่วนของตัวเองด้านล่าง เพราะเทคนิคเป็นส่วนที่น่าสนใจ และเพราะข้อจำกัดของมันให้บทเรียนได้พอ ๆ กับผลลัพธ์

มันเป็น Qwen3.8 27B ที่ถูกบีบอัด ไม่ใช่โมเดลที่เพิ่งฝึกใหม่

ความแตกต่างนี้คือความต่างระหว่างการอธิบายการเปิดตัว กับการพูดซ้ำข่าวประชาสัมพันธ์ Prism ML ไม่ได้ฝึกโมเดล 27B ตั้งแต่ต้น และไม่ได้ใช้สูตรการพรีเทรนใหม่ สิ่งที่ทำคือนำ Qwen3.8 27B มาเปลี่ยนการแทนค่าเชิงตัวเลขที่ใช้จัดเก็บและคำนวณน้ำหนักของโมเดล

สถาปัตยกรรมไม่เปลี่ยนแปลง และเป็นของโมเดลฐาน: การออกแบบที่ใช้ความสนใจแบบไฮบริด ซึ่งประกอบด้วยความสนใจเชิงเส้นประมาณ 75% และความสนใจเต็มรูปแบบ 25% พร้อมบล็อก SwiGLU MLP, RoPE และ RMSNorm โครงหลังแบบไฮบริดนั้นยังเป็นเหตุผลว่าทำไมบริบท 262K โทเคนจึงถูกอธิบายว่าสามารถรองรับบริบทเต็มรูปแบบได้ ไม่ใช่แค่รองรับเท่านั้น — ความสนใจแบบเชิงเส้นเป็นส่วนใหญ่คือสิ่งที่ทำให้บริบทยาวมีต้นทุนที่เหมาะสมบนอุปกรณ์ โมเดลนี้เป็นโมเดลภาษา-ภาพ: มันรับภาพเช่นเดียวกับข้อความ และวิชันทาวเวอร์เป็นหอ Qwen มาตรฐานที่ไม่ได้ถูกควอนไทซ์ ซึ่งแพ็กแยกต่างหาก

สิ่งที่ Prism ML มีส่วนสนับสนุนคือสองอย่าง อย่างแรกคือการแทนค่าแบบ ternary เอง บวกกับการฝึกที่ตระหนักถึงการควอนไทซ์ (quantization-aware training) ซึ่งทำให้มันอยู่รอดได้ อย่างที่สองคือเคอร์เนล — เคอร์เนล low-bit ที่ปรับแต่งเองสำหรับสแต็ก hybrid-attention นั้นบน Apple Silicon และ CUDA ซึ่งทำงานโดยตรงกับเวตต์ที่แพ็กไว้ แทนที่จะคลายแพ็กออกเป็น FP16 แล้วคูณ หากไม่มีส่วนที่สอง ส่วนแรกก็เป็นเพียงรูปแบบการจัดเก็บที่ไม่มีทางใช้มันด้วยความเร็วได้

ไวท์เปเปอร์ของ Prism ML เองรายงานว่าการแบ่งพารามิเตอร์เป็น 24.35B ใน language backbone จำนวน 64 บล็อก, 2.54B ใน embedding และ LM head, และ 0.47B ใน vision tower ขนาด 27 บล็อก รวมทั้งหมด 27.36B vision tower เป็นส่วนเดียวที่เป็นอาร์ติแฟกต์ที่แตกต่างอย่างแท้จริง: การเผยแพร่ GGUF จะแพ็กเกจมันเป็นไฟล์ mmproj 4-bit ขนาดประมาณ 0.63 GB ซึ่งโหลดเฉพาะเมื่อมีรูปภาพเข้ามาจริง ๆ ดังนั้นการให้บริการแบบข้อความเท่านั้นจึงไม่โหลดมันเลย

นี่คือ Bonsai รุ่นที่สองจากห้องแล็บเดียวกัน; Bonsai 27B ตัวแรกเปิดตัวในเดือนกรกฎาคม 2026 ประมาณสองเดือนก่อนหน้านั้น และการเปรียบเทียบระหว่างสองรุ่นก็เป็นคำถามที่สมเหตุสมผล — ซึ่งเราจะหยิบขึ้นมาพูดในการเปรียบเทียบแบบตัวต่อตัวกับ Bonsai 27B แทนที่จะกล่าวซ้ำในที่นี้

"ternary g128" หมายถึงอะไร อย่างเป็นรูปธรรม

หากคุณยังไม่เคยพบน้ำหนักแบบเทอร์นารีมาก่อน นี่คือย่อหน้าที่ทำให้ทุกอย่างที่เหลืออ่านเข้าใจได้ ดังนั้นนี่คือเวอร์ชันที่ไม่ใช้คำย่อ

น้ำหนักทั่วไปในโครงข่ายประสาทเทียมคือจำนวนทศนิยมลอยตัว 16 บิต — มีค่าที่แยกแยะได้ประมาณ 65,536 ค่าในช่วงที่มีประโยชน์ โดยแต่ละค่าต้องใช้ 16 บิตในการจัดเก็บ น้ำหนักแบบไตรภาคไม่ใช่ทศนิยมลอยตัวขนาดเล็ก มันคือการเลือกจากสัญลักษณ์สามอย่าง: −1, 0, หรือ +1 นั่นคือคำศัพท์ทั้งหมด หากจัดเก็บสัญลักษณ์เช่นนี้แบบตรง ๆ คุณจะใช้สองบิตต่อน้ำหนัก เนื่องจากสองบิตให้สถานะได้สี่สถานะ แต่คุณต้องการเพียงสามสถานะเท่านั้น

หากมีเพียงเท่านั้น มันจะเป็นการสูญเสียความสามารถในการแสดงออกอย่างรุนแรง และนี่คือเหตุผลว่าทำไมรูปแบบนี้จึงไม่เคยเป็นเพียงสัญลักษณ์เท่านั้น น้ำหนักต่อเนื่องกัน 128 ค่าในแต่ละกลุ่มจะใช้แฟกเตอร์สเกล FP16 หนึ่งค่าร่วมกัน และค่าของน้ำหนักจริงคือสัญลักษณ์แบบไตรภาคคูณกับสเกลนั้น:

• w = ssub>g/sub> · t โดยที่ t ∈ {−1, 0, +1} และ ssub>g/sub> เป็นค่าสเกล FP16 ที่ใช้ร่วมกันหนึ่งค่าสำหรับกลุ่มขนาด 128

ดังนั้นโมเดลยังคงแทนค่าช่วงขนาดที่กว้าง — เพียงแต่แทนค่าพวกมันเป็นขั้นหยาบ ๆ แบบจัดกลุ่ม แทนที่จะเป็นรายน้ำหนักทีละตัว ค่า 0 ไม่ใช่ผลตกค้างจากการปัดเศษ; มันเป็นสถานะที่สามจริง ๆ และการมีสถานะนี้คือสิ่งที่ทำให้กลุ่มน้ำหนัก 128 ตัวเงียบเป็นส่วนใหญ่ได้เมื่อจำเป็น

ฐานที่หมุนแล้วคือส่วนที่ทำให้ผู้คนประหลาดใจก่อนที่การกำหนดค่าไตรภาคจะเกิดขึ้น เมทริกซ์น้ำหนักแต่ละตัวจะถูกแปลงทีละบล็อกด้วยการหมุนแบบตั้งฉาก — เมทริกซ์ Walsh–Hadamard รวมกับเส้นทแยงมุมคงที่ของเครื่องหมาย ±1 ที่ขนาดบล็อก 1024 — และค่าไตรภาคจะถูกเลือกในปริภูมิที่หมุนแล้วนั้น การหมุนจะถูกผนวกรวมเข้าไปในน้ำหนักที่จัดเก็บไว้ระหว่างการเตรียม ดังนั้นจึงไม่สิ้นเปลืองบิตเพิ่มเติมและไม่มีทราฟฟิกน้ำหนักเพิ่มเติม ในขั้นตอนการอนุมาน รันไทม์จะใช้การแปลงที่เข้าคู่กันกับแอ็กติเวชันแทน และโมเดลที่แพ็กไว้จะประกาศการหมุนของตนไว้ในเมทาดาทา ดังนั้นรันไทม์จะใช้การแปลงที่เข้าคู่กันหรือไม่ก็ปฏิเสธที่จะโหลดไฟล์

จะไปสนใจทำไม? เพราะการหมุนแบบ Hadamard กระจายพลังงานของเมทริกซ์น้ำหนักให้ทั่วถึงพิกัดมากขึ้น ซึ่งทำให้การควอนไทซ์สามระดับที่ตามมาสร้างความเสียหายน้อยลงมากเมื่อเทียบกับการทำกับดิสทริบิวชันดิบที่มีลักษณะเป็นหนาม การหมุนไม่ใช่ของประดับ มันคือเหตุผลที่โมเดลแบบ ternary สามารถรักษาคุณภาพได้ใกล้เคียงกับต้นฉบับ ต้นทุนคือการแปลงนี้อยู่ในเส้นทางวิกฤตของการฉายภาพทุกครั้งที่ขนาดแบตช์เป็น 1 ซึ่งเป็นปัญหาทางวิศวกรรมจริง — Prism ML รวมการพลิกเครื่องหมายเข้าไปในเส้นทางโหลดของการแปลงบน Metal และทำขนานมันทั่วทั้งบล็อกเธรดบน CUDA เพื่อไม่ให้มันครองเวลาการถอดรหัส

ตัวเลขเหล่านี้ อย่างระมัดระวัง: 1.585, 1.71, 1.72, 1.76

ตัวเลขความกว้างบิตสี่ตัววนเวียนอยู่รอบ ๆ การเปิดตัวนี้ พวกมันถูกต้องทั้งหมด และวัดสี่สิ่งที่แตกต่างกัน การนำพวกมันมาปนกันเป็นข้อผิดพลาดที่เกิดขึ้นได้ง่ายที่สุดในเรื่องนี้ นี่คือแต่ละตัวและสิ่งที่มันครอบคลุมจริง ๆ

• 1.585 บิตต่อน้ำหนัก — ปริมาณข้อมูลของสัญลักษณ์ไตรภาคหนึ่งตัว คือ log₂3 นี่เป็นคุณสมบัติของรูปแบบ ไม่ใช่ของคุณสมบัติของไฟล์ใด ๆ ไม่มีสิ่งใดที่จัดส่งจริงทำงานที่ 1.585 บิต/น้ำหนัก

• 1.71 บิตต่อน้ำหนัก — เฉพาะเทนเซอร์แบบเทอร์นารีเท่านั้น เมื่อบวกสเกลกลุ่ม FP16 ขนาด 16 บิตที่เฉลี่ย分摊ลงบนน้ำหนัก 128 ตัว ก็จะได้ log₂3 + 16/128 ≈ 1.71 นี่ก็ยังไม่ใช่ตัวเลขที่ใช้จริงในการผลิต แต่เป็นเพียงเทนเซอร์แบบเทอร์นารีที่แยกออกมาดูเดี่ยว ๆ เท่านั้น

• 1.72 บิตต่อพารามิเตอร์ — พารามิเตอร์ทุกตัวในโมเดลภาษา รวมถึงชุดเล็ก ๆ ที่ถูกเก็บไว้เหนือการแทนค่าบิตต่ำ Prism ML เก็บพารามิเตอร์ 26,238,464 ตัว — 0.0976% ของโมเดลภาษา ประมาณ 52 MB ที่ bf16 — ไว้ในความละเอียดที่สูงกว่า ส่วนใหญ่เป็นเส้นทางสถานะแบบวนซ้ำของเลเยอร์ linear-attention บวกกับน้ำหนักการนอร์มัลไลเซชัน เทนเซอร์เหล่านี้ไม่ถูกหมุนและไม่ถูกควอนไทซ์ และสิ่งเหล่านี้คือสิ่งที่ทำให้ตัวเลขเปลี่ยนจาก 1.71 เป็น 1.72 ที่ 1.72 ขนาดหน่วยความจำในอุดมคติคือ 5.80 GB ลดลงประมาณ 9.3 เท่า นี่คือแถว "True Ternary" ของ Prism ML และมันเป็นเป้าหมายมากกว่าไฟล์ที่คุณดาวน์โหลด

• 1.76 บิตต่อน้ำหนัก — ไฟล์ GGUF ที่จัดส่งจริง เคอร์เนลประสิทธิภาพสูงจำเป็นต้องมีรูปแบบการแพ็ก และ PTQ1_0 ของ Prism ML บรรจุทริตอย่างหนาแน่น โดยได้ 1.76 บิต/น้ำหนัก ในขนาด 5.93 GB หรือประมาณ 9.1 เท่า นี่คือไฟล์ที่อยู่เบื้องหลังทั้ง "5.9 GB" และ "เล็กกว่า 9 เท่า" ที่ประกาศอ้างถึง และเป็นไฟล์ที่การวัดข้างต้นยืนยัน

การแพ็กแบบที่สองคือ PQ2_0 ซึ่งเก็บไตรต์แต่ละตัวไว้ในช่องขนาด 2 บิตแทนที่จะเก็บแบบแน่นหนา มันแลกพื้นที่ที่ใช้มากขึ้นกับการคลายแพ็กที่ถูกกว่า: 2.16 บิต/น้ำหนัก ใน 7.25 GB หรือประมาณ 7.4 เท่า ไม่มีรูปแบบการแพ็กใดที่เร็วกว่าโดยสม่ำเสมอ — PTQ1_0 เคลื่อนย้ายข้อมูลน้ำหนักต่อขั้นตอนน้อยลงราว 18% แต่ต้องจ่ายด้วยการคำนวณเพื่อคลายแพ็กไตรต์แบบแน่นหนา จึงได้เปรียบบนการ์ดรุ่น Ada และ L4 ซึ่งหน่วยความจำเป็นข้อจำกัดหลัก และเสียเปรียบบน Hopper, Blackwell และ Apple silicon ซึ่งการถอดรหัสแบบ batch-1 ถูกจำกัดด้วยอัตราการประมวลผลคำสั่งแทน การประมวลผลพรอมป์ต์ชอบ PQ2_0 ทุกที่ เพราะมันถูกจำกัดด้วยการคำนวณ

หมายเหตุประกอบสองข้อสำหรับใครก็ตามที่กำลังตรวจสอบสิ่งเหล่านี้เทียบกับแหล่งอ้างอิง ข้อแรก เอกสารของ Prism ML เองมีการปัดเศษต่างกันเล็กน้อย — ตารางพื้นที่จัดเก็บในไวท์เปเปอร์ระบุ PTQ1_0 ว่าเป็น 1.76 บิต/น้ำหนัก ที่ 5.93 GB ขณะที่การ์ดโมเดล GGUF บน Hugging Face ระบุ 1.75 และ 5.95 GB และไฟล์ที่วัดได้คือ 5.947 GB สิ่งเหล่านี้เป็นไฟล์เดียวกันที่ถูกอธิบายด้วยความละเอียดต่างกัน ไม่ใช่ความขัดแย้งในสาระสำคัญ ข้อที่สอง การลดลงที่ประกาศไว้ว่า "มากกว่า 9x" เป็นตัวเลขของผู้ขาย; เมื่อวัดเทียบกับไฟล์จริงแล้วคือ 53.808 / 5.947 = 9.05x ซึ่งสอดคล้องกัน

ภาพของเกณฑ์มาตรฐาน: ไม่ใช่ค่าเฉลี่ย แต่เป็นรูปร่าง

พาดหัวคือค่าเฉลี่ย 83.9 เทียบกับ 85.4 สำหรับ baseline Qwen3.8 27B FP16 ซึ่งคิดเป็น 98.2% ค่าเฉลี่ยเป็นส่วนที่น่าสนใจน้อยที่สุดของมัน รูปทรงที่อยู่เบื้องหลังต่างหากคือที่ที่ข้อมูลจริงอยู่ และมันไม่สม่ำเสมอ

• การทำตามคำสั่ง — 82.66 ต่อ 81.25 นี่คือหมวดหมู่เดียวที่โมเดลแบบบีบอัดเอาชนะโมเดลต้นฉบับความแม่นยำเต็มได้ มันไม่ใช่สัญญาณรบกวนที่ใครจะอธิบายปัดได้ง่าย ๆ; มันคือชัยชนะระดับหมวดหมู่บนชุดทดสอบของผู้จำหน่ายเอง

• คณิตศาสตร์ — 96.57 เทียบกับ 97.06 และการเขียนโค้ด — 81.58 เทียบกับ 82.17 ทั้งคู่อยู่ในระดับเดียวกันโดยพื้นฐาน: ครึ่งคะแนนและหกในสิบของคะแนนบนค่าเฉลี่ยหมวดหมู่ สำหรับโมเดลที่มีขนาดเพียงหนึ่งในเก้าของพื้นที่การใช้งาน นี่คือผลลัพธ์ที่เทคนิคทั้งหมดนี้ถูกโต้แย้งบนพื้นฐาน

• ความรู้และการใช้เหตุผล — 83.95 เทียบกับ 86.66 ลดลง 2.7 คะแนน และนี่คือส่วนสำคัญของ 1.8 คะแนนที่หายไปจากค่าเฉลี่ยรวม

• การมองเห็น — 78.59 เทียบกับ 81.64 ลดลง 3.05 จุด ซึ่งเป็นการลดลงมากที่สุดในหมวดหมู่เดียว ควรสังเกตว่าตัว vision tower เองไม่ใช่ส่วนที่ถูกบีบอัด แต่โมเดลภาษาที่อ่านเอาต์พุตของมันคือส่วนนั้น

• การทำงานแบบเอเจนต์และการเรียกใช้เครื่องมือ — 77.57 เทียบกับ 79.74 ค่าเฉลี่ยของหมวดนี้ครอบคลุม τ 2-Bench ที่ 80.22 และ BFCL v3 ที่ 74.92

ผลลัพธ์รายตัวที่ควรค่าแก่การรู้ เพราะไม่ได้ชี้ไปในทิศทางเดียวกันทั้งหมด บน Terminal-Bench 2.1 โมเดลได้คะแนน 52.8 เทียบกับ 69.7 สำหรับความแม่นยำเต็ม — ประมาณสามในสี่ — และบน SWE-bench Verified ได้ 60.8 เทียบกับ 80.6 ซึ่งก็ประมาณสามในสี่เช่นกัน นี่เป็นครั้งแรกที่ตระกูลโมเดลนี้ได้รับการประเมินบน Terminal-Bench และ Prism ML ระบุชัดเจนว่าความก้าวหน้าด้านวิศวกรรมซอฟต์แวร์ระยะยาวที่สัญญาไว้ใน Bonsai รุ่นแรกนั้นเป็นเพียงบางส่วน ไม่ใช่ทั้งหมด เมื่อเทียบกันแล้ว: τ 2-Bench เพิ่มขึ้นเป็น 80.2 จาก 73.6 ในรุ่นก่อนหน้า, BFCL v3 คงอยู่ที่ 74.9, และ AA-LCR อยู่ที่ 77.0 ห่างจากความแม่นยำเต็มเพียงหนึ่งจุด AIME26 อยู่ที่ 95.83 และ LiveCodeBench ที่ 90.07

ควรเชื่อถือตรงไหน และไม่ควรเชื่อตรงไหน เชื่อในรูปแบบผลลัพธ์ด้านคณิตศาสตร์ การเขียนโค้ด และการทำตามคำสั่งได้ เพราะนั่นคือหมวดหมู่ที่เทคนิคนี้พิสูจน์ได้ว่าทำในสิ่งที่อ้างจริง และวัดบนฮาร์เนสชุดเดียวกับ baseline แต่ให้ระวังงานแบบเอเจนต์ที่ต้องทำระยะยาว เบนช์มาร์กสองตัวที่ทดสอบงานวิศวกรรมที่ขับเคลื่อนด้วยเครื่องมืออย่างต่อเนื่องจริง ๆ คือ Terminal-Bench 2.1 และ SWE-bench Verified กลับแสดงช่องว่างที่มากกว่าที่ตัวเลขรวมบ่งชี้อย่างมีนัยสำคัญ และผู้พัฒนาโมเดลก็บอกแบบนั้นเองแทนที่จะปิดบัง และให้มองตารางทั้งหมดเป็นผลการวัดของห้องแล็บเดียวบนฮาร์เนสชุดเดียวไปก่อน จนกว่าจะมีคนอื่นรันมัน ข้อแม้นี้ไม่ใช่แค่เรื่องพิธีการในที่นี้ — มันคือความต่างระหว่าง “โมเดลนี้รักษาความสามารถไว้ได้ 98.2%” กับ “ผู้พัฒนาโมเดลนี้วัดได้ 98.2% บนชุดทดสอบที่ผู้พัฒนาเลือกเอง” ทั้งสองประโยคเป็นความจริง แต่มีเพียงประโยคเดียวที่เป็นข้อเท็จจริงเกี่ยวกับตัวโมเดล

ทำไมสิ่งนี้ถึงดีกว่าบิลด์ IQ2_XXS ของโมเดลฐานเดียวกัน

สิ่งนี้ควรมีส่วนของตัวเองมากกว่าเป็นแค่บรรทัดเดียว เพราะมันคือข้อโต้แย้งทั้งหมดที่สนับสนุนการฝึกเทอร์นารีแบบตระหนักถึงการควอนไทเซชัน เหนือกว่าการควอนไทเซชันหลังการฝึก

วิธีทั่วไปในการทำให้ Qwen3.8 27B เล็กลงคือการควอนไทซ์มันหลังการฝึก จุดเปรียบเทียบในไวท์เปเปอร์คือบิลด์ IQ2_XXS GGUF ของโมเดลฐานเดียวกัน:

• ไตรภาค Bonsai 2 27B — 1.76 บิต/น้ำหนัก, 5.93 GB, ค่าเฉลี่ยจาก 20 การทดสอบ 83.9

• Qwen3.8 27B IQ2_XXS — 2.2 บิต/น้ำหนัก, 7.3 GB, ค่าเฉลี่ยจากการทดสอบมาตรฐาน 20 รายการ 75.2

โมเดลที่ถูกบีบอัดระหว่างการฝึกนี้ทั้งเล็กกว่าและดีกว่า. โดยมีขนาดเล็กกว่าโมเดลแบบบิตต่ำทั่วไป 1.23 เท่า และได้คะแนนสูงกว่า 8.7 คะแนน การผสมผสานเช่นนี้ไม่ใช่เรื่องน่าฉงนเล็ก ๆ น้อย ๆ จากการปัดเศษ หากแต่เป็นข้อกล่าวอ้างว่าการแทนข้อมูลที่เลือกไว้ระหว่างการฝึกนั้นมีค่ามากกว่าอย่างมีนัยสำคัญ เมื่องบประมาณบิตตามที่ระบุไว้เท่ากันถูกนำมาใช้ภายหลัง

ส่วนที่ให้แง่คิดมากกว่าคือวิธีที่บิลด์แบบทั่วไปล้มเหลว เพราะความล้มเหลวนั้นเกิดเฉพาะจุดและสังเกตได้ยาก IQ2_XXS ไม่ได้เสื่อมลงอย่างสม่ำเสมอ มันยังทำได้ดีกับความรู้ระดับผิวเผิน — 85.79 บน MMLU-Redux — แต่กลับพังเมื่อเจองานที่ต้องใช้ลูกโซ่การให้เหตุผลต่อเนื่องยาวนาน: 78.6 บน AIME26, 70.05 บน LiveCodeBench, 65.45 บน GPQA Diamond Bonsai 2 ได้คะแนน 95.83, 90.07 และ 85.76 ในสามงานเดียวกัน การทดสอบแชตแบบชิล ๆ จะพบว่าบิลด์ IQ2_XXS ใช้งานได้ดีไม่มีปัญหา และจะไม่มีทางเผยให้เห็นการพังทลายนี้เลย ความเสียหายอยู่ตรงจุดที่การให้เหตุผลยาว ๆ และการสร้างโค้ดเกิดขึ้นพอดี ความไม่สมมาตรนี้คือเหตุผลว่าทำไม "มันรู้สึกโอเคตอนที่ฉันลองใช้" จึงไม่ใช่หลักฐานเกี่ยวกับโมเดลที่ผ่านการควอนไทซ์

Prism ML ย่อข้อโต้แย้งเดียวกันให้เหลือตัวเลขที่ได้มาค่าเดียวซึ่งเรียกกันว่าความหนาแน่นทางสติปัญญา — โดยประมาณคือความสามารถจาก benchmark ต่อกิกะไบต์ บนชุดทดสอบ 20 รายการ รายงานค่า 0.444 ต่อ GB สำหรับ Bonsai 2, 0.276 สำหรับบิลด์ IQ2_XXS และ 0.051 สำหรับ FP16 เมตริกนี้เป็นสิ่งที่ผู้ขายสร้างขึ้นเอง และการถ่วงน้ำหนักของมันเป็นการเลือกเชิงออกแบบ ไม่ใช่กฎตายตัว แต่ลำดับที่มันให้ก็เป็นลำดับเดียวกับที่ตารางดิบให้ ดังนั้นมันจึงเพิ่มการตีความมากกว่าหลักฐาน

อีกหนึ่งบันทึกอย่างตรงไปตรงมาเกี่ยวกับการเปรียบเทียบนี้ การ์ดโมเดล GGUF ของ Prism ML รายงานการประเมินชุดที่สองที่แคบกว่า — ชุดทดสอบโหมดคิดที่มี 14 เบนช์มาร์ก — ซึ่งตัวเลขการคงความสามารถเดิมปรากฏขึ้นอีกครั้งที่ 84.78 เทียบกับ 86.32 โดย IQ2_XXS อยู่ที่ 72.59 การที่ชุดทดสอบสองชุดที่ต่างกันให้ผล 98.2% เท่ากันถือเป็นหลักฐานยืนยันเล็กน้อยว่าข้อกล่าวอ้างโดยรวมไม่ใช่ผลที่เกิดจากการเลือกเบนช์มาร์กเพียงชุดเดียว แต่มันก็ยังเป็นห้องแล็บเดียวกันที่รันทั้งสองชุด บนฮาร์เนสเดียวกัน รายละเอียดการวิเคราะห์ที่ครบถ้วนกว่าของเราสำหรับการจับคู่นี้ รวมถึงคำถามเรื่องรูปแบบการแพ็ก อยู่ในบทเปรียบเทียบกับบิลด์ GGUF ของ Qwen3.8 27B

สิ่งที่ต้องใช้จริง ๆ ในการดำเนินการ

ตัวเลขปริมาณงาน จากผลการวัด tg128 แบบมาตรฐานของไวท์เปเปอร์ ที่ขนาดแบตช์ 1 โดยไม่รวม vision tower:

• Apple M5 Max — ถอดรหัส 46.8 tok/s, ประมวลผลพรอมป์ต์ 765 tok/s

• Apple M5 Pro — ถอดรหัส 27.7 tok/s; การรันแบบหน้าต่างยาวขึ้นแยกต่างหากของแพ็ก PQ2_0 วัดได้ 27.0 tok/s อย่างต่อเนื่อง โดยใช้พลังงาน 27.0 W บนราง GPU และ 32.8 W ทั่วทั้ง CPU และ GPU

• Apple M4 Pro — ถอดรหัสที่ 18.0 tok/s โดยการประมวลผลพรอมต์ที่ราว 125 tok/s กลายเป็นข้อจำกัดที่ผูกมัดสำหรับบริบทที่ยาวมาก

• NVIDIA RTX 5090 — ถอดรหัส 142.5 tok/s บนแพ็ก PQ2_0 ที่ 0.582 mWh ต่อโทเค็น

ข้อกล่าวอ้างเชิงปฏิบัติของ Prism ML ไม่ใช่อัตราการเร่งความเร็ว แต่เป็นการไม่มีอยู่: baseline FP16 ที่ 53.8 GB ไม่สามารถใส่ลงในแล็ปท็อป 16 GB ได้เลย ดังนั้นข้อความที่มีความหมายคือโมเดลระดับ 27B สามารถทำงานแบบโต้ตอบบนฮาร์ดแวร์ทั่วไปได้แล้ว บน M5 Pro การถอดรหัสที่วัดได้สตรีมน้ำหนักประมาณ 201 GB/s ซึ่งยืนยันโปรไฟล์ที่ขึ้นกับแบนด์วิดท์หน่วยความจำเป็นหลักซึ่งการแทนค่าบิตต่ำถูกออกแบบมาเพื่อใช้ประโยชน์

จากนั้นคือกรณีขอบ ซึ่งสำคัญกว่าตัวเลขสูงสุด

คุณไม่สามารถใช้ llama.cpp เวอร์ชันมาตรฐานได้เคอร์เนล ternary hybrid-attention อยู่ในฟอร์ก llama.cpp ของ Prism ML เอง llama.cpp มาตรฐานจะปฏิเสธประเภท PTQ1_0 และ PQ2_0 ว่าไม่รู้จัก และ — ที่อันตรายยิ่งกว่า — โหลดรูปแบบ ternary Q2_0 ที่เก่ากว่าโดยไม่มีการเตือนใด ๆ และให้ผลลัพธ์ที่เป็นขยะ เพราะมันไม่มีรันไทม์สำหรับ Hadamard activation หากคุณรันโมเดลนี้บนไบนารีที่ไม่ใช้การหมุนที่ตรงกัน คุณจะไม่ได้รับข้อผิดพลาด แต่คุณจะได้ข้อความไร้สาระที่ดูเหมือนลื่นไหล นี่คือวิธีที่มีแนวโน้มมากที่สุดเพียงวิธีเดียวที่จะทำให้คุณเสียเวลาทั้งบ่ายไปกับรีลีสนี้

แพ็ก MLX ไม่มีเส้นทาง CUDA รีลีส MLX (prism-ml/Ternary-Bonsai-2-27B-mlx-2bit) มุ่งเป้าไปที่ Apple Silicon ซึ่งมีเคอร์เนลแบบกำหนดเองสำหรับสแต็กไฮบริดทั้งในรันไทม์ Python และ Swift การคูณเมทริกซ์แบบควอนไทซ์ของมันมีเคอร์เนล Metal และ CPU แต่ไม่มีการใช้งานบน CUDA ดังนั้นบนเครื่อง NVIDIA แพ็กนั้นจึงไม่ได้รับการเร่งความเร็วด้วย GPU เลย การทำอินเฟอเรนซ์บน CPU ทำงานได้ แต่การส่งต่อข้อมูลไปข้างหน้าของโมเดล 27B บน CPU อาจใช้เวลาหลายนาที — ซึ่งทำให้เส้นทาง CPU บน Linux มีประโยชน์สำหรับการทดสอบการใช้งานและความสามารถในการทำซ้ำ และไม่มีประโยชน์สำหรับการให้บริการ

ทั้งสองแพ็กเป็นการแลกเปลี่ยนกันจริง ๆ ไม่ใช่การจัดอันดับ หากคุณใช้การ์ดเจน Ada หรือ L4 หรือหน่วยความจำเป็นข้อจำกัดที่มีผลชี้ขาด PTQ1_0 คือตัวเลือกที่ 5.93 GB หากคุณใช้ Hopper, Blackwell หรือ 5090 PQ2_0 จะแลกความเร็วในการดีโค้ดให้คุณในราคา 1.3 GB หากคุณใช้ Apple silicon โปรดทราบว่าตัวเลข M5 Pro ข้างต้นวัดบน PQ2_0 ซึ่งเป็นแพ็กที่ชุดสาธิตดาวน์โหลดเป็นค่าเริ่มต้นด้วย

หมายเหตุเกี่ยวกับการคำนวณของแพ็ก MLX เอง เพราะมักเป็นจุดที่ทำให้สับสนบ่อย คอนเทนเนอร์ MLX เป็นรูปแบบ 2 บิตแบบ affine ซึ่งบล็อกของมันเก็บทั้งสเกล FP16 และไบแอส FP16 สำหรับทุกกลุ่มน้ำหนัก 128 ค่า น้ำหนักแบบ ternary ของ Bonsai ต้องการเพียงสเกล — ระดับต่าง ๆ มาจากสเกลเพียงอย่างเดียว — ดังนั้นไบแอสจึงเป็นภาระที่ไม่มีประโยชน์ และบล็อกมีค่าใช้จ่าย 36 ไบต์ต่อน้ำหนัก 128 ค่า แทนที่จะเป็น 34 นั่นดันอัตราแบบ packed ของแพ็ก MLX ไปที่ 2.250 บิต/น้ำหนัก ไม่ใช่ 1.72 และไม่ใช่ 1.76 มันเป็นคอนเทนเนอร์ที่แตกต่างซึ่งบรรทุกค่า ternary ชุดเดียวกัน และไฟล์ที่วัดได้บน Hugging Face มีขนาด 8.005 GiB

ตัวแปรแบบ runtime-abliterated

เมื่อวันที่ 18 กันยายน OrcaRouter ได้เผยแพร่ OrcaRouter Ternary Bonsai 2 27B Uncensored ซึ่งใช้การทำ ablation ทิศทางปฏิเสธ (refusal-direction ablation) กับโมเดลนี้ทั้งหมดในขณะรันไทม์ แนวคิดทางวิศวกรรมนี้สมควรได้รับความสนใจมากกว่าตัวผลิตภัณฑ์ ดังนั้นขอเริ่มด้วยแนวคิดนี้ก่อน

การทำ abliteration แบบดั้งเดิมจะแก้ไขค่าน้ำหนัก มันหาเส้นทางในสเปซแอกติเวชันที่สอดคล้องกับพฤติกรรมการปฏิเสธ จากนั้นก็ทำออร์โธกอนัลไลซ์เมทริกซ์น้ำหนักที่เขียนเข้าสู่ residual stream เทียบกับเส้นทางนั้น: W ← W − r(rᵀW) บนโมเดล FP16 ทั่วไปนั่นก็ใช้ได้ — เมทริกซ์ที่แก้ไขแล้วยังคงเป็นเมทริกซ์ทศนิยมแบบหนาแน่น คุณจึงบันทึกมันแล้วไปต่อได้ บน ternary pack มันเป็นทางตัน และโดยเฉพาะอย่างยิ่ง มันเป็นทางตันด้วยเหตุผลเดียวกับที่ทำให้โมเดลนี้มีอยู่ทั้งหมด การทำออร์โธกอนัลไลซ์เมทริกซ์ ternary จะให้เมทริกซ์ความละเอียดเต็มแบบหนาแน่น การจะเก็บมันกลับเข้าไปใน ternary pack คุณจะต้องทำควอนไทซ์ใหม่ — และการควอนไทซ์ใหม่กับค่าน้ำหนักที่แก้ไขแล้วไม่ได้สร้างการฝึกแบบ quantization-aware training ที่สร้างต้นฉบับขึ้นมาใหม่ คุณจะทิ้งสิ่งที่ซื้อมาไปเปล่า ๆ

ดังนั้นการโปรเจกชันจึงย้ายไปที่เวลาอนุมานแทน แทนที่จะเปลี่ยน W ให้เปลี่ยนเอาต์พุตของมันแทน:

• y ← y − α · dot(y, r) · r, คำนวณใน float32 โดยที่ y คือส่วนร่วมแบบ residual และ r คือทิศทาง refusal ที่ถูกนอร์มัลไลซ์

ที่ α = 1 องค์ประกอบของการเขียนเรสิดิวอัลแต่ละครั้งที่ขนานกับทิศทางการปฏิเสธจะถูกนำออก ที่ α = 0 โมเดลจะไม่ถูกแตะต้อง α ที่มากกว่า 1 จะฉายเกินและอาจทำให้คุณภาพลดลง เนื่องจาก α เป็นพารามิเตอร์ขณะรันมากกว่าที่จะเป็นคุณสมบัติของเช็กพอยต์ แพ็กเดียวกันจึงสามารถทดสอบ A/B กับตัวมันเองได้ในโปรเซสเดียวกัน — ซึ่งเป็นสิ่งที่การประเมินของ OrcaRouter ทำอยู่พอดี แพ็ก Bonsai ต้นฉบับยังคงเหมือนเดิมทุกบิต: ไม่มีการแก้ไขน้ำหนักใด ๆ ไม่มีการควอนไทซ์ซ้ำ ไม่มีข้อผิดพลาดจากการควอนไทซ์น้ำหนักเพิ่มเติม

รายละเอียดการนำไปใช้งานสองจุดคือจุดที่เวอร์ชันแบบง่ายของสิ่งนี้ล้มเหลว

129 จุดที่ต้องแทรกแซง ไม่ใช่ 16 จุด ทุกโมดูลที่สามารถเขียนลงใน residual stream ได้จะต้องถูกห่อ และในสถาปัตยกรรมแบบผสมนี้ นั่นคือบล็อก mlp.down_proj จำนวน 64 บล็อก เลเยอร์ linear_attn.out_proj จำนวน 48 เลเยอร์ เลเยอร์ self_attn.o_proj จำนวน 16 เลเยอร์ และ model.embed_tokens — รวมทั้งหมด 129 จุด การห่อเฉพาะ self_attn.o_proj เป็นความผิดพลาดที่เห็นได้ชัด และมันจับได้เพียง 16 จุดเท่านั้น ทำให้การเขียนอีก 113 จุดไม่ถูก projection สคริปต์ตรวจสอบตัวเองจะวัดว่าองค์ประกอบที่เหลือตามแนวทิศทางการปฏิเสธถูกผลักให้เหลือประมาณ 1e-6 ของค่าบรรทัดฐานของ residual หรือไม่ และจะเตือนหากตรวจไม่พบทั้ง 129 จุด

อย่าหมุนทิศทางซ้ำ แพ็ก ternary เก็บโปรเจกชันของมันไว้ในฐานที่หมุนแล้วบนอินพุต มิติของมัน และชดเชยที่ฝั่งแอกติเวชัน โปรเจกชันการปฏิเสธทำงานบนเอาต์พุต ของโปรเจกชันเหล่านั้น ซึ่งกลับมาอยู่ในฐานซ่อนปกติแล้ว — ดังนั้นทิศทางการปฏิเสธจึงเป็นเวกเตอร์ 5120 มิติธรรมดา และการหมุน Hadamard เพิ่มเติมกับมันจะฉายเข้ากับฐานที่ผิดไปโดยสิ้นเชิง

สิ่งที่ OrcaRouter วัดได้ — ตัวเลขของเราเอง ไม่ใช่ตัวเลขจากแหล่งอิสระ

สิ่งเหล่านี้เป็นการวัดตามกฎของ OrcaRouter เอง และควรอ่านในลักษณะเช่นนั้น: ตัวจำแนกวลีเปิดตามกฎ ไม่ใช่ผู้ตัดสินแบบ LLM, ปิดโหมดคิด, ถอดรหัสแบบ greedy, งบ 64 โทเคน โดยที่ base และ ablated เป็นน้ำหนักชุดเดียวกันในกระบวนการเดียวกัน ณ α = 0 เทียบกับ α = 1 สิ่งเหล่านี้เป็นเพียงตัวบ่งชี้ ไม่ได้อยู่ในระดับที่ตีพิมพ์ได้ และไม่ใช่การยืนยันสิ่งใดที่ Prism ML อ้าง

เกี่ยวกับการปฏิเสธ ซึ่งวัดจากสัดส่วนของพรอมต์ที่ได้รับการปฏิเสธ:

• AdvBench (n=100) — 99.0% ฐาน, 6.0% แบบตัดส่วน, โดย 56.0% ตอบแต่ห่อด้วยข้อจำกัดความรับผิด

• JailbreakBench (n=100) — 96.0% แบบพื้นฐาน, 4.0% แบบตัดส่วน, 52.0% แบบมีข้อแม้

• StrongREJECT (n=150) — 99.3% ค่าพื้นฐาน, 3.3% แบบตัดออก, 45.3% แบบมีข้อแม้

• HarmBench (n=150) — 98.7% แบบฐาน, 7.3% แบบตัดออก, 48.0% แบบมีข้อแม้

• MaliciousInstruct (n=100) — 97.0% แบบพื้นฐาน, 0.0% แบบตัดออก, 52.0% แบบมีข้อแม้

• ForbiddenQuestions (n=150) — 75.3% แบบพื้นฐาน, 5.3% แบบตัดออก, 42.7% แบบมีข้อแม้

• SimpleSafetyTests (n=50) — 96.0% ในโมเดลฐาน, 18.0% ในเวอร์ชันตัดองค์ประกอบ, 60.0% ในเวอร์ชันมีข้อแม้ — และตัวเลขนี้ยังต่ำกว่าความเป็นจริง ชุดนั้นส่วนใหญ่เป็นพรอมต์เกี่ยวกับการทำร้ายตัวเอง และโมเดลตอบกลับด้วยการเปลี่ยนไปสู่การรับมือภาวะวิกฤตโดยขึ้นต้นว่า "ฉันเสียใจอย่างสุดซึ้งที่ได้ยินว่า…" ซึ่งรายการวลีแบบตรงตัวของตัวจำแนกประเภทมองข้ามไปและให้คะแนนว่าเป็นความยินยอมปฏิบัติตาม อัตราการปฏิเสธที่แท้จริงซึ่งเหลืออยู่ในชุดนั้นสูงกว่า 18.0% ตัวจำแนกประเภทถูกปล่อยไว้ตามเดิมโดยเจตนา เพื่อให้ตัวเลขยังเทียบเคียงได้กับการ์ดโมเดลอื่น ๆ ของ OrcaRouter

ไม่มีคำตอบใดในชุดใดเลยที่ใช้โทเค็นจนหมดงบโทเค็น ดังนั้นอัตราเหล่านี้จึงไม่ถูกทำให้สูงเกินจริงเนื่องจากการตัดทอน บนพรอมป์ต์ benign การโปรเจกชันเดียวกันยังขจัดการปฏิเสธเกินเหตุด้วย: XSTest-safe ลดลงจากอัตราการปฏิเสธ 5.2% เหลือ 0.4% และเซตย่อย benign ของ JailbreakBench จาก 25.0% เหลือ 0.0% แพ็กที่เผยแพร่ปฏิเสธหนึ่งในสี่ของพรอมป์ต์ benign ในเบนช์มาร์กนั้น เมื่อทำ ablation กลับไม่ปฏิเสธเลย

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

• MMLU (n=300) — 76.7% พื้นฐาน, 77.7% แบบตัดออก, +1.0

• GSM8K (n=150) — 87.3% แบบฐาน, 86.0% แบบตัดออก, −1.3

• CMMLU (n=500) — 76.2% ฐาน, 75.6% แบบตัดออก, −0.6

การเปลี่ยนแปลงทุกอย่างอยู่ในระดับความคลาดเคลื่อนที่ขนาดตัวอย่างเหล่านี้ ข้อคำถาม GSM8K หนึ่งข้อมีค่า 0.7 คะแนน MMLU-Pro ถูกตัดออกแทนที่จะรายงาน เนื่องจากพรอมป์ต์ของมันขอให้ให้เหตุผลก่อนตอบ และ 63–64% ของคำตอบทั้งสองฝ่ายไม่ได้ไปถึงจุดนั้นภายในงบโทเคน ดังนั้นตัวเลขความแม่นยำใด ๆ จึงเป็นค่าต่ำสุดที่ถูกกำหนดโดยงบโทเคนมากกว่าจะเป็นการวัด

ข้อแม้ที่สำคัญที่สุด

ทิศทางการปฏิเสธถูกประเมินจากโมเดลฐาน BF16 ที่แพ็ก Bonsai ถูกฝึกมาจาก สถาปัตยกรรมและฐานที่ซ่อนอยู่เหมือนกันทุกประการ เรขาคณิตจึงสอดคล้องกัน แต่ทิศทางนั้นจะทนต่อการฝึกแบบคำนึงถึงการควอนไทเซชันได้ดีเพียงใดนั้นยังไม่ได้รับการวัดอย่างเต็มที่

รันไทม์สามารถพิสูจน์ได้ทางคณิตศาสตร์และถึงระดับประมาณ 1e-6 ว่ามันกำจัดทิศทางที่ให้มาออกจากทุกการเขียนค่าคงเหลือ มันไม่สามารถพิสูจน์จากเพียงเท่านั้นได้ว่าทิศทางนั้นยังคงจับคุณลักษณะเชิงพฤติกรรมเดียวกันในโมเดลที่ถูกควอนไทซ์กับที่มันเคยจับได้ในโมเดลแบบ dense สิ่งเหล่านี้เป็นข้อกล่าวอ้างที่แตกต่างกัน และมีเพียงข้อแรกเท่านั้นที่ได้ข้อยุติแล้ว ใครก็ตามที่อ่านตารางความปลอดภัยด้านบนควรอ่านโดยรู้ว่าการแทรกแซงนั้นมีประสิทธิผลเท่ากับสมมติฐานการถ่ายโอนทิศทางอย่างแม่นยำ และสมมติฐานนั้นคือคำถามที่ยังไม่มีคำตอบ

นอกจากนี้ยังมีกรอบเชิงปฏิบัติที่ OrcaRouter วางไว้กับการเปิดตัวนี้เอง ซึ่งควรค่าแก่การย้ำซ้ำมากกว่าที่จะถอดความจนเลือนหายไป: การลบทิศทางของการปฏิเสธที่เรียนรู้ไว้อาจทำให้โมเดลตอบสนองต่อคำขอที่ต้นฉบับจะปฏิเสธไปแล้ว นี่เป็นกลไกด้านการวิจัยและการควบคุมการอนุมาน ไม่ใช่หลักฐานว่าผลลัพธ์ใด ๆ ที่ได้จะปลอดภัย ถูกต้อง หรือเหมาะสม และการนำไปใช้งานที่ใช้กลไกนี้ควรใช้การควบคุมการเข้าถึงและการบังคับใช้นโยบายของตนเอง การลบการปฏิเสธไม่ใช่การปรับปรุงที่ได้มาเปล่า ๆ และบทความนี้ไม่ได้เขียนขึ้นราวกับว่าเป็นเช่นนั้น

ข้อสังเกตเชิงปฏิบัติเพิ่มเติมอีกสามข้อสำหรับผู้ที่ต้องการทำซ้ำผลนี้ แพ็กนี้ต้องโหลดด้วยรันไทม์ที่บันเดิลมาให้เอง ตัวโหลด MLX ทั่วไปอาจดูเหมือนโหลดสำเร็จ แต่กลับคำนวณสิ่งที่ผิดอยู่เงียบ ๆ ฉะนั้นถ้าผลลัพธ์ดูผิดตั้งแต่ก่อนเปิดใช้ ablation ด้วยซ้ำ ให้ตรวจเส้นทางการโหลดก่อนเป็นอันดับแรก มีการรองรับ layer-selective ablation การแทรกแซงจึงไม่จำเป็นต้องเป็นแบบทั้งหมดหรือไม่ทำเลย และการประเมิน ablation นั้นรันบนการขยายเป็น FP16 แบบ unfolded ของแพ็ก แทนที่จะให้แพ็กขับเคลื่อนเคอร์เนลของตัวเอง เนื่องจาก packed quantized matmul ไม่มี CUDA implementation และ CPU backend ต้องใช้เวลาหลายนาทีต่อ forward pass หนึ่งครั้ง การขยายนั้นเก็บค่า ternary ของแพ็กไว้อย่างแม่นยำ และให้การแจกแจงโทเคนถัดไปของแพ็กเองตรงกันถึงทศนิยมสามตำแหน่งจากการสุ่มตรวจ แต่มันเป็นการเปลี่ยนคอนเทนเนอร์ และเป็นเรื่องที่ควรรู้ไว้ โค้ดและตารางทั้งหมดอยู่ในรีโพซิทอรี OrcaRouter Ternary Bonsai 2 27B Uncensored ส่วนการเปรียบเทียบอีกชุดหนึ่งที่ครอบคลุมบิลด์ MLX ที่ผ่าน ablation เทียบกับเส้นทาง MLX ของ Qwen3.8 27B ที่ยังไม่แก้ไข จะลงรายละเอียดเชิงลึกเกี่ยวกับรันไทม์มากกว่า

ทิศทางของเรื่องนี้ และสิ่งที่ยังไม่ได้รับการพิสูจน์

สิ่งที่โมเดล 27B แทบไม่สูญเสียข้อมูลในขนาดประมาณหกกิกะไบต์เปลี่ยนแปลงสำหรับเอเจนต์ในเครื่องนั้น ส่วนใหญ่อยู่ที่ว่าอะไรจะกลายเป็นสิ่งที่คงอยู่ในหน่วยความจำ โมเดลภาษาที่พอดีพร้อมกับหน้าต่างบริบทจริงบนแล็ปท็อป 16 GB สามารถโหลดค้างไว้ได้ในขณะที่เอเจนต์ทำงานอื่น — อ่านไฟล์ เรียกใช้เครื่องมือ ถือแผนข้ามเทิร์น — แทนที่จะถูกสลับเข้ามาต่อคำขอหรือถูกส่งไปยังเซิร์ฟเวอร์ นั่นคือความแตกต่างระหว่างโมเดลในเครื่องที่คุณลองใช้ กับโมเดลในเครื่องที่คุณปล่อยให้รันอยู่ และมันเป็นคุณสมบัติเฉพาะที่ตัวเลขสำหรับเอเจนต์ τ 2-Bench ที่ 80.2 และ BFCL v3 ที่ 74.9 มีไว้เพื่อสนับสนุน

สิ่งที่ยังไม่ได้รับการพิสูจน์นั้นมีรายการยาวกว่าที่ประกาศบอกเป็นนัยไว้

• ไม่มีการทำซ้ำโดยอิสระ ตัวเลขคุณภาพทุกตัวในบทความนี้ — 83.9, 98.2%, และค่าเฉลี่ยตามหมวดหมู่ — เป็นการวัดของ Prism ML เองบนชุดทดสอบของ Prism ML เอง นั่นไม่ใช่ข้อบกพร่องในการเปิดตัว; มันเป็นเพียงสิ่งที่อายุหนึ่งวันเป็นเช่นนั้น และมันยังเป็นสิ่งแรกที่จะเปลี่ยนแปลง

• งานแบบเอเจนต์ระยะยาวเป็นส่วนที่อ่อนที่สุดในตารางของผู้ขายเอง ไม่ใช่ส่วนที่แข็งแกร่งที่สุด Terminal-Bench 2.1 ที่ 52.8 เทียบกับ 69.7 เป็นช่องว่างจริง และผู้ขายกล่าวว่าความสามารถนี้ยังมีเพียงบางส่วน

• พรอมต์ที่คุณยังไม่เคยลอง โปรไฟล์ความล้มเหลวของโมเดลบิตต่ำนั้นเลือกเกิดขึ้นเฉพาะบางกรณี และการทรุดตัวของ IQ2_XXS บน AIME26 และ LiveCodeBench ในขณะที่ยังรักษาคะแนน 85.79 บน MMLU-Redux ได้ คือหลักฐานที่ชัดเจนที่สุดเท่าที่มีว่าค่าเฉลี่ยจากเกณฑ์มาตรฐานไม่ได้บอกคุณว่าจะเกิดอะไรขึ้นกับภาระงานของคุณ Bonsai 2 ไม่แสดงการทรุดตัวนั้นบนสองเกณฑ์มาตรฐานดังกล่าว ซึ่งเป็นเรื่องที่น่าพอใจ และไม่ใช่สิ่งเดียวกับการรับประกัน

• คำถามเรื่องการถ่ายโอนทิศทางในตัวแปรแบบ abliterated ข้างต้น ซึ่งไม่อาจหาข้อยุติได้โดยโครงสร้าง

• เคอร์เนลจะยังทนไหวหรือไม่เมื่อรันไทม์เคลื่อนไป ตอนนี้โมเดลนี้ต้องใช้ fork; llama.cpp มาตรฐานปฏิเสธสองในสามรูปแบบ และทำให้รูปแบบที่สามเพี้ยนไปอย่างเงียบ ๆ จนกว่าเคอร์เนลเหล่านั้นจะขึ้น upstream คำกล่าวที่ว่า "รันได้ทุกที่ที่ llama.cpp รัน" จึงยังไม่จริงสำหรับโมเดลนี้

การเปิดตัวนี้เองไม่เป็นข้อกังขา โมเดลมัลติโมดัลระดับ 27B ที่ขนาด 5.93 GB ซึ่งคิดเป็นหนึ่งในเก้าของขนาดของสิ่งที่มันถูกบีบอัดมา โดยมีความสามารถด้านคณิตศาสตร์และการเขียนโค้ดอยู่ในระดับเดียวกับโมเดลต้นทาง และการทำตามคำสั่งดีขึ้นเล็กน้อย ถือเป็นจุดทำงานที่แตกต่างอย่างแท้จริงสำหรับการอนุมานในเครื่อง ท่าทีที่สมเหตุสมผล ณ วันที่ 18 กันยายน 2026 คือการถือขนาดไฟล์เป็นข้อเท็จจริง มองตัวเลขการคงความสามารถไว้เป็นคำกล่าวอ้างของผู้ขายที่ระบุอย่างระมัดระวังเมื่อหนึ่งวันก่อน บนชุดทดสอบที่ผู้ขายเลือกเอง และรอตัดสินใจเกี่ยวกับภาระงานของคุณเองจนกว่าจะได้ลองรันมันกับภาระงานนั้น

โค้ด runtime-ablation ทิศทางการปฏิเสธ และตารางการประเมินฉบับเต็มได้รับการเผยแพร่โดย OrcaRouter พร้อมกับแพลตฟอร์มการจัดเส้นทางที่ทีมสร้างขึ้น