AI models کو self-host کرنے کے لیے کتنی RAM چاہیے؟

کون سی AI models کو self-host کیا جا سکتا ہے، یہ کیا چیز طے کرتی ہے

آپ کون سی AI models کو self-host کر سکتے ہیں، اس کا فیصلہ ایک عدد کرتا ہے: اس machine میں موجود RAM۔ Model family اور framework کی اہمیت اس بات کے مقابلے میں بہت کم ہے کہ weights اضافی memory کی گنجائش کے ساتھ memory میں سما جاتی ہیں یا نہیں۔ یہ تحریر اسی حساب کی وضاحت کرتی ہے۔ Runtime install کرنا الگ کام ہے، جس کی وضاحت VPS پر Ollama چلانے کی guide میں کی گئی ہے۔

دو اخراجات اس کا فیصلہ کرتے ہیں۔ Weights مستقل لاگت ہیں، جو parameter count اور quantisation سے طے ہوتی ہے۔ Context window جاری رہنے والی لاگت ہے، اور لوگ اسے اس وقت تک بھولے رہتے ہیں جب تک وہ model، جو کل load ہو گیا تھا، آج load ہونے سے انکار نہ کر دے۔

حساب کا اصول: ہر parameter کے لیے bits

Model file تقریباً مکمل طور پر weights پر مشتمل ہوتی ہے۔ ہر weight کو مخصوص تعداد میں bits پر محفوظ کیا جاتا ہے۔ Quantisation کا مطلب ہے کہ weights کو اس precision سے کم bits پر محفوظ کیا جائے جس پر انہیں train کیا گیا تھا۔ اس سے accuracy میں معمولی کمی آتی ہے، لیکن memory کی بچت بہت زیادہ ہوتی ہے۔ حجم براہِ راست اس اصول کے مطابق ہوتا ہے:

weights in GB = (parameters in billions x bits per weight) / 8

Models کو 16 bits پر release کیا جاتا ہے، یعنی ہر ایک billion parameters کے لیے 2 GB۔ اسی لیے تقریباً کوئی بھی VPS پر release precision استعمال نہیں کرتا۔ درج ذیل quantisations آپ کو عملاً ملیں گی، اور ان میں ہر weight کے لیے حقیقی اوسط bits یہ ہیں:

• Q8_0 ہر weight کے لیے تقریباً 8.5 bits محفوظ کرتا ہے، یعنی ہر ایک billion parameters کے لیے تقریباً 1.1 GB۔
• Q6_K 6.6 bits محفوظ کرتا ہے، یعنی ہر ایک billion کے لیے تقریباً 0.83 GB۔
• Q5_K_M 5.7 bits محفوظ کرتا ہے، یعنی ہر ایک billion کے لیے تقریباً 0.71 GB۔
• Q4_K_M 4.8 bits محفوظ کرتا ہے، یعنی ہر ایک billion کے لیے تقریباً 0.6 GB۔

اپنے حساب کے لیے ہر ایک billion parameters کے لیے 0.6 GB استعمال کریں۔ Memory bound box پر Q4_K_M ایک مناسب default ہے: زیادہ تر tasks میں 8 bits کے مقابلے میں quality loss کم ہوتا ہے، جبکہ file کا حجم تقریباً نصف رہ جاتا ہے۔ 4 bits سے کم پر loss تیزی سے بڑھتا ہے، اس لیے اسی generation کے 4 bits والے 32B model کے مقابلے میں 2 bits تک محدود کیا گیا 70B عموماً کم بہتر جواب دیتا ہے۔ جب memory کم ہو تو 4 bits سے نیچے جانے کے بجائے ایک size class کم کریں۔

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

