VPS پر Ollama کے ساتھ Qwen 27B کیسے چلائیں؟

کیا آپ GPU کے بغیر VPS پر Qwen 3.8 27B چلا سکتے ہیں؟

VPS پر Qwen 3.8 27B چلانے کے لیے پہلے ایسے model tag کی ضرورت ہے جو واقعی موجود ہو۔ 4 August 2026 تک Ollama library میں qwen3.8 کا کوئی entry موجود نہیں ہے۔ قریب ترین جاری شدہ 27B tag qwen3.6:27b ہے: اس میں 27.8 billion parameters، Q4_K_M quantisation اور Apache 2.0 licence ہے۔ ذیل کے تمام commands اور numbers Ollama v0.32.5 پر اسی tag کے لیے ہیں، جو 27 July 2026 کو شائع ہوا تھا۔

مختصر جواب یہ ہے کہ 32 GB یا اس سے زیادہ RAM والے VPS پر یہ چل سکتا ہے، لیکن رفتار کم ہوگی۔ Q4 پر 27B dense model کو صرف weights کے لیے تقریباً 17 GB RAM درکار ہوتی ہے۔ اس میں context کا ایک بھی token شامل نہیں ہے۔ اس لیے 8 GB اور 16 GB کے plans مکمل طور پر ناکافی ہیں۔ عام دو-channel DDR4 VPS پر زیادہ سے زیادہ رفتار تقریباً 3 tokens per second ہوتی ہے۔ یہ رفتار زیادہ تر لوگوں کی پڑھنے کی رفتار سے بھی کم ہے۔

3.8 کہاں سے آیا؟ غالباً یہ parameter count سے پیدا ہونے والی غلط فہمی ہے۔ qwen3.6:27b کے لیے Ollama page پر 27.8B parameters درج ہیں، اور 27.8 کو بعد میں 3.8 کے طور پر یاد رکھنا آسان ہے۔ ایک qwen3.5:27b بھی موجود ہے، جو پچھلے release کی وہی Q4_K_M build ہے۔ کوئی بھی command copy کرنے سے پہلے live list Ollama qwen3.6 tag page پر دیکھیں۔ اگر بعد میں حقیقی qwen3.8 release ہوتا ہے تو بھی یہاں کی arithmetic قابل اطلاق رہے گی، کیونکہ اس کا انحصار version number کے بجائے parameter count اور ہر weight کے bits پر ہے۔

کون سا Ollama tag حاصل کریں، اور اسے کیسے جانچیں

ایسا tag حاصل کرنے پر جو موجود نہ ہو، واضح error ظاہر ہوتا ہے۔ اس لیے خود اسی سرور پر یہ فیصلہ جلد کیا جا سکتا ہے۔

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 آپ کے پاس موجود tag کا architecture، parameter count، context length اور quantisation دکھاتا ہے۔ اگر parameter line میں 27.8B اور quantisation line میں Q4_K_M لکھا ہو تو آپ کے پاس وہ build ہے جس کے مطابق یہ guide لکھی گئی ہے۔ اسی weights کے لیے library میں زیادہ precision والے qwen3.6:27b-q8_0 اور qwen3.6:27b-bf16 بھی موجود ہیں۔ اس کے علاوہ 35b-a3b tags کا ایک مجموعہ بھی ہے جو MoE (mixture of experts) models ہیں اور 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 tag کا حجم 17 GB ہے، جو عملی طور پر فی وزن 4.89 بِٹس بنتا ہے۔

یہ فرق کوئی خرابی نہیں ہے۔ K-quant formats ہر tensor کو مقررہ nominal width پر ذخیرہ نہیں کرتے۔ compression سے جن tensors کے معیار پر سب سے زیادہ اثر پڑتا ہے، انہیں 5 یا 6 بِٹس پر رکھا جاتا ہے، جبکہ token embedding اور output layers عموماً Q6_K یا Q8_0 پر رہتی ہیں۔ format کے نام میں اوسط width ظاہر ہوتی ہے، اور یہ اوسط تقریباً 4.9 پر آتی ہے۔ یہی اثر scale کے دوسرے سرے پر بھی نظر آتا ہے: BF16 کے لیے 56 GB، flat 16 کے بجائے فی وزن 16.1 بِٹس بنتے ہیں، کیونکہ file میں metadata اور full-precision embedding table بھی شامل ہوتے ہیں۔

