Ollama quantization: q4_K_M، q8_0 یا fp16؟

Ollama quantization میں کیا تبدیلی آتی ہے

Ollama quantization ماڈل کے ہر weight کو اس فائل کے مقابلے میں کم bits میں محفوظ کرتی ہے جس میں اسے train کیا گیا تھا۔ q4_K_M پر ختم ہونے والا tag ہر weight کے لیے تقریباً چار bits محفوظ رکھتا ہے، جبکہ fp16 سولہ bits رکھتا ہے۔ اس لیے download تقریباً ایک چوتھائی سائز کا ہوتا ہے، اور machine ہر token تیار کرنے کے لیے تقریباً ایک چوتھائی bytes پڑھتی ہے۔ weights کو موٹے grid پر round کیا جاتا ہے، ضائع نہیں کیا جاتا، اور چار bits پر زیادہ تر models تقریباً اسی طرح جواب دیتے ہیں جیسے full precision پر دیتے تھے۔

یہی مکمل trade-off ہے: memory footprint بہت کم ہوتا ہے اور فی سیکنڈ زیادہ tokens تیار ہوتے ہیں، لیکن accuracy میں معمولی کمی آتی ہے۔ آگے بتایا گیا ہے کہ کسی مخصوص model کو کسی مخصوص box پر چلانے سے پہلے اس کے دونوں اثرات کا اندازہ کیسے لگایا جائے، تاکہ آپ ایسی file download کرنے میں بیس منٹ صرف نہ کریں جو fit ہی نہ ہو۔

اگر Ollama ابھی نہیں چل رہا تو VPS پر Ollama انسٹال کرنا سے شروع کریں۔ اس صفحے میں فرض کیا گیا ہے کہ ollama ls پہلے ہی کام کر رہا ہے۔

Ollama کے quantization tag جیسے q4_K_M کو کیسے پڑھیں

Local models، GGUF files کی صورت میں فراہم کیے جاتے ہیں۔ یہ وہ format ہے جسے llama.cpp weights کو disk پر محفوظ کرنے کے لیے استعمال کرتا ہے۔ Ollama کی بنیاد llama.cpp پر ہے، اس لیے Ollama tags میں llama.cpp کے quantization names بغیر تبدیلی کے شامل ہوتے ہیں۔

عدد target width کو ظاہر کرتا ہے۔ q4 کا مطلب ہے کہ زیادہ تر weight tensors کو ہر ایک 4 bits پر pack کیا گیا ہے۔ q8 کا مطلب 8 bits ہے۔ fp16 میں quantization بالکل نہیں کی جاتی۔ یہ model 16-bit floating point میں ہوتا ہے، جو وہ precision ہے جس میں زیادہ تر models شائع کیے جاتے ہیں۔

K ایک K-quant کو ظاہر کرتا ہے۔ Weights کو چھوٹے blocks میں تقسیم کیا جاتا ہے، اور ہر block میں packed values کے ساتھ اپنا scale محفوظ ہوتا ہے۔ جس block کے تمام weights تقریباً 0.01 کے قریب ہوں، اسے fine scale ملتا ہے۔ جس block میں ایک بڑا outlier ہو، اسے coarse scale ملتا ہے۔ یہی per-block scales 4-bit file کو قابلِ استعمال بناتے ہیں۔ یہی وجہ ہے کہ 4-bit file میں ہر weight کے لیے عین 4 bits استعمال نہیں ہوتے۔

آخری حرف mixture کو ظاہر کرتا ہے۔ S، M اور L یہ طے کرتے ہیں کہ کتنے tensors کو target width سے زیادہ پر promote کیا جائے گا۔ q4_K_M میں rounding سے سب سے زیادہ متاثر ہونے والے tensors کو زیادہ width پر محفوظ کیا جاتا ہے، جبکہ زیادہ تر weights 4 bits پر رہتے ہیں۔ اسی لیے q4_K_M تقریباً اسی file size پر پرانے q4_0 سے بہتر output دیتا ہے۔

