Ternary Bonsai 2 27B: ما الذي يتّسع في 5.9 GB، وما الذي لا تخبرك به نسبة 98.2%؟

Ternary Bonsai 2 27B هو نموذج لغوي متعدد الوسائط يضم 27.36 مليار معامل، أعلنت عنه Prism ML في 17 سبتمبر 2026، والأمر الذي ينبغي فهمه بشأنه هو أن أوزانه اللغوية لا تأخذ إلا واحدة من ثلاث قيم بالضبط. نموذجه الأساسي هو Qwen3.8 27B — وهو نموذج انتباه هجين بسعة 27B — ويحافظ Bonsai على تلك البنية، وذلك التدريب، وذلك الشكل، ويستبدل أوزان مصفوفات النموذج اللغوي بتمثيل ثلاثي. حجم الملف المُشحون هو 5.93 GB. والمرجع كامل الدقة هو 53.81 GB. والادعاء الرئيسي للبائع هو أنه يحتفظ بنسبة 98.2% من متوسط المعايير الخاص بالنسخة الأصلية.

ابدأ بالجزء الذي سيتجاهله معظم التغطية: أن 98.2% هو رقم Prism ML الخاص، مقاسًا على مجموعة اختبارات Prism ML الخاصة المكونة من 20 معيارًا، باستخدام أداة Prism ML الخاصة، ولم يكرره أحد خارج الشركة. هذا ليس اتهامًا — بل هو الوضع الطبيعي بعد يوم واحد من الإصدار، وهو بالضبط التصنيف الذي يجب أن تمنحه له. ما يمكنك التحقق منه بشكل مستقل اليوم هو الملف: واجهة برمجة تطبيقات Hugging Face تسرد Ternary-Bonsai-2-27B-PTQ1_0.gguf بحجم 5.947 جيجابايت مقابل مرجع FP16 بحجم 53.808 جيجابايت، وهو انخفاض بنسبة 9.05x ويتوافق مع "حوالي 9x" التي ذكرها المورد دون الحاجة إلى الوثوق بأي شخص. الحجم حقيقة. الاحتفاظ بالجودة هو قياس المورد. المادة المثيرة للاهتمام تقع في المنتصف — التفصيل حسب الفئة، الذي يوضح بدقة أين يكون الضغط مجانيًا وأين لا يكون.

هناك أيضًا وجه ثانٍ لهذا الإصدار. في 18 سبتمبر، بعد يوم واحد من الإعلان، نشرت OrcaRouter نسخة مُزالة الرفض أثناء التشغيل من النموذج نفسه — OrcaRouter Ternary Bonsai 2 27B Uncensored — وهي تزيل اتجاه رفض مُتعلَّمًا في وقت الاستدلال وتترك الأوزان متطابقة بتًا ببت. وهي مُغطاة في قسمها الخاص أدناه، لأن التقنية هي الجزء المثير للاهتمام، ولأن حدودها لا تقل إفادة عن نتائجها.

إنه نموذج Qwen3.8 27B مضغوط، وليس نموذجًا مدرَّبًا حديثًا

هذا التمييز هو الفرق بين شرح الإصدار وتكرار بيان صحفي. لم تدرّب Prism ML نموذجًا بحجم 27B من الصفر، ولم تستخدم وصفة تدريب مسبق جديدة. ما فعلته هو أنها أخذت Qwen3.8 27B وغيّرت التمثيل الرقمي الذي تُخزَّن وتُحسَب به أوزانها.

الهندسة المعمارية دون تغيير، وهي هندسة النموذج الأساسي: تصميم انتباه هجين يتكوّن من حوالي 75% انتباه خطي و25% انتباه كامل، مع كتل SwiGLU MLP، وRoPE وRMSNorm. هذا العمود الفقري الهجين هو أيضاً سبب وصف سياق الـ 262 ألف رمز بأنه قادر على السياق الكامل بدلاً من مجرد مدعوم — فالانتباه شبه الخطي هو ما يجعل السياق الطويل ممكناً بتكلفة معقولة على الجهاز. النموذج هو نموذج لغوي بصري: يقبل الصور بالإضافة إلى النص، وبرج الرؤية هو برج Qwen القياسي غير المُكمَّم، المعبأ بشكل منفصل.

