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 کے لیے ان دونوں اثرات کا اندازہ پہلے سے کیسے لگایا جائے، تاکہ آپ کسی ایسی فائل کو download کرنے میں بیس منٹ صرف نہ کریں جو machine میں fit ہی نہ ہو۔

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

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

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

عدد target width کو ظاہر کرتا ہے۔ q4 کا مطلب ہے کہ زیادہ تر weight tensors کو ہر ایک 4 bits پر pack کیا گیا ہے۔ q8 کا مطلب 8 bits ہے۔ fp16 بالکل quantized نہیں ہے۔ یہ 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 چار بٹ کی file کو قابلِ استعمال بناتے ہیں۔ اسی وجہ سے چار بٹ کی file میں فی weight بالکل چار bits نہیں ہوتے۔

آخری حرف mixture کو ظاہر کرتا ہے۔ S، M اور L طے کرتے ہیں کہ کتنے tensors کو target width سے زیادہ پر promote کیا جائے گا۔ q4_K_M میں rounding سے سب سے زیادہ متاثر ہونے والے tensors کو زیادہ width پر محفوظ کیا جاتا ہے، جبکہ زیادہ تر weights چار 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 print کرتا ہے۔ quantization line اس model کی اصل معلومات فراہم کرتی ہے جسے آپ نے کئی ماہ پہلے pull کیا تھا اور اب یاد نہیں کہ اسے منتخب کیا تھا۔

فی وزن بٹس سے فائل کا حجم متعین ہوتا ہے

حجم کا ہر تخمینہ ایک عدد سے شروع ہوتا ہے: پورے فائل میں اوسطاً format فی وزن کتنے بٹس استعمال کرتا ہے۔ 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
  }
]

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

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 شکل میں رہتے ہیں، اور ہر block کو استعمال کے وقت convert کیا جاتا ہے۔

ہر model size کے لیے Ollama اصل میں کیا فراہم کرتا ہے

Library زیادہ تر families کے لیے q4_K_M، q8_0 اور fp16 tags شائع کرتی ہے۔ یہ August 2026 تک Qwen3 کے sizes ہیں، جو model page پر موجود tag list سے لیے گئے ہیں۔

