جدول توافق VRAM ذات 8 جيجابايت يكذب بنسبة 7 بالمئة

أفضل نموذج ollama لذاكرة VRAM بسعة 8 جيجابايت: qwen2.5:7b (Q4_K_M) — نحو 5.4 جيبايت بالكامل عند سياق 8k، أكبر هامش، والوحيد من الخمسة الذي ما زال يدخل عند 32k. llama3.1:8b (≈6.2 جيبايت) وqwen3:8b (≈6.4 جيبايت) يدخلان عند 8k. gemma2:9b يحتاج ≈8.6 جيبايت عند 8k ويفشل — سياق 4k فقط.

ماذا تحمل ذاكرة VRAM ذات 8 جيجابايت فعلًا؟

الادعاء: البطاقة «ذات 8 جيجابايت» لا تحمل أبدًا 8 جيجابايت عشرية من النموذج — بل تحمل 8 جيبايت ثنائية، ويسحب سطح المكتب نصيبه قبل وصول النموذج. التسويق اشترى الرقم «8» مرتين وأعطاه معنيين مختلفين؛ وقاتل نفاد الذاكرة لديك لا يعترف إلا بمعنى واحد. جيجابايت البطاقة الثمانية هي 8 × 2³⁰ بايت = 8.59 جيجابايت عشرية. أما 4.92 جيجابايت لملف GGUF فهي 4.92 × 10⁹ بايت. الكلمة نفسها، مسطرتان، وفجوة ثابتة قدرها 7.4% بينهما — بدأت أسميها شبح السبعة بالمئة، لأنه يطارد كل جدول VRAM على الإنترنت، وما من جدول تقريبًا يعترف بأي مسطرة اختار.

الخصم الثاني الذي لا يضع له أحد ميزانية: البطاقة ليست فارغة قط. سطح مكتب لينكس بمركّب يوقف فيه 0.3–0.5 جيبايت، وسياق CUDA/ROCm يأخذ ~0.3 إضافية. بدون سطح مكتب تحصل على ~7.6 جيبايت للعب؛ وعلى سطح مكتب فخطط لـ7.3 جيبايت قابلة للاستخدام. كل حكم توافق في هذا النص يقاس على هذا الخط.

لماذا تختلف جداول VRAM بنسبة 7 بالمئة؟

الادعاء: الجداول لا تقرّب بشكل مختلف — بل تخلط المسطرتين، وعند الحد يكون الخلط هو من يحسم الجواب. خذ gemma2:9b. الملف يذكر 5.76 جيجابايت (عشرية). جدول ساذج يقارن 5.76 بـ«8» ويكتب ممتلئ 72% — حسنًا، أرسله. المدونة الصادقة عند سياق 4k: 5.37 جيبايت (ملف) + 1.31 جيبايت (KV) + 0.6 جيبايت (حد إضافي) = 7.28 جيبايت مقابل 7.3 قابلة للاستخدام. النموذج نفسه، البطاقة نفسها، السياق نفسه: نسبة 72% في الجدول ونسبة 99.7% في الواقع هما الصف نفسه. القسمة سطر واحد — جيبايت = جيجابايت ÷ 1.074 — وكل حكم أدناه يعرض قسمته.

أفضل نموذج ollama لذاكرة VRAM ذات 8 جيجابايت: جدول الحكم

الادعاء: عند سياق 8k تدخل أربعة من الخمسة الافتراضيات المجتمعية — والذي لا يدخل هو طراز 9B الذي توصي به القوائم بلا انقطاع. الأحجام مقيسة اليوم من واجهة ملفات Hugging Face (مستودعات GGUF من bartowski، Q4_K_M — التكميم الافتراضي لollama لهذه العائلات؛ mistral:7b يأتي بـq4_0 افتراضيًا، ضمن ~2% من الملف المقيس):

curl -s https://huggingface.co/api/models/bartowski/Meta-Llama-3.1-8B-Instruct-GGUF/tree/main \
  | jq '.[] | select(.path | test("Q4_K_M"))'

تحقق: Q4_K_M.gguf → 4,920,739,232 بايت، مسحوبة بتاريخ 2026-11-01. السطر نفسه دُوِّر على المستودعات الخمسة كلها.

النموذج (وسم ollama)	الملف، جيجابايت عشرية	÷ 1.074 = جيبايت	KV عند 8k	الحد الإضافي	المجموع جيبايت	الحكم عند 8k
qwen2.5:7b	4.68	4.36	0.44	0.6	5.40	يدخل — الأوسع احتواءً؛ يتحمل 32k (6.71)
mistral:7b	4.37	4.07	1.00	0.6	5.67	يدخل، باتساع
llama3.1:8b	4.92	4.58	1.00	0.6	6.18	يدخل؛ 16k على حافة الشفرة (7.18)؛ 32k يفشل (9.18)
qwen3:8b	5.03	4.68	1.13	0.6	6.41	يدخل — راقب ميزانية التفكير
gemma2:9b	5.76	5.37	2.63	0.6	8.59	يفشل عند 8k — سياق 4k فقط (7.28، على حافة الشفرة)

