يصبح ملف نموذج ضخم أصغر بكثير، وفجأة يبدو الذكاء الاصطناعي المحلي ممكنًا على جهاز في متناول يدك. التوفير في الذاكرة ظاهر. أما ما يبقى خفيًا في البداية فهو المعلومات التي تضيع بسبب تغيّر تمثيل الأعداد، وما إذا كانت هذه الخسارة مهمة لمهمتك.
تصف وثائق التكميم في llama.cpp طرقًا تُخزَّن بها أوزان النموذج بدقة أقل. وقد يوفّر هذا المساحة ويغيّر المعالجة، لكنه قد يكلّف أيضًا من الجودة. لذا فإن عدد البتات خاصية تقنية وليس ختم جودة عامًا.
تجربة عددية دون نموذج
لفهم الفكرة، تكفي في البداية طريقة تجريبية بسيطة مصنوعة منزليًا. نحصر الأعداد في النطاق من سالب واحد إلى واحد ونربطها بمستويات موزعة بالتساوي. نظريًا، تتسع أربعة مستويات في بتّين، وستة عشر مستوى في أربعة. ولا يحاكي هذا المثال أي طريقة GGUF محددة.
def runden_auf_stufen(wert, stufen):
wert = max(-1.0, min(1.0, wert))
index = round((wert + 1) * (stufen - 1) / 2)
return 2 * index / (stufen - 1) - 1
werte = [-0.83, -0.12, 0.18, 0.76]
for stufen in (4, 16):
angenaehert = [runden_auf_stufen(x, stufen) for x in werte]
fehler = max(abs(a-b) for a, b in zip(werte, angenaehert))
print(stufen, angenaehert, "largest deviation:", fehler)شغّل مثال Python الصغير ثم غيّر قيمة قريبة من حدّ أحد المستويات. يمكنك أن تلاحظ مباشرة كيف تقع مدخلات مختلفة على المستوى المخزَّن نفسه. وهذه خسارة في التفاصيل العددية، وليست خطأً مقيسًا في إجابة نموذج لغوي.
طرق التكميم الحقيقية أكثر تعقيدًا. فقد تعالج الأوزان على شكل كتل وتستخدم معلومات تحجيم إضافية. ولهذا السبب وحده، لا يمكن استنتاج حجم النموذج على نحو موثوق من رقم بتات واحد بوصفه حسابًا بسيطًا للتخزين.
المهمة الفعلية هي التي تحسم
قبل مقارنة النماذج، أعدّ خمس مهام قصيرة ذات متطلبات معروفة. تحتوي ملاحظة أولى على عدد المشاركين. وتحتوي ثانية على نفي. وتذكر ثالثة استثناءً. وتحتوي رابعة على تفاصيل متناقضة، وتفتقر خامسة إلى معلومة يجري البحث عنها.
لكل مهمة، دوّن ما يجب الحفاظ عليه. على سبيل المثال: ستة مشاركين، والمواد فقط بعد الموافقة، والتاريخ المجهول يبقى مجهولًا. بهذه الطريقة تحكم على الآثار في عملك، لا على مدى لطف وقع الإجابة فحسب.
قد يناسب إصدارٌ أصغر الملخصاتِ البسيطة جيدًا ويفشل في مهمة حدّية معينة. ونجاحٌ واحد ليس حكمًا عامًا على الجودة. كما أن ليس كل انحراف لغوي مهمًا من حيث المضمون؛ فالمهم هو المتطلبات المحددة مسبقًا.
المقارنة العادلة تغيّر أقل قدر ممكن
اختر إصدارات من مراجعة الأساس نفسها، وأبقِ الموجّه وبيئة التشغيل والمهام كما هي. فإذا دخل جيل نموذج مختلف، بدأت مقارنة مختلفة. ويساعدك اسم الملف والمصدر ومجموع التحقق على التعرّف لاحقًا على الملفات المستخدمة فعلًا.
إلى جانب الانحرافات في المضمون، دوّن أيضًا متطلبات الذاكرة والوقت المقيسين فعلًا. فملف الأوزان وحده لا يصف متطلبات التشغيل الكاملة؛ إذ تحتاج المعالجة الإضافية والسياق المستخدم أيضًا إلى موارد. لذا لا تنقل أرقام أجهزة الآخرين إلى حاسوبك.
وتجنّب كذلك ترتيبًا يبدو دقيقًا مبنيًا على مهمة واحدة. ففي قرارك الخاص، قد يكون قيدٌ ضائع نادر أهمَّ من فارق بضع ثوانٍ. وينبغي أن تُبقي ورقة التقييم مثل هذه الأخطاء ظاهرة.
ما الذي يتيحه الملف الأصغر حقًا
يفتح التكميم مجالات استخدام محلية إضافية عبر تغيير التمثيل العددي للأوزان. ويبقى الاختيار الصحيح موازنةً بين الموارد وما تحتاجه مهامك من حيث المضمون.
تُظهر تجربة المستويات الصغيرة المبدأ الأساسي دون تنزيل أو GPU أو استدعاء نموذج. أما المقارنة اللاحقة بين الإصدارات فتفحص مستوى مختلفًا: كيف يؤثر التمثيل المختار في تطبيقك الفعلي؟ وإذا فصلت بين هذين المستويين، يصبح الملف الصغير اللافت قرارًا تقنيًا يمكن تتبّعه.
المصادر والحالة
المصادر محدّثة حتى 25 أكتوبر 2026. وثائق quantize في llama.cpp.
