تشغيل Qwen 3.8 27B على VPS عبر Ollama

هل يمكنك تشغيل Qwen 3.8 27B على VPS من دون GPU؟

لتشغيل Qwen 3.8 27B على VPS، تحتاج إلى الوسم qwen3.8:27b. واعتباراً من 21 October 2026، تتضمن مكتبة Ollama هذا الوسم، ويمكن سحبه محلياً. وهو يضم 27.3 billion parameters، وتكميم Q4_K_M، وترخيص Apache 2.0، ونافذة سياق بحجم 256K، وتنزيلاً بحجم 18 GB يتضمن vision projector بحجم يقارب 0.9 GB. أضافت Ollama دعم Qwen 3.8 27B في الإصدار v0.32.12، الذي صدر في 14 August 2026، لذلك يجب ترقية التثبيت الأقدم أولاً. واعتباراً من 29 October 2026، أحدث إصدار مستقر هو v0.40.13، وقد نُشر في 28 October 2026.

الإجابة المختصرة هي نعم، على VPS بسعة 32 GB أو أكثر، ولكن الأداء سيكون بطيئاً. يحتاج نموذج 27B كثيف بتكميم Q4 إلى نحو 17 GB من RAM للأوزان وحدها، قبل تخزين أي token من السياق. لذلك تُستبعد خطط 8 GB و16 GB بالكامل. وعلى VPS شائع مزوّد بذاكرة DDR4 ثنائية القناة، يبلغ الحد الأقصى نحو 3 token في الثانية، وهذا أبطأ من سرعة قراءة معظم الأشخاص.

لا تزال الوسوم الأقدم لـ27B موجودة في المكتبة: qwen3.6:27b وqwen3.5:27b كلاهما إصداران بتكميم Q4_K_M وبحجم متقارب. يحافظ Qwen3.8-27B على بنية Qwen3.6-27B، كما أن ملفات الإعداد الرسمية للنموذجين تعرض التخطيط نفسه للطبقات، لذلك تنطبق حسابات الذاكرة أدناه على أي منهما. تحقّق من القائمة الحالية قبل نسخ أي أمر، في صفحة وسم qwen3.8 في Ollama. تعتمد الحسابات هنا على عدد المعاملات، وعدد البتات لكل وزن، وتخطيط الانتباه، لا على رقم الإصدار.

وسم Ollama الذي يجب سحبه وكيفية التحقق منه

يؤدي سحب وسم غير موجود إلى عرض خطأ واضح، لذلك يمكنك حسم هذا الأمر سريعاً على الخادم نفسه. لكن وجود الوسم لا يعني بالضرورة إمكانية تشغيله محلياً، وهذا ما يسبب الالتباس عند استخدام GLM 5.2، المدرج في المكتبة لكن لا يُخدَّم إلا من سحابة Ollama.

ollama --version
ollama pull qwen3.8:27b
ollama show qwen3.8:27b

يطبع ollama show البنية وعدد المعاملات وطول السياق ونوع التكميم للوسم الموجود لديك فعلياً. إذا كان سطر المعاملات يقرأ 27.3B وكان سطر التكميم يقرأ Q4_K_M، فلديك البنية التي كُتب هذا الدليل على أساسها. تحتوي المكتبة أيضاً على qwen3.8:27b-q8_0 وqwen3.8:27b-bf16 للأوزان نفسها بدقة أعلى، وعلى متغيرات 27b-mtp، وعلى الوسوم 27b-nvfp4 و27b-mxfp8 و27b-mlx و27b-mlx-bf16 التي تصفها صفحة الوسوم بأنها MLX، وهو تنسيق موجّه إلى Apple Silicon بدلاً من Linux VPS. وبخلاف qwen3.6، لا يحتوي الإدخال qwen3.8 على وسوم 35b-a3b. تظل نماذج MoE (مزيج الخبراء) هذه ضمن qwen3.6، ويختلف سلوكها كثيراً عند تشغيلها على CPU. يرد مزيد من التفاصيل عنها أدناه.

عدد المعلمات مضروباً في عدد البايتات لكل وزن

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.98,
    "notes": "published tag qwen3.8:27b, language model file"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.5,
    "bits_per_weight": 5.7,
    "notes": "computed, no official library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 18,
    "bits_per_weight": 5.27,
    "notes": "published tag 27b-nvfp4, MLX build, one file including the vision encoder"
  },
  {
    "label": "Q8_0",
    "size_gb": 29,
    "bits_per_weight": 8.5,
    "notes": "published tag 27b-q8_0, language model file"
  },
  {
    "label": "BF16",
    "size_gb": 55,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16, language model file"
  }
]