اس model کے لیے Q5_K_M کا کوئی published tag موجود نہیں، اس لیے 19.8 GB والی row ناپی ہوئی قدر کے بجائے اس format کے عام 5.7 بِٹس فی وزن کی بنیاد پر calculate کی گئی ہے۔ Q8_0، Q4 کے حجم کو تقریباً دگنا کرکے 30 GB تک پہنچا دیتا ہے۔ صرف CPU والے box پر یہ دگنا حجم ہر token کے لیے memory traffic بھی دگنا کر دیتا ہے، اس لیے tokens per second بھی تقریباً نصف رہ جاتے ہیں۔ اسی وجہ سے یہاں Q4_K_M بہترین default ہے۔

جیسے جیسے context بڑھتا ہے، KV cache کی لاگت

Weights ایک مقررہ لاگت ہیں۔ KV cache، یعنی key اور value cache، وہ attention state ہے جسے model پہلے سے دیکھے گئے ہر token کے لیے محفوظ رکھتا ہے۔ یہ context length کے ساتھ خطی طور پر بڑھتا ہے، اور عموماً 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
  }
]

یہ اعداد اس architecture پر مبنی ہیں جسے Qwen نے اس size class کے حالیہ dense models میں استعمال کیا ہے: 64 layers، GQA (grouped-query attention) کے تحت 8 key/value heads، اور 128 کی head dimension۔ f16 پر یہ ہر token کے لیے 256 KiB بنتا ہے۔ اس لیے 32k tokens پر 8 GB اور 128k پر 32 GB درکار ہوتے ہیں۔ اپنے server کے لیے میرے حساب پر انحصار نہ کریں۔ Model load کریں اور ollama ps کے SIZE column کو پڑھیں۔ یہ weights، cache اور overhead کو ملا کر ایک مجموعی figure دکھاتا ہے۔

اسی لیے model card میں درج 256K context ایک نمایاں حد ہے، عملی منصوبہ نہیں۔ f16 پر اسے مکمل بھرنے کے لیے weights کے علاوہ 64 GB cache درکار ہوگی، جبکہ machine پہلے ہی weights کے لیے 17 GB استعمال کر رہی ہے۔ Ollama default طور پر آپ کو پوری window نہیں دیتا۔ یہ بہت چھوٹی window load کرتا ہے، اور آپ OLLAMA_CONTEXT_LENGTH کے ذریعے اسے جان بوجھ کر بڑھاتے ہیں۔ اسے مرحلہ وار بڑھائیں اور ہر تبدیلی کے بعد ollama ps دیکھیں۔

دو settings cache کو نصف یا اس سے بھی کم کر دیتی ہیں۔ OLLAMA_KV_CACHE_TYPE=q8_0 cache کو 16 کے بجائے 8 bits پر محفوظ کرتا ہے۔ اس سے 32k tokens کے لیے cache 8 GB سے کم ہو کر 4 GB رہ جاتی ہے۔ اس کے لیے flash attention درکار ہے، اس لیے OLLAMA_FLASH_ATTENTION=1 بھی set کریں، اور یہ فرض کرنے کے بجائے کہ setting لاگو ہو گئی ہے، ollama ps میں کمی کی تصدیق کریں۔ OLLAMA_NUM_PARALLEL=1 بھی اتنا ہی اہم ہے۔ Ollama بیک وقت کئی requests فراہم کر سکتا ہے، اور ہر slot کو context کا اپنا حصہ ملتا ہے۔ اس لیے parallelism کو default پر چھوڑنے سے آپ کے مختص کردہ cache کی مقدار خاموشی سے کئی گنا بڑھ جاتی ہے۔ اگر یہ server ایک سے زیادہ افراد استعمال کریں گے تو مسئلہ یہیں سے شروع ہوتا ہے۔ self-hosted model کتنے بیک وقت users کو serve کر سکتا ہے اس کا فیصلہ core count سے بہت پہلے cache slots اور queue depth کرتے ہیں۔

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."
  }
]

