كم تحتاج من ⁨VRAM⁩ لنموذج ⁨LLM⁩ محلي؟ جداول من ⁨7B⁩ إلى ⁨70B⁩ (⁨2026⁩)

لا وقت للصيغة؟ استخدم هذه القواعد البسيطة:

بمجرد معرفة ميزانية VRAM لديك، راجع أي GPU تناسب كل مستوى ←

VRAM (GB) = (حجم النموذج بالمليار × 4 بايت × عامل التكميم)

• حجم النموذج: عدد المعاملات (7B, 13B, 70B, إلخ)

• 4 بايت: دقة FP32 (1 بايت = 8 بت)

• عامل التكميم: 1.0 (FP32)، 0.5 (Q8)، 0.25 (Q4)

مثال: Llama 3 70B، FP32، دون تكميم:

70 مليار × 4 بايت = 280 GB. غير عملي.

Llama 3 70B، تكميم Q4 (4 بت):

70 مليار × 4 بايت × 0.25 = 70 GB مخصصة، ~24 GB مستخدمة بعد الضغط.

نماذج MoE (المتفرقة): تحدد المعاملات النشطة الحوسبة، لكن يجب أن يبقى كل الخبراء محمّلين في VRAM. مثال: Llama 4 Scout لديه 109B معامل إجمالي مع 17B نشطة لكل token. بـ Q4 لا يزال يحتاج ~55 GB من VRAM لإبقاء كل الخبراء — يتسع في GPU بسعة 24 GB فقط بتكميم عدواني 1.78 بت (~20 tok/s). الحوسبة رخيصة؛ الذاكرة هي القيد.

توزّع نماذج Mixture-of-Experts (MoE) معاملاتها بين شبكات فرعية "خبيرة" عديدة وتفعّل جزءًا منها فقط لكل token. تقلّل المعاملات النشطة الحوسبة وتسرّع الاستدلال، لكن في معظم نماذج MoE يجب أن يبقى كل الخبراء محمّلين في VRAM — لذا يتبع استخدام الذاكرة إجمالي المعاملات لا النشطة.

القاعدة للنماذج الكثيفة: VRAM = المعاملات_الإجمالية × بايت_لكل_معامل

القاعدة لنماذج MoE (الحوسبة): تحدد المعاملات_النشطة الـ tokens/ثانية — لكن VRAM لا تزال تتوسّع مع الأوزان الإجمالية المقيمة.

مثال: Llama 4 Scout لديه 109B معامل إجمالي مع 17B نشطة فقط لكل token. سريع لحجمه، لكنه بـ Q4 لا يزال يحتاج ~55 GB من VRAM لإبقاء كل الخبراء — خارج متناول GPU واحدة بسعة 24 GB إلا بتكميم عدواني 1.78 بت (~20 tok/s على RTX 4090).

تستطيع بعض بيئات التشغيل بثّ الخبراء غير النشطين أو إنزالهم إلى RAM النظام، مضحّيةً بالسرعة مقابل بصمة VRAM أقل. الخلاصة الأساسية: لا تفترض أن نموذج MoE يتسع في VRAM بحجم معاملاته النشطة — تحقّق من الحجم الفعلي على القرص لمستوى التكميم لديك.

يقلّل التكميم عدد البتات اللازمة لتمثيل كل معامل في النموذج.

• FP32 (عدد عشري 32 بت): دقة كاملة. 1 معامل = 4 بايت. دون فقدان. الأبطأ.

• Q8 (8 بت): 1 معامل = 1 بايت. ~6% فقدان دقة. 75% توفير في VRAM.

• Q5 (5 بت): 1 معامل = 0.625 بايت. ~2% فقدان دقة. 84% توفير في VRAM.

• Q4 (4 بت): 1 معامل = 0.5 بايت. ~1% فقدان دقة. 87.5% توفير في VRAM.

لمعظم المستخدمين، Q4 هي النقطة المثالية: فقدان دقة غير محسوس، وبصمة VRAM أقل بنسبة 87%.

اعتبارًا من أبريل 2026، Q4 هي المعيار. وتتوفر Q5 و Q8 إذا كان لديك VRAM فائضة وتريد مكاسب جودة هامشية.

تحدد VRAM حجم النموذج، لكن تصميم الـ prompt يحدد جودة المخرجات. تستطيع تقنيات مثل chain-of-thought و few-shot prompting سد فجوة الجودة بين النماذج الأصغر والأكبر. استكشف مجموعة أدوات هندسة الـ prompt الكاملة للاستفادة أكثر من النماذج التي يدعمها جهازك. وإذا كان لديك 12–16 GB من VRAM وتريد حمل برمجة محددًا لتجربة تلك المجموعة، فإن استبدال GitHub Copilot بنموذج LLM محلي يربط حزمة Continue.dev + Ollama + Qwen3-Coder بدقة بمستويات VRAM تلك.

يؤثر batch size في الإنتاجية (tokens في الثانية)، لا في زمن استجابة استدلال فردي.

مستخدم واحد يسأل "كم 2+2؟" يستخدم VRAM نفسها بغض النظر عمّا إذا كان batch size 1 أو 32.

batch size = 32 يعني معالجة 32 prompt على التوازي. يستخدم هذا ~32× أكثر من VRAM، لكنه يولّد 32 إجابة أسرع.

لمستخدم واحد (الاستخدام النموذجي لـ LLM محلي): batch size = 1. تكون VRAM هي حجم النموذج + 1-2 GB عبء.

لخادم متعدد المستخدمين: خصّص batch size × VRAM النموذج. يحتاج نموذج 70B بـ batch=4 إلى ~96 GB (24 GB × 4).

نعم. إضافةً إلى أوزان النموذج، أضف:

• ذاكرة KV (ذاكرة المفتاح-القيمة للسياق): ~5-10% VRAM إضافية.

• حالة المُحسّن (عند الـ fine-tuning): 2-4× حجم النموذج (متعلقة بالتدريب فقط، لا بالاستدلال).

• عبء النظام (نظام التشغيل، التعريفات، بيئة تشغيل Ollama/LM Studio): ~1-2 GB.

القاعدة: نموذج 70B Q4 (20 GB) + ذاكرة KV (2 GB) + نظام (2 GB) = ~24 GB مخصصة.

اشترِ دائمًا GPU بهامش 1-2 GB على الأقل فوق الحد الأدنى النظري.

اختر حجم نموذجك والتكميم لتقدير متطلبات VRAM.