ما قدّمته Prism ML هو أمران. الأول هو التمثيل الثلاثي نفسه، بالإضافة إلى التدريب الواعي بالتكميم الذي يجعله قابلاً للصمود. والثاني هو النوى — نوى مخصّصة منخفضة البتات لمكدس الانتباه الهجين ذاك على Apple Silicon وCUDA، وهي تعمل مباشرةً على الأوزان المعبّأة بدلاً من فكّها إلى FP16 وضربها. وبدون المساهمة الثانية، تكون الأولى مجرّد صيغة تخزين لا سبيل لاستخدامها بسرعة.

تذكر الورقة البيضاء الخاصة بـ Prism ML تقسيم المعاملات على النحو التالي: 24.35 مليار في العمود الفقري اللغوي عبر 64 كتلة، و2.54 مليار في التضمين ورأس LM، و0.47 مليار في برج الرؤية المكوّن من 27 كتلة، ليصبح الإجمالي 27.36 مليار. برج الرؤية هو الجزء الوحيد الذي يُعد فعلاً قطعة أثرية مختلفة: إصدار GGUF يحزمه كملف mmproj 4-بت بحجم حوالي 0.63 جيجابايت، يتم تحميله فقط عند وصول صورة فعليًا، لذا فإن تقديم النص فقط لا يحمله أبدًا.

هذا هو الجيل الثاني من 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

إذن لا يزال النموذج يمثّل مدى واسعًا من المقادير — لكنه يمثّلها بخطوات خشنة على مستوى المجموعات بدلًا من خطوات لكل وزن على حدة. والصفر ليس أثرًا من آثار التقريب؛ بل هو حالة ثالثة حقيقية، ووجوده هو ما يسمح لمجموعة من 128 وزنًا بأن تكون صامتة في الغالب عندما تحتاج إلى ذلك.

الأساس المُدوَّر هو الجزء الذي يفاجئ الناس. قبل أن يحدث الإسناد الثلاثي، تُحوَّل كل مصفوفة أوزان كتلةً كتلةً عبر تدوير متعامد — مصفوفة والش–هادامارد مقترنة بقطر ثابت من إشارات ±1، بحجم كتلة 1024 — وتُختار القيم الثلاثية في ذلك الفضاء المُدوَّر. تُدمج عملية التدوير في الأوزان المخزنة أثناء التحضير، فلا تكلّف بتات إضافية ولا حركة نقل إضافية للأوزان. عند الاستدلال، تُطبّق بيئة التشغيل التحويل المطابق على التنشيطات بدلًا من ذلك، ويعلن النموذج المعبأ عن تدويره في بياناته الوصفية، بحيث إما أن تُطبّق بيئة التشغيل التحويل المطابق أو ترفض تحميل الملف.

لماذا نتكلف العناء؟ لأن دوران Hadamard يوزّع طاقة مصفوفة الأوزان بشكل أكثر تساويًا عبر الإحداثيات، ما يجعل التكميم الثلاثي المستويات اللاحق أقل ضررًا بكثير مما سيكون عليه مع التوزيع الخام كثير النتوءات. هذا الدوران ليس زخرفة؛ إنه السبب في أن نموذجًا ثلاثي القيم يمكنه الاحتفاظ بأي شيء يشبه جودة النموذج الأصلي. لكن التكلفة هي أن التحويل يقع على المسار الحرج لكل إسقاط عند حجم دفعة 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 ميجابايت عند bf16 — بدقة أعلى، معظمها مسار الحالة التكرارية لطبقات الانتباه الخطي بالإضافة إلى أوزان التطبيع. هذه الموتّرات لا تُدوَّر ولا تُكمَّم، وهي ما ينقل الرقم من 1.71 إلى 1.72. عند 1.72 تكون البصمة المثالية 5.80 جيجابايت، أي انخفاض بنحو 9.3x. هذا هو صف "True Ternary" من Prism ML، وهو هدف وليس ملفًا تنزّله.