نام سے اندازہ لگانے کے بجائے Ollama سے معلوم کریں کہ disk پر کیا موجود ہے:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show، architecture، parameters، quantization، context length اور embedding length دکھاتا ہے۔ quantization line اس model کے لیے اصل معلومات ہے جسے آپ نے کئی ماہ پہلے pull کیا تھا اور اب یاد نہیں کہ کون سا model منتخب کیا تھا۔

وزن کے لحاظ سے bits ہی فائل کا سائز متعین کرتے ہیں

سائز کا ہر اندازہ ایک عدد سے شروع ہوتا ہے: پورے فائل میں اوسطاً ہر weight کے لیے format کتنے bits استعمال کرتا ہے۔ llama.cpp اپنی quantize documentation میں Llama 3.1 8B کے لیے ناپی گئی قدریں فراہم کرتا ہے، اور یہ تقریباً اسی ساخت والے ہر dense model پر اچھی طرح لاگو ہوتی ہیں۔

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

اس جدول میں حیرت انگیز چیز دوسرا کالم ہے۔ Q4_K_M ہر weight کے لیے چار bits استعمال نہیں کرتا۔ اس کی پیمائش 4.89 bits ہے، کیونکہ block scales اور promoted tensors بھی حقیقی جگہ لیتے ہیں۔ اسی وجہ سے Q8_0 آٹھ کے بجائے 8.5 bits استعمال کرتا ہے۔ ناپی گئی قدر استعمال کریں تو حساب حقیقی فائل کے سائز سے چند فیصد کے اندر رہتا ہے:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

یہ 4.58 GiB کی Q4_K_M فائل ہے، جو دو اعداد سے دوبارہ حاصل کی گئی ہے۔ تقریباً یہی وہ memory بھی ہے جس پر load ہونے کے بعد weights قابض ہوتے ہیں۔ Ollama load کے وقت کچھ unpack نہیں کرتا۔ quantized weights memory میں اسی packed form میں رہتے ہیں، اور ہر block استعمال کے وقت convert ہوتا ہے۔

ہر ماڈل سائز کے لیے Ollama حقیقت میں کیا فراہم کرتا ہے

لائبریری زیادہ تر families کے لیے q4_K_M، q8_0 اور fp16 tags شائع کرتی ہے۔ کچھ نئی families اس pattern سے مختلف ہیں اور library میں صرف cloud-only tags کے طور پر ظاہر ہوتی ہیں۔ ان میں کسی بھی width پر pull کرنے کے لیے کچھ نہیں ہوتا۔ یہی وہ رکاوٹ ہے جس کا سامنا آپ کو VPS پر GLM 5.2 چلانے کی کوشش کرتے وقت ہوتا ہے۔ اگست 2026 تک Qwen3 کے یہ sizes model page کی tag list سے لیے گئے ہیں۔ ذیل میں دی گئی ہر figure اس disk space کو ظاہر کرتی ہے جو RAM میں load ہونے سے پہلے درکار ہوتی ہے۔ ان میں سے دو یا تین tags مل کر چھوٹے VPS کا root volume بھر سکتے ہیں۔ اس لیے tags جمع کرنا شروع کرنے سے پہلے یہ جاننا مفید ہے کہ Ollama ڈاؤن لوڈ کیے گئے models کہاں محفوظ کرتا ہے۔

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

یہاں default tag اہم ہے۔ ollama pull qwen3:8b بالکل اتنے ہی 5.2 GB ڈاؤن لوڈ کرتا ہے جتنے ollama pull qwen3:8b-q4_K_M، کیونکہ بغیر suffix والا tag خود q4_K_M build ہے۔ Q4_K_M کوئی ایسا سمجھوتا نہیں جو library مجبوری میں فراہم کرتی ہے۔ یہ وہ default ہے جسے upstream نے منتخب کیا ہے۔ اس لیے جس model کو آپ نے خود test نہ کیا ہو، اس کے لیے ابتدا میں اسی سے مطابقت رکھنا مناسب ہے۔ یہی منطق VPS پر Qwen 3 چلانے میں tag کے انتخاب پر بھی لاگو ہوتی ہے۔