[
  {
    "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 download کرتا ہے جتنے ollama pull qwen3:8b-q4_K_M، کیونکہ بغیر suffix والا tag دراصل q4_K_M build ہے۔ Q4_K_M کوئی ایسا compromise نہیں جسے 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 بھی درکار ہو۔ کون سے models کس machine پر چل سکتے ہیں، اس کی وسیع تر وضاحت کے لیے دیکھیں کہ آپ کون سے 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 کے لیے memory allocate کی جاتی ہے، گفتگو کے بڑھنے کے ساتھ نہیں۔ اسی لیے ایک لفظ کے 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 memory استعمال کرتا ہے۔ 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 میں شامل کریں:

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 کے لیے یہی ترتیب لاگو ہوگی۔ کم وسائل والے server پر بڑی window استعمال کرتے وقت cache کو نصف کرنا کسی بھی دوسری واحد تبدیلی کے مقابلے میں زیادہ memory آزاد کرتا ہے۔ num_ctx ترتیب دینا اور اس کی لاگت میں window کے بارے میں مزید تفصیل موجود ہے۔

8، 16 یا 32 GB کے VPS پر کیا چل سکتا ہے

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

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

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

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

کوانٹائزیشن سب سے پہلے کس چیز کو متاثر کرتی ہے

کوانٹائزیشن کی غلطی ماڈل کے تمام کاموں میں یکساں طور پر نہیں پھیلتی۔ روانی سب سے آخر میں متاثر ہوتی ہے، اور یہی وجہ ہے کہ نقصان کو محسوس کرنا مشکل ہوتا ہے: badly quantized ماڈل اب بھی صاف جملے لکھتا ہے۔ درستگی پہلے متاثر ہوتی ہے۔ version number، API signature یا تاریخ کو بالکل درست یاد رکھنا متاثر ہوتا ہے۔ استدلال کی طویل زنجیریں متاثر ہوتی ہیں، جہاں دوسرے مرحلے کی معمولی غلطی آٹھویں مرحلے پر غلط جواب بن جاتی ہے۔ سخت output formats بھی متاثر ہوتے ہیں، جہاں ایک غلط bracket سے tool call ناکام ہو جاتی ہے۔

آخری صورت عملی جانچ ہے۔ جب ماڈل کو ایسا JSON واپس کرنا ہو جسے آپ کا code parse کرتا ہے، تو quantization کا نقصان مبہم طور پر خراب prose کے بجائے parse error کی صورت میں ظاہر ہوتا ہے؛ اس لیے آپ اسے اسی دن دیکھ لیتے ہیں۔ coding agent اس جانچ کی سب سے سخت شکل ہے، کیونکہ وہ ماڈل کو مسلسل tool calls کے ذریعے چلاتا ہے۔ اسی لیے کسی agent کو اپنے Ollama server سے منسلک کرنا ایک دن کے اندر over aggressive quantization کو ظاہر کر دے گا۔

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

جب q8_0 یا fp16 کے لیے RAM مختص کرنا مفید ہو

q8_0 اسی وقت استعمال کریں جب memory واقعی فالتو ہو اور کام میں معمولی غلطیوں کی بھی زیادہ لاگت ہو: 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 سے بہتر ہوتا ہے۔ 14B weights کے 9.3 GB کے مقابلے میں 8B weights کے 8.9 GB تقریباً اتنی ہی RAM (random access memory) استعمال کرتے ہیں، لیکن بڑے model کو زیادہ معلومات حاصل ہوتی ہیں۔ اس نتیجے کو بلا تصدیق قبول کرنے کے بجائے اپنے prompts پر آزمائیں۔

صرف CPU پر inference، memory bandwidth سے محدود ہے

زیادہ تر VPS plans میں GPU نہیں ہوتا، اس لیے model، host کے CPU کی system memory میں چلتا ہے۔ اس کے بعد generation کا انحصار arithmetic کے بجائے memory bandwidth پر ہوتا ہے، کیونکہ ایک token بنانے کے لیے ہر weight کو ایک بار پڑھنا ضروری ہے۔ اس سے ایک ایسی حد مقرر ہوتی ہے جس کا تعلق آپ کے خریدے گئے 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 تقریباً theoretical figure ہے۔ آپ کے حصے میں اس سے کم bandwidth آتی ہے، کیونکہ VPS اس bus کو machine کے دیگر تمام tenants کے ساتھ share کرتا ہے۔ اس لیے ان numbers کو ایسی ceiling سمجھیں جس تک کوئی نہیں پہنچتا۔ اہم بات trend ہے: CPU پر ہر weight کے bits نصف کرنے سے token rate تقریباً دوگنا ہو جاتا ہے۔ GPU کے بغیر machine پر quantization رفتار بڑھانے کا سب سے مؤثر طریقہ ہے۔

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

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

خود model کو quantize کرنا

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

FROM /path/to/my/model/f16

پھر model 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 کریں۔ ollama show کی quantization line سے تصدیق ہوتی ہے کہ build آپ کی مطلوبہ configuration کے مطابق مکمل ہوا ہے۔

جب مسئلہ پیدا ہو تو آپ کیا دیکھیں گے

تمام کام CPU پر ہو رہا ہے، حالانکہ آپ نے GPU کی توقع کی تھی۔ 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 شامل کرنے سے مدد نہیں ملے گی۔

Loading کے دوران 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 سے بڑھ گیا۔ ایسے VPS پر جہاں swap configured نہ ہو، اس سطر کے ظاہر ہونے سے پہلے پوری machine کئی seconds تک رک سکتی ہے۔

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

FAQ

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

q4_K_M سے شروع کریں۔ Ollama library زیادہ تر models کے لیے اسے default tag کے طور پر release کرتی ہے، اس لیے ollama pull qwen3:8b اور ollama pull qwen3:8b-q4_K_M ایک ہی file fetch کرتے ہیں۔ 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 میں promote کیا جاتا ہے۔ اسی وجہ سے Q8_0 کی مقدار آٹھ کے بجائے 8.5 bits ہے۔ تخمینہ لگاتے وقت measured figure استعمال کریں: parameter count کو bits per weight سے ضرب دیں، پھر آٹھ سے تقسیم کریں۔ حاصل شدہ مقدار bytes میں file size دیتی ہے۔

CPU-only VPS پر 8B model کے لیے کتنی RAM درکار ہے؟

Weights، KV cache اور headroom کو جمع کریں۔ 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 مختص کریں۔

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

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