Ollama: مقارنة Q4 وQ8 وfp16 واستهلاك الذاكرة

ما الذي تغيّره عملية التكميم في Ollama

تخزّن عملية التكميم في Ollama كل وزن في النموذج بعدد بتات أقل من الملف الذي دُرِّب فيه. تحافظ علامة تنتهي بـq4_K_M على نحو أربع بتات لكل وزن، بينما تحافظ fp16 على ست عشرة بتة، لذلك يكون التنزيل بحجم يقارب الربع، وتقرأ الآلة ربع عدد البايتات تقريباً لإنتاج كل رمز. تُقرَّب الأوزان إلى شبكة متباعدة، ولا تُحذف، وتجيب معظم النماذج عند استخدام أربع بتات بطريقة قريبة من إجاباتها بالدقة الكاملة.

هذه هي المقايضة كاملة: مساحة أصغر بكثير في الذاكرة وعدد أكبر من الرموز في الثانية، مقابل خسارة بسيطة في الدقة. يوضح ما يلي كيفية توقّع كلا الجانبين لنموذج محدد على جهاز محدد، قبل أن تقضي عشرين دقيقة في تنزيل ملف لن يتسع له الجهاز.

إذا لم يكن Ollama قيد التشغيل بعد، فابدأ بـتثبيت Ollama على VPS. تفترض هذه الصفحة أن ollama ls يعمل بالفعل.

كيفية قراءة وسم تكميم Ollama مثل q4_K_M

تُوزَّع النماذج المحلية في ملفات GGUF، وهي الصيغة التي يستخدمها llama.cpp لتخزين الأوزان على القرص. يعتمد Ollama على llama.cpp، لذلك تنقل وسوم Ollama أسماء التكميم في llama.cpp دون تغيير.

يمثل الرقم العرض المستهدف. يعني q4 أن معظم موترات الأوزان معبأة بأربع بتات لكل وزن. ويعني q8 ثماني بتات. أما fp16 فلا يطبق التكميم إطلاقاً؛ فهو النموذج بدقة الفاصلة العائمة ذات 16 بت، وهي الدقة التي تُنشر بها معظم النماذج.

يشير K إلى تكميم K. تُجمَّع الأوزان في كتل صغيرة، وتخزّن كل كتلة مقياسها الخاص بجوار القيم المعبأة. تحصل الكتلة التي تقع أوزانها كلها قرب 0.01 على مقياس دقيق. أما الكتلة التي تحتوي على قيمة شاذة كبيرة فتحصل على مقياس خشن. تحافظ هذه المقاييس الخاصة بكل كتلة على قابلية استخدام الملف ذي الأربع بتات، وهي أيضاً السبب في أن الملف ذي الأربع بتات لا يستخدم أربع بتات بالضبط لكل وزن.

يمثل الحرف الأخير نوع المزج. تحدد S وM وL عدد الموترات التي تُرقّى إلى عرض أكبر من العرض المستهدف. في q4_K_M، تُخزَّن الموترات التي يتسبب تقريبها في أكبر خسارة بعرض أكبر، بينما تبقى معظم الأوزان عند أربع بتات. لذلك ينتج q4_K_M مخرجات أفضل من q4_0 الأقدم، مع بقاء حجم الملف مماثلاً تقريباً.

اطلب من Ollama عرض ما هو موجود على القرص بدلاً من التخمين استناداً إلى الاسم الذي أدخلته:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

يعرض ollama show كلاً من architecture وparameters وquantization وcontext length وembedding length. ويمثل السطر quantization المرجع الفعلي للنموذج الذي نزّلته قبل أشهر ولم تعد تتذكر اختيارك له.

عدد البتات لكل وزن هو مصدر حجم الملف

يبدأ كل تقدير للحجم من رقم واحد: عدد البتات التي يخصصها التنسيق لكل وزن، بعد حساب المتوسط على مستوى الملف بالكامل. تنشر llama.cpp قيماً مقاسة للنموذج Llama 3.1 8B في وثائق التكميم الخاصة بها، وتنطبق هذه القيم جيداً على أي نموذج كثيف ذي بنية مماثلة.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

المفاجأة في ذلك الجدول هي العمود الثاني. لا يستخدم Q4_K_M أربعة بتات لكل وزن. بل يستخدم 4.89 بتات، لأن مقاييس الكتل والموترات التي تحصل على دقة أعلى تشغل مساحة فعلية أيضاً. ويستخدم Q8_0 8.5 بتات بدلاً من ثمانية للسبب نفسه. استخدم الرقم المقاس، وستصل الحسابات إلى نتيجة لا تختلف عن حجم الملف الفعلي إلا ببضعة بالمئة:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

