صيغة نموذج GGUF: ما هي وكيفية تشغيل نموذج منها

أ نموذج GGUF هو نموذج لغوي كبير معبّأ بصيغة ملف GGUF — أي حاوية ملف واحد تحتوي الأوزان المكمَّنة ومُفكِّك الرموز والمُعطيات الفائقة (hyperparameters) ونموذج الموجه (prompt template) الخاص بالنموذج. وقد أنشأه جورجي جيرغانوف ومشروع llama.cpp في أغسطس 2023 ليحل محل الصيغة الأقدم GGML. وتُمكّن صيغة GGUF المستخدم من تنزيل ملف واحد فقط، ثم توجيه بيئة التشغيل إليه للحصول على نموذج يعمل فعليًّا نموذج لغوي محلي (LLM) على جهاز كمبيوتر محمول أو محطة عمل.

ماهية صيغة GGUF فعليًّا

GGUF تعني GPT-Generated Unified Format. وهي من الناحية البنائية ملف ثنائي يتضمّن رأسًا (header) وكتلة بيانات وصفية (metadata) ذات مفتاح-قيمة (key-value)، وفهرس التنسورات (tensor index)، وبيانات التنسورات نفسها. ويحدّد الوصف الرسمي لصيغة GGUF في مستودع ggml الترتيب البنيوي لها.

يوجد خاصيتان أساسيتان تهمّ المستخدمين:

• مستقلة ذاتيًّا (Self-contained). يحمل الملف مُفكِّك الرموز والرموز الخاصة ومعرّفات نهاية السلسلة/بداية السلسلة (EOS/BOS IDs) ونموذج المحادثة (chat template) والبيانات الوصفية الخاصة بالبنية (architecture metadata). وبالتالي، لا تحتاج إلى وجود ملف منفصل tokenizer.json أو config.json بجانبه.
• قابلة لمُطابقة الذاكرة (Memory-mappable). تستخدم بيئات التشغيل دالة mmap() لتحميل الملف، لذا يكون وقت بدء التشغيل شبه فوري، وتقوم نظام التشغيل بتحميل أوزان النموذج عند الحاجة (on demand). ولذلك يفتح ملف GGUF بحجم 40 غيغابايت في غضون ثوانٍ حتى على قرص SSD بطيء.

استُبدلت صيغة GGUF بصيغة GGML لأن الأخيرة لم تكن تدعم الترقيم الإصداري (versioning)، وكانت تخلط بين البيانات الوصفية والأوزان، كما كانت تتوقف عن العمل في كل مرة يتم فيها إدخال بنية جديدة. أما صيغة GGUF فهي مُرقَّمة وقابلة للتوسيع.

التكمين: نظام التسمية

معظم ملفات GGUF التي تقوم بتنزيلها تكون مكمَّنة — أي أن الأوزان مخزَّنة بعدد بتات أقل من الأصلية (FP16). ويشير اللاحقة في اسم الملف إلى نظام التكمين المستخدم. وأُدرجت عائلات التكمين الحالية في ملف README الخاص بأداة quantize في مشروع llama.cpp.

الكمّ	عدد البتات لكل وزن (تقريبي)	الاستخدام النموذجي
Q2_K	~2.6	أصغر حجم ممكن مع فقدان ملحوظ في الجودة
Q3_K_M	~3.9	ضغط عدواني
Q4_K_M	~4.8	الافتراضي الأكثر شيوعًا — توازن جيد بين الحجم والجودة
Q5_K_M	~5.7	جودة أعلى مع حجم ملف أكبر
Q6_K	~6.6	شبيه بالفقدان الصفري مقارنةً بـ FP16
Q8_0	~8.5	فعليًّا بدون فقدان، وبحجم يقارب ضعف حجم Q4
F16 / BF16	16	مرجع غير مكمَّن

الـ _K الأنواع المتغيرة (k-quants) تستخدم دقة متغيرة لكل كتلة تنسور. ورمز _M / _S / _L تشير اللاحقة إلى إعدادات مسبقة لمزج الكتل متوسطة أو صغيرة أو كبيرة. الإصدارات الأحدث بادئات IQ (مثل،) IQ4_XSتستخدم معايرة مصفوفة الأهمية لتحقيق جودة أفضل عند نفس ميزانية البت.

وكقاعدة عامة بالنسبة لذاكرة VRAM، خذ حجم الملف على القرص وأضف تقريبًا ١–٣ جيجابايت لمخبأ KV في السياقات القصيرة، والمزيد في السياقات الطويلة. فعلى سبيل المثال، يحتاج Convly: Llama 3.1 8B حوالي ٥ جيجابايت عند التكمين بـ ٤ بت، Llama 3.3 70B حوالي ٤٠ جيجابايت، و Mistral 7B حوالي ٤٫٥ جيجابايت. ولأي نموذج أكبر من ذلك، فإن جدول متطلبات الـ VRAM أسرع طريقة للبحث.