یہ ratios ہر row میں برقرار رہتے ہیں۔ q4_K_M سے q8_0 پر منتقل ہونے سے لاگت تقریباً ستر فیصد بڑھتی ہے، بالکل دگنی نہیں ہوتی، کیونکہ embedding اور output tensors باقی حصوں کی طرح scale نہیں ہوتے۔ fp16 کا سائز q4_K_M سے تقریباً تین گنا ہوتا ہے۔ q4_K_M پر 32B model کے weights 20 GB ہوتے ہیں۔ یہ مقدار پہلے ہی اس حد سے زیادہ ہے جسے 16 GB کی machine کسی بھی context window کے ساتھ رکھ سکتی ہے۔ یہ دیکھنے کے لیے کہ کون سی machine پر کون سا model فٹ ہوتا ہے، وہ models دیکھیں جنہیں آپ self-host کر سکتے ہیں۔

KV cache کی دوسری، context-dependent لاگت کیوں ہے

Weights مستقل لاگت ہیں۔ KV cache (key اور value cache) متغیر لاگت ہے۔ context window کے ہر token کے لیے ہر layer میں اس کے key اور value vectors محفوظ رہتے ہیں، اس لیے cache آپ کی مقرر کردہ window کے ساتھ خطی طور پر بڑھتا ہے۔ Model load ہونے پر یہ پوری window کے لیے allocate ہوتا ہے، conversation کے بڑھنے کے ساتھ نہیں۔ اسی لیے ایک لفظ کے prompt پر بھی بڑی window memory استعمال کرتی ہے۔

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

یہ model numbers خود model کی configuration سے آتے ہیں: 36 layers، 8 key/value heads، اور head dimension 128۔ ollama show architecture اور parameter count فراہم کرتا ہے، جبکہ Hugging Face پر model کا config.json باقی معلومات فراہم کرتا ہے۔ فی token لاگت کو window size سے ضرب دیں تو cache معمولی اضافی لاگت نہیں رہتا۔

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

Ollama کی default window، یعنی 4096 tokens، پر cache weights کے علاوہ 0.6 GB شامل کرتا ہے۔ Window کو 32k تک بڑھائیں تو صرف cache 4.83 GB تک پہنچ جاتا ہے۔ یہ quantized weights جتنی memory کے تقریباً برابر ہے، اور پورے model کے لیے کم از کم درکار memory 10 GB ہو جاتی ہے۔ اسے کم از کم حد اس لیے کہیں کیونکہ compute buffers اور operating system بھی اس کے علاوہ memory استعمال کرتے ہیں۔ Model load ہونے کے بعد اصل figure ollama ps کے SIZE column سے پڑھیں۔

جب آپ Ollama کو service کے طور پر چلاتے ہیں تو window server پر set ہوتی ہے، ہر request کے لیے الگ نہیں:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

systemd install کے لیے اسے drop-in میں set کریں:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

sudo systemctl restart ollama سے restart کریں، پھر ollama ps کا CONTEXT column دیکھ کر تصدیق کریں کہ running model کو حقیقت میں کس window کے ساتھ load کیا گیا تھا۔ OLLAMA_KV_CACHE_TYPE خود cache کو quantize کرتا ہے: f16 default ہے، q8_0، f16 کے مقابلے میں تقریباً آدھی memory استعمال کرتا ہے، جبکہ q4_0 تقریباً ایک چوتھائی memory استعمال کرتا ہے۔ یہ global option ہے، اس لیے اس server پر موجود ہر model پر ایک ہی setting لاگو ہوتی ہے۔ بڑی window والے چھوٹے system پر cache کو نصف کرنا کسی بھی دوسری واحد تبدیلی کے مقابلے میں زیادہ memory آزاد کرتا ہے۔ num_ctx set کرنا اور اس کی لاگت window کی تفصیل بیان کرتا ہے۔ Cache ہر server کے لیے ایک بار نہیں بلکہ ہر concurrent request slot کے لیے الگ size ہوتا ہے۔ اس لیے Ollama کو بیک وقت دو prompts کا جواب دینے کی اجازت دینے سے ابھی budget کی گئی figure دوگنی ہو جاتی ہے۔ یہی حساب parallel slot count اور queue limit منتخب کرنا کی بنیاد ہے۔

