اپنی VPS پر کون سی AI models خود چلائی جا سکتی ہیں؟

کون سی AI models آپ self-host کر سکتے ہیں، یہ کیا طے کرتا ہے

آپ کون سی AI models self-host کر سکتے ہیں، اس کا فیصلہ ایک عدد کرتا ہے: box میں موجود RAM۔ Model family اور framework کی اہمیت اس بات کے مقابلے میں بہت کم ہے کہ weights میموری میں اضافی گنجائش کے ساتھ fit ہوتی ہیں یا نہیں۔ یہ تحریر اسی حساب کا طریقہ بیان کرتی ہے۔ 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۔ کچھ models پہلے ہی جزوی طور پر quantised ہوتے ہیں۔ مثال کے طور پر OpenAI's gpt-oss کو post-training کے دوران اس کے mixture of experts weights کے لیے 4 bit MXFP4 کے ساتھ تیار کیا گیا تھا۔ بہرحال، تقریباً کوئی بھی شخص VPS پر 16 bit weights نہیں چلاتا۔ آپ کو عموماً یہ 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 کا 2 bits پر چلنے والا 70B عموماً 4 bits والے 32B سے بدتر جواب دیتا ہے۔ جب 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 میں ہر billion کے لیے 0.6 GB والا اصول استعمال کیا گیا ہے۔ حقیقی 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 ہوتا ہے۔

سیاق کی لمبائی 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 میں دیکھیں کہ running model کو حقیقتاً کیا value ملی۔ اس setting کے پیچھے موجود memory arithmetic 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 کے بعد model کو 5 منٹ تک memory میں رکھتا ہے، پھر اسے unload کر دیتا ہے۔ یہ default laptop کے لیے مناسب ہے، لیکن server کے لیے درست نہیں، کیونکہ ہر idle gap کے بعد پہلی request کو دوبارہ load time ادا کرنا پڑتا ہے۔

ollama ps
ollama stop qwen3:4b

ollama ps resident models کی فہرست دکھاتا ہے۔ اس میں SIZE column موجود memory کی مقدار دکھاتا ہے، جبکہ UNTIL column بتاتا ہے کہ model کب 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 اب بھی فہرست میں موجود ہوگا۔ یہی مقصد ہے: کوئی اسے استعمال کر رہا ہو یا نہیں، وہ RAM روکے رکھتا ہے۔ pinned model اضافی capacity نہیں ہوتا۔ 16 GB VPS پر 8B model، 8k context کے ساتھ، service چلنے تک تقریباً 6 GB memory استعمال کرتا ہے۔ اس لیے server کی گنجائش model کے ساتھ اپنی application کو مدنظر رکھ کر طے کریں، صرف model کے مطابق نہیں۔ model کو memory میں pin کرنا 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 کے مطابق rewrite کرنا۔ یہ multi step reasoning اور کئی files پر پھیلے ہوئے code میں کمزور ہوتے ہیں، اور prompting کی کوئی مقدار اس کمزوری کو دور نہیں کرتی۔

اس سطح پر بنیادی failure mode swap ہے۔ اگر model fit نہ ہو تو Linux اسے load کرنے سے انکار نہیں کرتا۔ اس کے بجائے وہ memory کو disk پر page out کرتا ہے۔ چونکہ ایک token generate کرنے کے لیے ہر weight کو ایک بار پڑھنا پڑتا ہے، اس لیے generation کی رفتار کم ہو کر ہر token کے لیے کئی seconds تک پہنچ جاتی ہے۔ Model کے جواب دیتے وقت free -h اور vmstat 1 کے si اور so columns کو monitor کریں۔ vmstat کے output کی پہلی line نظرانداز کریں، کیونکہ وہ boot کے بعد سے ہر چیز کا average دکھاتی ہے۔ یہ بھی یاد رکھیں کہ counters پورے system کا احاطہ کرتے ہیں، صرف model کا نہیں۔ اگر box idle ہونے پر swap in اور swap out zero ہوں، لیکن generation شروع ہوتے ہی بڑھ جائیں، تو اس کا مطلب ہے کہ model اس plan کے لیے بہت بڑا ہے۔

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

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

اصل رکاوٹ رفتار ہے۔ CPU پر 8B تقریباً 3 سے 7 tokens فی second پیدا کرتا ہے، جبکہ 14B تقریباً 1.5 سے 3.5 tokens فی second پیدا کرتا ہے۔ انسان تقریباً 5 سے 10 tokens فی second پڑھتا ہے، اس لیے CPU VPS پر 8B ایسے محسوس ہوتا ہے جیسے کوئی سست رفتار ٹائپسٹ لکھ رہا ہو۔ 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 ہوتا ہے۔ یہ اسی حساب کے مطابق ہے جس میں Ollama، Q4_K_M پر Llama 3.3 70B کے لیے 43 GB بتاتا ہے۔ لہٰذا یہ مختصر context کے ساتھ 48 GB plan میں بمشکل آتا ہے، جبکہ اس سے طویل context کے لیے 64 GB درکار ہوتی ہے۔