اوپر دیا گیا weight column اسی 0.6 GB فی billion کے اصول کے مطابق ہے۔ حقیقی GGUF files اس قدر سے چند فیصد کے اندر رہتی ہیں، کیونکہ embedding اور output layers کو باقی layers کے مقابلے میں زیادہ precision پر رکھا جاتا ہے۔ 4 bits والا 3B model تقریباً 1.8 GB ہوتا ہے۔ 8B تقریباً 4.8 GB ہوتا ہے۔ 32B تقریباً 19.2 GB ہوتا ہے، اور 70B تقریباً 42 GB ہوتا ہے۔

کیوں context length کے لیے weights سے زیادہ RAM درکار ہوتی ہے

KV cache (key value cache، یعنی attention state جسے model گفتگو میں موجود ہر token کے لیے محفوظ رکھتا ہے) دوسرا بڑا خرچ ہے۔ Model load ہونے پر یہ allocate ہوتا ہے، آپ کی مقرر کردہ context length کے مطابق اس کا سائز طے ہوتا ہے، اور یہ length کے ساتھ خطی طور پر بڑھتا ہے۔

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Ollama کی default context میں یہ 8B model cache کے لیے آدھا gigabyte استعمال کرتا ہے۔ 8192 tokens پر یہ 1 GB استعمال کرتا ہے۔ اس کے model card میں درج 128k context پر یہ 16 GB استعمال کرتا ہے، جو weights سے تین گنا سے بھی زیادہ ہے۔ 70B کے معاملے میں صورتِ حال مختلف ہے: 128k پر اس کا cache 40 GB ہے، جو اس کے اپنے weights سے کم ہے، کیونکہ grouped query attention فی token لاگت کو parameter count جتنی تیزی سے بڑھنے نہیں دیتا۔

CPU only server پر Ollama کی default context length 4096 tokens ہے۔ GPU موجود ہو تو یہ VRAM کے مطابق default منتخب کرتا ہے: 24 سے 48 GiB کے درمیان 32k، اور 48 GiB یا اس سے زیادہ پر 256k۔ Server پر OLLAMA_CONTEXT_LENGTH variable کے ذریعے اسے بڑھائیں، پھر ollama ps کے CONTEXT column میں دیکھیں کہ چلتے ہوئے model کو حقیقت میں کون سی قدر ملی ہے۔ اس setting کے پیچھے memory کا حساب num_ctx اور context length پر موجود تحریر میں تفصیل سے بیان کیا گیا ہے۔

Cache کو دوبارہ کم کرنے کے دو طریقے ہیں۔ Model card میں دی گئی context کے بجائے اپنی مطلوبہ context مانگیں، کیونکہ زیادہ تر chat اور coding کا کام 8k سے 32k کے اندر مکمل ہو جاتا ہے۔ یا خود cache کو 8 bits پر quantise کریں، جس سے اس کا سائز آدھا ہو جاتا ہے، لیکن long context recall میں کچھ کمی آ سکتی ہے۔

ایک resident model اس وقت تک RAM میں رہتا ہے جب تک کوئی اسے unload نہ کرے

Ollama آخری request کے بعد 5 منٹ تک model کو memory میں رکھتا ہے، پھر اسے unload کر دیتا ہے۔ یہ default laptop کے لیے مناسب ہے، لیکن server کے لیے درست نہیں، کیونکہ ہر idle gap کے بعد آنے والی پہلی request کو دوبارہ load time برداشت کرنا پڑتا ہے۔

ollama ps
ollama stop qwen3:4b

ollama ps resident models کی فہرست دکھاتا ہے۔ اس میں موجود SIZE column بتاتا ہے کہ model کتنی memory استعمال کر رہا ہے، جبکہ UNTIL column اس کے expire ہونے کا وقت دکھاتا ہے۔ کسی model کو مستقل طور پر memory میں رکھنے کے لیے service پر OLLAMA_KEEP_ALIVE=-1 set کریں۔ 0 کی value ہر response مکمل ہوتے ہی اسے unload کر دیتی ہے۔

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