هذا هو ملف Q4_K_M بحجم 4.58 GiB، وقد استُخرج حجمه من رقمين. وهو أيضاً، تقريباً، مقدار الذاكرة التي تشغلها الأوزان بعد تحميلها. لا يفكك Ollama الأوزان عند التحميل؛ إذ تبقى الأوزان المكمّمة في الذاكرة بالشكل المعبأ نفسه، ويُحوَّل كل بلوك عند استخدامه.

ما الذي توفّره Ollama فعلياً لكل حجم من أحجام النماذج

تنشر المكتبة وسم q4_K_M ووسم q8_0 ووسم fp16 لمعظم العائلات. هذه هي أحجام Qwen3 في أغسطس 2026، كما تظهر في قائمة الوسوم على صفحة النموذج.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

يهمّ الوسم الافتراضي هنا. ينزّل ollama pull qwen3:8b العدد نفسه تماماً، وهو 5.2 GB، الذي ينزّله ollama pull qwen3:8b-q4_K_M، لأن الوسم غير المُلحق هو إصدار q4_K_M نفسه. لا يمثّل Q4_K_M حلاً وسطاً توفّره المكتبة على مضض. بل هو الإصدار الافتراضي الذي اختاره المصدر upstream، ولذلك فإن مطابقته خطوة أولى منطقية لأي نموذج لم تختبره بنفسك. وينطبق المنطق نفسه على اختيارات الوسوم في تشغيل Qwen 3 على VPS.

تنطبق النسب على كل صف. الانتقال من q4_K_M إلى q8_0 يكلّف نحو سبعين بالمئة إضافية، وليس ضعف الحجم تماماً، لأن موترات التضمين والإخراج لا تتوسع بالطريقة نفسها التي تتوسع بها بقية المكونات. ويبلغ حجم fp16 نحو ثلاثة أضعاف q4_K_M. يحتاج نموذج 32B باستخدام q4_K_M إلى 20 GB من الأوزان، وهذا يتجاوز بالفعل سعة جهاز بسعة 16 GB إذا أُريد له استخدام أي نافذة سياق. للحصول على صورة أشمل عن النماذج التي تناسب كل جهاز، راجع النماذج التي يمكنك استضافتها ذاتياً.

لماذا تُعدّ KV cache تكلفة ثانية تعتمد على السياق

الأوزان هي التكلفة الثابتة. أما KV cache، أي ذاكرة التخزين المؤقت للمفاتيح والقيم، فهي التكلفة المتغيرة. يحتفظ كل token في نافذة السياق بمتجهَي المفتاح والقيمة الخاصين به في كل طبقة، لذلك تنمو ذاكرة التخزين المؤقت خطياً مع حجم النافذة التي تسمح بها. تُخصَّص للنافذة كاملة عند تحميل النموذج، ولا تنمو تدريجياً مع امتلاء المحادثة. لذلك تستهلك النافذة الطويلة الذاكرة حتى مع prompt من كلمة واحدة.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

تأتي أرقام النموذج من إعداداته الخاصة: 36 طبقة، و8 رؤوس للمفاتيح والقيم، وبُعد رأس قدره 128. يمنحك ollama show بنية النموذج وعدد المعاملات، بينما يمنحك config.json للنموذج على Hugging Face بقية المعلومات. اضرب تكلفة كل token في حجم النافذة، ولن تعود تكلفة ذاكرة التخزين المؤقت هامشية.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

عند استخدام نافذة Ollama الافتراضية التي تضم 4096 token، تضيف ذاكرة التخزين المؤقت 0.6 GB فوق الأوزان. ارفع النافذة إلى 32k، وستصل ذاكرة التخزين المؤقت وحدها إلى 4.83 GB. وهذا يساوي تقريباً حجم الذاكرة الذي تستهلكه الأوزان المكمّمة، فتصبح الذاكرة الدنيا المطلوبة للنموذج كله 10 GB. نسميها حداً أدنى لأن مخازن الحساب ونظام التشغيل يستهلكان ذاكرة إضافية. اقرأ القيمة الفعلية من العمود SIZE في ollama ps بعد تحميل النموذج.

تُحدَّد النافذة على الخادم، وليس لكل طلب، عند تشغيل Ollama كخدمة:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

