ما هو تنسيق GGUF؟ شرح تنسيق ملفات النماذج اللغوية الكبيرة الذي يعتمد عليه كلٌّ من Ollama وllama.cpp

GGUF (ويُشار إليه عادةً باسم GPT-Generated Unified Format) هو تنسيق ملف ثنائي لتخزين النماذج اللغوية الكبيرة: أي أوزان النموذج ومُفكِّك الرموز وجميع بيانات الإعدادات التكوينية في ملف واحد متكامل ذاتيًا. وهو التنسيق الأصلي المستخدم في llama.cpp, وهو ما تستخدمه برامج مثل Ollama, LM StudioKoboldCpp وJan ومعظم تطبيقات تشغيل النماذج اللغوية الكبيرة محليًّا الأخرى فعليًّا. فإذا كنت قد قمت يومًا بتنزيل ملف ينتهي امتداده بـ .ggufأو استرجعت نموذجًا باستخدام الأمر ollama run، فأنت حينها تستخدم هذا التنسيق.

المحتوى الفعلي لملف GGUF

يبدأ ملف GGUF بأربعة بايتات ASCII هي GGUF، يليها رقم الإصدار، ثم قسم للمetadata المكوَّن من أزواج المفتاح-القيمة، ثم تتبعه المتجهات (tensors) نفسها. ويعتبر قسم metadata هو القرار التصميمي المهم: فهو يخزن بنية النموذج وطول السياق والمفردات الخاصة بمُفكِّك الرموز (tokenizer) ونموذج المحادثة (chat template) وتفاصيل التكميم كمفاتيح مُسَمَّاة، بحيث يمكن لأي برنامج تشغيل تحميل أي ملف GGUF دون الحاجة إلى ملفات منفصلة مثل config.json أو ملفات المعالج اللغوي (tokenizer) جنبًا إلى جنب معه.

ينجم عن هذا التصميم ثلاثة نتائج عملية:

• ملف واحد يمثل النموذج بأكمله. يمكنك نسخ ملف .gguf بين أجهزة مختلفة، ويُشتغل عليه مباشرةً دون مشاكل. (أما النماذج الكبيرة جدًّا فهي تُقسَّم أحيانًا إلى أجزاء مرقَّمة مثل -00001-of-00002.gguf، لكنها ما زالت تشكِّل نموذجًا منطقيًّا واحدًا.)
• يُمكن خرْط الملف في الذاكرة (memory-mappable). وتستطيع بيئات التشغيل (runtimes) استخدام دالة «mmap» لخرْط الملف في الذاكرة وتحميل أوزانه صفحيةً عند الحاجة، مما يجعل عملية التحميل سريعةً ويسمح بتشغيل نموذجٍ أكبر من مقدار الذاكرة العشوائية (RAM) المتاح.
• الكمِّيَّة (quantisation) مدمجةٌ في التنسيق. يحتوي ملف GGUF على الأوزان مضغوطة مسبقًا إلى ٢–٨ بت لكل وزن، ولذلك فإن نموذجًا بسعة ٨ مليارات معلَّمة قد لا يتجاوز حجمه ٤,٩ غيغابايت بدلًا من ١٦ غيغابايت.

السبب الذي دفع إلى استبدال GGML بـ GGUF

وقبل شهر أغسطس ٢٠٢٣، كان مشروع llama.cpp يستخدم تنسيقًا يُدعى GGML (وهو اسمٌ مستمدٌ من مكتبة التنسور الأساسية التي يعمل عليها). وقد كان تنسيق GGML فعّالًا، لكنه اشتكى عيبًا هيكليًّا: فقد كان ترتيب الملفات فيه جامدًا وغير مُرقَّم. وكل مرة أضاف فيها llama.cpp ميزة جديدة — مثل هياكل نماذج جديدة أو طرق كميّة أفضل أو معايير قياس تدرجات الحبال (rope scaling parameters) — كان يتعيَّن تعديل التنسيق، ما أدّى إلى توقف جميع ملفات النماذج الموجودة مسبقًا على كل الأقراص الصلبة عن العمل. ونتيجةً لذلك، اضطر المستخدمون إلى إعادة تنزيل أو إعادة تحويل مجموعات نماذجهم بالكامل عدة مرات خلال بضعة أشهر.

أمّا تنسيق GGUF، الذي قدّمه مشروع llama.cpp في أغسطس ٢٠٢٣، فقد عالج هذه المشكلة عبر تغييرين:

• التقسيم إلى إصدارات (versioning). فيعلن الملف عن إصدار تنسيقه، لكي يعرف قارئو الملف بالضبط كيفية تحليله.
• بيانات وصفية قابلة للتوسّع على شكل أزواج مفتاح-قيمة (extensible key-value metadata). أما المعلومات الجديدة (مثل حقل جديد لهيكل النموذج أو قالب دردشة أو معلَّمة فائقة إضافية) فهي مجرّد مفتاح جديد. وبذلك تظل الملفات القديمة التي لا تحتوي ذلك المفتاح قابلة للتحميل، بينما تعمل الملفات الجديدة التي تتضمّنه في بيئات التشغيل المحدَّثة. ولا يتسبّب أي تغيير في كسر التوافق العكسي (retroactive breakage).

وقد ألغى llama.cpp دعم GGML بعد فترة وجيزة، وتبعه النظام البيئي كله. واليوم لم يبقَ GGML سوى كاسمٍ لمكتبة التنسور الأساسية؛ فإذا وجدت ملف نموذج ذا الامتداد .ggml أو أو .bin من عام ٢٠٢٣، فلن يُحمَّل في أي أداة حالية، بل ينبغي عليك تنزيل نسخة منه بتنسيق GGUF بدلًا من ذلك.

كيفية قراءة لواحق التكميم

يحمل كل اسم ملف GGUF لاحقةً مثل Q4_K_M توضح مدى شدة ضغط الأوزان. والنمط هو:

• فالرقم الواقع بعد حرف Q يشير تقريبًا إلى عدد البتات لكل وزن: فـ Q4 تعني تقريبًا ٤ بت، وQ8 تعني تقريبًا ٨ بت. وكلما قلّ عدد البتات، قلّ حجم الملف وانخفضت جودته.
• _K تشير إلى طرق الكمّ الجديدة المُسماة «k-quant»، والتي تخصص بتات إضافية للتينسورات الأكثر تأثيرًا في جودة المخرجات. وبالمقارنة عند نفس الحجم، فإن الكمّ من نوع K يتفوّق على الطريقة الأقدم.
• _S / _M / _L (صغير/متوسط/كبير) هي متغيرات ضمن عائلة K — حيث إن _M تحتفظ بعدد قليل من التينسورات الحساسة بدقة أعلى من تلك التي تحتفظ بها _S.
• _0 (أما Q8_0, Q4_0فتشير إلى طريقة الكمّ الكتلي البسيطة الأقدم.) Q8_0 ولا تزال تُستخدم على نطاق واسع لأن الطريقة البسيطة عند ٨ بت تكون قريبة جدًّا من حالة عدم الفقدان (near-lossless)، أما Q4_0 فقد أصبحت قديمةً إلى حدٍّ كبير — لذا يُفضَّل استخدام Q4_K_M.
• بادئات IQ (مثلIQ2_M, وIQ3_XSإلخ) وهي طرق «كمّ أهمي» (i-quants) تُبنى باستخدام مصفوفة أهمية، وتُستخدَم لضغط النماذج إلى أقل من ٤ بت مع تقليل الضرر مقارنةً بالبدائل الأخرى.
• F16 / BF16 / F32 تعني أن الأوزان غير مكمَّمة (unquantised) وبدقة ١٦ أو ٣٢ بت — وهي الجودة المرجعية، وأكبر حجم ممكن.

وفيما يلي تكلفة الخيارات الشائعة عمليًّا، باستخدام نماذج Llama من فئة ٨ مليار معلَّمة (instruct models) كمثال (مع العلم أن الأحجام تقريبية وتتفاوت قليلًا باختلاف النموذج):

قواعِدُ مفيدةٌ اثنتان: يؤثر التكميم سلبًا على النماذج الصغيرة أكثر من تأثيره على النماذج الكبيرة (فنموذج 70 مليار معلَّمة عند مستوى Q3 يحتفظ بجودته بشكلٍ أفضل بكثيرٍ من نموذج 8 مليارات معلَّمة عند نفس المستوى Q3)، كما أن منحنى الجودة ينخفض انخفاضًا حادًّا تحت مستوى Q4. وعند الشك، Q4_K_M هو الخيار الافتراضي للمجتمع ولسبب وجيه.

اختيار درجة تكميم مناسبة لسعة ذاكرة VRAM لديك

إجمالي الذاكرة المطلوبة يساوي تقريبًا حجم الملف + ذاكرة التخزين المؤقت للسياق + الهوامش الإضافية. خصِّص ميزانية إضافية قدرها 1–2 غيغابايت فوق حجم الملف لمعالجة بضعة آلاف من الرموز (tokens) ضمن السياق، وزِد هذه الميزانية إذا كنت تستخدم سياقات طويلة جدًّا. ويؤدي النموذج بأقصى سرعةٍ ممكنةٍ عندما تتسع كل هذه المكونات داخل ذاكرة VRAM الخاصة بالوحدة الرسومية (GPU)؛ أما أدوات llama.cpp فهي قادرة على تحميل الأجزاء المتبقية إلى ذاكرة النظام الرئيسية (RAM)، وهي تعمل لكنها تتباطأ كثيرًا كلما زاد عدد الطبقات التي تُحمَّل خارج الـ VRAM.