پھر رفتار کو حقیقت پسندانہ طور پر دیکھیں۔ CPU پر 32B تقریباً 0.6 سے 1.5 tokens فی second کی رفتار سے چلتا ہے، جبکہ 70B کی رفتار 0.2 سے 0.5 tokens فی second ہوتی ہے۔ اس 70B سے 500 tokens کا جواب تیار ہونے میں تقریباً بیس منٹ لگتے ہیں۔ اس رفتار پر request عموماً model کے مکمل ہونے سے پہلے ختم ہو جاتی ہے، کیونکہ Ollama کے سامنے موجود کوئی client یا proxy timeout پہلے فعال ہو جاتا ہے۔ اسی وجہ سے context deadline exceeded error ظاہر ہوتی ہے۔ یہ 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 model جتنی memory لیتا ہے اور رفتار کے لحاظ سے dense 3B کے قریب رہتا ہے، کیونکہ ہر token صرف active experts کو پڑھتا ہے۔ 32 GB box پر اس ساخت کا MoE، dense 30B کے مقابلے میں کہیں زیادہ قابل استعمال ہوتا ہے۔ یاد رکھنے کا اصول یہ ہے: total parameters memory طے کرتے ہیں، جبکہ active parameters رفتار طے کرتے ہیں۔

CPU inference حقیقت میں کتنی تیز ہوتی ہے؟

ایک token بنانے کے لیے memory سے تمام active weights کو ایک بار پڑھنا ضروری ہے۔ اس عمل سے بچنے کا کوئی طریقہ نہیں، اس لیے CPU پر generation speed کا تعین core count نہیں بلکہ memory bandwidth کرتی ہے۔ زیادہ سے زیادہ رفتار کا حساب usable memory bandwidth کو weights کے سائز، یعنی bytes میں، تقسیم کر کے لگایا جاتا ہے۔ ایک چھوٹا 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
  }
]

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

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

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

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

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

جب آپ GPU شامل کرتے ہیں تو کیا تبدیل ہوتا ہے

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

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

جب کوئی model fit نہیں ہوتا تو 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 ہی اسے حد سے آگے لے جاتی ہے۔

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

GPU کو rent پر لینا مفید ہے یا نہیں، یہ بھی حساب کا سوال ہے۔ فیصلہ اس بات پر ہوتا ہے کہ آپ حقیقت میں ہر ماہ کتنے 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 کرنے کے لیے درکار وسائل میں اصل تقاضوں کی وضاحت ہے۔ یہی فرق Ollama کی اپنی library میں بھی نظر آتا ہے، جہاں GLM 5.2 صرف cloud model کے طور پر درج ہے اور اس کا ایک بہت چھوٹا sibling ہی وہ model ہے جو حقیقتاً VPS پر download ہوتا ہے۔

دونوں کے درمیان عملی اصول یہ ہے: جب 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، billions میں معلوم کرنے کے لیے باقی مقدار کو 0.6 سے تقسیم کریں۔ پھر مطلوبہ context کے لیے KV cache منہا کریں۔ جو مقدار باقی بچے، وہ آپ کا جواب ہے۔ model names کی فہرست کے برعکس یہ جواب پرانا نہیں ہوتا۔

FAQ

8B model چلانے کے لیے کتنی 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 weights کا پورا set RAM سے پڑھنا پڑتا ہے۔ چند cores کے memory channels کو بھر دینے کے بعد باقی cores انتظار کرتے ہیں۔ دوسری عام وجہ swap ہے۔ اگر prompt بھیجنے سے پہلے vmstat 1 میں si اور so صفر دکھیں، اور model کے جواب دیتے وقت ان کی قدر بڑھنے لگے، تو غالب امکان ہے کہ weights RAM میں فٹ نہیں ہو رہے۔ اس صورت میں ہر token کا کچھ حصہ disk سے فراہم ہوتا ہے، جس کی لاگت توقع سے کہیں زیادہ ہوتی ہے۔

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

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

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

4 bits پر چھوٹا model منتخب کریں۔ 8 bits سے 4 bits تک quality آہستہ کم ہوتی ہے، لیکن 4 bits سے نیچے تیزی سے کم ہوتی ہے۔ اس لیے 70B model کو 2 bits تک محدود کرنے سے عموماً اسی model generation کے 4 bits پر چلنے والے 32B model کے مقابلے میں خراب جوابات ملتے ہیں۔ Heavy quantisation error message کے بجائے repetition اور instructions نظرانداز ہونے کی صورت میں ظاہر ہوتی ہے۔ اس لیے مسئلہ 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 بالکل distribute نہیں کیے جاتے۔ عام hardware ایک مخصوص کام کے لیے اچھا 8B سے 32B model چلا سکتا ہے۔ ایسے کام میں محدود دائرہ کار اور اچھی طرح لکھا ہوا prompt رکھنے والا چھوٹا model اکثر general model جیسی کارکردگی دے سکتا ہے۔ اگر آپ کو frontier quality درکار ہے تو hardware خریدنے سے پہلے API کی قیمت کا hardware کی لاگت سے موازنہ کریں۔