• 1.76 بت لكل وزن — الـ GGUF الفعلي الذي يتم شحنه. النوى الفعالة تحتاج صيغة تغليف، و PTQ1_0 من Prism ML يحزم التريتات بكثافة، ليصل إلى 1.76 بت/وزن في 5.93 جيجابايت، حوالي 9.1x. هذا هو الملف وراء كل من "5.9 جيجابايت" و "أصغر بـ 9 مرات" الذي يذكره الإعلان، وهو الذي تؤكده القياسات أعلاه.

التعبئة الثانية هي PQ2_0، وهي تخزّن كل تريت في خانة بسعة 2 بت بدلاً من تخزينها كثيفًا. وهي تستهلك مساحة أكبر مقابل فك تعبئة أرخص: 2.16 بت/وزن في 7.25 غيغابايت، أي نحو 7.4x. ولا توجد تعبئة أسرع بشكل موحّد — فـ PTQ1_0 تنقل نحو 18% أقل من بيانات الأوزان لكل خطوة، لكنها تدفع تكلفة حسابية لفك تعبئة التريتات الكثيفة، لذا تتفوق على بطاقات جيل Ada وL4 حيث تكون الذاكرة هي القيد الحاكم، وتخسر على Hopper وBlackwell وApple silicon حيث يكون فك الترميز بدفعة 1 محدودًا بإنتاجية التعليمات بدلاً من ذلك. وتفضّل معالجة المطالبات PQ2_0 في كل مكان، لأنها محدودة بالحوسبة.

ملاحظتان إداريتان لكل من يتحقق من هذه مقابل المصادر. أولًا، مستندات Prism ML نفسها تُقرّب الأرقام بشكل مختلف قليلًا — جدول التخزين في الورقة البيضاء يعطي PTQ1_0 بـ 1.76 بت/وزن عند 5.93 غيغابايت، بينما تعطي بطاقة نموذج GGUF على Hugging Face ‏1.75 و5.95 غيغابايت، والملف المقاس هو 5.947 غيغابايت. هذا هو الملف نفسه موصوفًا بدقات مختلفة، وليس خلافًا في الجوهر. ثانيًا، التخفيض المعلن «أكثر من 9x» هو من الجهة المورّدة؛ وعند قياسه مقابل الملفات الفعلية يكون 53.808 / 5.947 = 9.05x، وهو متسق.

الصورة المرجعية: ليست المتوسط، بل الشكل

الرقم الرئيسي هو متوسط قدره 83.9 مقابل 85.4 لخط الأساس 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 نقطة، وهو أكبر خسارة في فئة واحدة. ومن الجدير بالملاحظة أن برج الرؤية نفسه ليس الجزء المضغوط؛ بل نموذج اللغة الذي يقرأ مخرجاته هو.

• القدرات الوكيلية واستدعاء الأدوات — 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.

أين تثق به وأين لا تثق به. ثق في الشكل في الرياضيات والبرمجة واتباع التعليمات — فهذه هي الفئات التي تُظهر فيها التقنية بشكل ملموس أنها تفعل ما تدّعيه، وهي تُقاس على نفس منصة الاختبار المستخدمة في خط الأساس. توخَّ الحذر بشأن العمل الوكيلي طويل الأفق: فالمعياران اللذان يختبران فعليًا الهندسة المستدامة المدفوعة بالأدوات، Terminal-Bench 2.1 وSWE-bench Verified، يُظهران فجوة أكبر بدرجة ملموسة مما يوحي به الإجمالي، ويقول المورّد ذلك بدلًا من إخفائه. وتعامل مع الجدول بأكمله باعتباره قياس مختبر واحد على منصة اختبار واحدة إلى أن تُشغّله جهة أخرى. هذا التحذير ليس مجرد إجراء شكلي هنا — إنه الفرق بين "هذا النموذج يحتفظ بنسبة 98.2%" و"قاس مورّد هذا النموذج 98.2% على مجموعة اختارها المورّد". كلاهما صحيح؛ أحدهما فقط حقيقة تخص النموذج.