في تثبيت systemd، ضعها في ملف drop-in بدلاً من ذلك:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

أعد التشغيل باستخدام sudo systemctl restart ollama، ثم تحقق من العمود CONTEXT في ollama ps لتأكيد النافذة التي حُمِّل بها النموذج قيد التشغيل فعلياً. يكمّم OLLAMA_KV_CACHE_TYPE ذاكرة التخزين المؤقت نفسها: ‏f16 هو الإعداد الافتراضي، ويستخدم q8_0 نحو نصف الذاكرة التي يستخدمها f16، بينما يستخدم q4_0 نحو الربع. هذا خيار عام، لذلك تحصل كل النماذج على الخادم على المعالجة نفسها. في جهاز صغير ذي نافذة طويلة، يؤدي تقليل حجم ذاكرة التخزين المؤقت إلى النصف إلى تحرير ذاكرة أكبر من أي تغيير منفرد آخر. يشرح ضبط num_ctx وتكلفته النافذة نفسها بالتفصيل.

ما الذي يتسع له VPS بسعة 8 أو 16 أو 32 GB

تحتاج إلى احتساب أحجام الأوزان، وذاكرة KV cache، ومساحة احتياطية لنظام التشغيل وأي شيء آخر قيد التشغيل. تُعد مساحة احتياطية قدرها 2 GB مريحة على VPS صغير.

8 GB. يستهلك نموذج 4B بإعداد q4_K_M مقدار 2.6 GB، ويترك مساحة لنافذة سياق طويلة. يتسع نموذج 8B بإعداد q4_K_M مع نافذة 4k الافتراضية، لكن المساحة المتبقية قليلة جداً. لا تخطط لاستخدام 8B مع نافذة 32k هنا، لأن الحد الأدنى البالغ 10 GB يتجاوز سعة الخادم بالفعل.

16 GB. يكون نموذج 8B بإعداد q4_K_M مريحاً مع نافذة 16k أو 32k. يستهلك نموذج 14B بإعداد q4_K_M مقدار 9.3 GB من الأوزان، ويتسع مع نافذة متوسطة. يستهلك نموذج 8B بإعداد q8_0 مقدار 8.9 GB، ولذلك يتسع أيضاً. وتُعد مقارنة النموذجين باستخدام مطالباتك الخاصة أكثر ساعة مفيدة يمكنك إنفاقها في هذا الموضوع.

32 GB. يُحمَّل كل من نموذج 14B بإعداد q8_0 (16 GB) ونموذج 32B بإعداد q4_K_M (20 GB). سيدفع إصدار 32B مع نافذة كبيرة الذاكرة إلى الحد الأقصى، لذا راقب ollama ps بدلاً من افتراض أنه سيتسع.

ما الذي يتدهور أولاً بسبب التكميم

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

النقطة الأخيرة هي الاختبار العملي. عندما يجب على النموذج إرجاع JSON يحلله برنامجك، يظهر ضرر التكميم على شكل خطأ في التحليل بدلاً من نثر أسوأ بشكل غير محدد، ولذلك تلاحظه في اليوم نفسه. ويُعد وكيل البرمجة النسخة الأصعب من هذا الاختبار، لأنه يمرر النموذج عبر استدعاءات أدوات متتالية، لذلك فإن توجيه وكيل إلى خادم Ollama لديك سيكشف التكميم المفرط في غضون فترة بعد الظهر.

تزداد الخسارة بحدة عند النزول إلى أقل من 4 بتات. يوجد نوعا q3 والبتّين لمن يحاولون تشغيل نموذج كبير على عتاد صغير، وهما خيار حقيقي عندما يكون البديل هو عدم تشغيل النموذج إطلاقاً. لكنهما ليسا خياراً افتراضياً جيداً. الفارق بين q4_K_M وq8_0 صغير بما يكفي بحيث لن يحسمه جدول perplexity منشور وفقاً لحمل العمل لديك، لذلك لا تحاول حسم الأمر بهذه الطريقة. شغّل كليهما على 30 مطالبة من مطالباتك واقرأ الناتج.

متى تستحق q8_0 أو fp16 استهلاك الذاكرة

استخدم q8_0 عندما تكون الذاكرة متاحة فعلاً، وعندما تعاقب المهمة الأخطاء الصغيرة: الاستخراج المنظّم، واستدعاء الأدوات، والبرمجية التي يجب أن تُترجم بنجاح. أنت تشتري هنا هامش أمان، لا نموذجاً أذكى بشكل ملحوظ.