ایک prompt بھیجیں، پھر 10 منٹ بعد دوبارہ ollama ps چلائیں۔ Model اب بھی فہرست میں موجود ہوگا۔ یہی مقصد ہے: service اسے استعمال کرنے والا کوئی نہ بھی ہو، پھر بھی وہ RAM استعمال کر رہا ہے۔ Pinned model spare capacity نہیں ہوتا۔ 16 GB VPS پر 8B model، 8k context کے ساتھ، service کے چلنے تک تقریباً 6 GB استعمال کرتا ہے۔ اس لیے server کا سائز model اور آپ کی application دونوں کو مدنظر رکھ کر طے کریں، صرف model کو نہیں۔ Memory میں model کو pinned رکھنا cold start latency کے مقابل اس trade-off کی وضاحت کرتا ہے۔

4 GB VPS پر کیا چلتا ہے

Operating system اور model server کے لیے تقریباً 1 GB مختص کریں۔ اس سے تقریباً 3 GB باقی رہتے ہیں۔ یہ default 4096 token context پر 4 bits میں 1B سے 4B model کے لیے کافی ہے۔ August 2026 تک اس زمرے میں 3B کا Llama 3.2، 1.7B اور 4B کے Qwen 3، اور چھوٹے Gemma اور Phi releases شامل ہیں۔ انہیں سفارشات نہیں بلکہ سائز کی مثالیں سمجھیں۔ ماڈل کے نام ہر چند ماہ بعد بدلتے رہتے ہیں، لیکن حساب تبدیل نہیں ہوتا۔

تقریباً 6 سے 14 tokens per second کی توقع رکھیں۔ اتنے چھوٹے models محدود نوعیت کے کام اچھی طرح کرتے ہیں، مثلاً classification، tag extraction، مختصر summaries، اور کسی paragraph کو house style کے مطابق دوبارہ لکھنا۔ multi step reasoning اور کئی files پر پھیلے ہوئے code میں یہ کمزور ہوتے ہیں۔ prompting کی کوئی مقدار اس مسئلے کو حل نہیں کرتی۔

اس درجے پر عام failure mode swap ہے۔ اگر model memory میں fit نہ ہو تو Linux اسے load کرنے سے انکار نہیں کرتا۔ اس کے بجائے وہ memory کو disk پر page out کرتا ہے۔ ایک token generate کرنے کے لیے ہر weight کو ایک بار پڑھنا پڑتا ہے، اس لیے generation کی رفتار کم ہو کر فی token کئی seconds تک پہنچ جاتی ہے۔ Model کے جواب دینے کے دوران free -h اور vmstat 1 کے si اور so columns monitor کریں۔ Generation کے دوران swap in اور swap out کی non zero مقدار کا مطلب ہے کہ model اس plan کے لیے بہت بڑا ہے۔

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

یہ وہ سطح ہے جہاں self-hosted model عام استعمال کے لیے واقعی مفید ہو جاتا ہے۔ 8 GB پر آپ 4 bits میں 7B یا 8B model چلا سکتے ہیں، جس کے weights تقریباً 4.8 GB ہوتے ہیں، اور 8k context رکھ سکتے ہیں۔ 16 GB پر آپ 4 bits میں 13B یا 14B model چلا سکتے ہیں، جس کے weights تقریباً 8.4 GB ہوتے ہیں۔ اگر آپ parameter count کے بجائے precision کو ترجیح دینا چاہیں تو 8B model کو 8 bits پر بھی چلا سکتے ہیں۔

اصل مسئلہ رفتار ہے۔ CPU پر 8B model تقریباً 3 سے 7 tokens فی second generate کرتا ہے، جبکہ 14B model تقریباً 1.5 سے 3.5 tokens فی second generate کرتا ہے۔ انسان تقریباً 5 سے 10 tokens فی second پڑھتا ہے، اس لیے CPU VPS پر 8B model ایسے محسوس ہوتا ہے جیسے کوئی بہت سست رفتار سے ٹائپ کر رہا ہو۔ background job کے لیے یہ رفتار قابل قبول ہے، لیکن interactive chat کے لیے تھکا دینے والی ہے۔ VPS پر Qwen 3 کے 8B اور اس سے بڑے models کے عملی نتائج سے معلوم ہوتا ہے کہ عملی طور پر کارکردگی کیسی رہتی ہے۔

