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

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

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

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

من أين جاء الرقم 3.8؟ على الأرجح من عدد المعلمات. تعرض صفحة Ollama الخاصة بـ qwen3.6:27b عدد 27.8B من المعلمات، ومن السهل تذكّر 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 كل موتر بالعرض الاسمي نفسه. تُخزّن الموترات التي تفقد أكبر قدر من الجودة عند الضغط بدقة 5 أو 6 بت، بينما تُترك طبقتا تضمين الرموز والإخراج عادةً بتنسيق Q6_K أو Q8_0. الاسم المعطى للتنسيق يمثل متوسطاً، ويقترب هذا المتوسط من 4.9. ويظهر التأثير نفسه عند الطرف الآخر من المقياس: إنّ 56 GB بتنسيق BF16 تعادل 16.1 بت لكل وزن بدلاً من 16 ثابتة، لأن الملف يحتوي أيضاً على بيانات وصفية وجدول تضمين بالدقة الكاملة.

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

تكلفة ذاكرة KV المؤقتة مع زيادة السياق

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

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

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

ما الذي يتسع له 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 حالات متقاربة. لا تتسع أوزان بحجم 17 GB في 16 GB من RAM، ولا يغيّر أي إعداد للسياق ذلك. كما أن إضافة swap لا تحل المشكلة. يستخدم Ollama أسلوب memory-mapping لملف 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 واحد من نموذج كثيف قراءة كل وزن من الذاكرة مرة واحدة. ليس بعض الأوزان، بل كلها. لذلك لا يحدد عدد الأنوية حد السرعة، بل تحدده سرعة الذاكرة مقسومة على حجم الأوزان. عند Q4، يبلغ حجم حركة الذاكرة لكل token 17 GB.

[
  {
    "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 لكل طلب.

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

When to rent a GPU hour instead

[
  {
    "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
  }
]

The same formula applied to published GPU memory bandwidth gives a different category of answer. A 24 GB consumer card has a ceiling of 59 tokens per second on these weights. A current data centre card reaches 197. That is not a gap you close by tuning thread counts. The card runs its memory at 1008 GB/s where your VPS runs at tens.

So draw the line by workload rather than by preference. CPU inference is the right answer when the work is asynchronous and nobody is waiting on it: overnight summarisation of a document pile, or a nightly classification job that runs while you sleep. Rent a GPU the moment a person is waiting for output, or the moment requests arrive faster than one every 30 seconds, because a CPU-only box has no batching headroom and the queue simply grows.

The cost comparison is less obvious than it looks. A 64 GB VPS bills every hour of the month whether the model is loaded or not, while a GPU instance bills only the hours you keep it running. If your real usage is two hours a day, the rented GPU can be both faster and cheaper. Work out your duty cycle first, then price it. Picking a VPS with a GPU covers what to check on the instance itself, and vLLM pulls ahead of Ollama once you serve concurrent requests on a GPU because it batches them properly.

There is a third option people forget. Keep the 27B on CPU for batch work and put a hosted API model in front of the interactive path. Nothing requires one model to serve both.

تثبيت 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 بدلاً من ضبطها في الصدفة. يعمل النموذج داخل الخدمة، لذلك لا يرى بيئتك التفاعلية.

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

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

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

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

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

ما الذي يفيد فيه نموذج 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 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 cache نحو 1 GB لكل 4000 token من السياق عند استخدام f16. لا يمكن لخطة بسعة 16 GB استيعاب الأوزان أصلاً، ولا تفيد swap لأن الملف مموضع في الذاكرة، ولذلك يعيد kernel قراءته من القرص عند كل 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 المشغّل دائماً.