للحصول على أرقام دقيقة لمُخطَّط معين وطول سياق معيَّن، فإن حاسبة الذاكرة الافتراضية (VRAM) يقوم تلقائيًّا بهذه الحسابات نيابةً عنك، وهناك تفصيلٌ لكل نموذج في متطلبات ذاكرة VRAM لكل نموذج لغوي رئيسي. وإذا كنت تختار الأجهزة بدلًا من مستوى التكميم، فابدأ بـ أفضل وحدات معالجة رسومية (GPUs) لأنظمة النماذج اللغوية الكبيرة المحلية (local LLMs).

مقارنة بين GGUF وsafetensors

يتعايش هذان التنسيقان معًا لأن كلًّا منهما يخدم بيئات تشغيل مختلفة، وليس لأن أحدهما يتفوق على الآخر.

القرار يتعلَّق في الواقع بالبرمجيات التي تستخدمها: فبرامج سطح المكتب وأداة Ollama تتطلب تنسيق GGUF، بينما تتطلب أنظمة الخدمة القائمة على الـ GPU وأي عملية تتضمَّن ضبط النموذج الدقيق (fine-tuning) تنسيق safetensors. وعادةً ما ينشر مقدِّمو النماذج تنسيق safetensors أولًا، ثم يقوم المجتمع بتحويله إلى تنسيق GGUF خلال أيام قليلة.

مصدر ملفات GGUF

تقريبًا جميع ملفات GGUF موجودة على منصة Hugging Face. وتقوم شركة Labs أحيانًا بنشر ملفات GGUF رسمية، لكن معظمها يأتي من مُكمِّمي المجتمع — مثل الحسابات bartowski, unsloth, lmstudio-community و ggml-org — الذين يقومون بتحويل كل إصدار جديد إلى كامل نطاق مستويات التكميم. وستحتوي مستودع (repo) باسمٍ كـ Meta-Llama-3.1-8B-Instruct-GGUF على ملف واحد لكل مستوى تكميم.

وبإمكانك أيضًا تحويل النموذج بنفسك باستخدام أدوات llama.cpp: convert_hf_to_gguf.py يحوِّل نموذج Hugging Face إلى ملف GGUF بصيغة F16، أما أداة llama-quantize الثنائية (binary) (التي تُبنى عند تجميع llama.cpp) فتضغطه إلى مستوى التكميم الذي تختاره، مثال: نموذج llama-quantize model-f16.gguf model-Q4_K_M.gguf بكمية كمية Q4_K_M.

تحميل ملف GGUF في Ollama

يمكن لبرنامج Ollama سحب مستودعات GGUF مباشرةً من منصة Hugging Face، مع تحديد نوع الكمّية بعد الرمز النقطي (:)

ollama run hf.co/bartowski/Meta-Llama-3.1-8B-Instruct-GGUF:Q4_K_M

لملفٍ لديك بالفعل على القرص الصلب، أنشئ ملف نص عادي باسم Modelfile ويحتوي على ما يلي:

FROM ./my-model.gguf

ثم سجّله وشغّله عبر الأوامر التالية:

ollama create my-model -f Modelfile
ollama run my-model

الإصدارات الحالية من Ollama تقرأ قالب المحادثة المضمَّن في بيانات تعريف ملف GGUF؛ وإذا أنتج نموذج مستورد مخرجات مشوَّشة، فإن الحل عادةً هو إضافة سطر صريح يحمل اسم TEMPLATE إلى ملف Modelfile. أما دليل Ollama الشامل فيتناول ملفات Modelfile بشكل معمَّق. تحميل ملف GGUF في LM Studio

الطريقة الاعتيادية هي استخدام برنامج التنزيل المدمج: افتح علامة التبويب «اكتشف» (Discover)، وابحث عن النموذج المطلوب، فتعرض لك LM Studio قائمةً بكميات GGUF المتاحة، مع الإشارة إلى تلك التي تتوافق مع أجهزتك. ولاستيراد ملفٍ لديك بالفعل، استخدم واجهة سطر الأوامر (CLI) عبر الأمر