32 سے 64 GB VPS پر کیا چلتا ہے

4 bits پر 32B کا حجم تقریباً 19.2 GB ہوتا ہے، اس لیے یہ مختصر context کے ساتھ 32 GB plan میں فٹ ہو جاتا ہے اور 48 GB یا 64 GB پر آرام سے چلتا ہے۔ 4 bits پر 70B کا حجم تقریباً 42 GB ہوتا ہے، اس لیے اسے کسی بھی cache کے اضافے سے پہلے ہی 64 GB درکار ہوتی ہے۔

اس کے بعد رفتار کا حقیقت پسندانہ جائزہ لیں۔ CPU پر 32B تقریباً 0.6 سے 1.5 tokens فی second کی رفتار سے چلتا ہے، جبکہ 70B کی رفتار 0.2 سے 0.5 tokens فی second ہوتی ہے۔ 70B سے 500 tokens کا جواب تیار ہونے میں تقریباً بیس منٹ لگتے ہیں۔ یہ batch tools ہیں۔ اگر آپ انہیں رات بھر documents کی queue دیں تو رفتار اہم نہیں رہتی۔ انہیں chat window کے پیچھے رکھیں تو رفتار بہت اہم ہو جاتی ہے۔

Mixture of experts routing اس حساب کو بدل دیتی ہے، اور یہی architecture کی وہ تفصیل ہے جسے سمجھنا مفید ہے۔ MoE model ہر token کو اپنے weights کے صرف ایک چھوٹے حصے سے گزارتا ہے۔ 30B total parameters اور ہر token کے لیے 3B active parameters والا model، memory کے لحاظ سے 30B کے برابر درکار ہوتا ہے اور رفتار کے لحاظ سے تقریباً dense 3B کے قریب رہتا ہے، کیونکہ ہر token صرف active experts کو پڑھتا ہے۔ 32 GB کے server پر اس ساخت والا MoE، dense 30B کے مقابلے میں کہیں زیادہ قابلِ استعمال ہوتا ہے۔ یاد رکھنے کا اصول یہ ہے: total parameters memory طے کرتے ہیں، جبکہ active parameters رفتار طے کرتے ہیں۔

CPU inference کی رفتار حقیقتاً کتنی ہے؟

ایک token بنانے کے لیے ہر فعال weight کو memory سے ایک بار پڑھنا ضروری ہے۔ اس سے بچنے کا کوئی طریقہ نہیں۔ اس لیے CPU پر generation speed کا تعین core count نہیں بلکہ memory bandwidth کرتی ہے۔ زیادہ سے زیادہ رفتار کا حساب usable memory bandwidth کو weights کے byte size سے تقسیم کرکے کیا جا سکتا ہے۔ ایک چھوٹا shared VPS اپنے vCPUs کے درمیان عموماً 10 سے 25 GB فی سیکنڈ فراہم کرتا ہے، اس لیے 4.8 GB model کی زیادہ سے زیادہ رفتار تقریباً 2 سے 5 tokens فی سیکنڈ ہوتی ہے۔

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

یہ ranges عام VPS hardware پر عموماً رپورٹ کی جاتی ہیں، کسی ایک machine کا benchmark نہیں ہیں۔ آپ کا نتیجہ memory generation، host پر channels کی تعداد، اور اس memory کو استعمال کرنے والے neighbours کی تعداد پر منحصر ہوتا ہے۔ اپنے موجودہ کسی بھی model tag سے خود پیمائش کریں:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