لماذا يتفوق هذا على إصدار IQ2_XXS من النموذج الأساسي نفسه

يستحق هذا قسمًا خاصًا به بدلًا من سطر واحد، لأنه يمثل الحجة الكاملة لصالح التدريب الثلاثي المدرك للتكميم مقابل التكميم بعد التدريب.

الطريقة التقليدية لجعل Qwen3.8 27B صغيرًا هي تكميمه بعد التدريب. ونقطة المقارنة في الورقة البيضاء هي نسخة IQ2_XXS GGUF مبنية من النموذج الأساسي نفسه:

• Ternary Bonsai 2 27B — 1.76 بت/وزن، 5.93 جيجابايت، متوسط 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 الحجة نفسها في رقم مشتق واحد يسميه كثافة الذكاء — تقريبًا، قدرة المعايير لكل غيغابايت. وعلى مجموعة المعايير العشرين، يسجل 0.444 لكل غيغابايت لـ Bonsai 2، و0.276 لبناء IQ2_XXS، و0.051 لـ FP16. المقياس من إنشاء المورّد نفسه، وترجيحه خيار تصميمي لا قانون؛ لكن الترتيب الذي ينتجه هو الترتيب نفسه الذي ينتجه الجدول الخام، لذا فهو يضيف تفسيرًا لا دليلًا.

ملاحظة صادقة أخرى حول المقارنة. تُورد بطاقة نموذج GGUF الخاصة بـ Prism ML تقييمًا ثانيًا أضيق — مجموعة من 14 معيارًا في وضع التفكير — تظهر فيه نسبة الاستبقاء نفسها مرة أخرى عند 84.78 مقابل 86.32، مع IQ2_XXS عند 72.59. إن وصول مجموعتين مختلفتين إلى النسبة نفسها البالغة 98.2% يعد تأكيدًا طفيفًا على أن الادعاء الإجمالي ليس ناتجًا عن اختيار معيار واحد بعينه. لكن لا يزال المختبر نفسه هو من يدير كليهما، على منصة الاختبار نفسها. تحليلنا الأكثر تفصيلًا لهذه المواجهة، بما في ذلك مسألة صيغة التعبئة، موجود في المقارنة مع إصدارات Qwen3.8 27B GGUF.

ما يتطلبه التشغيل فعلياً

أرقام الإنتاجية، من قياس tg128 المعياري في الورقة البيضاء عند حجم دفعة 1 مع استبعاد برج الرؤية:

• 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 توكن/ث على حزمة PQ2_0 عند 0.582 مللي واط/ساعة لكل توكن

الادعاء العملي الذي تقدمه Prism ML ليس نسبة تسريع بل غياب: خط الأساس FP16 عند 53.8 جيجابايت لا يتسع على الإطلاق على حاسوب محمول بسعة 16 جيجابايت، لذا فإن العبارة ذات المعنى هي أن نموذجًا من فئة 27B يعمل الآن بشكل تفاعلي على الأجهزة اليومية. على M5 Pro، يبث فك التشفير المقاس حوالي 201 جيجابايت/ثانية من الأوزان، مما يؤكد الملف الشخصي المهيمن على عرض النطاق الترددي للذاكرة الذي صُمم التمثيل منخفض البتات لاستغلاله.

ثم الحالات الحدية، التي تهم أكثر من أرقام الذروة.