أين يمكن الحصول على ملفات GGUF

يتم توزيع معظم ملفات GGUF على منصة Hugging Face. ابحث عن اسم النموذج مع إضافة عبارة «GGUF». ومن أدوات إعادة التكمين الموثوقة: bartowski, كوين (الرسمية لـ Qwen3)، lmstudio-community, unsloth و MaziyarPanahi. وتُصدر شركات Meta وGoogle وMistral وMicrosoft بعض الإصدارات الرسمية من ملفات GGUF؛ أما النماذج الأخرى فيقوم المجتمع بتكمينها يدويًّا من ملفات safetensors.

عادةً ما تحتوي المستودعات (repo) على ملف واحد لكل مستوى تكمين، مثل: Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf. أما بالنسبة للنماذج التي يتجاوز حجمها ~٥٠ جيجابايت، فيُقسَّم الملف إلى أجزاء (shards) تحمل أسماء مثل: -00001-of-00003.gguf؛ وتقوم برامج التشغيل (runtimes) تلقائيًّا بتحميلها بدءًا من الجزء الأول.

تشغيل نموذج GGUF

لينكس

ابنِ llama.cpp من المصدر أو ثبِّت الحزمة الجاهزة المُسبقة التجميع. مع دعم CUDA:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j
./build/bin/llama-cli -m ~/models/llama-3.1-8b-instruct-Q4_K_M.gguf 
    -p "اشرح تنسيق GGUF في فقرة واحدة." -n 256 -ngl 99

الـ (عدد طبقات وحدة معالجة الرسومات). يحدد العلم (n-gpu-layers) عدد طبقات المحول (transformer) التي تُحمَّل على وحدة معالجة الرسومات (GPU). اضبطه على قيمة عالية بما يكفي لتناسب النموذج بأكمله في ذاكرة VRAM؛ وإذا نفد المكان، فقلِّل هذه القيمة ليظل الجزء المتبقي على وحدة المعالجة المركزية (CPU). ولتشغيل واجهة برمجة تطبيقات HTTP متوافقة مع OpenAI، استخدم llama-server والتي تعمل افتراضيًّا على المنفذ ٨٠٨٠.

macOS

على أجهزة Apple Silicon، يستخدم llama.cpp تلقائيًّا واجهة Metal. ثبِّته عبر Homebrew:

brew install llama.cpp
llama-cli -m ~/models/qwen3-8b-Q5_K_M.gguf -p "مرحبًا" -ngl 99

تعني الذاكرة الموحَّدة أن (عدد طبقات وحدة معالجة الرسومات). الحد الأقصى هو إجمالي ذاكرة RAM لديك ناقصًا ما تستهلكه نظام التشغيل. ويمكن لأجهزة Mac من سلسلة M ذات سعة ٣٢ جيجابايت تشغيل نموذج Qwen3 بحجم ١٤ مليار معلَّمة أو Gemma 3 12B عند مستوى تكمين Q4_K_M — ويُدرج قاعدة البيانات تلك النماذج بسعة حوالي ٩ جيجابايت و٨ جيجابايت من ذاكرة VRAM على التوالي.

أما بالنسبة لواجهة المستخدم الرسومية (GUI)، فإن LM Studio هي الخيار الشائع على أجهزة Mac. فهي تقوم تلقائيًّا بتنزيل ملفات GGUF من Hugging Face وتقدِّم خادمًا محليًّا متوافقًا مع واجهة برمجة تطبيقات OpenAI.

ويندوز

وهناك ثلاث طرق عملية:

• Ollama. ثبِّته من ollama.com/download، ثم ollama run llama3.1:8b. ويقوم Ollama تلقائيًّا بتنزيل ملفات GGUF الخاصة به والمُختارة بعناية. ولتحميل ملف عشوائي، اكتب ملف نموذج (Modelfile) يحتوي على سطر مثل: FROM ./mymodel.gguf ثم شغِّل الأمر: ollama create mymodel -f Modelfile. راجع دليلنا الخاص بـ دليل تثبيت Ollama.
• LM Studio. تثبيت بنقرة واحدة، واستعراض وتنزيل ملفات GGUF عبر واجهة مستخدم رسومية، مع شريط تمرير لتفعيل أو تعطيل تسريع GPU.
• الحزم الجاهزة المُسبقة التجميع من llama.cpp. يوفِّر المشروع ملفات مضغوطة جاهزة لأنظمة Windows مخصصة لوحدات المعالجة المركزية (CPU) وCUDA وVulkan على صفحة إصدارات GitHub. وقم باستخراج الملف المضغوط ثم شغِّل llama-cli.exe بالطريقة نفسها المتبعة في أنظمة Linux.