8، 16 یا 32 GB VPS پر کیا فٹ ہوتا ہے

Budget weights، KV cache، operating system اور چلنے والی دیگر تمام چیزوں کے لیے اضافی گنجائش شامل کریں۔ چھوٹے VPS پر 2 GB اضافی گنجائش مناسب رہتی ہے۔

8 GB۔ q4_K_M پر 4B model 2.6 GB ہے اور طویل window کے لیے گنجائش چھوڑتا ہے۔ q4_K_M پر 8B model، default 4k window کے ساتھ فٹ ہو جاتا ہے، لیکن اضافی گنجائش بہت کم رہتی ہے۔ یہاں 32k window کے ساتھ 8B کا منصوبہ نہ بنائیں، کیونکہ 10 GB کی کم از کم ضرورت ہی اس مشین کی دستیاب RAM سے زیادہ ہے۔

16 GB۔ q4_K_M پر 8B، 16k یا 32k window کے ساتھ آرام سے چلتا ہے۔ q4_K_M پر 14B کے weights 9.3 GB ہیں اور یہ modest window کے ساتھ فٹ ہو جاتا ہے۔ q8_0 پر 8B 8.9 GB ہے، اس لیے یہ بھی فٹ ہو جاتا ہے۔ اپنے prompts پر ان دونوں کا موازنہ کرنا اس موضوع پر صرف ہونے والا سب سے مفید ایک گھنٹہ ہے۔

32 GB۔ q8_0 پر 14B (16 GB) اور q4_K_M پر 32B (20 GB) دونوں load ہو جاتے ہیں۔ بڑی window کے ساتھ 32B build حد کے قریب پہنچ جائے گا، اس لیے فرض کرنے کے بجائے ollama ps کو monitor کریں۔

پہلے کیا متاثر ہوتا ہے

Quantization error ماڈل کے تمام کاموں کو یکساں طور پر متاثر نہیں کرتا۔ روانی سب سے آخر میں متاثر ہوتی ہے، اور یہی وجہ ہے کہ نقصان کو محسوس کرنا مشکل ہوتا ہے: ناقص طور پر quantized ماڈل اب بھی صاف جملے لکھتا ہے۔ Precision پہلے متاثر ہوتی ہے۔ Version number، API signature یا date کو بالکل درست یاد رکھنا متاثر ہوتا ہے۔ Reasoning کی طویل زنجیریں متاثر ہوتی ہیں، جہاں step two کی ایک معمولی غلطی step eight تک غلط جواب بن جاتی ہے۔ Strict output formats بھی متاثر ہوتے ہیں، جہاں ایک غلط bracket tool call کو ناکام بنا دیتا ہے۔

عملی جانچ یہی آخری معاملہ ہے۔ جب ماڈل کو ایسا JSON واپس کرنا ہو جسے آپ کا code parse کرتا ہے، تو quantization کا نقصان مبہم طور پر خراب نثر کے بجائے parse error کی صورت میں ظاہر ہوتا ہے، اس لیے آپ اسے اسی دن دیکھ لیتے ہیں۔ Coding agent اس جانچ کی سخت ترین صورت ہے، کیونکہ وہ ماڈل کو مسلسل tool calls کے ذریعے چلاتا ہے۔ اس لیے اپنے Ollama server کی طرف agent کو بھیجنا چند گھنٹوں میں حد سے زیادہ aggressive quantization کو ظاہر کر دے گا۔