لا يمكنك استخدام نسخة llama.cpp القياسية. توجد الأنوية الثلاثية للانتباه الهجين في تفريعة llama.cpp الخاصة بـ Prism ML. ترفض نسخة llama.cpp القياسية النوعين PTQ1_0 وPQ2_0 باعتبارهما غير معروفين، والأخطر من ذلك أنها تحمّل صيغة Q2_0 الثلاثية الأقدم دون أي تحذير وتنتج نتائج تالفة، لأنها لا تملك بيئة تشغيل لتنشيط Hadamard. إذا شغّلت هذا النموذج على ملف ثنائي لا يطبّق الدوران المطابق، فلن تحصل على خطأ؛ بل ستحصل على هراء يبدو طليقًا. هذه هي الطريقة الأكثر ترجيحًا لإضاعة عصر كامل على هذا الإصدار.

لا يحتوي حزمة 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 بت تخزّن كتلتها مقياسًا FP16و وانحيازًا FP16 لكل مجموعة من 128 وزنًا. لا تحتاج أوزان Bonsai الثلاثية إلا إلى المقياس — فالمستويات تنبع من المقياس وحده — لذا فإن الانحياز وزن زائد لا طائل منه، وتكلّف الكتلة 36 بايت لكل 128 وزنًا بدلًا من 34. وهذا يرفع المعدل المعبّأ لحزمة MLX إلى 2.250 بت/وزن، لا 1.72 ولا 1.76. إنها حاوية مختلفة تحمل القيم الثلاثية نفسها، وملفها المقيس على Hugging Face هو 8.005 GiB.

النسخة المُستأصلة في وقت التشغيل

في 18 سبتمبر، نشرت OrcaRouter نموذج OrcaRouter Ternary Bonsai 2 27B Uncensored، الذي يطبّق استئصال اتجاه الرفض على هذا النموذج بالكامل أثناء التشغيل. الفكرة الهندسية تستحق اهتمامًا أكبر من المنتج، لذا إليك الفكرة أولًا.

الاجتثاث التقليدي يعدّل الأوزان. فهو يجد اتجاهًا في فضاء التنشيط يقابل سلوك الرفض، ثم يجعل مصفوفات الأوزان التي تكتب في المسار المتبقي متعامدة معه: W ← W − r(rᵀW). في نموذج FP16 عادي لا بأس بذلك — فالمصفوفة المعدّلة تظل مصفوفة كثيفة بالفاصلة العائمة، لذا تحفظها وتمضي قدمًا. أما على حزمة ثلاثية القيم فهو طريق مسدود، وبالتحديد هو طريق مسدود للسبب ذاته الذي وُجد هذا النموذج كله من أجله. إن جعل مصفوفة ثلاثية القيم متعامدة يُنتج مصفوفة كثيفة كاملة الدقة. ولتخزين ذلك مرة أخرى في الحزمة الثلاثية، سيتعين عليك إعادة التكميم — وإعادة تكميم أوزان معدّلة لا تعيد إنتاج التدريب الواعي بالتكميم الذي أنتج الأصل. وستكون قد أهدرت بالضبط ما تم شراؤه.

لذا ينتقل الإسقاط إلى وقت الاستدلال بدلًا من ذلك. بدلًا من تغيير W، غيّر مخرجاته:

• y ← y − α · dot(y, r) · r، محسوبًا بصيغة float32، حيث y مساهمة متبقية و r هو اتجاه الرفض المطبع

عند α = 1، يُزال المكوّن الموازي لاتجاه الرفض من كل كتابة متبقية. وعند α = 0 يبقى النموذج دون تغيير. أما α الأكبر من 1 فيُفرط في الإسقاط وقد يخفض الجودة. ولأن α معامل زمن تشغيل وليس خاصية في نقطة تفتيش، يمكن اختبار الحزمة نفسها بطريقة A/B مقابل نفسها في العملية نفسها — وهذا بالضبط ما تفعله تقييمات OrcaRouter. تبقى حزمة Bonsai الأصلية متطابقة على مستوى البت: لا تعديل لأي أوزان، ولا إعادة تكميم، ولا خطأ تكميم إضافي في الأوزان.