المعادلة في سطر واحد. عدد بايتات الأوزان = عدد المعلمات * عدد البتات لكل وزن / 8. عند استخدام 4 بتات تماماً، يكون حجم 27.3 مليار معلمة 13.7 GB. يبلغ حجم ملف نموذج اللغة في الوسم qwen3.8:27b المشحون 17 GB، ما يعادل عملياً 4.98 بت لكل وزن.

هذا الفرق ليس خطأ. لا تخزّن تنسيقات K-quant كل tensor بالعرض الاسمي نفسه. تحصل tensors التي تفقد أكبر قدر من الجودة عند الضغط على عدد أكبر من البتات. تعرض قائمة Ollama الخاصة بـtensor في ملف qwen3.8:27b المشحون هذه العناصر بتنسيق Q6_K: طبقة الإخراج، ونحو نصف إسقاطات down في طبقات feed-forward، وإسقاطات attention V في نحو نصف طبقات full-attention، ونحو نصف إسقاطات QKV المدمجة في طبقات linear-attention. تبقى tensors الصغيرة الخاصة بالتطبيع بدقة 32-bit كاملة. كما تبقى token embedding وإسقاطات attention Q وK وإسقاطات feed-forward gate وup بتنسيق Q4_K، مثل معظم النموذج. الاسم الموجود في التنسيق يمثل متوسطاً، ويقترب المتوسط من 5. يظهر التأثير نفسه عند الطرف الآخر من المقياس: إن 55 GB لتنسيق BF16 تعادل 16.1 بت لكل وزن، بدلاً من 16 ثابتة. هناك تكون token embedding بتنسيق BF16 مثل كل شيء آخر، وتأتي الزيادة الصغيرة من metadata الملف، وtensors التطبيع المحتفظ بها بدقة 32-bit، ومن تقريب الحجم المعروض إلى أقرب GB.

احسب ميزانية الوسم بالكامل، لا ملف نموذج اللغة وحده. يشحن كل وسم GGUF من qwen3.8:27b أيضاً vision projector بحجم يقارب 0.9 GB، ولذلك يُدرج وسم Q4_K_M بحجم 18 GB.

لا يوجد وسم Q5_K_M منشور في إدخال مكتبة qwen3.8 الرسمية، لذلك يُحسَب صف 19.5 GB باستخدام القيمة المعتادة البالغة 5.7 بت لكل وزن لهذا التنسيق، بدلاً من قياسه. يضاعف Q8_0 حجم Q4 تقريباً ليصل إلى 29 GB. على جهاز يعمل بالـCPU فقط، يضاعف ذلك حركة الذاكرة لكل token، ولذلك يخفض أيضاً معدل المعالجة من token إلى نحو النصف. لهذا السبب وحده، يُعد Q4_K_M الخيار الافتراضي المناسب هنا. إذا كنت تريد تقييم جانب الجودة من هذا القرار، لا جانب الذاكرة، تعرض مقارنة أقرب بين Q4 وQ8 وfp16 الموضع الذي تبدأ فيه المخرجات بالتدهور فعلياً.

تكلفة ذاكرة KV مع نمو السياق

أوزان النموذج تكلفة ثابتة. أمّا ذاكرة KV المؤقتة (ذاكرة المفتاح والقيمة، وهي حالة الانتباه التي يحتفظ بها النموذج لكل token سبق أن رآه) فتنمو خطياً مع طول السياق، وهي السبب الذي يجعل معظم المستخدمين ينفد لديهم RAM فعلياً.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 0.25,
    "kv_q8_gb": 0.13
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 0.5,
    "kv_q8_gb": 0.25
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  }
]