جواب ختم ہونے کے بعد چھپنے والے summary میں ایک سطر eval rate: ... tokens/s لکھی ہوتی ہے۔ یہی آپ کی generation speed ہے۔ session کے پہلے run کو نظرانداز کریں، کیونکہ اسی summary میں load duration کو disk سے weights پڑھنے کا وقت بھی شامل ہوتا ہے۔ tokens فی سیکنڈ کی درست پیمائش میں بتایا گیا ہے کہ موازنے کے قابل نتیجہ کیسے حاصل کریں۔

یہاں دو نتائج لوگوں کو حیران کرتے ہیں۔ vCPUs شامل کرنے سے فائدہ جلد ختم ہو جاتا ہے، کیونکہ تقریباً 8 cores کے بعد اضافی cores arithmetic کرنے کے بجائے memory کا انتظار کر رہے ہوتے ہیں۔ Shared plan پر یہی command مختلف اوقات میں مختلف numbers واپس کرتی ہے۔ یہ noisy neighbour کی CPU steal time کی وجہ سے ہوتا ہے، نہ کہ کسی غلط configuration کی وجہ سے۔

اپنے prompt کو پڑھنا جواب generate کرنے سے مختلف کام ہے۔ Prompt processing compute bound ہوتی ہے، اس لیے cores کی تعداد بڑھنے سے اس کی رفتار بھی بڑھتی ہے۔ یہی وہ مرحلہ ہے جس میں GPU سب سے زیادہ آگے نکلتا ہے۔ ایک طویل document پڑھنے میں CPU کو minutes لگ سکتے ہیں، جبکہ GPU اسے seconds میں پڑھ لیتا ہے۔ جب آپ اپنے host کیے ہوئے model پر coding agent چلاتے ہیں تو یہی پہلی بڑی رکاوٹ بنتی ہے، کیونکہ جواب کا ایک بھی token واپس آنے سے پہلے ہر turn میں file context اور tool definitions دوبارہ بھیجنی پڑتی ہیں۔

GPU شامل کرنے پر کیا تبدیلی آتی ہے

حساب تبدیل نہیں ہوتا، صرف وہ pool تبدیل ہوتا ہے جس پر یہ لاگو ہوتا ہے۔ VRAM ایک سخت حد ہے، اس لیے server کرائے پر لینے سے پہلے معلوم کریں کہ کیا فٹ ہوتا ہے:

• 8 GB کی VRAM مختصر context کے ساتھ 4 bits پر 7B یا 8B کو رکھ سکتی ہے۔
• 16 GB کی VRAM حقیقی context کے ساتھ 4 bits پر 14B، یا 8 bits پر 8B کو رکھ سکتی ہے۔
• 24 GB کی VRAM مختصر context کے ساتھ 4 bits پر 32B کو رکھ سکتی ہے۔
• 48 GB یا اس سے زیادہ کی VRAM cache اور concurrency کی گنجائش کے ساتھ 4 bits پر 70B کو رکھ سکتی ہے۔

جب کوئی model فٹ نہ ہو تو Ollama اسے تقسیم کر دیتا ہے: کچھ layers GPU پر اور باقی CPU پر چلی جاتی ہیں۔ ollama ps یہ تقسیم اپنے PROCESSOR column میں، مثلاً 78%/22% CPU/GPU کی شکل میں، دکھاتا ہے۔ اسے feature کے بجائے warning سمجھیں۔ رفتار CPU والے حصے سے متعین ہوتی ہے، کیونکہ ہر token کو اب بھی ان layers کا انتظار کرنا پڑتا ہے۔ اس لیے جس model کی ایک چوتھائی layers CPU پر ہوں، اس کی رفتار GPU کے بجائے CPU کی رفتار کے زیادہ قریب ہوتی ہے۔ اگر ایسی تقسیم نظر آئے جس کا آپ نے ارادہ نہیں کیا تھا تو پہلے context length کم کریں۔ عموماً cache ہی اضافی memory استعمال کرنے کی وجہ بنتی ہے۔