هناك تفصيلان في التنفيذ يفشل عندهما أي إصدار ساذج من هذا.

129 موقع تدخل، وليس 16. كل وحدة يمكنها الكتابة في التدفق المتبقي يجب تغليفها، وفي هذه المعمارية الهجينة تكون 64 كتلة mlp.down_proj، و48 طبقة linear_attn.out_proj، و16 طبقة self_attn.o_proj، وmodel.embed_tokens — 129 إجمالًا. تغليف self_attn.o_proj فقط هو الخطأ الواضح، وهو يلتقط 16 منها، تاركًا 113 كتابة أخرى غير مُسقطة. يقيس نص برمجي للتحقق الذاتي ما إذا كان المكوّن المتبقي على امتداد اتجاه الرفض قد دُفع إلى نحو 1e-6 من معيار المتبقي، ويحذر إذا لم يكتشف جميع المواقع الـ129.

لا تُعِد تدوير الاتجاه.تُبقي الحزمة الثلاثية إسقاطاتها في أساس مُدار على بُعد الإدخال الخاص بها، وتعوّض من جانب التنشيط. يعمل إسقاط الرفض على مخرجات تلك الإسقاطات، التي عادت بالفعل إلى الأساس المخفي العادي — لذا فإن اتجاه الرفض متجه عادي بأبعاد 5120، وسيؤدي تطبيق تدوير هادامارد إضافي عليه إلى الإسقاط مقابل الأساس الخطأ تمامًا.

ما قاسه OrcaRouter — أرقامنا الخاصة، وليست أرقامًا مستقلة

هذه قياسات OrcaRouter الخاصة القائمة على القواعد، وينبغي قراءتها على هذا الأساس: مصنّف عبارات افتتاحية قائم على القواعد، وليس حكمًا من LLM، مع تعطيل التفكير، وفك ترميز جشع، وميزانية 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.

لم يستنفد أي رد في أي مجموعة ميزانية الرموز الخاصة به، لذا لا تُضخَّم أي من هذه المعدلات بسبب الاقتطاع. وعلى المطالبات الحميدة، يزيل الإسقاط نفسه أيضًا الرفض المفرط: فانخفض معدل الرفض في XSTest-safe من 5.2% إلى 0.4%، وانخفضت المجموعة الفرعية الحميدة لدى JailbreakBench من 25.0% إلى 0.0%. وترفض الحزمة المنشورة ربع المطالبات الحميدة في ذلك المعيار؛ وعند استئصالها، لا ترفض أيًّا منها.

من حيث القدرة، فإن كون الأوزان متطابقة على مستوى البتات يعني أنه لا توجد إعادة تكميم يُدفع ثمنها، والقياسات متسقة مع ذلك:

• MMLU (ن=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، أنها تزيل الاتجاه المُزوَّد من كل كتابة إلى المتبقي. لكنها لا تستطيع أن تُثبت من ذلك وحده أن الاتجاه لا يزال يلتقط السمة السلوكية نفسها في النموذج المكمَّم التي كان يلتقطها في النموذج الكثيف. هذان ادّعاءان مختلفان، ولم يُحسَم إلا الأول. ينبغي لكل من يقرأ جدول السلامة أعلاه أن يقرأه وهو يعلم أن التدخّل فعّال تمامًا بقدر افتراض نقل الاتجاه، وأن ذلك الافتراض هو المسألة المفتوحة.

هناك أيضًا الإطار العملي الذي يضعه OrcaRouter على الإصدار نفسه، وهو جدير بالتكرار بدلًا من إعادة صياغته بما يطمسه: إن إزالة اتجاه رفض مُتعلَّم قد تجعل النموذج يستجيب لطلبات كان النموذج الأصلي سيرفضها. هذه آلية بحثية وخاصة بالتحكم في الاستدلال، وليست دليلًا على أن أي مخرجات ناتجة آمنة أو صحيحة أو مناسبة، وعلى عمليات النشر التي تستخدمها أن تطبّق ضوابط الوصول وإنفاذ السياسات الخاصة بها. إزالة حالات الرفض ليست تحسينًا مجانيًا، ولم تُكتب هذه المقالة وكأنها كذلك.

ثلاث ملاحظات عملية إضافية لأي شخص يعيد إنتاج ذلك. يجب تحميل الحزمة باستخدام بيئة التشغيل المضمّنة الخاصة بها — فقد يبدو محمّل MLX عادي وكأنه حمّلها بنجاح بينما يحسب الشيء الخطأ بصمت، لذا إذا بدت المخرجات خاطئة قبل حتى تمكين الاستئصال، فافحص مسار التحميل أولًا. الاستئصال الانتقائي حسب الطبقة مدعوم، لذا لا يلزم أن يكون التدخل إما كليًا أو لا شيء. وقد أُجري تقييم الاستئصال على توسعة FP16 غير المطوية للحزمة بدلًا من تشغيل الحزمة لنواها الخاصة، لأن ضرب المصفوفات المعبّأ والمكمَّم ليس له تنفيذ CUDA وتحتاج الواجهة الخلفية CPU إلى دقائق لكل تمريرة أمامية؛ تلك التوسعة تحمل القيم الثلاثية للحزمة بدقة تامة وتعيد إنتاج توزيعات الرمز التالي الخاصة بالحزمة نفسها إلى ثلاث منازل عشرية في فحوصات موضعية، لكنه تغيير في الحاوية ويستحق معرفته. الشيفرة والجداول الكاملة موجودة في مستودع OrcaRouter Ternary Bonsai 2 27B Uncensored. وهناك مقارنة منفصلة تغطي نسخة MLX المستأصلة مقابل مسار Qwen3.8 27B MLX غير المعدَّل وتتعمق أكثر في تفاصيل بيئة التشغيل.

إلى أين يتجه هذا، وما لا يزال غير مُثبت

ما يغيّره نموذج 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) أعلاه، وهي غير محلولة بحكم التكوين.

• ما إذا كانت الأنوية تصمد مع تطوّر بيئات التشغيل. في الوقت الراهن، يحتاج هذا النموذج إلى تفرّع؛ إذ ترفض نسخة llama.cpp القياسية اثنتين من الصيغ الثلاث وتُشوّه الثالثة بصمت. وإلى أن تصل تلك الأنوية إلى المنبع (upstream)، فإن "يعمل في أي مكان يعمل فيه llama.cpp" لا ينطبق بعد على هذا النموذج.

الإصدار نفسه ليس محل تساؤل. نموذج متعدد الوسائط من فئة 27B بحجم 5.93 غيغابايت، ببصمة تعادل تُسع بصمة الأصل الذي ضُغط منه، مع مستوى في الرياضيات والبرمجة مماثل للنموذج الأصل واتباع تعليمات متقدم قليلاً، هو نقطة تشغيل مختلفة فعلاً للاستدلال المحلي. الموقف المعقول في 18 سبتمبر 2026 هو أن تعتبر حجم الملف حقيقة مسلّمة، وأن تأخذ رقم الاحتفاظ باعتباره ادعاءً حذراً من المورّد صدر قبل يوم واحد على مجموعة اختبارات اختارها المورّد، وأن ترجئ الحكم على عبء عملك الخاص حتى تشغّل النموذج عليه.

كود الاستئصال وقت التشغيل، واتجاه الرفض، وجداول التقييم الكاملة منشورة منOrcaRouter، إلى جانب منصة التوجيه التي يبنيها الفريق.