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

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

لتشغيل Qwen 3.8 27B على VPS، تحتاج أولاً إلى وسم نموذج موجود فعلاً. وحتى 4 August 2026، لا تحتوي مكتبة Ollama على إدخال qwen3.8 على الإطلاق. أقرب وسم 27B مُصدر هو qwen3.6:27b: يحتوي على 27.8 billion parameters، ويستخدم Q4_K_M quantisation، ومرخّص بموجب Apache 2.0. تستخدم جميع الأوامر والأرقام أدناه هذا الوسم على Ollama v0.32.5، المُصدر في 27 July 2026.

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

من أين جاء الرقم 3.8؟ على الأرجح من عدد المعاملات. تعرض صفحة Ollama الخاصة بـ qwen3.6:27b عدد 27.8B parameters، ومن السهل تذكّر 27.8 لاحقاً على أنه 3.8. يوجد أيضاً qwen3.5:27b، وهو الإصدار نفسه المبني باستخدام Q4_K_M من الإصدار السابق. تحقّق من القائمة المباشرة قبل نسخ أي أمر، في صفحة وسم qwen3.6 على Ollama. إذا صدر qwen3.8 فعلي لاحقاً، فستظل الحسابات هنا صحيحة، لأنها تعتمد على عدد المعاملات وعدد bits per weight، لا على رقم الإصدار.

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

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

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

يطبع ollama show البنية، وعدد المعاملات، وطول السياق، ونوع التكميم للوسم الموجود لديك فعلياً. إذا كان سطر المعاملات يقرأ 27.8B وكان سطر التكميم يقرأ Q4_K_M، فلديك الإصدار الذي يستند إليه هذا الدليل. تحتوي المكتبة أيضاً على qwen3.6:27b-q8_0 وqwen3.6:27b-bf16 للأوزان نفسها بدقة أعلى، بالإضافة إلى مجموعة من وسوم 35b-a3b، وهي نماذج MoE (مزيج من الخبراء) وتتصرف بطريقة مختلفة جداً عند تشغيلها على CPU. يرد مزيد من التفاصيل عنها أدناه.

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

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

الصيغة في سطر واحد. عدد بايتات الأوزان = عدد المعاملات * عدد البتات لكل وزن / 8. عند استخدام 4 بتات بالضبط، سيبلغ حجم 27.8 مليار معامل 13.9 GB. يبلغ حجم وسم Q4_K_M المُصدَر 17 GB، ما يعادل عملياً 4.89 بت لكل وزن.

هذا الفرق ليس خطأً. لا تخزّن تنسيقات K-quant كل tensor بالعرض الاسمي نفسه. تُخزّن tensors التي تفقد أكبر قدر من الجودة عند الضغط بدقة 5 أو 6 بتات، وتُترك عادةً طبقتا token embedding وoutput عند Q6_K أو Q8_0. الاسم المعطى للتنسيق هو متوسط، ويقترب المتوسط من 4.9. ويظهر التأثير نفسه عند الطرف الآخر من المقياس: 56 GB لتنسيق BF16 تعادل 16.1 بت لكل وزن، لا 16 ثابتة، لأن الملف يحتوي أيضاً على metadata وجدول embedding كامل الدقة.

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

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

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

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

تفترض هذه الأرقام البنية التي استخدمتها Qwen في نماذجها الكثيفة الحديثة ضمن فئة الحجم هذه: 64 طبقة، و8 رؤوس للمفتاح والقيمة ضمن GQA (grouped-query attention)، وبُعد رأس مقداره 128. ينتج عن ذلك 256 KiB لكل token عند f16، أي 8 GB عند 32k token و32 GB عند 128k. لا تعتمد على حساباتي بدلاً من القياس على جهازك. حمّل النموذج واقرأ عمود SIZE في ollama ps، فهو يعرض الأوزان وذاكرة التخزين المؤقت والنفقات الإضافية في رقم واحد.

لهذا السبب، يُعد سياق 256K المذكور في بطاقة النموذج رقماً بارزاً وليس خطة تشغيل. فملؤه عند f16 سيستهلك 64 GB من ذاكرة التخزين المؤقت فوق الأوزان، على جهاز أنفق بالفعل 17 GB على الأوزان. لا يمنحك Ollama نافذة السياق الكاملة افتراضياً. بل يحمّل نافذة أصغر بكثير، ويمكنك زيادتها عمداً باستخدام OLLAMA_CONTEXT_LENGTH. هذا المتغير على مستوى الخادم ليس أداة التحكم الوحيدة، ويتيح لك ضبط num_ctx في الطلب الفردي الإبقاء على قيمة افتراضية منخفضة التكلفة لكل شيء آخر، مع منح مهمة طويلة نافذة أكبر. ارفع القيمة تدريجياً وافحص ollama ps بعد كل تغيير.

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

ما الذي يتسع في 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": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

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

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