ان دونوں اعداد کو weights کے ساتھ دستیاب context کے ہزاروں tokens سمجھیں۔ یہ حساب f16 cache کے ساتھ، headless Linux VPS پر کیا گیا ہے، جہاں operating system کے لیے تقریباً 1.5 GB اور معمولی اضافی گنجائش باقی رکھی گئی ہے۔ صفر کا مطلب ہے کہ weights خود fit نہیں ہوتے، اس لیے کوئی context fit نہیں ہوتا۔

8 GB اور 16 GB معمولی فرق والے معاملات نہیں ہیں۔ 17 GB کے weights، 16 GB RAM میں fit نہیں ہوتے، اور context setting تبدیل کرنے سے یہ مسئلہ حل نہیں ہوتا۔ swap شامل کرنے سے بھی فائدہ نہیں ہوتا۔ Ollama، GGUF file کو memory-map کرتا ہے۔ جب resident pages، RAM سے بڑھ جائیں تو kernel انہیں disk پر منتقل کر کے دوبارہ پڑھنا شروع کر دیتا ہے۔ اس کے بعد ہر token کے لیے disk سے gigabytes پڑھنے پڑتے ہیں۔ server میں iowait بہت زیادہ رہتا ہے اور رفتار ایک token فی second سے بھی کم ہو جاتی ہے۔

32 GB ابتدائی قابلِ استعمال سطح ہے۔ Weights 17 GB لیتے ہیں اور تقریباً 13 GB باقی رہتے ہیں۔ یہ margin کے ساتھ تقریباً 32k tokens کے f16 context کے لیے کافی ہے۔ 30 GB کے Q8_0 weights اس tier میں بالکل fit نہیں ہوتے۔

64 GB میں مناسب گنجائش رہتی ہے۔ Q4 تقریباً 128k tokens کے context کے لیے جگہ چھوڑتا ہے، جبکہ Q8_0 weights کے بعد تقریباً 64k tokens دستیاب رہتے ہیں۔ Q8 حاصل کرنے کے لیے 64 GB RAM خریدنے سے پہلے واضح طور پر سمجھ لیں کہ آپ کیا حاصل کر رہے ہیں: رفتار آدھی، جبکہ output معمولی بہتر، اور وہ بھی ایسی machine پر جو پہلے ہی سست تھی۔ تقریباً ہر صارف کے لیے Q4 کے ساتھ زیادہ طویل context بہتر انتخاب ہے۔

VPS پر CPU inference کتنی تیز ہے؟

Dense model سے ایک token تیار کرنے کے لیے memory سے ہر weight کو ایک بار پڑھنا پڑتا ہے۔ صرف کچھ weights کو نہیں، بلکہ سبھی weights کو۔ اس لیے رفتار کی حد core count نہیں، بلکہ memory bandwidth کو weights کے حجم سے تقسیم کرنے کا نتیجہ ہے۔ Q4 پر فی token memory traffic 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
  }
]

یہ زیادہ سے زیادہ نظریاتی حدیں ہیں، پیمائش کے نتائج نہیں۔ حقیقی output عموماً دکھائی گئی قدر کے تقریباً 50 سے 70 فیصد تک ہوتا ہے، کیونکہ memory latency اور ناقص prefetching کی وجہ سے theoretical peak حاصل نہیں ہوتی۔ دو-channel DDR4-3200 VPS کی حد 3 tokens فی second ہے، اس لیے تقریباً 2 کی توقع رکھیں۔ دو-channel DDR5-4800 سرور کی حد 4.5 ہے، اس لیے تقریباً 3 کی توقع رکھیں۔

بڑے سرور کے rows کے ساتھ ایک اہم تنبیہ بھی ہے۔ بارہ-channel EPYC platform میں 460.8 GB/s memory bandwidth اور 27.1 tokens فی second کی نظریاتی حد ہوتی ہے، لیکن آپ پورا EPYC کرائے پر نہیں لیتے۔ Memory bandwidth پورے host کا مشترکہ resource ہے، جسے اس machine کے تمام tenants استعمال کرتے ہیں۔ اس لیے 8 vCPU slice کے ساتھ بارہ channels کی exclusive bandwidth نہیں ملتی۔ GPU پر مرکوز guides اس بات کو عموماً نظرانداز کرتی ہیں، اور یہی وجہ ہے کہ یکساں vCPU count والے دو VPS plans ایک ہی model پر رفتار میں تین گنا تک مختلف ہو سکتے ہیں۔