تأتي هذه الأرقام من ملف إعداد النموذج نفسه. Qwen3.8-27B، مثل Qwen3.6-27B، نموذج ذو انتباه هجين. تستخدم 16 طبقة فقط من أصل 64 طبقة الانتباه الكامل، وتحتفظ بذاكرة مؤقتة تنمو مع كل token. وتحتوي هذه الطبقات على 4 رؤوس للمفتاح/القيمة ضمن GQA (الانتباه ذي الاستعلامات المجمّعة)، وعلى بُعد رأس يبلغ 256. أمّا الطبقات الـ48 الأخرى فتستخدم الانتباه الخطي (Gated DeltaNet)، وتحتفظ بدلاً من ذلك بحالة ثابتة الحجم. ووفق حساباتي، يبلغ حجم هذه الحالة نحو 150 MB لكل خانة محادثة، مهما بلغ طول السياق. يعادل ذلك 64 KiB لكل token عند f16، أي 2 GB عند 32k token و8 GB عند 128k. لا تعتمد على حساباتي بدلاً من فحص جهازك. حمّل النموذج واقرأ عمود SIZE في ollama ps، إذ يعرض الأوزان والذاكرة المؤقتة والنفقات الإضافية كرقم واحد.

يمكن الوصول إلى سياق 256K المذكور في بطاقة النموذج على هذه البنية، لكنه ليس مجانياً. يتطلب ملء هذا السياق عند f16 نحو 16 GB من الذاكرة المؤقتة، إضافة إلى الأوزان التي استهلكت مسبقاً 17 GB على الجهاز. لا يمنحك Ollama نافذة السياق الكاملة افتراضياً. تحدد وثائق طول السياق فيه القيمة الافتراضية وفق VRAM: 4k token عند أقل من 24 GiB، و32k عند 24 إلى 48 GiB، و256k عند 48 GiB أو أكثر. لا يملك VPS يعمل بالـCPU فقط أي VRAM، لذلك يستخدم فئة 4k، ويمكنك رفعها عمداً باستخدام OLLAMA_CONTEXT_LENGTH. هذا المتغير على مستوى الخادم ليس وسيلة التحكم الوحيدة، كما يتيح لك تعيين num_ctx في الطلب الفردي الإبقاء على قيمة افتراضية منخفضة التكلفة لبقية الطلبات، مع منح مهمة طويلة نافذة أكبر. ارفع القيمة على مراحل، وافحص ollama ps بعد كل تغيير.

يوجد إعدادان يقللان حجم الذاكرة المؤقتة. يخزّن OLLAMA_KV_CACHE_TYPE=q8_0 الذاكرة المؤقتة بدقة 8 بت بدلاً من 16 بت، فيخفض الحجم عند 32k token من 2 GB إلى 1 GB. ويتطلب ذلك flash attention، لذلك اضبط OLLAMA_FLASH_ATTENTION=1 أيضاً، وتأكد من الانخفاض في ollama ps بدلاً من افتراض تطبيق الإعداد. إذا لم تغيّر نوع الذاكرة المؤقتة من قبل، يشرح دليل مقارنة q8_0 مع f16 لذاكرة KV المؤقتة في Ollama كيفية ضبط المتغيرين وقراءة القيمتين قبل التغيير وبعده. ويؤثر OLLAMA_NUM_PARALLEL=1 بالقدر نفسه. يستطيع Ollama معالجة عدة طلبات في الوقت نفسه، وتحصل كل خانة على جزء خاص بها من السياق، لذلك يؤدي رفع التوازي بهدوء إلى مضاعفة الذاكرة المؤقتة التي خصصت لها الميزانية. القيمة الافتراضية الحالية هي 1، ويثبتها التجاوز أدناه عند هذه القيمة. إذا كان أكثر من شخص سيستخدم هذا الجهاز، يبدأ التعقيد من هذا التضاعف، ويُحسم عدد المستخدمين المتزامنين الذين يستطيع نموذج مستضاف ذاتياً خدمتهم بواسطة خانات الذاكرة المؤقتة وعمق قائمة الانتظار قبل أن يُحسم بعدد الأنوية بوقت طويل.

ما الذي يتسع له 8 و16 و32 و64 GB من RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": null,
    "notes": "Q4 fits with room for long context. Q8 weights fit, but usable context needs a measured total memory budget."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 256,
    "q8_max_ctx_ktok": 256,
    "notes": "Both fit with the full 256K window."
  }
]

اقرأ الرقمين على أنهما عدد آلاف tokens من السياق التي يمكن استيعابها إلى جانب الأوزان وvision projector، مع ذاكرة تخزين مؤقت f16، على VPS يعمل بنظام Linux دون واجهة رسومية، مع بقاء نحو 1.5 GB لنظام التشغيل وهامش صغير إضافي. يعني الصفر أن الأوزان نفسها لا تتسع في الذاكرة، ولذلك لا يتسع فيها شيء؛ أما null فتعني أن الأوزان تتسع، لكن لم يتم تأكيد رقم صالح للسياق في تلك الفئة.