Four bits سے کم پر نقصان تیزی سے بڑھتا ہے۔ q3 اور two bit types ان لوگوں کے لیے ہیں جو بڑے model کو محدود hardware پر چلانا چاہتے ہیں، اور جب متبادل یہ ہو کہ model بالکل نہ چلایا جائے تو یہ حقیقی اختیار ہیں۔ انہیں default کے طور پر استعمال کرنا مناسب نہیں۔ q4_K_M اور q8_0 کے درمیان فرق اتنا کم ہے کہ شائع شدہ perplexity table آپ کے workload کے لیے فیصلہ نہیں کر سکتی، اس لیے اس طریقے سے فیصلہ کرنے کی کوشش نہ کریں۔ اپنے تیس prompts پر دونوں کو چلائیں اور output پڑھیں۔

q8_0 یا fp16 کب RAM کے قابل ہوتے ہیں

جب memory واقعی اضافی ہو اور کام میں معمولی غلطیاں بھی مسئلہ بنیں تو q8_0 حاصل کریں: structured extraction، tool calling، اور ایسا code جس کا compile ہونا ضروری ہو۔ یہاں آپ نمایاں طور پر زیادہ ذہین model نہیں خرید رہے؛ آپ اضافی تحفظ حاصل کر رہے ہیں۔

fp16 صرف دو صورتوں میں حاصل کریں۔ پہلی صورت یہ ہے کہ آپ خود model کو quantize کر رہے ہوں اور source file درکار ہو۔ دوسری صورت یہ ہے کہ آپ baseline کی پیمائش کر رہے ہوں تاکہ معلوم ہو سکے کہ آپ کے four bit build نے کتنی صلاحیت کھوئی۔ fp16 سے serving کے لیے q4_K_M کے مقابلے میں تین گنا memory درکار ہوتی ہے، جبکہ فرق ایسا ہوتا ہے جسے زیادہ تر لوگ blind test میں محسوس نہیں کر سکتے۔ صرف CPU والے box پر اس سے آپ کی token rate بھی ایک تہائی رہ جاتی ہے۔

ایک ہی memory budget میں زیادہ مضبوط اصول یہ ہے: q4_K_M میں بڑا model عموماً q8_0 میں چھوٹے model سے بہتر ہوتا ہے۔ 9.3 GB کی 14B weights اور 8.9 GB کی 8B weights تقریباً اتنی ہی RAM (random access memory) استعمال کرتی ہیں، لیکن بڑے model کو زیادہ معلومات ہوتی ہیں۔ اس بات کو اپنے prompts پر آزمائیں، محض اعتماد کی بنیاد پر اسے درست نہ مانیں۔

CPU پر صرف inference memory bandwidth کی وجہ سے محدود رہتا ہے

زیادہ تر VPS plans میں GPU نہیں ہوتا، اس لیے model host کے CPU کی system memory میں چلتا ہے۔ اس کے بعد generation memory bandwidth سے bound ہوتی ہے، arithmetic سے نہیں، کیونکہ ہر token تیار کرنے کے لیے تمام weights کو ایک بار پڑھنا ضروری ہوتا ہے۔ اس سے ایک ایسی حد مقرر ہوتی ہے جس کا تعلق آپ کے خریدے گئے cores کی تعداد سے نہیں ہوتا۔

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

Dual-channel DDR4-3200 host کے لیے 50 GB/s تقریباً نظریاتی رفتار ہے۔ آپ کا حصہ اس سے کم ہوتا ہے، کیونکہ VPS اس bus کو machine پر موجود ہر دوسرے tenant کے ساتھ share کرتا ہے۔ اس لیے ان اعداد کو ایسی زیادہ سے زیادہ حد سمجھیں جس تک کوئی نہیں پہنچتا۔ مفید بات اس رجحان میں ہے: CPU پر ہر weight کے bits نصف کرنے سے token rate تقریباً دوگنا ہو جاتا ہے۔ GPU کے بغیر machine پر quantization رفتار بڑھانے کا سب سے مؤثر طریقہ ہے۔ باقی رہ جانے والی rate قابلِ قبول ہے یا نہیں، اس کا انحصار model پر ہوتا ہے، اور VPS پر Nemotron 3.5 Lightning ایک مخصوص build، tag اور RAM figure کے لیے اس حساب کو عملی طور پر واضح کرتا ہے۔ انتظار کا دوسرا حصہ اس بات پر منحصر ہے کہ model کتنا متن لکھنے کا فیصلہ کرتا ہے۔ 10 tokens فی second کی رفتار پر 600 tokens کا جواب مکمل ہونے میں پورا 1 minute لگتا ہے، اس لیے num_predict سے جواب کی حد مقرر کرنا اکثر precision کو مزید ایک درجے تک کم کرنے کے مقابلے میں زیادہ انتظار کا وقت بچاتا ہے۔