اسی وجہ سے زیادہ vCPUs جلد فائدہ دینا بند کر دیتے ہیں۔ جب cores، memory controller کی فراہم کردہ رفتار سے زیادہ تیزی سے data طلب کرنے لگیں تو اضافی threads صرف scheduling overhead بڑھاتے ہیں۔ OLLAMA_NUM_THREAD کو اپنے physical core count پر set کریں، پیمائش کریں، پھر اس count کا نصف آزمائیں۔ بہت سے shared plans پر کم setting زیادہ تیز ہوتی ہے۔

Prompt processing کا رویہ مختلف ہوتا ہے۔ Prefill، یعنی پہلے token کے ظاہر ہونے سے پہلے input پر کیا جانے والا pass، bandwidth bound کے بجائے compute bound ہوتا ہے، اس لیے cores بڑھانے سے اس کی رفتار بھی بڑھتی ہے۔ عملی طور پر بڑے prompt پر output شروع ہونے سے پہلے طویل وقفہ آتا ہے، جس کے بعد اوپر بیان کردہ سست لیکن مستقل rate ملتی ہے۔ --verbose کے ذریعے دونوں حصوں کا وقت الگ الگ ناپیں۔ یہ ہر request کے لیے ایک prompt eval rate اور ایک eval rate دکھاتا ہے۔

اگر dense 27B بہت سست ہو تو CPU سے دستبردار ہونے سے پہلے qwen3.6:35b-a3b tags دیکھیں۔ یہ ہر token کے لیے تمام 27.8 billion parameters کے بجائے تقریباً 3 billion parameters فعال کرتے ہیں۔ اس طرح disk پر file بڑی ہونے کے باوجود فی token memory traffic تقریباً ایک order of magnitude کم ہو جاتا ہے۔ اس کے بدلے RAM footprint بڑھتا ہے اور رفتار بہتر ہوتی ہے۔ یہاں runtime کا انتخاب بھی اہم ہے، اور Ollama اور llama.cpp ایک ہی بنیادی inference code پر مختلف CPU tuning controls فراہم کرتے ہیں۔

اس کے بجائے 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 memory bandwidth پر یہی formula لاگو کرنے سے جواب ایک مختلف category میں آتا ہے۔ 24 GB consumer card پر ان weights کے لیے زیادہ سے زیادہ رفتار 59 tokens per second ہے۔ موجودہ data centre card 197 تک پہنچتا ہے۔ یہ فرق thread counts کو tune کرکے ختم نہیں کیا جا سکتا۔ card اپنی memory کو 1008 GB/s پر چلاتا ہے، جبکہ آپ کا VPS دسیوں GB/s پر چلتا ہے۔

اس لیے فیصلہ preference کے بجائے workload کی بنیاد پر کریں۔ CPU inference اس وقت درست انتخاب ہے جب کام asynchronous ہو اور کوئی اس کے نتیجے کا انتظار نہ کر رہا ہو، مثلاً رات بھر documents کے ایک مجموعے کا summarisation یا ایسا nightly classification job جو آپ کے سوتے وقت چلتا رہے۔ جیسے ہی کوئی شخص output کا انتظار کر رہا ہو، یا requests ہر 30 seconds میں ایک سے زیادہ کی رفتار سے آنے لگیں، GPU کرائے پر لیں۔ CPU-only box میں batching کی گنجائش نہیں ہوتی، اس لیے queue مسلسل بڑھتی رہتی ہے۔

لاگت کا تقابل بظاہر جتنا واضح لگتا ہے، اتنا نہیں ہے۔ 64 GB VPS مہینے کے ہر گھنٹے کا بل لیتا ہے، چاہے model loaded ہو یا نہ ہو، جبکہ GPU instance صرف ان گھنٹوں کا بل لیتا ہے جن میں آپ اسے چلاتے ہیں۔ اگر آپ کا حقیقی استعمال روزانہ دو گھنٹے ہے تو rented GPU بیک وقت زیادہ تیز اور سستا ہو سکتا ہے۔ پہلے اپنا duty cycle معلوم کریں، پھر قیمت کا حساب لگائیں۔ GPU والے VPS کا انتخاب میں instance پر خود جانچنے والی چیزیں بیان کی گئی ہیں، اور GPU پر concurrent requests serve کرنے کے بعد vLLM، Ollama سے آگے نکل جاتا ہے کیونکہ یہ requests کو درست طریقے سے batch کرتا ہے۔