الفائز مممل عمدًا: ollama pull qwen2.5:7b يمنحك أكبر سياق قابل للاستخدام لكل جيبايت، وهو الصف الوحيد هنا الذي ما زال يدخل عند مضاعفة السياق إلى 32k (6.71 جيبايت). صف الفشل هو الإيصال الذي يبرر النص: gemma2:9b يفتقد 8k بمقدار 1.29 جيبايت حتى مع ميزانية إضافية معدومة — 5.37 + 2.63 = 8.0 مقابل 7.3 قابلة للاستخدام. لا تكميم يصلح ذلك؛ Q4_K_M هو الصغير أصلًا.

كم من الـVRAM تلتهمه ذاكرة KV؟

الادعاء: السياق هو النموذج الثاني الذي تحمّله، والمعمارية هي من تحدد الثمن — لكل token يفرض gemma2:9b ستة أضعاف ما يفرضه qwen2.5:7b. ذاكرة KV هي ذاكرة عمل النموذج للمحادثة: 2 بايت × طبقات × kv-heads × head-dim، بدقة fp16، لكل token. انتباه Qwen2.5-7B النحيف 28×4×128 يفرض 56 KiB/token. وGemma-2-9B بنسبته 42×8×256 يفرض 336 KiB/token. هذا السعر لكل token — لا حجم الملف — هو ما يقتل السياق الطويل على بطاقة صغيرة.

النموذج	KV عند 4k	KV عند 8k	KV عند 16k	KV عند 32k
qwen2.5:7b (56 KiB/tok)	0.22 جيبايت	0.44	0.88	1.75
mistral:7b / llama3.1:8b (128)	0.50	1.00	2.00	4.00
qwen3:8b (144)	0.56	1.13	2.25	4.50
gemma2:9b (336)	1.31	2.63	5.25	10.50

حاشية خاصة بعام 2026: qwen3 نموذج مفكر. رموز استدلاله النصية هي رموز سياق — جواب قصير «فكر» لمدة 3,000 token يدفع ثمنها عند 144 KiB للرمز حتى يُعاد ضبط السياق. على بطاقة بسعة 7.3 جيبايت، ميزانية التفكير ليست إعدادًا مزاجيًا؛ إنها جدول KV أعلاه وهو يتراكم فائدة على فائدة.

الحساب، سطرًا بسطر

خط القابل للاستخدام: 8 جيبايت − 0.4 (سطح المكتب، مركّب + عرض) − 0.3 (سياق CUDA) ≈ 7.3 جيبايت؛ وضع بلا سطح مكتب يستعيد ~0.3 إضافية. الحد الإضافي 0.6 = سياق CUDA ~0.3 + ذاكرة حسابية ~0.3 عند 8k؛ النطاق الصادق 0.4–1.2 جيبايت حسب الواجهة الخلفية والسياق — حكم فشل gemma2 صامد على كامل النطاق، ولهذا يكفي الحد. معدلات KV: llama3.1-8B بنسبة 32L×8kv×128d؛ qwen2.5-7B بنسبة 28×4×128؛ qwen3-8B بنسبة 36×8×128؛ gemma2-9B بنسبة 42×8×256؛ mistral-7B-v0.3 بنسبة 32×8×128 — الكل ×2 بايت ×2 (K وV). تحويلات الجيبايت: بايتات الملف ÷ 2³⁰ (4,920,739,232 → 4.58؛ 4,683,074,240 → 4.36؛ 4,372,812,000 → 4.07؛ 5,027,784,224 → 4.68؛ 5,761,057,728 → 5.37). ملاحظة صدق عن gemma2: نصف طبقاته منزلقة النافذة، فذاكرة KV الحقيقية في llama.cpp أصغر من هذا الرقم المحافظ للانتباه الكامل — حكم الفشل لا يحتاج الخصم ليصمد. آخر اختبار 2026-11-01.

ما لا يستطيع هذا الجدول إخبارك به

الادعاء: كل رقم أعلاه حساب على أحجام عامة — والرقمان اللذان ما زال الجدول يخمنهما هما الحد الإضافي وMoE، وهو بالضبط موضع القياس القادم. الحد الإضافي نطاق يرتدي زيًا رسميًا؛ أي حاسبة تطبع رقمًا واحدًا للحد الإضافي إنما تخمّن، بما في ذلك مقال حاسبة GGUF VRAM لدينا — جرحه، ذاك الذي يرفض حساب MoE، موثق هناك. وخط التوافق يتحرك مع سطح مكتبك: أقلع بلا سطح مكتب، تستعيد ~0.3 جيبايت، ويتحول gemma2:9b عند 4k من حافة الشفرة إلى ضيق عادي. ما سيحسم الأمر: النماذج الخمسة نفسها عبر ollama على بطاقة حقيقية سعتها 8 جيجابايت، وأرقام nvidia-smi مطبوعة مقابل تنبؤات هذا الجدول. ذلك المنضدة ليست هذا النص — البطاقة على هذا المكتب لا حق لها أن تتظاهر بأنها كذلك.

آخر اختبار 2026-11-01 — الأحجام مسحوبة مباشرة من واجهة ملفات Hugging Face؛ حساب التوافق قسمة، لا انطباعات.