وبخصوص اختيار وحدة معالجة الرسومات (GPU)، فإن دليل GPU المحلي للنماذج اللغوية الكبيرة (LLM) يغطي الخيارات الحالية من حيث السعر مقابل سعة VRAM.

GGUF مقابل Safetensors مقابل AWQ مقابل GPTQ

الصيغة	بيئة التشغيل الأساسية	الدقة	الأفضل لـ
GGUF	llama.cpp، Ollama، LM Studio	من ٢ إلى ٨ بت + F16	وحدة معالجة مركزية (CPU)، أو مزيج من CPU/GPU، أو Apple Silicon، أو استخدام فردي
Safetensors (FP16/BF16)	Transformers، vLLM	١٦ بت	التدريب، والبحث، والاستنتاج بدقة كاملة
AWQ	vLLM، AutoAWQ	٤ بت	الاستخدام عالي الإنتاجية على وحدات معالجة الرسومات (GPU)
GPTQ	vLLM، ExLlamaV2	من ٣ إلى ٨ بت	الاستنتاج على وحدة معالجة الرسومات فقط مع دعم التجميع (batching)
MLX	MLX (Apple)	4–16 بت	مخصص لرقاقات Apple Silicon فقط

اختر تنسيق GGUF عند استهداف مستخدم واحد على أجهزة متنوعة أو عندما ترغب في تشغيل النموذج على وحدة معالجة مركزية (CPU) بأي شكلٍ من الأشكال. أما عند خدمة عدد كبير من المستخدمين المتزامنين على وحدة معالجة رسومية (GPU) في مركز بيانات، فاختر vLLM مع ملفات safetensors المُكمَّنة بـ AWQ أو GPTQ.

متى لا تكون صيغة GGUF هي الحل المناسب

يفترض GGUF استنتاجًا أحادي التدفق وبحجم دفعة يساوي 1. وبالتالي فإن معدل الإنتاجية (throughput) يكون أقل بكثير مقارنةً بـ vLLM أو TensorRT-LLM تحت حمل متزامن، كما أنه لا يدعم آلية الانتباه المُفصَّلة (paged attention). فإذا كنت تُشغِّل واجهة برمجية (API) لتلبية طلبات حقيقية، فإن نشر النموذج بتنسيق FP16 أو AWQ على vLLM سيتفوق على GGUF من حيث عدد الرموز المُولَّدة لكل ثانية ولكل دولار، حتى قبل أن تُحسب وقت المطور الضائع.

كما أنه يفشل تمامًا عند الحدود العليا لحجم النماذج. Kimi K3 يتطلب ما يقارب 1.4 تيرابايت من ذاكرة VRAM عند التكمين بـ 4 بت، DeepSeek بينما تتطلب وحدة V4-Pro نحو 800 جيجابايت — وهذه عمليات نشر متعددة العُقد (multi-node)، وليست مهام GGUF مخصصة لأجهزة سطح المكتب. أما بالنسبة للنماذج المُستضافة المتقدمة مثل Claude Sonnet 4.6 التي تبلغ تكلفة المعالجة الداخلة 3 دولارات والخارجة 15 دولارًا لكل مليون رمز، أو Gemini 3.6 Flash التي تبلغ تكلفتها 1.50 دولار داخلاً و7.50 دولارات خارجاً، فلا توجد أوزان محلية (local weights) قابلة للتحويل أصلًا. لذا احسب الأرقام بدقة على حاسبة المقارنة بين الاستضافة الذاتية وواجهة برمجة التطبيقات (API) قبل الالتزام بشراء وحدة معالجة رسومية.

تحويل نموذج إلى صيغة GGUF

إذا وُجد نموذج ما على Hugging Face بصيغة safetensors لكن لم يُكمَّن بعدُ من قِبل أحد، فإن سير العمل يكون كالتالي:

# في مستودع llama.cpp
pip install -r requirements.txt
python convert_hf_to_gguf.py /path/to/hf-model --outfile model-f16.gguf
./build/bin/llama-quantize model-f16.gguf model-Q4_K_M.gguf Q4_K_M

يدعم نص التحويل فقط هياكل النماذج التي علَّمتها llama.cpp — مثل llama وmistral وqwen2/3 وgemma وphi، إضافةً إلى قائمة متزايدة من الهياكل الأخرى. أما الهياكل الجديدة (novel architectures) فتتطلب تعديلًا في الكود أولًا. وقد تغيَّرت أسماء الملفات والعلمات (flags) في النص بين إصدارات llama.cpp، لذا تأكَّد من مراجعة python convert_hf_to_gguf.py --help بالنسبة للإصدار الذي قمت ببنائه من المصدر.

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

هل تُعدّ صيغة GGUF مماثلة لـ GGML؟