ایک تیسرا option بھی ہے جسے لوگ بھول جاتے ہیں۔ batch work کے لیے 27B کو CPU پر رکھیں اور interactive path کے سامنے hosted API model لگا دیں۔ ایک ہی model سے دونوں کام کرانا ضروری نہیں ہے۔

Ollama انسٹال کریں اور اپنے سرور کی پیمائش کریں

انسٹالیشن اسکرپٹ سرکاری ہے، اور یہ dedicated ollama user کے طور پر چلنے والی systemd service ترتیب دیتا ہے۔

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

ollama --version کو 0.32.5 یا اس کے بعد کا ورژن دکھانا چاہیے۔ کچھ بھی pull کرنے سے پہلے free -g چیک کریں۔ اگر Mem لائن کے total کالم میں قدر 32 سے کم ہو تو یہیں رک جائیں اور چھوٹا model منتخب کریں، کیونکہ ایسا 17 GB کا model pull کرنا جسے آپ چلا نہیں سکتے، ایک گھنٹہ اور کافی disk space ضائع کرتا ہے۔

Runtime options اپنی shell کے بجائے systemd override میں مقرر کریں۔ model service کے اندر چلتا ہے، اس لیے اسے آپ کا interactive environment نظر نہیں آتا۔

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 کا output وہ پیمائش ہے جس کے لیے آپ نے یہ عمل کیا ہے۔ eval rate generation کے دوران آپ کی tokens per second رفتار ہے۔ prompt eval rate prefill speed ہے۔ load duration اس وقت کو ظاہر کرتا ہے جو weights کو disk سے پڑھنے میں لگا، اسی لیے OLLAMA_KEEP_ALIVE=60m مقرر ہے: CPU پر ہر request کے دوران disk سے 17 GB دوبارہ load کرنا خود request سے زیادہ وقت لیتا ہے۔

جب model load ہو، تو دوسرے terminal سے اس کا memory footprint چیک کریں۔

ollama ps

SIZE کالم KV cache سمیت حقیقی memory footprint دکھاتا ہے، اور یہ weights کے حجم اور KV chart میں آپ کے context length والی row کے مجموعے کے قریب ہونا چاہیے۔ 8192 tokens پر 8-bit cache کے ساتھ weights کے علاوہ تقریباً ایک gigabyte کی توقع رکھیں؛ اگر cache f16 پر رہتا تو یہ مقدار 2 GB ہوتی۔ PROCESSOR کالم میں 100% CPU دکھنا چاہیے۔ اگر اس میں کوئی اور قدر ہو تو کسی چیز نے GPU استعمال کر لیا ہے، اور اس guide میں دی گئی speed numbers آپ کے server پر لاگو نہیں ہوتیں۔

ناکامی کی صورتیں اور آپ کو نظر آنے والے عین strings

ماڈل load ہونے سے انکار کر دیتا ہے۔ Ollama دونوں figures کے نام والی ایک line اس شکل میں دکھاتا ہے: model requires more system memory (18.6 GiB) than is available (15.2 GiB)۔ یہ بہتر قسم کی ناکامی ہے، کیونکہ Ollama memory allocate کرنے سے پہلے جانچ کر لیتا ہے، بجائے اس کے کہ فیصلہ kernel پر چھوڑ دے۔ context length کم کریں، چھوٹا tag منتخب کریں، یا زیادہ بڑے plan پر منتقل ہوں۔

جواب کے درمیان process غائب ہو جاتا ہے۔ client کوئی مفید output نہیں دکھاتا، اور journalctl -u ollama -n 50 سے معلوم ہوتا ہے کہ service دوبارہ start ہو رہی ہے۔ dmesg -T | tail چلائیں۔ اگر Out of memory: Killed process ... (ollama) والی line نظر آئے تو اس کا مطلب ہے کہ kernel کے OOM killer نے process ختم کر دی۔ ایسا اس وقت ہوتا ہے جب pre-load check کامیاب ہو جائے، لیکن طویل گفتگو کے دوران cache اندازے سے زیادہ بڑھ جائے۔ context length کم کریں۔