لا يمثل 8 GB و16 GB حالتين متقاربتين. لا يمكن وضع 17 GB من الأوزان في 16 GB من RAM، ولا يمكن لأي إعداد للسياق تغيير ذلك. كما أن إضافة swap لا تحل المشكلة. يستخدم Ollama أسلوب memory-mapping لملف GGUF، ولذلك يبدأ kernel، بعد تجاوز الصفحات المقيمة لحجم RAM، في إخراجها من الذاكرة وإعادة قراءتها. عندها يجلب كل token عدة GB من القرص. وتبقى الخادم في حالة iowait مرتفع، وينتج أقل بكثير من token واحد في الثانية.

تمثل 32 GB نقطة البداية. تشغل الأوزان 17 GB، ويضيف vision projector نحو 0.9 GB، ويبقى لديك نحو 12.5 GB. وهذا يكفي لنحو 128k tokens من سياق f16 مع هامش. تتسع أوزان Q8_0 البالغة 29 GB في 32 GB، لكن السياق القابل للاستخدام يعتمد أيضاً على vision projector وcache ونظام التشغيل وذاكرة runtime. تحقّق من إجمالي الاستهلاك على خادمك قبل اعتبار Q8 قابلاً للتشغيل في هذه الفئة.

توفّر 64 GB مساحة مريحة. يترك Q4 مجالاً لنافذة كاملة بحجم 256k، كما تتسع أوزان Q8_0 مع نافذتها الكاملة البالغة 256k خلفها. قبل أن تدفع مقابل 64 GB للحصول على Q8، كن واضحاً بشأن ما تشتريه: مخرجات أفضل قليلاً بسرعة تعادل نصف السرعة، على جهاز كان بطيئاً أصلاً. يصل Q4 بالفعل إلى 128k tokens في خطة 32 GB، وهذا هو الخيار الأفضل لمعظم المستخدمين.

ما مدى سرعة الاستدلال على CPU في VPS؟

يعني توليد token واحد من نموذج كثيف قراءة كل weight من الذاكرة مرة واحدة. وليس بعضها، بل كلها. لذلك لا يحدد السرعة عدد أنوية المعالج، بل عرض النطاق الترددي للذاكرة مقسوماً على حجم weights. عند Q4، يبلغ ذلك 17 GB من حركة الذاكرة لكل token.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

هذه حدود قصوى وليست قياسات فعلية. يبلغ الناتج الفعلي نحو 50 إلى 70 بالمئة من الرقم المعروض، لأن زمن وصول الذاكرة وعمليات الجلب المسبق غير المثالية يعنيان أنك لا تبلغ الحد النظري أبداً. يبلغ الحد الأقصى لـ VPS بذاكرة DDR4-3200 ثنائية القناة 3 token في الثانية، لذلك توقّع نحو 2. ويبلغ الحد الأقصى لخادم بذاكرة DDR5-4800 ثنائية القناة 4.5، لذلك توقّع نحو 3.

تتطلب صفوف الخوادم الكبيرة تنبيهاً. تحتوي منصة EPYC ذات اثنتي عشرة قناة على 460.8 GB/s، ويبلغ حدها الأقصى 27.1 token في الثانية، لكنك لا تستأجر منصة EPYC كاملة. عرض النطاق الترددي للذاكرة مورد على مستوى المضيف، وتتشارك فيه كل المستأجرين على ذلك الجهاز، لذلك لا تأتي شريحة تحتوي على 8 vCPU مع عرض نطاق ترددي حصري عبر اثنتي عشرة قناة. تتجاهل الأدلة التي تركّز على GPU هذه النقطة بالكامل، وهي سبب اختلاف أداء خطتي VPS لهما العدد نفسه من vCPU بمقدار ثلاثة أضعاف على النموذج نفسه.

