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

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

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۔ ذیل میں ہر command اور ہر number 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 مکمل طور پر ناکافی ہیں۔ عام two-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 جاری کیا جاتا ہے تو بھی یہاں کی arithmetic درست رہے گی، کیونکہ اس کا انحصار parameter count اور bits per weight پر ہے، version number پر نہیں۔

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

ایسا tag حاصل کرنے پر جو موجود نہ ہو، واضح error ظاہر ہوتا ہے۔ اس لیے خود server پر یہ فیصلہ جلد کیا جا سکتا ہے۔ موجود tag بھی مقامی طور پر چلنے کے قابل نہ ہو سکتا ہے۔ یہی بات لوگوں کو GLM 5.2، جو library میں درج ہے لیکن صرف Ollama کے cloud سے فراہم کیا جاتا ہے کے معاملے میں الجھاتی ہے۔

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 لکھی گئی ہے۔ library میں انہی weights کے لیے زیادہ precision والے qwen3.6:27b-q8_0 اور qwen3.6:27b-bf16 بھی موجود ہیں۔ اس کے علاوہ 35b-a3b tags کا ایک مجموعہ بھی ہے، جو MoE (mixture of experts) models ہیں اور CPU پر بہت مختلف انداز میں کام کرتے ہیں۔ ان کی مزید وضاحت نیچے دی گئی ہے۔

وزن کی بائٹس = parameters × ہر وزن کے bits

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

فارمولا ایک ہی سطر پر مشتمل ہے۔ weights کی بائٹس = parameters × ہر weight کے bits / 8۔ اگر ہر weight کے لیے درست طور پر 4 bits ہوں تو 27.8 billion parameters کے لیے 13.9 GB درکار ہوں گے۔ فراہم کردہ Q4_K_M tag کا حجم 17 GB ہے، جو عملی طور پر ہر weight کے لیے 4.89 bits بنتا ہے۔

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

اس model کے لیے Q5_K_M کا کوئی published tag موجود نہیں، اس لیے 19.8 GB والی row کی calculation اس format کے معمول کے 5.7 bits per weight پر مبنی ہے، measured value نہیں۔ Q8_0، Q4 کے حجم کو تقریباً دوگنا کرکے 30 GB تک پہنچا دیتا ہے۔ صرف CPU والے box پر یہ doubling ہر token کے لیے memory traffic کو دوگنا کرتی ہے، اس لیے tokens per second بھی تقریباً نصف رہ جاتے ہیں۔ اسی وجہ سے یہاں Q4_K_M موزوں default ہے۔ اگر آپ memory کے بجائے اس فیصلے کے quality پہلو کو سمجھنا چاہتے ہیں تو Q4، Q8 اور fp16 کا مزید قریب سے موازنہ دکھاتا ہے کہ output کا معیار کہاں سے حقیقتاً کم ہونا شروع ہوتا ہے۔

جیسے جیسے 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، اور head dimension 128۔ اس سے f16 پر فی token 256 KiB بنتا ہے؛ چنانچہ 32k tokens پر 8 GB اور 128k پر 32 GB بنتا ہے۔ اپنے server پر میری arithmetic کو حتمی نہ سمجھیں۔ 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 کے ذریعے اسے جان بوجھ کر بڑھاتے ہیں۔ یہ server-wide variable واحد اختیار نہیں ہے، اور انفرادی request پر num_ctx مقرر کرنے سے آپ باقی تمام کاموں کے لیے کم لاگت والا default برقرار رکھتے ہوئے کسی ایک طویل کام کو بڑی window دے سکتے ہیں۔ اسے مرحلہ وار بڑھائیں اور ہر تبدیلی کے بعد ollama ps چیک کریں۔