pull فوراً ناکام ہو جاتا ہے۔ Error: pull model manifest: file does not exist کا مطلب ہے کہ tag library میں موجود نہیں ہے۔ qwen3.8:27b لکھنے سے عین یہی output آتا ہے، اور version number میں کسی بھی typo سے بھی یہی ہوتا ہے۔ اپنے network کو ذمہ دار ٹھہرانے سے پہلے library page پر tag کی تصدیق کریں۔

سب کچھ کام کرتا ہے، لیکن رفتار ناقابلِ برداشت حد تک کم ہے۔ اگر کافی RAM والے box پر رفتار ایک token فی second سے کم ہو تو مسئلہ compute کے بجائے paging ہو سکتا ہے۔ generation کے دوران vmstat 1 چلائیں۔ si یا so column میں non-zero value کا مطلب ہے کہ kernel swapping کر رہا ہے۔ اس کا حل کم context یا کم loaded models ہیں۔ اگر swap activity کے بغیر wa مسلسل زیادہ ہو تو memory-mapped weights disk سے دوبارہ پڑھے جا رہے ہیں۔ اس کا مطلب ہے کہ وہ حقیقت میں memory میں fit نہیں ہوتے۔

پہلا token 30 seconds بعد آتا ہے، پھر output تیز ہو جاتا ہے۔ اسے prefill کہتے ہیں، اور یہ معمول کی بات ہے۔ جو request cache سے فائدہ نہیں اٹھاتی، اس پر طویل system prompt کی processing ہر بار دوبارہ ہوتی ہے۔ اس لیے کسی اور tuning سے پہلے system prompt مختصر کریں۔

CPU-only 27B ماڈل حقیقت میں کس کام کے لیے موزوں ہے

توقعات امید کے بجائے اعداد و شمار کی بنیاد پر مقرر کریں۔ 2 سے 4 tokens فی سیکنڈ کی رفتار پر 500 tokens کا جواب 2 سے 4 منٹ لیتا ہے۔ یہ chat کے لیے ناقابلِ استعمال ہے، لیکن queue کے لیے بالکل قابلِ عمل ہے۔ دستاویزات کا خلاصہ، بڑے پیمانے پر tagging، فائلوں کے ذخیرے سے fields نکالنا، اور unattended code review اس رفتار کو برداشت کر لیتے ہیں، کیونکہ جواب کا انتظار نہیں کیا جا رہا ہوتا۔ Coding assistance اسی حد پر آتی ہے۔ اس لیے coding agent کو اپنے host کردہ model سے منسلک کرنا commit messages اور test scaffolding جیسے background jobs کے لیے مفید ہے، نہ کہ ان inline suggestions کے لیے جن کا آپ بیٹھ کر انتظار کرتے ہیں۔

اصل دلیل privacy ہے۔ model ایسے hardware پر چلتا ہے جسے آپ rent اور control کرتے ہیں، کوئی request اس machine سے باہر نہیں جاتی، اور per-token bill بھی نہیں ہوتا۔ Regulated data کے لیے یہ فائدہ 3 tokens فی سیکنڈ کی رفتار پر بھی بہت اہم ہے۔ تاہم متبادل کا دیانت داری سے موازنہ کریں: frontier-scale model کو self-host کرنے کے لیے ایک order of magnitude زیادہ hardware درکار ہوتا ہے، اور CPU پر 27B اس curve پر وہ کم ترین نقطہ ہے جہاں output اب بھی پڑھنے کے قابل رہتا ہے۔

اگر یہ آپ کی پہلی Ollama installation ہے تو VPS پر Ollama چلانے کی مکمل رہنمائی میں service setup، HTTP API اور firewall rules شامل ہیں جن کے پہلے سے موجود ہونے کا یہ guide فرض کرتا ہے۔ port 11434 کو internet پر expose نہ کریں۔ Ollama اپنی authentication فراہم نہیں کرتا، اس لیے جو بھی اس port تک پہنچ سکتا ہے وہ آپ کا model استعمال کر سکتا ہے اور آپ کے prompts پڑھ سکتا ہے۔

FAQ

کیا Ollama پر Qwen 3.8 27B model موجود ہے؟

