- GGUF هو تنسيق ملفاتٍ يُستخدم لتشغيل النماذج اللغوية الكبيرة محليًّا. It packs a model’s weights, tokenizer and configuration into a single binary file that llama.cpp, Ollama, LM Studio معظم أدوات تشغيل النماذج اللغوية الكبيرة محليًّا الأخرى.
- وقد حلَّ هذا التنسيق محلَّ GGML في أغسطس 2023 لأن ملفات GGML كانت تتوقف عن العمل فور تغيُّر التنسيق. أما GGUF فهو تنسيق مُرقَّم وقابل للتوسُّع، وبالتالي تظل الملفات القديمة تعمل دون مشاكل.
- واللاحقة تشير إلى درجة التكميم (quantisation). Q4_K_M (حوالي 4,9 جيجابايت لنموذج بحجم 8 مليار معلَّمة) هو الإعداد الافتراضي القياسي من حيث الجودة والحجم؛ بينما Q8_0 يقترب من عدم فقدان البيانات تمامًا عند حجم حوالي 8,5 جيجابايت؛ أما F16 فهو تنسيق غير مكمَّم.
- قاعدة عامة: اختر أكبر درجة تكميم يسمح حجم ملفها بالتناسب ضمن سعة ذاكرة VRAM لديك مع ترك هامش 1–2 جيجابايت إضافي للسياق.
GGUF (ويُشار إليه عادةً باسم GPT-Generated Unified Format) هو تنسيق ملف ثنائي لتخزين النماذج اللغوية الكبيرة: أي أوزان النموذج ومُفكِّك الرموز وجميع بيانات الإعدادات التكوينية في ملف واحد متكامل ذاتيًا. وهو التنسيق الأصلي المستخدم في llama.cpp, وهو ما تستخدمه برامج مثل Ollama, LM Studio, KoboldCpp، يناير ومعظم تطبيقات النماذج اللغوية المحلية الأخرى تعمل فعليًّا. وإذا سبق لك تنزيل ملفٍ ينتهي بامتداد .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 على الأوزان مضغوطة مسبقًا إلى 2–8 بت لكل وزن، ولذلك فإن نموذجًا بسعة 8 مليارات معلَّمة قد لا يتجاوز حجمه 4,9 غيغابايت بدلًا من 16 غيغابايت.
السبب الذي دفع إلى استبدال GGML بـ GGUF
وقبل شهر أغسطس 2023، كان مشروع llama.cpp يستخدم تنسيقًا يُدعى GGML (وهو اسمٌ مستمدٌ من مكتبة التنسور الأساسية التي يعمل عليها). وقد كان تنسيق GGML فعّالًا، لكنه اشتكى عيبًا هيكليًّا: فقد كان ترتيب الملفات فيه جامدًا وغير مُرقَّم. وكل مرة أضاف فيها llama.cpp ميزة جديدة — مثل هياكل نماذج جديدة أو طرق كميّة أفضل أو معايير قياس تدرجات الحبال (rope scaling parameters) — كان يتعيَّن تعديل التنسيق، ما أدّى إلى توقف جميع ملفات النماذج الموجودة مسبقًا على كل الأقراص الصلبة عن العمل. ونتيجةً لذلك، اضطر المستخدمون إلى إعادة تنزيل أو إعادة تحويل مجموعات نماذجهم بالكامل عدة مرات خلال بضعة أشهر.
أمّا تنسيق GGUF، الذي قدّمه مشروع llama.cpp في أغسطس 2023، فقد عالج هذه المشكلة عبر تغييرين:
- التقسيم إلى إصدارات (versioning). فيعلن الملف عن إصدار تنسيقه، لكي يعرف قارئو الملف بالضبط كيفية تحليله.
- بيانات وصفية قابلة للتوسّع على شكل أزواج مفتاح-قيمة (extensible key-value metadata). أما المعلومات الجديدة (مثل حقل جديد لهيكل النموذج أو قالب دردشة أو معلَّمة فائقة إضافية) فهي مجرّد مفتاح جديد. وبذلك تظل الملفات القديمة التي لا تحتوي ذلك المفتاح قابلة للتحميل، بينما تعمل الملفات الجديدة التي تتضمّنه في بيئات التشغيل المحدَّثة. ولا يتسبّب أي تغيير في كسر التوافق العكسي (retroactive breakage).
وقد ألغى llama.cpp دعم GGML بعد فترة وجيزة، وتبعه النظام البيئي كله. واليوم لم يبقَ GGML سوى كاسمٍ لمكتبة التنسور الأساسية؛ فإذا وجدت ملف نموذج ذا الامتداد .ggml أو أو .bin من عام 2023، فلن يُحمَّل في أي أداة حالية، بل ينبغي عليك تنزيل نسخة منه بتنسيق GGUF بدلًا من ذلك.
كيفية قراءة لواحق التكميم
يحمل كل اسم ملف GGUF لاحقةً مثل Q4_K_M توضح مدى شدة ضغط الأوزان. والنمط هو:
- فالرقم الواقع بعد حرف Q يشير تقريبًا إلى عدد البتات لكل وزن: فـ Q4 تعني تقريبًا 4 بت، وQ8 تعني تقريبًا 8 بت. وكلما قلّ عدد البتات، قلّ حجم الملف وانخفضت جودته.
- _K تشير إلى طرق الكمّ الجديدة المُسماة «k-quant»، والتي تخصص بتات إضافية للتينسورات الأكثر تأثيرًا في جودة المخرجات. وبالمقارنة عند نفس الحجم، فإن الكمّ من نوع K يتفوّق على الطريقة الأقدم.
- _S / _M / _L (صغير/متوسط/كبير) هي متغيرات ضمن عائلة K — حيث إن
_Mتحتفظ بعدد قليل من التينسورات الحساسة بدقة أعلى من تلك التي تحتفظ بها_S. - _0 (أي
Q8_0,Q4_0) يشير إلى تكميم الكتل الأقدم والأبسط.Q8_0لا يزال يُستخدم على نطاق واسع لأنه عند 8 بت تكون الطريقة البسيطة قريبة جداً من عدم الفقدان؛Q4_0عفا عليه الزمن في الغالب — يُفضّل استخدامQ4_K_M. - IQ البادئات (
IQ2_M,IQ3_XS…) وهي «i-quants» مبنية بمصفوفة أهمية، تُستخدم لضغط النماذج أقل من 4 بت بضرر أقل من البدائل. - F16 / BF16 / F32 يعني أوزان 16 أو 32 بت غير مكممة — الجودة المرجعية، بالحجم الأقصى.
إليك ما تكلفه الخيارات الشائعة عملياً، باستخدام نماذج Llama-class 8B instruct كمثال (الأحجام تقريبية وتختلف قليلاً حسب النموذج):
| التكميم | حجم الملف (نموذج 8B) | الجودة مقابل F16 | متى يتم الاستخدام |
|---|---|---|---|
| F16 | ~16.1 GB | مرجعي | المعايير، التكميم الإضافي؛ نادراً ما يستحق التشغيل |
| Q8_0 | ~8.5 GB | لا يمكن تمييزها عملياً | لديك VRAM إضافية وتريد أقصى جودة |
| Q6_K | ~6.6 GB | فقدان مهمل | جودة عالية مع توفير حجم ذي مغزى |
| Q5_K_M | ~5.7 GB | فقدان ضئيل جداً | حل وسط جيد |
| Q4_K_M | ~4.9 GB | فقدان بسيط، مقبول عادة | الخيار الافتراضي القياسي. أفضل جودة لكل جيجابايت لمعظم الناس |
| Q3_K_M | ~4.0 GB | تدهور ملحوظ | فقط عندما لا يناسب Q4 حقاً |
| Q2_K / IQ2 | ~3.2 GB | تدهور كبير | الملاذ الأخير؛ نموذج أصغر عند Q4 غالباً ما يكون أفضل |
قاعدتان مفيدتان: التكميم يضر النماذج الصغيرة أكثر من الكبيرة (70B عند Q3 يصمد بشكل أفضل بكثير من 8B عند Q3)، وأقل من Q4 تنخفض منحنى الجودة بشدة. في حالة الشك، Q4_K_M هو الخيار الافتراضي للمجتمع لسبب ما.
اختيار درجة تكميم مناسبة لسعة ذاكرة VRAM لديك
الذاكرة الإجمالية المطلوبة تقريباً حجم الملف + ذاكرة التخزين المؤقت للسياق + النفقات العامة. خصص 1-2 GB فوق حجم الملف لبضعة آلاف رمز من السياق، أكثر إذا قمت بتشغيل سياقات طويلة. يعمل النموذج بسرعة أقصى عندما يناسب كل ذلك في GPU VRAM؛ يمكن لأدوات llama.cpp نقل الباقي إلى RAM النظام، وهذا يعمل أيضاً ولكن يصبح أبطأ بكثير كلما تسربت المزيد من الطبقات.
| ذاكرة VRAM | ما يناسب بشكل مريح |
|---|---|
| 8 جيجابايت | نماذج 7-8B عند Q4_K_M أو Q5_K_M |
| 12 جيجابايت | 8B عند Q8_0، أو 12-14B عند Q4_K_M |
| 16 جيجابايت | 14B عند Q5_K_M / Q6_K |
| 24 جيجابايت | ~32B عند Q4_K_M، أو 14B عند Q8_0 مع سياق طويل |
للأرقام الدقيقة على نموذج محدد وطول السياق، حاسبة VRAM يقوم بإجراء العمليات الحسابية لك، وهناك تفصيل لكل نموذج في متطلبات ذاكرة VRAM لكل نموذج لغوي رئيسي. إذا كنت تختار الأجهزة بدلاً من التكميم، ابدأ بـ أفضل GPUs للشبكات العصبية المحلية.
مقارنة بين GGUF وsafetensors
هذان الصيغتان موجودة معاً لأنهما يخدمان أوقات تشغيل مختلفة، وليس لأن أحدهما ينتصر.
| GGUF | safetensors | |
|---|---|---|
| مصمم لـ | llama.cpp وأنظمتها البيئية | نظام Hugging Face / PyTorch البيئي |
| المحتويات | الأوزان + المحلل اللغوي + الإعدادات في ملف واحد | الموترات فقط؛ الإعدادات والمحلل اللغوي عبارة عن ملفات JSON منفصلة |
| التكمية | مدمج في التنسيق (Q4_K_M إلخ) | عادة FP16/BF16؛ يتم تكميتها عبر طرق منفصلة (GPTQ و AWQ) |
| أوقات التشغيل النموذجية | Ollama و LM Studio و llama.cpp و KoboldCpp و Jan | transformers و vLLM و TGI و SGLang |
| النقطة المثالية | أجهزة المستهلك، CPU+GPU الهجينة، مستخدم واحد | وحدات معالجة الرسومات بمركز البيانات، الخدمة عالية الإنتاجية، التدريب |
القرار يتعلّق في الواقع بالبرنامج الذي تُشغّله: فأدوات سطح المكتب وOllama تتطلّب تنسيق GGUF؛ أما مكدّسات الخدمة على وحدات معالجة الرسومات (GPU) وأي شيء يتضمّن ضبط النموذج بدقة (fine-tuning) فيتطلّب safetensors. وعادةً ما يُصدِر ناشرو النماذج ملفات safetensors أولاً، ثم يقوم المجتمع بتحويلها إلى تنسيق GGUF خلال أيام قليلة.
مصدر ملفات GGUF
تقريباً جميع ملفات GGUF موجودة على Hugging Face. تنشر المختبرات أحياناً GGUFs رسمية، لكن معظمها يأتي من مكممات المجتمع — حسابات مثل bartowski, unsloth, lmstudio-community و ggml-org — التي تحول كل إصدار جديد إلى النطاق الكامل للتكميات. مستودع باسم مثل Meta-Llama-3.1-8B-Instruct-GGUF سيحتوي على ملف واحد لكل مستوى تكمية.
يمكنك أيضاً تحويل نموذج بنفسك باستخدام أدوات llama.cpp: convert_hf_to_gguf.py يحول نموذج Hugging Face إلى GGUF من نوع F16، و llama-quantize الملف الثنائي (المُنشأ عند تجميع 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 الكامل Modelfiles بالتفصيل.
تحميل GGUF في LM Studio
المسار الطبيعي هو مُحمِّل البرنامج المدمج: افتح علامة التبويب Discover، ابحث عن نموذج، وسيعرض LM Studio تكميات GGUF المتاحة، مع وضع علامة على أيها يناسب جهازك. لاستيراد ملف موجود بالفعل، استخدم سطر الأوامر ("lms import path/to/model.gguf") أو ضعه في دليل نماذج LM Studio — يختلف المسار الافتراضي الدقيق حسب الإصدار ونظام التشغيل، لكن علامة التبويب My Models تعرضه وتتيح لك تغييره. يجب أن توجد الملفات في بنية مجلد publisher/model-name/ ليتم التعرف عليها. انظر دليل LM Studio الكامل للحصول على الشرح الكامل.
مستعدٌ لتشغيل أحد هذه النماذج؟ دليلنا الخاص بالنسبة لنماذج GGUF يتطرّق إلى تحديد أحجام النماذج، وتنزيلها، وتشغيلها على أنظمة Linux وmacOS وWindows.
الأسئلة الشائعة
هل GGUF يعمل على CPU فقط، أم أنه يستخدم GPU؟
كلاهما. وُلد llama.cpp كمشروع استدلال CPU، لكنه يفرّغ طبقات النموذج إلى GPU (CUDA و Metal و Vulkan و ROCm) ويعمل بالكامل على GPU عندما يكون النموذج مناسباً في VRAM. يتعامل Ollama و LM Studio مع انقسام CPU/GPU تلقائياً؛ مع llama.cpp مباشرة تتحكم فيه بـ -ngl (عدد طبقات GPU).
ما الفرق بين Q4_K_M و Q4_K_S؟
كلاهما حول 4-bit k-quants؛ الحرف هو متغير الحجم. _M M (متوسط) يحافظ على المزيد من الموترات الحساسة للجودة بدقة أعلى من _S S (صغير)، لذلك فهو أكبر قليلاً وأفضل قليلاً. الفرق صغير — اختر _M M إلا إذا كان آخر مئات ميجابايت تحدد ما إذا كان النموذج يناسب.
كم جودة أفقدها فعلاً عند التكمية؟
عند Q8_0 و Q6_K، لا يوجد فرق عملي تقريباً — الاختبارات العمياء تجد صعوبة في التمييز بينها وبين F16. Q4_K_M يظهر خسارة صغيرة يمكن قياسها لكن معظم المستخدمين لا يلاحظونها في الحوار العادي، رغم أنها قد تؤثر في المهام الدقيقة مثل توليد الأكواد أو الحسابيات. تحت Q4 يصبح التدهور واضحاً جداً، والنماذج الصغيرة تعاني أكثر من النماذج الكبيرة.
هل يمكنني استخدام GGUF مع transformers أو vLLM؟
الدعم موجود لكنه محدود وليس الطريق الأساسي — يستطيع transformers فك ضغط بعض ملفات GGUF عند التحميل، و vLLM يملك دعم تجريبي لـ GGUF يختلف حسب البنية. إذا كنت تبني على تلك المكدسات، استخدم safetensors؛ GGUF يُفضل التعامل معه كصيغة لعائلة llama.cpp من أدوات التشغيل.
لماذا يتم تقسيم نموذجي إلى عدة ملفات .gguf؟
النماذج الضخمة جداً يتم تقسيمها إلى أجزاء بأسماء مثل model-00001-of-00002.gguf، بشكل أساسي للبقاء تحت حدود حجم الملفات على منصات الاستضافة. احتفظ بجميع الأجزاء في نفس المجلد وأشر أداة التشغيل إلى الأول — llama.cpp والأدوات المبنية عليه تحمل البقية تلقائياً.
بمجرد أن تعرف أي مستوى ضغط يناسب عتادك، السؤال العملي التالي هو أي نموذج تضع فيه — قاعدة بيانات النماذج يسرد المواصفات واحتياجات VRAM والأسعار لـ 37 نموذج حالي، و أفضل النماذج المحلية لـ Ollama قائمة جيدة للبدء منها.