تكميم Ollama: أيهما أفضل Q4 أم Q8 أم fp16؟

تغييرات التكميم في Ollama

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

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

إذا لم يكن 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 في وثائق quantize، وتنطبق هذه القياسات جيداً على أي نموذج كثيف ذي بنية مماثلة.

[
  {
    "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 لمعظم العائلات. تخالف بعض العائلات الأحدث هذا النمط، وتظهر في المكتبة بوسوم سحابية فقط، من دون أي ملف يمكن سحبه بأي حجم. هذا هو العائق الذي تواجهه عند محاولة تشغيل GLM 5.2 على VPS. هذه هي أحجام Qwen3 اعتباراً من August 2026، وقد قرأناها من قائمة الوسوم في صفحة النموذج. كل رقم أدناه يعبّر عن حجم القرص قبل تحميل النموذج إلى RAM، وسيؤدي جمع نموذجين أو ثلاثة منها إلى امتلاء وحدة التخزين الجذرية في VPS صغير. لذلك من المفيد معرفة مكان تخزين Ollama للنماذج التي ينزّلها قبل البدء في جمع الوسوم.

[
  {
    "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 إلى زيادة تبلغ نحو سبعين بالمئة، وليس إلى الضعف تماماً، لأن tensors الخاصة بالتضمين والإخراج لا تتوسع بالطريقة نفسها التي تتوسع بها بقية المكونات. ويبلغ fp16 نحو ثلاثة أضعاف q4_K_M. يحتاج نموذج 32B بإصدار q4_K_M إلى 20 GB من الأوزان، وهو حجم يتجاوز بالفعل ما يمكن لخادم بسعة 16 GB استيعابه مع أي context window. للحصول على صورة أوسع عن النماذج التي تناسب كل جهاز، راجع النماذج التي يمكنك استضافتها ذاتياً.

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

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

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 ببقية المعلومات. اضرب تكلفة الرمز الواحد في حجم النافذة، وستتوقف تكلفة الذاكرة المؤقتة عن كونها هامشية.

[
  {
    "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 رمزاً، تضيف الذاكرة المؤقتة 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 وتكلفته النافذة نفسها بالتفصيل. كما تُحدَّد سعة الذاكرة المؤقتة مرة لكل خانة طلب متزامن، وليس مرة واحدة لكل خادم. لذلك فإن السماح لـOllama بالإجابة عن طلبين في الوقت نفسه يضاعف القيمة التي حسبت ميزانيتها للتو. وهذا هو الأساس الحسابي وراء اختيار عدد الخانات المتوازية وحدّ قائمة الانتظار.

ما الذي يناسب 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 لديك سيكشف التكميم المفرط خلال فترة بعد الظهر.

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

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

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

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

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

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

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

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، تؤدي مضاعفة عدد البتات لكل weight إلى خفض معدل token إلى النصف تقريباً، ويؤدي خفضها إلى النصف إلى مضاعفة المعدل تقريباً. تُعد Quantization أكبر وسيلة لزيادة السرعة على جهاز لا يحتوي على GPU. يعتمد مدى تحمّل المعدل المتبقي على النموذج. يوضّح Nemotron 3.5 Lightning على VPS هذا الحساب لبنية محددة، مع تضمين tag وقيمة RAM. ويتعلق نصف وقت الانتظار الآخر بكمية النص التي يقرر النموذج كتابتها. فعند معدل يبلغ 10 tokens في الثانية، تستغرق إجابة من 600 token دقيقة كاملة. لذلك يتيح تحديد طول الرد باستخدام num_predict غالباً تقليل وقت الانتظار أكثر مما يتيحه خفض الدقة خطوة إضافية.

تختلف معالجة الـ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 النهائي. يتضمن مسار الاستيراد هذا مشكلة محتملة خاصة به، وهي عدم تطابق قالب المحادثة، ما يجعل النموذج يرد بنص غير مفهوم. يشرح استيراد ملف GGUF إلى Ollama هذه العملية بالتفصيل. يوضح السطر 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 المؤقتة وbuffers تجاوز سعة الذاكرة في الجهاز. على VPS لا يحتوي على swap مُعدّ، قد يتوقف الجهاز بالكامل لعدة ثوانٍ قبل ظهور ذلك السطر.

أصبحت الإجابات أسوأ رغم أنك لم تغيّر شيئاً. قد يوجد buildان من النموذج نفسه جنباً إلى جنب في ollama ls باستخدام tags مختلفة، وقد يتبع script ينزّل الاسم غير المضاف إليه suffix أي نسخة تشير إليها المكتبة حالياً. شغّل ollama show باستخدام tag المطابق تماماً لما يطلبه client، واقرأ السطر 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 بتاً بدلاً من ثمانية للسبب نفسه. استخدم القيمة المقاسة عند التقدير: عدد المعاملات مضروباً في عدد البتات لكل وزن، ثم مقسوماً على ثمانية، يعطي حجم الملف بالبايت.

ما مقدار RAM الذي يحتاج إليه نموذج 8B على 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 لتقليل الذاكرة المؤقتة إلى النصف، أو نزّل تكميمًا أصغر.