نہیں۔ 4 August 2026 تک Ollama library میں qwen3.8 namespace موجود نہیں ہے۔ موجودہ 27B tags qwen3.5:27b اور qwen3.6:27b ہیں، اور دونوں 27.8 billion parameters والے dense model کی Q4_K_M builds ہیں۔ تلاش میں استعمال کیا گیا 3.8 تقریباً یقینی طور پر 27.8B parameter count ہے، جسے version number سمجھ لیا گیا ہے۔ موجودہ فہرست کے لیے https://ollama.com/library/qwen3.6/tags دیکھیں، اور اگر آپ تازہ ترین released 27B چاہتے ہیں تو qwen3.6:27b pull کریں۔ ایسا tag جو موجود نہ ہو، Error: pull model manifest: file does not exist کے ساتھ fail ہوتا ہے۔

VPS پر Qwen 27B model چلانے کے لیے کتنی RAM درکار ہے؟

Q4_K_M کے لیے 32 GB عملی کم از کم ہے۔ Weights 17 GB ہیں، operating system کو تقریباً 1.5 GB درکار ہوتی ہے، اور f16 میں ہر 4000 tokens کے context پر KV cache تقریباً 1 GB مزید شامل کرتی ہے۔ 16 GB plan میں weights کے لیے بالکل گنجائش نہیں ہوتی، اور swap مدد نہیں کرتی کیونکہ file memory-mapped ہوتی ہے اور kernel ہر token پر اسے disk سے دوبارہ پڑھتا ہے۔ 64 GB میں long context یا 30 GB والی Q8_0 weights کے لیے گنجائش مل جاتی ہے۔

CPU پر 27B model مجھے فی سیکنڈ کتنے tokens دے گا؟

اپنی memory bandwidth کو weights کے سائز پر تقسیم کریں، پھر اس کا 50 سے 70 فیصد لیں۔ دو-channel DDR4-3200 VPS کی حد تقریباً 3 tokens فی سیکنڈ ہے اور یہ تقریباً 2 فراہم کرتا ہے۔ دو-channel DDR5-4800 system کی حد تقریباً 4.5 ہے اور یہ تقریباً 3 فراہم کرتا ہے۔ زیادہ channels والے server platforms کاغذ پر کہیں بہتر دکھائی دیتے ہیں، لیکن host پر موجود ہر tenant memory bandwidth میں شریک ہوتا ہے۔ اس لیے ollama run qwen3.6:27b --verbose سے اپنی رفتار ناپیں اور eval rate line پڑھیں۔

کیا صرف CPU والے VPS پر Q4 استعمال کرنا چاہیے یا Q8؟

تقریباً ہر صورت میں Q4_K_M استعمال کریں۔ Q8_0 کا سائز 30 GB ہے، جبکہ Q4_K_M کا سائز 17 GB ہے۔ اس لیے Q8_0 کے لیے 64 GB plan درکار ہوتا ہے، اور یہ فی token تقریباً دو گنا زیادہ memory منتقل کرتا ہے، جس سے tokens فی سیکنڈ تقریباً آدھے رہ جاتے ہیں۔ 27B model پر زیادہ تر tasks کے لیے Q4_K_M اور Q8_0 کے quality فرق معمولی ہے۔ RAM کو longer context کے لیے استعمال کریں، کیونکہ اس سے model کے کام کرنے کی صلاحیت بدلتی ہے، صرف اس کا اندازِ بیان نہیں۔

بڑی RAM والے VPS کے مقابلے میں GPU کرائے پر لینا کب سستا ہوتا ہے؟

جب آپ کا duty cycle کم ہو یا کوئی شخص output کا انتظار کر رہا ہو۔ 24 GB memory والا GPU ان weights پر تقریباً 59 tokens فی سیکنڈ تک پہنچتا ہے، جبکہ عام VPS پر رفتار 2 یا 3 ہوتی ہے، اور GPU صرف چلنے والے hours کے لیے bill ہوتا ہے۔ 64 GB VPS پورے مہینے کا bill لیتا ہے، خواہ model loaded ہو یا نہ ہو۔ حساب کریں کہ آپ واقعی روزانہ کتنے hours tokens generate کرتے ہیں۔ اگر یہ مدت دو یا تین hours سے کم ہو تو hourly GPU rental عموماً speed اور cost دونوں میں بہتر رہتی ہے۔ مسلسل low-priority batch work میں ہمیشہ چلنے والا VPS بہتر ثابت ہوتا ہے۔