تمثل 32 GB نقطة البداية. تشغل الأوزان 17 GB، ويتبقى لديك نحو 13 GB. وهذا يكفي لنحو 32k token من سياق f16 مع هامش. أما أوزان Q8_0 بحجم 30 GB فلا تتسع في هذه الفئة إطلاقاً.

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

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

يعني توليد token واحد من نموذج كثيف قراءة كل weight من الذاكرة مرة واحدة. ليس بعضها. بل كلها. لذلك لا يحدد عدد الأنوية حد السرعة، بل تحدده bandwidth الذاكرة مقسومة على حجم 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 بالمئة من الرقم المعروض، لأن زمن وصول الذاكرة وعمليات prefetch غير المثالية يعنيان أنك لا تصل أبداً إلى الحد النظري الأقصى. يبلغ الحد الأقصى لـVPS مزود بقناتي DDR4-3200 مقدار 3 token في الثانية، لذلك توقّع نحو 2. ويبلغ الحد الأقصى لجهاز مزود بقناتي DDR5-4800 مقدار 4.5، لذلك توقّع نحو 3.

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

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

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

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

متى تستأجر ساعة 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 فور انتظار شخص للنتيجة، أو فور وصول الطلبات بمعدل أسرع من طلب واحد كل 30 ثانية، لأن خادماً يعتمد على CPU فقط لا يملك سعة كافية للتجميع، وستستمر قائمة الانتظار في النمو.

مقارنة التكلفة أقل وضوحاً مما تبدو عليه. يُحاسَب 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.5 أو إصداراً أحدث. تحقّق من free -g قبل تنزيل أي شيء. إذا كانت قيمة العمود total في سطر Mem أقل من 32، فتوقف هنا واختر نموذجاً أصغر، لأن تنزيل نموذج حجمه 17 GB لا يمكنك تشغيله سيهدر ساعة ومساحة كبيرة على القرص.

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

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.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

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

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

ollama ps

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

أنماط الفشل والرسائل النصية الدقيقة التي ستراها

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

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

يفشل السحب فوراً. يعني Error: pull model manifest: file does not exist أن tag غير موجود في library. يؤدي إدخال qwen3.8:27b إلى ظهور هذه الرسالة نفسها تماماً، وكذلك أي خطأ مطبعي في رقم الإصدار. أكّد tag في صفحة library قبل إلقاء اللوم على الشبكة.

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

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

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

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

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

لاختبار أي من ذلك، تحتاج إلى إدخال منظم حقيقي، ومعظم واجهات برمجة التطبيقات للبيانات العامة تطلب إنشاء حساب قبل أن تتمكن حتى من قياس معدل المعالجة. تجيب نقطة النهاية التجريبية في Strasmore (نحن نديرها) عن SQL للقراءة فقط على بيانات السوق الأمريكية الممتدة لـ22 عاماً من دون مفتاح أو تسجيل: يعيد طلب GET إلى https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 بيانات JSON يمكنك تمريرها مباشرة إلى حلقة prompts، مع SQL الدقيق الذي أنشأها، بحيث يكون لدى النموذج محتوى يمكنه تلخيصه ويمكنك التحقق منه بشكل مستقل. الحدود هي 500 صفاً و20 ثانية لكل استدعاء، وهي تتجاوز بسهولة ما سيستهلكه خادم يعمل بمعدل رمزين في الثانية. توجد القائمة الكاملة للأعمدة في https://api.strasmore.com/v1/schema.

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

FAQ

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

لا. حتى 4 August 2026، لا تحتوي مكتبة Ollama على مساحة أسماء qwen3.8. العلامتان الخاصتان بـ27B الموجودتان هما qwen3.5:27b وqwen3.6:27b، وكلتاهما مبنيتان بإعداد Q4_K_M لنموذج كثيف يحتوي على 27.8 billion parameter. الرقم 3.8 في عبارة البحث هو على الأرجح عدد المعاملات 27.8B الذي جرى تذكّره على أنه رقم إصدار. راجع https://ollama.com/library/qwen3.6/tags للاطلاع على القائمة الحالية، واستخدم pull qwen3.6:27b إذا أردت أحدث إصدار 27B. تفشل العلامة غير الموجودة مع Error: pull model manifest: file does not exist.

ما مقدار RAM اللازم لتشغيل نموذج Qwen 27B على VPS؟

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

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

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

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

استخدم Q4_K_M في كل الحالات تقريباً. يبلغ حجم Q8_0 30 GB مقابل 17 GB، لذلك يحتاج إلى خطة بسعة 64 GB، وينقل تقريباً ضعف كمية الذاكرة لكل token، ما يخفض عدد token في الثانية إلى النصف تقريباً. الفرق في الجودة بين Q4_K_M وQ8_0 في نموذج 27B صغير في معظم المهام. استخدم RAM لسياق أطول بدلاً من ذلك، لأن السياق يغيّر ما يستطيع النموذج فعله، لا طريقة صياغته فقط.

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

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