Concurrency capacity بڑھانے کی ایک اور وجہ ہے۔ بیک وقت آنے والی requests کے درمیان weights مشترک ہوتے ہیں، لیکن ہر active request کو اپنا KV cache درکار ہوتا ہے۔ اس لیے 8k context پر 8B model کے دس concurrent users کو weights کے علاوہ cache کے لیے 1 GB کا دس گنا درکار ہوتا ہے۔ ایک self-hosted model سے concurrent users کو service دینا یہ واضح کرتا ہے کہ یہ حد کہاں آتی ہے۔

GPU کرائے پر لینا فائدہ مند ہے یا نہیں، یہ بھی حساب کا سوال ہے، اور اس کا انحصار اس بات پر ہے کہ آپ واقعی ہر ماہ کتنے tokens generate کرتے ہیں۔ GPU VPS اور API tokens کے درمیان break even میں یہ اعداد موجود ہیں۔

آپ خود کیا self-host نہیں کر سکتے

یہاں دو الگ رکاوٹیں ہیں، اور یہ جاننا مفید ہے کہ آپ کو کس رکاوٹ کا سامنا ہے۔

پہلی رکاوٹ closed weights ہیں۔ Frontier commercial models تقسیم نہیں کیے جاتے، اس لیے download کرنے کے لیے کوئی file موجود نہیں ہوتی، اور RAM کی مقدار بڑھانے سے بھی یہ مسئلہ حل نہیں ہوتا۔ آپ ان کے گرد موجود ہر چیز self-host کر سکتے ہیں: interface، retrieval layer، agent loop اور logs۔ خود model ایک remote API ہی رہتا ہے۔ Claude کو self-host کرنے کے امکانات میں اس کی مکمل وضاحت موجود ہے۔

دوسری رکاوٹ open weights ہیں جو عملی طور پر بہت بڑے ہوتے ہیں۔ سب سے بڑے open releases، mixture of experts designs ہوتے ہیں جن کے total parameters سیکڑوں ارب ہوتے ہیں۔ ان پر بھی یہی اصول لاگو ہوتا ہے: 4 bits پر 400B total parameter model کو صرف weights کے لیے تقریباً 240 GB درکار ہوتے ہیں، کسی cache کے بغیر۔ اس کے لیے specialist hardware چاہیے، اور اسے ماہانہ کرائے پر لینا API tokens پر ایک سال میں زیادہ تر لوگوں کے خرچ سے کہیں مہنگا ہوتا ہے۔ Kimi class model کو self-host کرنے کے تقاضے میں حقیقی requirements کی وضاحت کی گئی ہے۔

دونوں کے درمیان دیانت دارانہ اصول یہ ہے: جب load مستقل ہو اور data کو آپ کے server سے باہر نہیں جانا چاہیے تو self-host کریں۔ جب load bursty ہو، یا آپ کو دراصل frontier answer quality درکار ہو، تو tokens خریدیں۔

انتخاب کرنے سے پہلے دستیاب وسائل کی جانچ کریں

free -h
nproc
lscpu | grep 'Model name'

free -h کے available کالم کے مطابق منصوبہ بنائیں، total کالم کے مطابق نہیں، کیونکہ total میں وہ memory بھی شامل ہے جسے system پہلے ہی استعمال کر رہا ہے۔ operating system اور model server کے لیے تقریباً 1 GB کم کریں۔ 4 bits پر قابلِ استعمال زیادہ سے زیادہ parameter count، اربوں میں، معلوم کرنے کے لیے باقی مقدار کو 0.6 سے تقسیم کریں۔ اس کے بعد مطلوبہ context کے لیے KV cache کو منہا کریں۔ جو مقدار باقی بچے، وہی آپ کا جواب ہے۔ model names کی فہرست کے برعکس یہ جواب وقت کے ساتھ پرانا نہیں ہوتا۔

FAQ

8B ماڈل چلانے کے لیے کتنی RAM درکار ہے؟