Prompt processing کا رویہ مختلف ہوتا ہے۔ ایک طویل prompt پڑھنا bandwidth-bound کے بجائے compute-bound ہوتا ہے، اس لیے اضافی cores یہاں مدد دیتے ہیں، جبکہ generation speed میں تقریباً کوئی اضافہ نہیں کرتے۔ ایسا system جو 4k prompt تیزی سے ingest کرے اور پھر آہستہ generation کرے، معمول کے مطابق کام کر رہا ہوتا ہے۔

کسی بھی arithmetic کو بغیر تصدیق کے درست نہ سمجھیں۔ اپنے system پر tokens فی second کی پیمائش کریں، اور ہر quantization کے لیے وہی prompt استعمال کریں۔ پھر اپنے اعداد کو ان اعداد پر فوقیت دیں۔

خود ماڈل کو quantize کرنا

Ollama کسی fp16 یا fp32 source سے quantized model بنا سکتا ہے۔ یہ اس وقت اہم ہوتا ہے جب آپ نے کسی model کو fine-tune کیا ہو اور اس کے لیے کوئی library tag موجود نہ ہو۔ unquantized weights کی طرف Modelfile کی نشاندہی کریں:

FROM /path/to/my/model/f16

پھر build کریں اور تصدیق کریں:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize، q8_0، q4_K_S اور q4_K_M قبول کرتا ہے۔ یہاں q6_K یا q5_K_M کا کوئی option موجود نہیں۔ اس لیے ان کے لیے llama.cpp کے اپنے tool سے quantize کریں اور تیار شدہ GGUF file import کریں۔ اس import طریقے میں ایک الگ خرابی بھی ہو سکتی ہے: chat template mismatch کی وجہ سے model ناقابلِ فہم جواب دے سکتا ہے۔ GGUF file کو Ollama میں import کرنا اس عمل کی وضاحت کرتا ہے۔ ollama show کی quantization line سے تصدیق ہوتی ہے کہ build نے وہی نتیجہ دیا جس کی آپ نے ہدایت کی تھی۔

خرابی کی صورت میں آپ کیا دیکھیں گے

جب آپ نے GPU کی توقع کی ہو لیکن سب کچھ CPU پر چل رہا ہو۔ PROCESSOR کالم دیکھیں:

ollama ps

اس میں 100% GPU، 100% CPU، یا 48%/52% CPU/GPU جیسی تقسیم شدہ قدر دکھائی دیتی ہے۔ تقسیم شدہ قدر کا مطلب ہے کہ weights اور KV cache، VRAM (video RAM، یعنی graphics card کی memory) میں نہیں سما سکے، اس لیے model کا کچھ حصہ system memory میں رکھ دیا گیا۔ اس کے بعد رفتار تقریباً صرف CPU کی رفتار تک گر جاتی ہے، کیونکہ ہر token کو سست حصے کے مکمل ہونے کا انتظار کرنا پڑتا ہے۔ context window کم کریں، cache کو quantize کریں، یا کم حجم والا build استعمال کریں۔ cores کی تعداد بڑھانے سے فائدہ نہیں ہوگا۔

لوڈ ہوتے وقت model ختم ہو جاتا ہے۔ kernel اور service log دیکھیں:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Out of memory: Killed process پر مشتمل سطر کا مطلب ہے کہ weights، KV cache اور buffers کا مجموعی حجم اس machine کی دستیاب memory سے زیادہ ہو گیا۔ swap کے بغیر VPS پر، یہ سطر ظاہر ہونے سے پہلے پوری machine کئی seconds تک رک سکتی ہے۔