يتوقف ازدياد فائدة vCPU في وقت مبكر للسبب نفسه. عندما تطلب الأنوية البيانات بسرعة تتجاوز قدرة متحكم الذاكرة على توفيرها، تضيف الخيوط الإضافية عبئاً على الجدولة فقط ولا تضيف شيئاً آخر. لا يوفّر Ollama متغير بيئة على مستوى الخادم لتحديد عدد الخيوط، لذلك اضبط num_thread في الطلب options على عدد أنويتك الفعلية، ثم قِس الأداء وجرب نصف ذلك العدد. يكون الإعداد الأقل أسرع في كثير من الخطط المشتركة.

تعمل معالجة prompt بطريقة مختلفة. فـPrefill، أي المرور على مدخلاتك قبل ظهور token الأول، تعتمد على قدرة المعالجة لا على عرض النطاق الترددي، ولذلك تستفيد من زيادة عدد الأنوية. عملياً، يؤدي ذلك إلى انتظار طويل قبل بدء الإخراج عند استخدام prompt كبير، ثم معدل ثابت وبطيء كما سبق. قِس الجزأين كلّاً على حدة باستخدام --verbose، الذي يطبع prompt eval rate وeval rate لكل طلب.

إذا كان النموذج الكثيف 27B بطيئاً جداً، فتحقق من وسوم qwen3.6:35b-a3b قبل التخلي عن CPU. فهي تفعّل نحو 3 مليارات parameter لكل token بدلاً من جميع الـ27.3 ملياراً، لذلك تنخفض حركة الذاكرة لكل token بما يقارب مرتبة عشرية كاملة، رغم أن الملف على القرص أكبر. أنت تستبدل حجم RAM بالسرعة. ويهم اختيار runtime هنا أيضاً، إذ يوفّر Ollama وllama.cpp عناصر تحكم مختلفة لضبط CPU فوق رمز الاستدلال الأساسي نفسه.

متى تستأجر ساعة GPU بدلاً من ذلك

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

تعطي الصيغة نفسها عند تطبيقها على عرض نطاق الذاكرة المعلن لوحدات GPU فئة مختلفة من الإجابات. تبلغ بطاقة استهلاكية بسعة 24 GB حداً أقصى قدره 59 رمزاً في الثانية عند استخدام هذه الأوزان. وتصل بطاقة حالية مخصصة لمركز بيانات إلى 197. لا يمكن سد هذه الفجوة بضبط أعداد الخيوط. تعمل البطاقة بذاكرة تبلغ 1008 GB/s، بينما يعمل VPS لديك بعشرات GB/s.

لذلك حدّد القرار وفقاً لعبء العمل، لا وفقاً للتفضيل الشخصي. يكون الاستدلال على CPU هو الخيار الصحيح عندما يكون العمل غير متزامن ولا ينتظر أحد نتيجته: مثل تلخيص مجموعة مستندات طوال الليل، أو مهمة تصنيف ليلية تعمل أثناء نومك. استأجر GPU فور انتظار شخص للنتيجة، أو فور وصول الطلبات بمعدل أسرع من قدرة جهازك على معالجتها. لا تقتصر بيئات تشغيل CPU على معالجة طلب واحد في كل مرة؛ إذ يوضح خادم llama.cpp أنه يدعم فك الترميز المتوازي والتجميع الدفعي المستمر على CPU وGPU، كما يستطيع Ollama خدمة الطلبات المتوازية، مقابل استهلاك مزيد من ذاكرة التخزين المؤقت. العامل الحاسم هو معدل الخدمة الذي تقيسه مقارنة بمعدل وصول الطلبات، لذلك قِس زمناً واقعياً لمعالجة دفعة على جهازك. وعندما تصل الطلبات بمعدل أسرع من ذلك، يزداد طول قائمة الانتظار.

مقارنة التكلفة أقل وضوحاً مما تبدو عليه. تُحاسَب على VPS بسعة 64 GB عن كل ساعة من الشهر، سواء كان النموذج محمّلاً أم لا، بينما تفصل استئجار وحدة GPU بالساعة رسوم الحوسبة عن رسوم التخزين التي قد تستمر بعد إيقافها. إذا كان استخدامك الفعلي ساعتين يومياً، فقد تكون وحدة GPU المستأجرة أسرع وأقل تكلفة في الوقت نفسه. احسب أولاً نسبة التشغيل الفعلية، ثم احسب التكلفة. يوضّح اختيار VPS مزوّد بوحدة GPU ما يجب التحقق منه في المثيل نفسه، ويتفوّق vLLM على Ollama في عند تقديم طلبات متزامنة على وحدة GPU لأنه يجمعها في دفعات بطريقة صحيحة.