دو settings cache کو نصف یا اس سے بھی کم کر دیتی ہیں۔ OLLAMA_KV_CACHE_TYPE=q8_0 cache کو 16 کے بجائے 8 bits پر محفوظ کرتا ہے، جس سے 32k tokens کی لاگت 8 GB سے کم ہو کر 4 GB رہ جاتی ہے۔ اس کے لیے flash attention درکار ہے، اس لیے OLLAMA_FLASH_ATTENTION=1 بھی set کریں، اور یہ فرض کرنے کے بجائے کہ setting نافذ ہو گئی ہے، ollama ps میں کمی کی تصدیق کریں۔ OLLAMA_NUM_PARALLEL=1 بھی اتنا ہی اہم ہے۔ Ollama ایک وقت میں متعدد requests serve کر سکتا ہے، اور ہر slot کو context کا اپنا حصہ ملتا ہے؛ اس لیے parallelism کو default پر چھوڑنے سے آپ کے مختص کردہ cache کا حجم خاموشی سے کئی گنا بڑھ جاتا ہے۔ اگر اس server کو ایک سے زیادہ افراد استعمال کریں گے تو مسئلہ اسی multiplication سے شروع ہوتا ہے، اور self-hosted model بیک وقت کتنے صارفین کو 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."
  }
]

دونوں اعداد کو context کے ان ہزاروں tokens کے طور پر پڑھیں جو f16 cache میں weights کے ساتھ headless Linux VPS پر fit ہوتے ہیں، جہاں operating system کے لیے تقریباً 1.5 GB اور تھوڑا اضافی margin باقی رکھا گیا ہے۔ صفر کا مطلب ہے کہ خود 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 انہیں بار بار evict کر کے دوبارہ پڑھتا ہے، اور پھر ہر token کے لیے disk سے کئی GB data پڑھنا پڑتا ہے۔ machine میں iowait زیادہ رہتا ہے اور رفتار ایک second میں ایک token سے بھی کم ہو جاتی ہے۔

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 generate کرنے کے لیے ہر weight کو memory سے ایک بار پڑھنا پڑتا ہے۔ صرف کچھ weights کو نہیں، بلکہ سبھی weights کو۔ اس لیے رفتار کی حد آپ کے cores کی تعداد نہیں، بلکہ memory bandwidth کو weights کے حجم پر تقسیم کرنے سے حاصل ہونے والی قدر ہے۔ Q4 پر یہ فی token 17 GB memory traffic بنتا ہے۔

