اپنی 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 کا مطلب ہے کہ انہیں training کے دوران استعمال ہونے والی precision سے کم bits پر محفوظ کیا جائے۔ اس سے accuracy میں معمولی کمی آتی ہے، لیکن memory کی بچت بہت زیادہ ہوتی ہے۔ Size براہِ راست اس اصول کے مطابق ہوتا ہے:

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

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

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

اپنے عملی حساب کے لیے ہر 1 billion parameters پر 0.6 GB استعمال کریں۔ Memory-bound server پر Q4_K_M ایک مناسب default ہے: زیادہ تر tasks میں 8 bits کے مقابلے میں quality loss معمولی ہوتا ہے، جبکہ file تقریباً نصف size کی ہوتی ہے۔ 4 bits سے کم پر loss تیزی سے بڑھتا ہے۔ اس لیے ایک ہی generation کے 70B model کو 2 bits پر compress کرنے کے بجائے 32B model کو 4 bits پر استعمال کرنا عموماً بہتر جواب دیتا ہے۔ جب 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 ہر 1 billion parameters کے لیے 0.6 GB کے اصول پر مبنی ہے۔ حقیقی GGUF files اس مقدار سے چند فیصد کے اندر رہتی ہیں، کیونکہ embedding اور output layers کو باقی layers کے مقابلے میں زیادہ precision پر رکھا جاتا ہے۔ 4 bits والا 3B model تقریباً 1.8 GB کا ہوتا ہے۔ 8B model 4.8 GB کا ہوتا ہے۔ 32B model 19.2 GB کا ہوتا ہے، جبکہ 70B model 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 پر کیا چل سکتا ہے

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

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

اس tier میں بنیادی failure mode swap ہے۔ اگر model کے لیے کافی memory نہ ہو تو 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 چلا سکتے ہیں، جس کے 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 ماڈل کے weights تقریباً 19.2 GB ہوتے ہیں، اس لیے یہ مختصر context کے ساتھ 32 GB plan میں آ جاتا ہے اور 48 GB یا 64 GB پر آرام سے چلتا ہے۔ 4 bits پر 70B ماڈل کے weights تقریباً 42 GB ہوتے ہیں، اس لیے کسی بھی cache کو شامل کرنے سے پہلے ہی اسے 64 GB درکار ہوتی ہے۔

پھر رفتار کا حقیقت پسندانہ اندازہ لگائیں۔ CPU پر 32B ماڈل تقریباً 0.6 سے 1.5 tokens فی سیکنڈ پیدا کرتا ہے، جبکہ 70B ماڈل 0.2 سے 0.5 tokens فی سیکنڈ کی رفتار دیتا ہے۔ اس 70B ماڈل سے 500 tokens کا جواب تیار ہونے میں تقریباً 20 منٹ لگتے ہیں۔ اس رفتار پر عموماً model کے مکمل ہونے سے پہلے request ناکام ہو جاتی ہے، کیونکہ Ollama کے سامنے موجود کوئی client یا proxy timeout پہلے نافذ ہو جاتا ہے۔ اسی وجہ سے context deadline exceeded کی خرابی ظاہر ہوتی ہے۔ یہ tools batch processing کے لیے ہیں۔ انہیں رات بھر documents کی queue دیں تو رفتار اہم نہیں رہتی۔ لیکن انہیں chat window کے پیچھے چلائیں تو رفتار بہت اہم ہو جاتی ہے۔

Mixture of experts routing اس حساب کو بدل دیتی ہے، اور یہی architecture کی وہ تفصیل ہے جسے سمجھنا مفید ہے۔ MoE model ہر token کو اپنے weights کے صرف ایک چھوٹے حصے سے process کرتا ہے۔ 30B total parameters اور ہر token کے لیے 3B active parameters والے model کو 30B model جتنی memory درکار ہوتی ہے، لیکن اس کی generation speed dense 3B model کے قریب ہوتی ہے، کیونکہ ہر token صرف active experts سے data پڑھتا ہے۔ 32 GB machine پر اس ساخت کا 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 ایک سخت حد ہے، اس لیے سرور کرائے پر لینے سے پہلے طے کریں کہ کیا فٹ ہو سکتا ہے:

• 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 ہی وہ وجہ ہوتی ہے جس سے model حد سے بڑھ جاتا ہے۔

Concurrency وسائل بڑھانے کی دوسری وجہ ہے۔ بیک وقت آنے والی requests کے درمیان weights مشترک رہتے ہیں، لیکن ہر فعال request کو اپنی KV cache درکار ہوتی ہے۔ اس لیے 8k context پر 8B استعمال کرنے والے 10 concurrent users کو weights کے علاوہ cache کے لیے 1 GB کا 10 گنا درکار ہوگا۔ ایک 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 کرنے کے لیے درکار وسائل میں اصل تقاضوں کی وضاحت ہے۔ یہی فرق 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 ماڈل چلانے کے لیے کتنی 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 ہونے کے باوجود میرا ماڈل سست کیوں ہے؟

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

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

ہاں، اور tokens کے ساتھ اس میں خطی اضافہ ہوتا ہے۔ ایک عام 8B ماڈل ہر 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 پر مشتمل ہو۔

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

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

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

عام VPS پر نہیں۔ سب سے طاقتور open weight models میں parameters کی تعداد سینکڑوں ارب تک ہوتی ہے۔ 4 bits پر بھی KV cache شامل کیے بغیر 200 GB سے زیادہ RAM درکار ہوتی ہے، جبکہ سب سے طاقتور commercial models بالکل distribute نہیں کیے جاتے۔ عام hardware ایک مخصوص کام کے لیے اچھا 8B سے 32B ماڈل مؤثر طور پر چلا سکتا ہے۔ ایسے کام میں محدود دائرہ کار اور اچھے prompt والا چھوٹا ماڈل اکثر general model کے برابر کارکردگی دیتا ہے۔ اگر آپ کو frontier quality درکار ہے تو کسی ایک کو خریدنے سے پہلے API کی قیمت کا hardware کی لاگت سے موازنہ کریں۔