هناك خيار ثالث ينساه البعض. أبقِ نموذج 27B على CPU للمهام الدفعية، وضع نموذجاً مستضافاً عبر API أمام المسار التفاعلي. لا شيء يفرض استخدام نموذج واحد لتقديم الخدمتين.

ثبّت Ollama وقِس أداء جهازك

يستخدم سكربت التثبيت الرسمي، ويُنشئ خدمة systemd تعمل بحساب مستخدم مخصص هو ollama.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

يجب أن يعرض ollama --version الإصدار 0.32.12 أو إصداراً أحدث، فهو أول إصدار يدعم Qwen 3.8 27B. تحقّق من free -g قبل تنزيل أي شيء. يعرض هذا الأمر القيم بوحدة GiB، لذلك قد تُظهر خطة معلَن عنها بذاكرة RAM سعتها 32 GB نحو 29 في العمود total؛ قارن الذاكرة المتاحة بأحجام الأوزان وميزانية الذاكرة المؤقتة المذكورتين أعلاه.

اضبط خيارات وقت التشغيل في override لخدمة systemd بدلاً من ضبطها في الصدفة. يعمل النموذج داخل الخدمة، لذلك لا يرى بيئتك التفاعلية.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.8:27b
ollama run qwen3.8:27b --verbose "Name two Linux distributions."

ناتج --verbose هو القياس المطلوب. يعبّر eval rate عن عدد الرموز في الثانية أثناء التوليد. ويعبّر prompt eval rate عن سرعة prefill. ويعبّر load duration عن المدة اللازمة لقراءة الأوزان من القرص، ولذلك تم ضبط OLLAMA_KEEP_ALIVE=60m: ففي وضع CPU، تستغرق إعادة تحميل 17 GB من القرص في كل طلب وقتاً أطول من تنفيذ الطلب نفسه. المهلة الافتراضية للخمول هي خمس دقائق. وهي قصيرة بما يكفي لكي تتحمل قائمة انتظار الدفعات التي تفصل بين عناصرها فترات توقف تكلفة التحميل تلك مراراً. وتغطي خيارات إبقاء النموذج محمّلاً كلاً من الحقل keep_alive الخاص بكل طلب، وجعل الإعداد مستمراً بعد إعادة التشغيل.

أثناء تحميل النموذج، تحقّق من حجمه في الذاكرة من طرفية ثانية.

ollama ps

يمثّل العمود SIZE الحجم الفعلي في الذاكرة، بما في ذلك ذاكرة KV المؤقتة. وينبغي أن يقترب من مجموع الأوزان وvision projector والصف الموافق لطول السياق في مخطط KV. عند 8192 رمزاً وباستخدام ذاكرة مؤقتة بحجم 8-bit، لا يتجاوز الجزء المتزايد من الذاكرة المؤقتة نحو ربع gigabyte، مقارنةً بـ 0.5 GB إذا بقيت بحجم f16، إضافةً إلى حالة linear-attention الثابتة. يجب أن يقرأ العمود PROCESSOR القيمة 100% CPU. وإذا قرأ قيمة أخرى، فهذا يعني أن شيئاً ما استخدم GPU، وأن أرقام السرعة في هذا الدليل لا تصف جهازك.

أنماط الفشل والرسائل النصية التي ستظهر لك بالضبط

يرفض النموذج التحميل. يطبع Ollama سطراً يذكر الرقمين، بالصيغة model requires more system memory (18.6 GiB) than is available (15.2 GiB). هذا هو الفشل الجيد، لأن Ollama أجرى الفحص قبل تخصيص الذاكرة، بدلاً من ترك النواة تتولى الأمر. خفّض طول السياق، أو انتقل إلى وسم أصغر، أو استخدم خطة أكبر.

تختفي العملية في منتصف الإجابة. لا يعرض العميل أي معلومات مفيدة، بينما يوضح journalctl -u ollama -n 50 أن الخدمة تعيد التشغيل. شغّل dmesg -T | tail، وتعني قراءة السطر Out of memory: Killed process ... (ollama) أن قاتل OOM في النواة أنهى العملية. يحدث ذلك عندما ينجح فحص ما قبل التحميل، ثم تتجاوز ذاكرة التخزين المؤقت التقدير أثناء محادثة طويلة. خفّض طول السياق.

