> حاسبة VRAM لملفات GGUF: تحقّق قبل التنزيل▋

ggml_backend_cuda_buffer_type_alloc_buffer: failed to allocate 3412 MiB. نزل الملف بلا أي مشكلة. البطاقة ما كانت لتتحمله من الأصل — والحساب الذي توقّع هذا يتسع في هامش إيصال بقالة. المسار المعتاد يسير بالعكس: اضغط تنزيلًا، راقب شريط التقدم، ودع خطأ نفاد الذاكرة يجري الحساب. هذا الترتيب تحديدًا هو ما ترفضه أداة اليوم. حاسبة VRAM لملفات GGUF أصبحت مباشرة: حجم النموذج والكمّي وطول السياق مدخلات — الأوزان وذاكرة KV وحكم لكل بطاقة شائعة مخرجات. أو بالعكس: ابدأ من ميزانية بطاقتك نحو أعلى كمّي يتسع. كل شيء يعمل في متصفحك، ولا شيء يُرفع إلى أي خادم، وانضمت إلى صفحة تشغيل النماذج محليًا إلى جانب بقية هذا العنقود.

لها وضعان، لأن السؤال يأتي بشكلين:

• "كم من VRAM يحتاج هذا النموذج؟" — المعاملات والكمّي والسياق والمعمارية مدخلات؛ التفصيل الرقمي وحكم لكل بطاقة (من 6 إلى 96 غيغابايت) مخرجات.
• "ما الذي يتسع لذاكرتي؟" — الميزانية وحجم النموذج والسياق مدخلات؛ كل كمّي من Q2_K إلى F16 بحكمه الخاص مخرجات.

كم من ذاكرة VRAM يحتاج نموذج GGUF؟

ثلاثة أجزاء، دائمًا الثلاثة نفسها:

VRAM ≈ الأوزان + ذاكرة KV + الحمولة
الأوزان  = المعاملات × بت-لكل-وزن / 8
ذاكرة KV = 2 × الطبقات × kv_dim × السياق × 2 بايت   (f16)
الحمولة  ≈ 0.7 غيغابايت CUDA/تشغيل + ~5% مخازن حساب

مثال محلول، الأكثر شيوعًا: نموذج 8B بكمّي Q4_K_M وسياق 32k. الأوزان: 8 × 4.85 / 8 = 4.85 غيغابايت. ذاكرة KV: 2 × 32 طبقة × 1024 kv-dim × 2 بايت = 128 كيلوبايت لكل رمز × 32,768 = 4.0 غيغابايت. مع الحمولة: ~9.8 غيغابايت إجمالًا — «Q4 8B» الذي يصفه الجميع بأنه نموذج لبطاقة 8 غيغابايت يفوّتها بنسبة 23% لحظة أن تمنحه سياقًا طويلًا. الكمّي لم يكن المتهم قط؛ السياق هو. لصيفة العطل هذه ملاحظة ميدانية خاصة، لأنها تلتهم ذاكرة النظام أيضًا عند التحميل الجزئي.

أي نسخة كمّي تتسع لبطاقتي؟

الوضع الثاني موجود لأن السؤال المعكوس هو ما يملكه الناس فعلًا: بطاقة ثابتة ونموذج في البال. نموذج 7B بسياق 4096 أمام ميزانية 8 غيغابايت يعيد ما يلي تمامًا:

الكمّي	الأوزان	الإجمالي (تقديري)	الحكم
Q4_K_M	4.24 غيغابايت	~5.7 غيغابايت	يتسع بهامش
Q6_K	5.77 غيغابايت	~7.3 غيغابايت	على الحد
Q8_0	7.44 غيغابايت	~9.0 غيغابايت	تحميل جزئي على المعالج، أبطأ بكثير

شاشة واحدة، والنقاش الدائم في المنتديات «Q4 أم Q8» ينحصر في جهازك أنت بدل جهاز غيرك.

من أين تأتي الأرقام

جدول البت-لكل-وزن يأتي من صيغ الكمّي ggml في llama.cpp — الأرقام نفسها التي بُنيت بها الملفات على Hugging Face:

الكمّي	bpw	الكمّي	bpw
Q2_K	3.35	Q5_K_M	5.69
Q3_K_M	3.91	Q6_K	6.59
IQ4_XS	4.25	Q8_0	8.50
Q4_K_M	4.85	F16	16.0

ونصف ذاكرة KV يستخدم الهندسة المعلَمة لكل عائلة نماذج. الانتباه المجمّع للاستعلامات (GQA) هو القصة كلها هناك: نموذج 8B من فئة Llama-3 يحتفظ بـ 8 رؤوس KV × 128 بُعدًا × 32 طبقة، أي 128 كيلوبايت لكل رمز — بينما يحرق Llama 2 بحجم 13B، بلا GQA، 640 كيلوبايت لكل رمز، خمسة أضعاف، وهو من جيل أقدم. قائمة المعماريات المنسدلة تغطي الأشكال الأربعة الشائعة، إضافة إلى وضع مخصص لأي شيء يمكن قراءته من ملف config.json.

حجم الملف أخبرك بما ستُنزّل. ولم يخبرك قط بما تستطيع تشغيله.

ما تتجاهله التقديرات عمدًا

ثلاثة أمور، عن قصد. توجيه mixture-of-experts: الاستدلال يلمس الخبراء النشطين فقط، لكن الأداة تسعّر مجموعة الأوزان كاملة، فتظهر إجماليات MoE مرتفعة. الكمّي المختلط: Q4_K_M هو نفسه متوسط عبر الموترات، والملف الحقيقي يهبط أو يعلو بضع نقاط مئوية عن قيمة الجدول. وحشو جهة CUDA يتبع نسخة الواجهة الخلفية — الـ 0.7 غيغابايت الثابتة رقم متوسط، وليس ثابتًا فيزيائيًا. حين يكون القرار يستحق أكثر من بضع مئابات ميغابايت، تجاوز التقديرات واقرأ ترويسة الملف بـ gguf_dump.py من llama.cpp — الحواسيب التي تقرأ الترويسات تفعل ذلك بالضبط. هذه تبقى حسابًا بقصد: ثلاثة مدخلات يمكنك إعادة اشتقاقها يدويًا، وحكم يمكنك أن تجادله.

الأداة تعيش على github.com/mrsaynothing/gguf-vram-calculator — ملف HTML واحد، بلا اعتماديات، بلا خط بناء. تجاور دليل GGUF المحلي وllama.cpp مقابل Ollama وقائمة أفضل النماذج المحلية للبرمجة، ونظيرتها في جانب التقديم في هل يشغّل vLLM ملفات GGUF.

إذا خالف حكمٌ ما أزمنة التحميل عندك، افتح issue في المستودع مع النموذج والكمّي والسياق — الجدول يجب أن ينجو من ملامسة العتاد الحقيقي، وكل موضع خلاف هو صف يُصلَح.