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

هل يمكنك تشغيل 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 للأوزان وحدها، قبل تخزين أي token من السياق. لذلك لا تكفي خطط 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 فعلي لاحقاً، فستظل الحسابات هنا منطبقة، لأنها تعتمد على عدد المعاملات وعدد البتات لكل وزن، لا على رقم الإصدار.

وسم 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 والإخراج عند Q6_K أو Q8_0. الاسم المستخدم للتنسيق يعبّر عن متوسط، ويبلغ هذا المتوسط نحو 4.9. ويظهر التأثير نفسه في الطرف الآخر من المقياس: إن 56 GB لتنسيق BF16 تعادل 16.1 بت لكل وزن، لا 16 بت ثابتة، لأن الملف يحتوي أيضاً على بيانات وصفية وجدول embedding كامل الدقة.

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

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

تكلفة الأوزان ثابتة. أمّا ذاكرة KV cache (ذاكرة key وvalue، أي حالة الانتباه التي يحتفظ بها النموذج لكل 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 رؤوس key/value ضمن GQA (grouped-query attention)، وبُعد رأس يبلغ 128. ينتج عن ذلك 256 KiB لكل token عند f16، أي 8 GB عند 32k token و32 GB عند 128k. لا تعتمد على حساباتي بدلاً من القياس على جهازك. حمّل النموذج واقرأ عمود SIZE في ollama ps، فهو يعرض الأوزان وذاكرة cache والنفقات الإضافية في قيمة واحدة.

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

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

ما الذي يتسع له 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."
  }
]

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

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

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

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

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

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

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

إذا كان نموذج dense بحجم 27B بطيئاً جداً، فافحص وسوم qwen3.6:35b-a3b قبل التخلي عن CPU. فهي تنشّط نحو 3 مليارات parameter لكل token بدلاً من جميع الـ27.8 ملياراً، لذلك ينخفض حجم حركة الذاكرة لكل 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 فور انتظار شخص للنتيجة، أو فور وصول الطلبات بمعدل أسرع من طلب واحد كل 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 لا يمكنك تشغيله يهدر ساعة ومساحة كبيرة على القرص.

اضبط خيارات وقت التشغيل في override لـ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 من القرص مع كل طلب وقتاً أطول من تنفيذ الطلب نفسه.

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

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 أجرى الفحص قبل تخصيص الذاكرة بدلاً من ترك النواة تتولى الأمر. خفّض طول السياق، أو انتقل إلى وسم أصغر، أو استخدم خطة أكبر.

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

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

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

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

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

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

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

FAQ

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

لا. حتى 4 August 2026، لا تحتوي مكتبة Ollama على مساحة أسماء qwen3.8. العلامتان 27B الموجودتان هما qwen3.5:27b وqwen3.6:27b، وكلتاهما إصداران Q4_K_M من نموذج كثيف يضم 27.8 مليار معلَمة. الرقم 3.8 في عبارة البحث هو على الأرجح عدد المعلمات 27.8B الذي تذكّره المستخدم باعتباره رقم إصدار. تحقّق من https://ollama.com/library/qwen3.6/tags للاطلاع على القائمة الحالية، واسحب 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 رمز من سياق f16. لا تستطيع خطة بسعة 16 GB استيعاب الأوزان أصلاً، ولا يفيد swap لأن الملف مربوط بالذاكرة، ولذلك يعيد kernel قراءته من القرص مع كل رمز. تمنحك سعة 64 GB مجالاً لسياق طويل أو لأوزان Q8_0 بحجم 30 GB.

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

اقسم عرض نطاق الذاكرة على حجم الأوزان، ثم خذ 50 إلى 70 بالمئة من الناتج. يبلغ الحد الأقصى النظري لـ VPS ذي قناتين من DDR4-3200 نحو 3 رمزاً في الثانية، ويحقق نحو 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، كما أنه ينقل ما يقارب ضعف كمية الذاكرة لكل رمز، ما يخفض عدد الرموز في الثانية إلى النصف تقريباً. الفرق في الجودة بين Q4_K_M وQ8_0 على نموذج 27B صغير في معظم المهام. استخدم RAM لسياق أطول بدلاً من ذلك، لأن السياق يغيّر ما يستطيع النموذج فعله، لا طريقة صياغته فقط.

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

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