يفشل السحب فوراً. يعني Error: pull model manifest: file does not exist أن الوسم غير موجود في المكتبة. ينتج رقم الإصدار الذي لم يُطرح بعد هذه الرسالة بالضبط، وينتجها أيضاً أي خطأ إملائي في الوسم. أما qwen3.8:27b فهو موجود فعلاً، لذلك إذا فشل هذا الوسم بالضبط، فتحقق أولاً من وجود خطأ إملائي. أكد الوسم في صفحة المكتبة قبل إلقاء اللوم على الشبكة، وإذا نجح سحب وسم صحيح لكنه لم يعمل، فتحقق من ollama --version مقابل 0.32.12.

يعمل كل شيء، لكنه بطيء جداً. يشير معدل يقل عن token واحد في الثانية على جهاز يملك ذاكرة RAM كافية إلى الترحيل، لا إلى قدرة المعالجة. شغّل vmstat 1 أثناء التوليد. يعني وجود قيمة غير صفرية في العمود si أو so أن النواة تستخدم مساحة التبديل، والحل هو تقليل السياق أو عدد النماذج المحمّلة. أما ارتفاع wa المستمر من دون نشاط للتبديل، فيعني أن الأوزان المعينة للذاكرة تُعاد قراءتها من القرص، وهذا يعني أنها لا تتسع فعلياً في الذاكرة.

يستغرق ظهور الرمز الأول 30 ثانية، ثم تزداد سرعة الإخراج. هذه مرحلة prefill، وهي طبيعية. تُحتسب تكلفة مطالبة النظام الطويلة مع كل طلب لا يستفيد من ذاكرة التخزين المؤقت، لذلك اختصر مطالبة النظام قبل ضبط أي شيء آخر.

ما الذي يمكن فعله فعلياً بنموذج 27B يعمل على CPU فقط

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

حجة الخصوصية هي الأهم فعلياً. يعمل النموذج على عتاد تستأجره وتتحكم فيه، ولا يغادر أي طلب الخادم، ولا توجد فاتورة لكل رمز. وهذا يستحق الكثير للبيانات الخاضعة للامتثال التنظيمي، حتى عند سرعة 3 رموز في الثانية. قارن ذلك بصدق بالبديل: يتطلب استضافة نموذج بحجم frontier عتاداً أكبر بمرتبة مقدار، ويُعد نموذج 27B على CPU أرخص نقطة على هذا المنحنى تظل مخرجاتها جديرة بالقراءة.

لاختبار أي من ذلك، تحتاج إلى إدخال منظّم فعلي. وتتطلب معظم واجهات برمجة التطبيقات للبيانات العامة حساباً قبل أن تتمكن حتى من قياس معدل النقل. يوثّق مخطط Strasmore التجريبي، الذي نشغّله، استعلامات SQL للقراءة فقط على بيانات الأسهم والخيارات الأمريكية، من دون مفتاح أو تسجيل، باستخدام أسماء جداول مؤهلة بقاعدة البيانات: https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM global_markets.delayed_stocks_minute_aggs LIMIT 5. تقتصر النسخة التجريبية على 500 صف و20 ثانية لكل استدعاء، وتوفّر سجلاً يبدأ من 1 January 2025، وهو أكثر من كافٍ لما سيستهلكه خادم يعمل بسرعة رمزين في الثانية. توجد قائمة الأعمدة الكاملة هنا: https://ai.strasmore.com/api/demo/schema.

إذا كان هذا أول تثبيت لك لـOllama، فإن الشرح الكامل لتشغيل Ollama على VPS يغطّي إعداد الخدمة، وHTTP API، وقواعد الجدار الناري التي يفترض هذا الدليل أنك أعددتها مسبقاً. لا تعرّض المنفذ 11434 للإنترنت. لا تتطلب واجهة Ollama المحلية المصادقة، لذلك يمكن لأي جهة تصل إلى المنفذ استخدام نموذجك.

FAQ

هل يوجد نموذج Qwen 3.8 27B على Ollama؟