استخدم fp16 لسببين فقط. إما أنك تجري quantization للنموذج بنفسك وتحتاج إلى الملف المصدر، أو أنك تقيس خط أساس حتى تعرف مقدار ما خسره إصدارك ذي 4 بت. يستهلك تقديم النموذج من fp16 ثلاثة أضعاف ذاكرة q4_K_M، مقابل فرق لا يستطيع معظم الناس تمييزه في اختبار أعمى. وعلى جهاز يعمل بوحدة المعالجة المركزية فقط، يخفض ذلك أيضاً معدل الرموز إلى الثلث.

القاعدة الأقوى عند ثبات ميزانية الذاكرة هي أن نموذجاً أكبر باستخدام q4_K_M يتفوق عادةً على نموذج أصغر باستخدام q8_0. إن استخدام 9.3 GB من أوزان 14B مقابل 8.9 GB من أوزان 8B يحتاج إلى مقدار متقارب من ذاكرة RAM (ذاكرة الوصول العشوائي)، بينما يعرف النموذج الأكبر المزيد. اختبر ذلك باستخدام مطالباتك الخاصة بدلاً من الاعتماد عليه دون تحقق.

يقتصر الاستدلال باستخدام CPU فقط بسبب عرض نطاق الذاكرة

لا تتضمن معظم خطط VPS وحدة GPU، لذلك يعمل النموذج في ذاكرة النظام باستخدام CPU الخاص بالمضيف. عندئذٍ يصبح التوليد مقيداً بعرض نطاق الذاكرة، لا بالعمليات الحسابية، لأن إنتاج token واحد يتطلب قراءة كل وزن مرة واحدة. لذلك يوجد حد أقصى لا علاقة له بعدد الأنوية التي اشتريتها.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

تبلغ القيمة النظرية تقريباً 50 GB/s في مضيف يستخدم DDR4-3200 ثنائي القناة. حصتك أصغر، لأن VPS يشارك ناقل الذاكرة مع كل المستأجرين الآخرين على الجهاز. لذلك اعتبر هذه الأرقام حداً أقصى لا يصل إليه أحد. المهم هو الاتجاه: عند استخدام CPU، تؤدي قسمة عدد البتات لكل وزن إلى النصف تقريباً إلى مضاعفة معدل إنتاج tokens. ويُعد Quantization أكبر عامل متاح لزيادة السرعة على جهاز لا يحتوي على GPU.

تعمل معالجة prompt بطريقة مختلفة. فقراءة prompt طويل تعتمد على القدرة الحسابية أكثر من اعتمادها على عرض النطاق، لذلك تساعد الأنوية الإضافية في هذه المرحلة، لكنها لا تفعل شيئاً تقريباً لسرعة التوليد. من الطبيعي أن يعالج الجهاز prompt بحجم 4k بسرعة ثم يولّد النص ببطء.

لا تقبل أي حسابات كما هي دون تحقق. قِس عدد tokens في الثانية على جهازك باستخدام prompt نفسه مع كل مستوى Quantization، ودَع أرقامك تتغلب على هذه التقديرات.

إجراء التكميم بنفسك

يمكن لـOllama إنشاء نموذج مكمَّم من مصدر fp16 أو fp32. يفيد ذلك عندما تُجري ضبطاً دقيقاً لنموذج ولا توجد وسم مكتبة له. وجّه Modelfile إلى الأوزان غير المكمَّمة:

FROM /path/to/my/model/f16

ثم أنشئ النموذج وتحقق منه:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

يقبل --quantize القيم q8_0 وq4_K_S وq4_K_M. لا يوجد خيار q6_K أو q5_K_M هنا. لذلك، استخدم أداة llama.cpp الخاصة لتكميم النموذج، ثم استورد ملف GGUF الناتج. يوضح السطر quantization من ollama show ما إذا كان البناء قد نفّذ الإعداد المطلوب.

ما ستراه عند حدوث خلل

يعمل كل شيء على CPU بينما كنت تتوقع استخدام GPU. اقرأ العمود PROCESSOR:

ollama ps

يعرض هذا العمود 100% GPU أو 100% CPU أو توزيعاً مثل 48%/52% CPU/GPU. يعني التوزيع أن الأوزان وذاكرة KV المؤقتة لم تتسع لها VRAM (ذاكرة الفيديو، أي الذاكرة الموجودة على بطاقة الرسومات)، ولذلك وُضع جزء من النموذج في ذاكرة النظام. تنخفض السرعة عندئذٍ إلى ما يقارب معدل CPU وحده، لأن كل token ينتظر الجزء الأبطأ. خفّض نافذة السياق، أو أجرِ quantization لذاكرة التخزين المؤقت، أو استخدم build أصغر. لن تساعد إضافة أنوية.