جوابات خراب ہو گئے اور آپ نے کچھ تبدیل نہیں کیا۔ ایک ہی model کے دو builds مختلف tags کے تحت ollama ls میں ساتھ موجود ہو سکتے ہیں، اور جو script بغیر suffix والا نام pull کرتی ہے وہ اسی build کو استعمال کرے گی جس کی طرف library اس وقت اشارہ کر رہی ہو۔ اپنے client کی درخواست کردہ exact tag کے ساتھ ollama show چلائیں اور quantization سطر پڑھیں؛ configuration file میں موجود نام پر بھروسا نہ کریں۔

FAQ

مجھے کون سا Ollama quantization حاصل کرنا چاہیے؟

q4_K_M سے شروع کریں۔ زیادہ تر models کے لیے Ollama library اسے default tag کے طور پر فراہم کرتی ہے، اس لیے ollama pull qwen3:8b اور ollama pull qwen3:8b-q4_K_M ایک ہی file حاصل کرتے ہیں۔ q8_0 پر صرف اس وقت جائیں جب memory دستیاب ہو اور task میں چھوٹی غلطیوں کی گنجائش نہ ہو، مثلاً tool calling یا structured JSON output میں۔ جب memory budget مقرر ہو تو q4_K_M پر بڑا model عموماً q8_0 پر چھوٹے model سے بہتر کارکردگی دیتا ہے۔ اس لیے precision کے لیے اضافی RAM مختص کرنے سے پہلے اس pairing کو test کریں۔

کیا q4_K_M کا واقعی مطلب ہر weight کے لیے چار bits ہے؟

نہیں۔ Llama 3.1 8B پر پیمائش کے مطابق یہ 4.89 bits per weight ہے، کیونکہ weights کے ہر block میں اپنا scale محفوظ ہوتا ہے اور سب سے زیادہ حساس tensors کو زیادہ وسیع type میں منتقل کیا جاتا ہے۔ اسی وجہ سے Q8_0 کی پیمائش آٹھ کے بجائے 8.5 bits ہوتی ہے۔ تخمینہ لگاتے وقت measured figure استعمال کریں: parameter count کو bits per weight سے ضرب دے کر آٹھ پر تقسیم کریں، تو bytes میں file size حاصل ہوگا۔

صرف CPU والے VPS پر 8B model کو کتنی RAM درکار ہوتی ہے؟

Weights، KV cache اور اضافی گنجائش شامل کریں۔ q4_K_M پر Qwen3 8B کے weights کا حجم 5.2 GB ہے۔ default 4096 token window پر cache مزید 0.6 GB لیتا ہے، لہٰذا compute buffers اور operating system سے پہلے کم از کم تقریباً 5.8 GB درکار ہوتے ہیں۔ 32k window پر صرف cache کا حجم 4.83 GB ہے۔ مختصر window کے لیے 8 GB اور طویل window کے لیے 16 GB RAM مختص کریں۔

GPU موجود ہونے کے باوجود میرا model 100% CPU پر کیوں چل رہا ہے؟

ollama ps چلائیں اور PROCESSOR column پڑھیں۔ 100% CPU یا 48%/52% CPU/GPU جیسا split اس بات کی نشاندہی کرتا ہے کہ weights اور KV cache VRAM میں نہیں سما سکے، اس لیے Ollama نے model کا کچھ یا تمام حصہ system memory میں رکھ دیا۔ عام وجہ ایسا context window ہے جو GPU card کی گنجائش سے بڑا ہو، کیونکہ model load ہونے پر پورے window کے لیے cache allocate کیا جاتا ہے۔ OLLAMA_CONTEXT_LENGTH سے window کم کریں، cache کو نصف کرنے کے لیے OLLAMA_KV_CACHE_TYPE=q8_0 set کریں، یا چھوٹا quantization حاصل کریں۔