4 bit quantisation پر weights کے لیے تقریباً 4.8 GB درکار ہوتے ہیں۔ اس کے علاوہ آپ کی context length کے لیے KV cache، اور operating system اور model server کے لیے تقریباً 1 GB درکار ہوتا ہے۔ 8192 token context پر cache میں تقریباً 1 GB کا اضافہ ہوتا ہے، اس لیے 8 GB plan کام کرتا ہے، لیکن 4 GB plan نہیں۔ اگر آپ model card میں بتائی گئی مکمل 128k context استعمال کرنا چاہتے ہیں تو صرف cache کے لیے 16 GB درکار ہوں گے، اور آپ کو 32 GB plan لینا ہوگا۔

VPS میں کافی vCPUs ہونے کے باوجود میرا model سست کیوں ہے؟

کیونکہ generation کا انحصار cores کے بجائے memory bandwidth پر ہوتا ہے۔ ہر token کے لیے پورے active weight set کو RAM سے پڑھنا پڑتا ہے۔ اس لیے چند cores کے memory channels بھر جانے کے بعد باقی cores انتظار کرتے ہیں۔ دوسری عام وجہ swap ہے۔ اگر model جواب دے رہا ہو اور vmstat 1 میں non zero si اور so دکھائی دیں تو weights RAM میں پوری طرح fit نہیں ہو رہے۔ ہر token کا کچھ حصہ disk سے فراہم ہو رہا ہے، جس کی لاگت بظاہر توقع سے کہیں زیادہ ہوتی ہے۔

کیا طویل context window کے لیے واقعی زیادہ memory درکار ہوتی ہے؟

ہاں، اور tokens کی تعداد کے ساتھ یہ اضافہ linear ہوتا ہے۔ ایک عام 8B model تقریباً 128 KiB KV cache فی token استعمال کرتا ہے۔ اس لیے 8192 tokens کے لیے 1 GB اور 131072 tokens کے لیے 16 GB درکار ہوتے ہیں۔ Cache model load ہوتے وقت allocate ہوتی ہے، conversation کے بڑھنے پر نہیں۔ اس لیے 128k context منتخب کرنے سے memory فوراً reserve ہو جاتی ہے، چاہے آپ کا ہر prompt صرف 200 tokens کا ہو۔

کیا مجھے بڑا model 2 bits پر یا چھوٹا model 4 bits پر چلانا چاہیے؟

4 bits پر چھوٹا model منتخب کریں۔ 8 bits سے 4 bits تک quality آہستہ کم ہوتی ہے، لیکن 4 bits سے نیچے تیزی سے کم ہوتی ہے۔ اس لیے عموماً اسی model generation کے 70B model کو 2 bits پر دبانے سے 32B model کو 4 bits پر چلانے کے مقابلے میں خراب answers ملتے ہیں۔ Heavy quantisation repetition اور instructions نظر انداز ہونے کی صورت میں ظاہر ہوتی ہے، error message کی صورت میں نہیں۔ اس لیے الزام prompt پر ڈالنا آسان ہوتا ہے۔ 4 bits کو کم از کم حد سمجھیں اور اس کے بجائے parameter count تبدیل کریں۔

کیا میں اتنی صلاحیت رکھنے والا model self-host کر سکتا ہوں جتنی بڑے commercial models میں ہوتی ہے؟

عام VPS پر نہیں۔ سب سے مضبوط open weight models میں hundreds of billions parameters ہوتے ہیں۔ 4 bits پر بھی KV cache کے بغیر 200 GB سے زیادہ RAM درکار ہوتی ہے، جبکہ سب سے مضبوط commercial models بالکل distributed نہیں کیے جاتے۔ عام hardware کسی ایک مخصوص کام کے لیے اچھا 8B سے 32B model چلا سکتا ہے۔ ایسے کام میں narrow اور اچھی طرح prompted چھوٹا model اکثر general model کے برابر نتائج دیتا ہے۔ اگر آپ کو frontier quality درکار ہے تو hardware خریدنے سے پہلے API کی لاگت کا hardware کے ساتھ موازنہ کریں۔