lms import path/to/model.ggufأو انقل الملف إلى مجلد النماذج الخاص بـ LM Studio — حيث يختلف المسار الافتراضي الدقيق حسب الإصدار ونظام التشغيل، لكن علامة التبويب «نماذجي» (My Models) تعرض هذا المسار وتسمح لك بتغييره. ويجب أن تكون الملفات موجودة ضمن هيكل مجلدات فرعية على الشكل التالي:publisher/model-name/ لكي يتم التعرُّف عليها. راجع الدليل الشامل لـ LM Studio للاطلاع على الشرح الكامل خطوةً بخطوة. هل تنسيق GGUF مقصورٌ على وحدة المعالجة المركزية (CPU) فقط، أم أنه يستخدم أيضًا وحدة معالجة الرسومات (GPU)؟

الأسئلة الشائعة

كلاهما. فقد وُلد مشروع llama.cpp في الأصل كمشروع استنتاج يعمل على وحدة المعالجة المركزية فقط، لكنه يُفوِّض طبقات النموذج إلى وحدة معالجة الرسومات (عبر CUDA أو Metal أو Vulkan أو ROCm)، ويعمل بالكامل على وحدة معالجة الرسومات عندما يتسع النموذج كاملاً في ذاكرة VRAM. وتتعامل برامج Ollama وLM Studio تلقائيًّا مع تقسيم الحمل بين وحدة المعالجة المركزية ووحدة معالجة الرسومات؛ أما عند استخدام llama.cpp مباشرةً، فيمكنك التحكم بهذا التقسيم باستخدام العلم

-ngl (عدد طبقات وحدة معالجة الرسومات). ما الفرق بين Q4_K_M وQ4_K_S؟

كلا النوعين يمثلان كمّيات k-quants بعرض 4 بت تقريبًا، والحرف يشير إلى متغير الحجم.

(متوسط) تحتفظ بمزيد من المتجهات الحساسة للجودة بدقة أعلى مقارنةً بنوع _M (صغير)، وبالتالي فهي أكبر قليلًا وأفضل أداءً قليلًا. والفرق ضئيل جدًّا — لذا اختر _S ما لم تكن بضعة مئات ميجابايت إضافية هي العامل الحاسم في إمكانية تحميل النموذج على جهازك. _M ما مدى الخسارة الفعلية في الجودة الناتجة عن الكمّية؟

عند الكمّية Q8_0 وQ6_K، تكون الخسارة فعليًّا معدومة — إذ يصعب جدًّا على الاختبارات العمياء التمييز بينها وبين النموذج الأصلي بتنسيق F16. أما عند الكمّية Q4_K_M فتظهر خسارة صغيرة يمكن قياسها، لكن معظم المستخدمين لا يلاحظونها أثناء المحادثة، رغم أنها قد تؤثر في المهام الدقيقة مثل توليد الأكواد أو العمليات الرياضية. وتصبح التدهورات واضحة عند الكمّيات دون Q4، كما أن النماذج الصغيرة تتأثر أكثر من النماذج الكبيرة.

هل يمكنني استخدام تنسيق GGUF مع مكتبات transformers أو vLLM؟

توجد دعم محدود لهذا الاستخدام، لكنه ليس الطريق القياسي أو الأصلي — فمكتبة transformers تستطيع إلغاء الكمّية (dequantise) لبعض ملفات GGUF عند التحميل، بينما تمتلك vLLM دعمًا تجريبيًّا لـ GGUF يتفاوت حسب بنية النموذج. فإذا كنت تبني تطبيقاتك على هذه المكتبات، فمن الأفضل استخدام تنسيق safetensors؛ أما GGUF فهو التنسيق الأمثل لأنظمة التشغيل التابعة لعائلة llama.cpp.

لماذا انقسم نموذجي إلى عدة ملفات بامتداد .gguf؟

النماذج الكبيرة جدًّا تُقسَّم إلى أجزاء تحمل أسماءً مثل

model-00001-of-00002.gguf وغالبًا ما يكون ذلك لضمان عدم تجاوز الحد الأقصى لحجم الملف المسموح به على منصات الاستضافة. ويجب الاحتفاظ بجميع الأجزاء في المجلد نفسه، ثم توجيه برنامج التشغيل إلى الملف الأول — فستقوم مكتبة llama.cpp والأدوات المبنية عليها تلقائيًّا بتحميل باقي الأجزاء.وبمجرد أن تعرف أي كمّية تتوافق مع أجهزتك، فإن السؤال العملي التالي هو: أي نموذج يجب تحميله في هذه الكمّية؟ — القائمة المعنونة

تسرد مواصفات 37 نموذجًا حاليًّا، واحتياجاتها من ذاكرة VRAM وأسعارها، بينما توفر قائمة قاعدة بيانات النماذج أفضل النماذج المحلية لـ Ollama قائمة موجزة ممتازة لتبدأ منها. قائمة جيدة قصيرة يمكن البدء منها.