نعم. اعتباراً من 21 October 2026، تحتوي مكتبة Ollama على إدخال qwen3.8، ويُعد qwen3.8:27b (الموسوم أيضاً بـlatest) إصدار Q4_K_M بحجم 18 GB لنموذج كثيف يضم 27.3 billion parameters، مع مُسقِط رؤية ونافذة سياق بحجم 256K. يعمل هذا النموذج محلياً، ويتطلب Ollama v0.32.12 أو إصداراً أحدث. ولا يزال الوسمان الأقدم qwen3.6:27b وqwen3.5:27b مدرجين. راجع https://ollama.com/library/qwen3.8/tags للاطلاع على القائمة الحالية. يفشل الوسم غير الموجود مع Error: pull model manifest: file does not exist.

كم أحتاج من RAM لتشغيل نموذج Qwen 27B على VPS؟

يُعد 32 GB الحد الأدنى العملي لـQ4_K_M. يبلغ حجم الأوزان 17 GB، ويضيف مُسقِط الرؤية نحو 0.9 GB، ويحتاج نظام التشغيل إلى نحو 1.5 GB، بينما يضيف مخزن KV المؤقت نحو 1 GB لكل 16,000 token من السياق عند f16، لأن 16 طبقة فقط من طبقات النموذج البالغ عددها 64 تحتفظ بمخزن مؤقت يتزايد حجمه. لا يمكن لخطة بسعة 16 GB استيعاب الأوزان أصلاً، ولا يفيد swap لأن الملف مربوط بالذاكرة، وتعيد النواة قراءته من القرص عند كل token. تمنحك سعة 64 GB مساحة لنافذة 256K كاملة، حتى مع أوزان Q8_0 بحجم 29 GB.

كم token في الثانية سيعطيني نموذج 27B على CPU؟

اقسم عرض النطاق الترددي للذاكرة على حجم الأوزان، ثم خذ نسبة تتراوح بين 50 و70 بالمئة من الناتج. يبلغ الحد النظري لـVPS يستخدم قناتين من DDR4-3200 نحو 3 token في الثانية، ويحقق نحو 2. أما الخادم الذي يستخدم قناتين من DDR5-4800، فيبلغ حده النظري نحو 4.5 ويحقق نحو 3. تبدو منصات الخوادم ذات القنوات الأكثر أفضل بكثير نظرياً، لكن عرض النطاق الترددي للذاكرة مشترك بين جميع المستأجرين على المضيف. لذلك قِس الأداء بنفسك باستخدام ollama run qwen3.8:27b --verbose، واقرأ السطر eval rate.

هل أستخدم Q4 أم Q8 على VPS يعتمد على CPU فقط؟

استخدم Q4_K_M في كل الحالات تقريباً. يبلغ حجم Q8_0 29 GB مقارنةً بـ17 GB، لذلك يمكن لأوزانه أن تتسع ضمن 32 GB، لكن مُسقِط الرؤية والمخزن المؤقت ونظام التشغيل وبيئة التشغيل لا تترك مساحة احتياطية كبيرة؛ وتمنحه سعة 64 GB مساحة لسياق طويل. ينقل Q8_0 ذاكرة تعادل ضعف ما ينقله Q4_K_M تقريباً لكل token، ما يخفض عدد token في الثانية إلى النصف تقريباً. الفارق في الجودة بين Q4_K_M وQ8_0 على نموذج 27B صغير في معظم المهام. أنفق سعة RAM على سياق أطول بدلاً من ذلك، لأن السياق الأطول يغيّر ما يستطيع النموذج فعله، لا طريقة صياغته للعبارات.

متى يكون استئجار GPU أرخص من VPS بسعة RAM كبيرة؟

يكون ذلك عندما يكون معدل الاستخدام منخفضاً أو عندما يكون هناك شخص ينتظر النتيجة. يملك GPU بسعة ذاكرة 24 GB حداً نظرياً يبلغ نحو 59 token في الثانية مع هذه الأوزان، مقارنةً بتقدير يتراوح بين 2 و3 على VPS نموذجي. تتوقف رسوم تشغيل GPU بالساعة عند إيقاف المثيل، لكن قد تظل تكلفة التخزين الدائم مستمرة. أما VPS بسعة 64 GB، فتُحتسب تكلفته طوال الشهر، سواء كان النموذج محمّلاً أم لا. احسب عدد الساعات التي تولّد فيها token فعلياً كل يوم. تعتمد نقطة التعادل على أسعار الاستئجار وتكاليف بيئة التشغيل والتخزين الدائم. يفوز VPS العامل دائماً عند تنفيذ مهام دفعات منخفضة الأولوية بصورة مستمرة.