تتوقف العملية أثناء تحميل النموذج. افحص سجل kernel وسجل الخدمة:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

يعني السطر الذي يحتوي على Out of memory: Killed process أن إجمالي الأوزان وذاكرة KV المؤقتة والمخازن المؤقتة تجاوز الذاكرة المتاحة على الجهاز. في VPS لا يحتوي على swap مهيأ، قد يتوقف الجهاز بأكمله لعدة ثوانٍ قبل ظهور هذا السطر.

أصبحت الإجابات أسوأ رغم أنك لم تغيّر شيئاً. يمكن أن توجد نسختان من build النموذج نفسه جنباً إلى جنب في ollama ls تحت tags مختلفة، وقد يتبع script يسحب الاسم غير المُلحق بأي tag الوجهة التي تشير إليها المكتبة حالياً. شغّل ollama show باستخدام tag المطابق تماماً لما يطلبه العميل، واقرأ السطر quantization بدلاً من الوثوق بالاسم الموجود في ملف الإعدادات.

FAQ

ما تكميم Ollama الذي ينبغي أن أسحبه؟

ابدأ بـ q4_K_M. هذه هي العلامة الافتراضية التي توفّرها مكتبة Ollama لمعظم النماذج، لذلك يجلب كل من ollama pull qwen3:8b وollama pull qwen3:8b-q4_K_M الملف نفسه. انتقل إلى q8_0 فقط عندما تتوفر ذاكرة فائضة وتكون المهمة حساسة للأخطاء الصغيرة، مثل استدعاء الأدوات أو إخراج JSON منظّم. عندما تكون ميزانية الذاكرة ثابتة، يتفوق نموذج أكبر عند q4_K_M عادةً على نموذج أصغر عند q8_0، لذلك اختبر هذا الاقتران قبل تخصيص RAM إضافية للدقة.

هل يعني q4_K_M فعلاً أربعة بتات لكل وزن؟

لا. عند قياسه على Llama 3.1 8B، يبلغ 4.89 بت لكل وزن، لأن كل كتلة من الأوزان تخزّن معامل التحجيم الخاص بها، ولأن أكثر الموترات حساسية تُرقّى إلى نوع بيانات أعرض. ويبلغ Q8_0 8.5 بت بدلاً من ثمانية للسبب نفسه. استخدم القيمة المقاسة عند التقدير: عدد المعاملات مضروباً في عدد البتات لكل وزن، ثم مقسوماً على ثمانية، يعطي حجم الملف بالبايت.

كم يحتاج نموذج 8B من RAM على VPS يعمل بوحدة CPU فقط؟

أضف الأوزان وذاكرة KV وهامشاً احتياطياً. يستهلك Qwen3 8B عند q4_K_M مقدار 5.2 GB من الأوزان. عند نافذة 4096 رمزاً الافتراضية، تضيف ذاكرة التخزين المؤقت مقدار 0.6 GB، ليكون الحد الأدنى قريباً من 5.8 GB قبل احتساب مخازن المعالجة ونظام التشغيل. عند نافذة 32k، تستهلك ذاكرة التخزين المؤقت وحدها 4.83 GB. خطط لتوفير 8 GB لنافذة قصيرة و16 GB إذا كنت تريد نافذة طويلة.

لماذا يعمل نموذجي عند استخدام CPU بنسبة 100% رغم أن الخادم يحتوي على GPU؟

شغّل ollama ps واقرأ عمود PROCESSOR. يعني 100% CPU، أو تقسيم مثل 48%/52% CPU/GPU، أن الأوزان مع ذاكرة KV لم تتسع لها VRAM، لذلك وضع Ollama جزءاً من النموذج أو النموذج كله في ذاكرة النظام. السبب المعتاد هو أن نافذة السياق أكبر من سعة البطاقة، لأن ذاكرة التخزين المؤقت تُخصَّص للنافذة بأكملها عند تحميل النموذج. خفّض النافذة باستخدام OLLAMA_CONTEXT_LENGTH، واضبط OLLAMA_KV_CACHE_TYPE=q8_0 على تقسيم ذاكرة التخزين المؤقت إلى النصف، أو اسحب تكميمًا أصغر.