[
  {
    "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 کی وجہ سے آپ نظریاتی peak تک نہیں پہنچتے۔ دو-channel DDR4-3200 VPS کی حد 3 tokens per second ہے، اس لیے تقریباً 2 کی توقع رکھیں۔ دو-channel DDR5-4800 مشین کی حد 4.5 ہے، اس لیے تقریباً 3 کی توقع رکھیں۔

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

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

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

اگر dense 27B model بہت سست ہو تو CPU کو ترک کرنے سے پہلے qwen3.6:35b-a3b tags دیکھیں۔ یہ تمام 27.8 billion parameters کے بجائے ہر token کے لیے تقریباً 3 billion parameters activate کرتے ہیں۔ اس لیے 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 پر لاگو کیا جائے تو نتیجہ ایک مختلف زمرے میں آتا ہے۔ 24 GB کا consumer card ان weights پر زیادہ سے زیادہ 59 tokens فی سیکنڈ چلا سکتا ہے۔ موجودہ data centre card 197 تک پہنچتا ہے۔ اس فرق کو thread counts کی tuning سے ختم نہیں کیا جا سکتا۔ card اپنی memory کو 1008 GB/s پر چلاتا ہے، جبکہ آپ کا VPS چند دسیوں GB/s پر چلتا ہے۔

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

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

ایک تیسرا اختیار بھی ہے جسے لوگ بھول جاتے ہیں۔ 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 اس بات کا وقت ہے کہ disk سے weights پڑھنے میں کتنا وقت لگا؛ اسی لیے OLLAMA_KEEP_ALIVE=60m مقرر کیا گیا ہے۔ CPU پر ہر request کے دوران disk سے 17 GB دوبارہ load کرنے کی لاگت خود request سے زیادہ ہو سکتی ہے۔ Default idle timeout پانچ منٹ ہے۔ یہ اتنا مختصر ہے کہ items کے درمیان وقفوں والی batch queue بار بار یہ load cost ادا کرتی ہے۔ model کو resident رکھنے کے options فی request keep_alive field اور reboot کے بعد setting برقرار رکھنے، دونوں کا احاطہ کرتے ہیں۔

Model کے load ہونے کے دوران دوسرے terminal سے memory footprint چیک کریں۔

ollama ps

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

خرابی کی صورتیں اور وہ عین strings جو آپ دیکھیں گے

ماڈل load ہونے سے انکار کر دیتا ہے۔ Ollama دونوں figures کے نام والی ایک line دکھاتا ہے، جس کی صورت model requires more system memory (18.6 GiB) than is available (15.2 GiB) ہوتی ہے۔ یہ بہتر قسم کی failure ہے، کیونکہ 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 فوراً fail ہو جاتا ہے۔ 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 چلائیں۔ non-zero si یا so column کا مطلب ہے کہ kernel swapping کر رہا ہے۔ اس کا حل کم context یا کم loaded models ہیں۔ swap activity کے بغیر مسلسل زیادہ wa کا مطلب ہے کہ memory-mapped weights کو disk سے بار بار دوبارہ پڑھا جا رہا ہے، یعنی وہ واقعی memory میں fit نہیں ہوتے۔

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

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

توقعات امید کے بجائے اعداد و شمار کی بنیاد پر طے کریں۔ 2 سے 4 tokens فی سیکنڈ کی رفتار پر 500 tokens کا جواب 2 سے 4 منٹ لیتا ہے۔ یہ chat کے لیے ناقابلِ استعمال ہے، لیکن queue کے لیے بالکل قابلِ عمل ہے۔ جو model جواب دینے سے پہلے سوچتا ہے، اس میں یہ حساب مزید خراب ہو جاتا ہے، کیونکہ پوشیدہ reasoning tokens بھی جواب جتنی ہی سست رفتار سے generate ہوتے ہیں۔ اس لیے reasoning effort level کو کام کے مطابق رکھنا model تبدیل کیے بغیر جواب مختصر کرنے کے چند مؤثر طریقوں میں سے ایک ہے۔ Document summarisation، bulk tagging، files کے backlog سے field extraction، اور unattended code review اس رفتار کو برداشت کر لیتے ہیں، کیونکہ کسی کو جواب کا انتظار نہیں ہوتا۔ Coding assistance اسی حد پر آتی ہے۔ اس لیے coding agent کو اپنے host کیے ہوئے model سے جوڑنا commit messages اور test scaffolding جیسے background jobs کے لیے مفید ہے، نہ کہ ان inline suggestions کے لیے جن کا آپ بیٹھ کر انتظار کرتے ہیں۔

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

اس کارکردگی کو benchmark کرنے کے لیے real structured input درکار ہوتا ہے، اور زیادہ تر public data APIs throughput ناپنے سے پہلے account بنانے کا تقاضا کرتی ہیں۔ Strasmore کا demo endpoint (ہم اسے چلاتے ہیں) 22 سال کے US market data پر read-only SQL کا جواب دیتا ہے۔ اس کے لیے key یا signup درکار نہیں۔ https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 کو GET کرنے سے JSON واپس آتا ہے جسے آپ براہِ راست prompt loop میں pipe کر سکتے ہیں۔ اس کے ساتھ وہ exact SQL بھی شامل ہوتی ہے جس سے data تیار کیا گیا، تاکہ model کے پاس summarise کرنے کے لیے ایسا مواد ہو جس کی آپ آزادانہ طور پر تصدیق کر سکیں۔ حدود 500 rows اور ہر call کے لیے 20 seconds ہیں، جو 2 tokens فی سیکنڈ کی machine کے استعمال سے خاصی زیادہ ہیں۔ مکمل column list https://api.strasmore.com/v1/schema پر موجود ہے۔

اگر یہ آپ کی پہلی 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 دیکھیں، اور اگر آپ تازہ ترین جاری شدہ 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 میں context کے ہر 4000 tokens پر KV cache تقریباً 1 GB اضافی لیتا ہے۔ 16 GB plan میں weights بالکل نہیں آتے، اور swap مدد نہیں کرتی کیونکہ file memory-mapped ہوتی ہے، اس لیے kernel ہر token پر اسے disk سے دوبارہ پڑھتا ہے۔ 64 GB سے طویل context یا 30 GB والے Q8_0 weights کے لیے گنجائش مل جاتی ہے۔

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

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

کیا CPU-only VPS پر Q4 یا Q8 استعمال کرنا چاہیے؟

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

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

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