كلا. كان GGML التنسيق الأقدم الذي استخدمته llama.cpp حتى منتصف عام 2023. ثم حلَّ محله GGUF في أغسطس 2023، ليضم رأسًا مُرقَّم الإصدار (versioned header)، وبيانات وصفية مضمنة (embedded metadata)، وتخطيطًا ثابتًا للموترات (stable tensor layout). ولا تُحمَّل ملفات GGML القديمة بعد الآن في أحدث إصدارات llama.cpp؛ بل يجب عليك العثور على نسخة مُكمَّنة مجددًا بصيغة GGUF. أو .bin ولا تُحمَّل ملفات GGML القديمة بعد الآن في أحدث إصدارات llama.cpp؛ بل يجب عليك العثور على نسخة مُكمَّنة مجددًا بصيغة GGUF.

أي تكمين يجب أن أحمّله؟

ابدأ بـ Q4_K_Mوهو يناسب أوسع نطاق ممكن من الأجهزة، كما أن فقدان الجودة مقارنةً بـ FP16 ضئيلٌ بالنسبة لمعظم النماذج التي تتجاوز 7 مليار معلَّمة. وإذا توفر لديك مساحة إضافية في ذاكرة VRAM واهتممت بدقة الترميز أو الاستنتاج المنطقي، فانتقل إلى Q5_K_M أو Q6_K أما إذا لم يتناسب النموذج مع الجهاز إلا عند خفض التكمين أكثر، فانزل إلى Q3_K_M أو إلى أحد تنسيقات IQ3 فقط عندما لا يتناسب النموذج بأي صيغة أخرى.

هل يمكنني نماذج GGUF استخدام وحدة معالجة الرسوميات (GPU) الخاصة بي؟

نعم. يدعم llama.cpp واجهة CUDA (NVIDIA) وROCm (AMD) وMetal (Apple) وVulkan (متعدد الموردين) وSYCL (Intel). (عدد طبقات وحدة معالجة الرسومات). يُفعِّل هذا العلم نقل الطبقات إلى وحدة معالجة الرسومات (GPU). وإذا استوعبت الذاكرة العشوائية لوحدة معالجة الرسومات (VRAM) النموذج بالكامل، فإن معدل الإنتاجية يقترب من معدل الإنتاجية المحقَّق عند التشغيل على وحدات معالجة رسومات مخصصة؛ أما في حالة النقل الجزئي للطبقات، فيتحدد معدل التشغيل وفقًا لأبطأ طبقةٍ موجودةٍ في أي مستوى من المستويات.

هل تعمل صيغة GGUF مع نماذج الرؤية أو الصوت؟

جزئيًا. تدعم llama.cpp نماذج الرؤية متعددة الوسائط على غرار LLaVA عبر ملف mmproj GGUF مُرفق يحتوي على مشروع الرؤية (vision projector). وقد أُضيف الدعم تدريجيًّا لنماذج مثل Qwen-VL وGemma 3 vision وغيرها، لكنه يتأخر عن إصدارات النصوص فقط. أما نماذج الصوت مثل Whisper فهي تستخدم تنسيقًا مرتبطًا خاصًا بها يُدار بواسطة whisper.cpp، وليس بواسطة البرنامج التنفيذي الرئيسي لـ llama.cpp.

كيف أختار نموذج GGUF يتوافق مع أجهزتي؟

ابحث عن النموذج في Convly للمعرفة المطلوبة من ذاكرة VRAM عند التكمين بـ 4 بت، ثم اطرح 1–3 جيجابايت كمساحة احتياطية (headroom) للسياق وتكاليف نظام التشغيل. فعلى سبيل المثال، وبطاقة سعة 24 جيجابايت، فإن نموذج Qwen3 32B (حوالي 20 جيجابايت) أو Gemma 3 27B (حوالي 16 جيجابايت) عند تكمين Q4 سيكونان مناسبين تمامًا. أما حاسبة الذاكرة VRAM فيتعامل مع السياقات الأطول، والتي توسّع ذاكرة KV cache بشكل ملحوظ.

هل ملفات GGUF آمنة للتشغيل؟

إن الأوزان نفسها ليست سوى أعدادٍ — وعلى عكس نقاط التحقق (checkpoints) القائمة على pickle في بايثون، لا يقوم تنسيق GGUF بتنفيذ أي كود عند التحميل. والمخاطر الوحيدة تكمن في أن يحتوي ملفٌ مُصمَّم خبيثًا على ثغرة في محلِّل (parser) وقت التشغيل. لذا التزم بمصادر Hugging Face الموثوقة (مثل bartowski وunsloth وlmstudio-community والحسابات الرسمية لمورِّدي النماذج)، واحرص على تحديث llama.cpp أو Ollama أو LM Studio بشكل دوري.