AI agent، LLM اور AI assistant میں کیا فرق ہے؟

AI agent، LLM اور AI assistant میں کیا فرق ہے؟

AI agent، LLM اور AI assistant ایک ہی stack کی تین تہیں ہیں۔ ان میں فرق سمجھنے کا طریقہ یہ ہے کہ دیکھا جائے ہر تہہ کو server سے کیا درکار ہے۔ LLM (large language model) weights کی ایک file ہے، جس کے لیے RAM اور compute درکار ہوتے ہیں۔ assistant اسی model کو chat surface، account اور محفوظ شدہ history کے ساتھ پیش کرتا ہے، اور یہ تقریباً ہمیشہ کسی دوسرے فریق کے hardware پر چلتا ہے۔ agent ایسا assistant ہے جس کے پاس tools اور ایک loop بھی ہوتا ہے۔ یہ credentials محفوظ رکھتا ہے، اسی لیے اسے ایسی machine پر چلانا پڑتا ہے جو مسلسل آن رہے۔

اس موضوع پر زیادہ تر تحریریں definitions تک محدود رہتی ہیں۔ Definitions اس لیے اہم ہیں کہ ہر تہہ کے اخراجات کا طریقہ مختلف ہوتا ہے۔ ایک کے لیے RAM درکار ہوتی ہے۔ دوسری کے لیے public URL اور TLS (transport layer security) درکار ہوتا ہے۔ آخری کے لیے credentials درکار ہوتے ہیں۔ Agent جس credential کو استعمال کر چکا ہو، اسے اب rotate کرنا ضروری ہے۔

ایک LLM دراصل weights پر مشتمل ہوتا ہے، اور weights کے لیے RAM درکار ہوتی ہے

ایک LLM اعداد پر مشتمل فائل ہے۔ آپ اسے download کرتے ہیں، runtime اسے memory میں load کرتا ہے، اور یہ ایک وقت میں ایک request کا جواب دیتا ہے۔ اس کا دائرۂ کار محدود ہے: text اندر جاتا ہے اور text باہر آتا ہے۔ Calls کے درمیان model کے پاس کوئی memory نہیں ہوتی، نہ clock، نہ network access، اور نہ ہی file کھولنے کا کوئی طریقہ۔ LLM کو جو کچھ بھی یاد رہتا ہوا دکھائی دیتا ہے، وہ دراصل اسے call کرنے والے program نے اس کے context میں شامل کیا ہوتا ہے۔

آپ کے VPS plan کا فیصلہ کرنے والا بنیادی عدد اس فائل کا size ہے، کیونکہ model کے چلنے کے دوران پوری فائل memory میں رہتی ہے۔ Ollama کی default 4-bit quantisation میں تقریباً 0.6 GB فی billion parameters کا اندازہ رکھیں، پھر context window اور runtime کے لیے مزید 1 یا 2 GB شامل کریں۔

[
  {
    "label": "qwen3:4b",
    "download_gb": 2.5,
    "ram_gb_needed": 6
  },
  {
    "label": "qwen3:8b",
    "download_gb": 5.2,
    "ram_gb_needed": 8
  },
  {
    "label": "qwen3:14b",
    "download_gb": 9.3,
    "ram_gb_needed": 12
  },
  {
    "label": "qwen3:32b",
    "download_gb": 20.0,
    "ram_gb_needed": 24
  }
]

qwen3:8b build ڈسک پر 5.2 GB ہے اور swapping کے بغیر چلنے کے لیے تقریباً 8 GB RAM چاہتا ہے۔ 4 GB VPS qwen3:14b load نہیں کر سکے گا، جو ایک بھی لفظ لکھنے سے پہلے 9.3 GB کا ہے۔ یہاں موجود سب سے بڑی row، qwen3:32b، تقریباً 24 GB کی ضرورت رکھتی ہے۔ زیادہ تر price lists میں اس کے لیے مختلف plan اور مختلف ماہانہ bill کی ضرورت ہوتی ہے۔

Memory میں fit ہونا ایک سوال ہے۔ Speed دوسرا سوال ہے۔ صرف CPU والے VPS پر bottleneck clock speed کے بجائے memory bandwidth ہوتی ہے، اس لیے fit ہونے والا model بھی چند tokens فی second کی رفتار سے جواب دے سکتا ہے۔ رات بھر چلنے والے job کے لیے یہ مناسب ہے، لیکن chat کے لیے تکلیف دہ حد تک سست ہے۔ GPU اس رفتار کو تقریباً ایک order of magnitude تک بڑھا دیتا ہے، مگر bill بھی بڑھاتا ہے۔ اس لیے فیصلہ measurement کی بنیاد پر کریں: اس workload کے ساتھ VPS کا benchmark لیں جسے آپ چلانے کا ارادہ رکھتے ہیں اور پڑھیں GPU VPS کب اپنی قیمت ثابت کرتا ہے۔ Weights کو بالآخر چلانے کے لیے اپنے VPS پر Ollama سے شروع کریں۔

ایک assistant، LLM اور chat surface کا مجموعہ ہے

assistant کسی model کے گرد موجود product layer ہے۔ ChatGPT اور Claude assistants ہیں: ایک model، ایک chat window، ایک account، محفوظ شدہ conversations، اور rate limit۔ اس کا تقریباً کوئی حصہ بھی آپ کے زیرِ انتظام hardware پر نہیں چلتا۔ اسی لیے hosted assistant کے لیے subscription درکار ہوتی ہے اور RAM کی ضرورت صفر ہوتی ہے۔

Self-hosted ورژن میں Open WebUI جیسا front end ہوتا ہے، جو local Ollama یا hosted API کی طرف متوجہ ہوتا ہے۔ front end ایک چھوٹا software ہوتا ہے۔ chat surface کے لیے تقریباً 1 GB resident memory درکار ہوگی، model کی ضرورت کے علاوہ۔ اسے ایک public URL اور certificate بھی درکار ہوتا ہے، جبکہ bare model کو یہ درکار نہیں ہوتے، کیونکہ آپ اسے phone سے access کرنا چاہتے ہیں: Certbot اور Nginx سے certificate جاری کریں، یا متعدد apps کے سامنے Traefik پر TLS terminate کریں۔ اگر آپ ابھی front end منتخب کر رہے ہیں تو Open WebUI کے متبادل دیکھیں۔

assistant جواب دیتا ہے۔ یہ خود action نہیں لیتا۔ جب یہ shell command لکھتا ہے تو ایک شخص اس command کو پڑھ کر فیصلہ کرتا ہے کہ اسے paste کرنا ہے یا نہیں۔ یہ شخص safety layer ہے، اور agent وہ چیز ہے جو اس layer کو ہٹا دیتا ہے۔

ایک agent tools اور loop شامل کرتا ہے

agent ایسا assistant ہے جو functions کو call کر کے ان کے نتائج پڑھ سکتا ہے۔ یہ کام دو حصے کرتے ہیں۔ پہلا حصہ tool ہے: ایسے function کی وضاحت جس کی model درخواست کر سکتا ہے، اور آپ کا وہ code جو اسے حقیقت میں چلاتا ہے۔ دوسرا حصہ loop ہے: آپ کا program model کو call کرتا ہے، model کسی tool کی درخواست کرتا ہے، آپ کا program اسے چلاتا ہے، output کو conversation میں شامل کرتا ہے، اور model کو دوبارہ call کرتا ہے۔ یہ عمل اس وقت تک جاری رہتا ہے جب تک model یہ نہ کہے کہ کام مکمل ہو گیا ہے، یا کوئی limit اسے روک نہ دے۔

loop عام code ہوتا ہے، اور بنیادی loop سو lines سے بھی کم میں بن جاتا ہے۔ اسے agent بنانے والی بات یہ ہے کہ tools کے پاس حقیقی credentials ہوتے ہیں، اس لیے loop اپنے باہر موجود کسی چیز میں تبدیلی کر سکتا ہے۔ ذیل کے ہر hosting فیصلے کی بنیاد یہی ایک حقیقت ہے۔ Agent skills اور MCP (model context protocol) servers ایسے دو طریقے ہیں جن سے loop کو دوبارہ لکھے بغیر agent کو مزید tools دیے جا سکتے ہیں۔

• یہ آپ کے session سے زیادہ دیر تک چلتا ہے۔ chat آپ کے tab بند کرتے ہی ختم ہو جاتی ہے۔ agent run میں بیس منٹ لگ سکتے ہیں، اور اسے آپ کے laptop کے sleep mode میں جانے کے باوجود جاری رہنا چاہیے، اس لیے اسے ایسے box پر چلائیں جو مسلسل آن رہے۔ اسے systemd service یا timer کے ذریعے start کریں تاکہ reboot کے بعد دوبارہ چل سکے۔
• اس کے پاس secrets ہوتے ہیں۔ API key، SSH key یا database password۔ agent جو کچھ پڑھ سکتا ہے، اس میں چھپی ہوئی hostile instruction اسے استعمال کرنے پر مجبور کر سکتی ہے، اس لیے secrets کو agent کی رسائی سے باہر رکھیں۔
• اس کی لاگت آپ کے سوال کے بجائے loop کے ساتھ بڑھتی ہے۔ ہر step میں پوری conversation کو input کے طور پر دوبارہ بھیجا جاتا ہے، اس لیے ten-step run میں اس transcript کی لاگت ten times ادا ہوتی ہے۔ اسی وجہ سے input tokens agent کے bill پر غالب آتے ہیں اور آپ کو اس بات پر hard cap لگانی چاہیے کہ ایک run کتنی لاگت کر سکتا ہے۔
• یہ ایسی غلطی کر سکتا ہے جس سے data لکھا یا حذف ہو جائے۔ chat میں غلط answer کی قیمت صرف دوبارہ پڑھنا ہے۔ loop کے اندر غلط delete کی قیمت پوری directory ہو سکتی ہے۔ اسے ایسے user کے طور پر چلائیں جسے کام کے لیے درکار کم سے کم privileges حاصل ہوں، اور coding agents کے لیے اپنی repository دینے سے پہلے اسے sandbox میں چلائیں۔

باکس سے ہر layer کی ضرورت

[
  {
    "label": "LLM (weights you host)",
    "ram_gb": 8,
    "gpu": "helps a lot",
    "public_url": "no",
    "credentials": "none"
  },
  {
    "label": "Assistant (chat surface)",
    "ram_gb": 1,
    "gpu": "no",
    "public_url": "yes",
    "credentials": "one login"
  },
  {
    "label": "Agent (tools and a loop)",
    "ram_gb": 2,
    "gpu": "no",
    "public_url": "only for webhooks",
    "credentials": "several"
  }
]

RAM والے کالم کو غور سے پڑھیں، کیونکہ اس میں model شامل نہیں ہے۔ chat front end اور agent runtime دونوں چھوٹے پروگرام ہیں۔ اگر agent کسی hosted model کو call کرتا ہے تو 2 GB RAM اسے چلا دیتی ہے، اور سستا plan کسی سمجھوتے کے بجائے ایک حقیقی جواب ہوتا ہے۔ اگر weights اسی box پر رکھے جائیں تو 8 GB model کی سطر باقی ہر چیز پر غالب آ جاتی ہے۔

باقی کالم توقع سے زیادہ اہم ہیں۔ صرف model layer کو GPU سے رفتار ملتی ہے۔ صرف assistant layer کو معمول کے طور پر public URL درکار ہوتا ہے، کیونکہ browser کو اس تک پہنچنا ہوتا ہے؛ agent کو یہ صرف اس وقت چاہیے جب باہر سے کسی چیز کو اسے call کرنا ہو، مثلاً webhook کے ذریعے۔ مزید یہ کہ agent کے پاس several credentials ہوتے ہیں، اور یہی chat window کے ساتھ اس کا حقیقی فرق ہے۔ chat window غلط ہو سکتی ہے۔ agent غلط ہو کر اس بنیاد پر کارروائی بھی کر سکتا ہے۔

کیا AI agent چلانے کے لیے GPU درکار ہے؟

نہیں، جب تک آپ اسی machine پر model weights بھی host نہ کر رہے ہوں۔ agent loop میں HTTP requests، JSON parsing اور subprocess calls شامل ہوتے ہیں، اور network کے جواب کا انتظار کرتے وقت CPU تقریباً idle رہتا ہے۔ GPU کا سوال دراصل LLM layer سے متعلق ہے۔

اس لیے فیصلہ الگ الگ کریں۔ اگر text آپ کی machine سے باہر نہیں جا سکتا تو model رکھنے کے لیے درکار memory اور قابلِ استعمال رفتار کے لیے اسے چلانے والا GPU خریدیں۔ اگر آپ صرف automation چاہتے ہیں تو model کو token کی بنیاد پر rent کریں اور رقم uptime اور backups پر خرچ کریں۔ 2026 میں زیادہ تر self-hosted agents hosted model کو call کرتے ہیں، اور اسی وجہ سے انہیں چلانا کم خرچ ہوتا ہے۔

کیا آپ AI agent کو self-host کر سکتے ہیں؟

ہاں، اور agent وہ layer ہے جسے self-host کرنا سب سے زیادہ مفید ہے، کیونکہ loop میں آپ کا data اور credentials موجود ہوتے ہیں۔ 2 GB RAM، ایک service manager اور outbound network access والا چھوٹا VPS حقیقی agent چلا سکتا ہے۔ اگر آپ loop کا مکمل اختیار چاہتے ہیں تو VPS پر خود بنانے والا طریقہ اختیار کریں، یا اگر آپ تیار حل سے آغاز کرنا چاہتے ہیں تو تیار self-hosted agents میں سے کوئی deploy کریں۔

assistant کو self-host کرنا آسان ہے: اس کے لیے ایک container اور certificate درکار ہوتا ہے۔ model کو self-host کرنا مہنگا حصہ ہے، اور CPU سے tokens کے بہت آہستہ generate ہونے کا مشاہدہ کرنے کے بعد اکثر لوگ اسے ترک کر دیتے ہیں۔ جب data اس machine سے باہر نہیں جا سکتا، یا آپ کے استعمال کے حجم کی وجہ سے فی-token قیمت ناقابلِ برداشت ہو، تو weights کو self-host کریں۔ بصورتِ دیگر agent کو API call کرنے دیں اور اہم اجزا local رکھیں۔

کیا ChatGPT ایک AI agent ہے؟

جیسے ہی کوئی chat product کسی tool کو call کر کے آپ سے پہلے اجازت لیے بغیر اس کے نتیجے پر عمل کر سکتا ہے، وہ agent بن جاتا ہے۔ اس معیار کے مطابق browsing، code execution یا connectors رکھنے والے hosted assistants agents ہیں۔ آپ کے لیے فرق یہ ہے کہ یہ loop کہاں چلتا ہے اور اس میں کس کے credentials استعمال ہوتے ہیں۔ hosted product میں دونوں چیزیں vendor کی ملکیت ہوتی ہیں۔ اپنے server پر دونوں آپ کے اختیار میں ہوتے ہیں، اور رات کے 3 بجے یہ loop جو کچھ بھی کرے، اس کی ذمہ داری بھی آپ کی ہوتی ہے۔

Reactive، planning اور multi-agent

Roundups میں agent کی سات اقسام کی فہرست عام ہے۔ ان میں سے زیادہ تر اقسام marketing ہیں۔ دو امتیازات آپ کے لکھے ہوئے code کو بدلتے ہیں، اور ایک آپ کے bill کو بدلتا ہے۔ reactive agent کسی tool کو call کرتا ہے، جواب پڑھتا ہے اور reply کرتا ہے۔ planning agent پہلے ایک plan لکھتا ہے اور پھر اس کے مراحل مکمل کرتا ہے۔ یہ طویل jobs میں زیادہ قابل اعتماد رہتا ہے، لیکن اس میں زیادہ tokens خرچ ہوتے ہیں، کیونکہ ہر step پر plan دوبارہ send کیا جاتا ہے۔ multi-agent setup میں ایک agent دوسرے agents شروع کر سکتا ہے۔ اس سے token spend اور failure modes بیک وقت کئی گنا بڑھتے ہیں۔ اس کا فائدہ صرف اس وقت ہوتا ہے جب sub-jobs واقعی independent ہوں، مثلاً بیک وقت چار sources تلاش کرنا۔ reactive سے شروع کریں۔ runs طویل ہونے پر planning شامل کریں۔ multi-agent کو آخر میں اختیار کریں۔ وسیع تر جائزے کے لیے دیکھیں: 2026 میں AI agents کے بارے میں کیا سیکھنا مفید ہے۔

اس بات کا تعین کیسے کریں کہ آپ حقیقت میں کون سی layer چلا رہے ہیں

سرور پر معلوم کریں کہ memory کن processes کے پاس ہے۔

free -h
ps -eo rss,comm --sort=-rss | head -5

اگر اوپر والی لائن میں ollama یا llama-server کئی gigabytes کی RSS (resident set size، یعنی وہ memory جس پر process حقیقتاً قابض ہے) استعمال کر رہا ہے، تو آپ model host کر رہے ہیں۔ اگر کوئی process چند سو megabytes سے زیادہ استعمال نہیں کر رہا اور آپ کا API bill مسلسل بڑھ رہا ہے، تو آپ agent یا assistant host کر رہے ہیں اور model کرائے پر لے رہے ہیں۔ اگر یہ فہرست خالی ہے کیونکہ سب کچھ browser tab میں ہو رہا ہے، تو آپ assistant کے صارف ہیں۔ یہ بھی ایک مناسب صورت ہے، جب تک آپ کو ایسا software درکار نہ ہو جو آپ کی جانب سے کام کرے۔

آپ کون سا چلانا چاہتے ہیں؟

• متن کو نجی رکھنے کے لیے model چلائیں: Ollama کے ساتھ LLM کو self-host کریں، پھر جب ایک user کی تعداد دس ہو جائے تو Ollama اور vLLM کے runtime کا موازنہ کریں۔
• مکمل control اور tools اپنے ہاتھ میں رکھنے کے لیے agent بنائیں: VPS پر اپنا AI agent بنائیں۔
• آج شام تک کوئی چیز فعال کرنے کے لیے چلانے کے قابل self-hosted agents میں سے کوئی تیار agent deploy کریں۔
• اگر ابھی تک ان میں سے کسی کے لیے server موجود نہیں ہے تو سمجھیں کہ VPS دراصل آپ کو کیا فراہم کرتا ہے سے آغاز کریں۔

FAQ

کیا AI agent صرف اضافی مراحل والا LLM ہے؟

اضافی مراحل ہی اس کی اصل خصوصیت ہیں۔ LLM متن کو متن میں تبدیل کرتا ہے اور اس کے علاوہ کچھ نہیں کرتا۔ Agent کے ساتھ ایسے tools اور ایک loop شامل ہوتا ہے جنہیں وہ چلا سکتا ہے اور بار بار استعمال کر سکتا ہے۔ ان tools کے پاس credentials ہوتے ہیں، اس لیے output کسی file، database یا live service میں تبدیلی کر سکتا ہے۔ اسی وجہ سے agent کے لیے ہمیشہ آن رہنے والی machine، service manager اور secrets policy درکار ہوتی ہے، جبکہ LLM کو جواب دیتے وقت صرف اتنی memory چاہیے ہوتی ہے جس میں اس کے weights سما سکیں۔

کیا AI agent چلانے کے لیے GPU ضروری ہے؟

Agent کے لیے نہیں۔ اس کا loop HTTP requests، JSON handling اور subprocess calls پر مشتمل ہوتا ہے، جنہیں کوئی بھی CPU network response کا انتظار کرتے ہوئے سنبھال سکتا ہے۔ GPU صرف اس وقت درکار ہوتا ہے جب آپ model weights خود host کریں اور ان سے چند tokens فی second سے زیادہ حاصل کرنا چاہیں۔ Hosted model کو call کرنے والا agent بغیر کسی GPU کے چھوٹے VPS پر بھی آسانی سے چلتا ہے۔

AI agent کے لیے VPS میں کتنی RAM درکار ہے؟

تقریباً 2 GB، جب agent hosted model کو call کرتا ہے، کیونکہ اس صورت میں صرف runtime، اس کی dependencies اور ایک چھوٹا local database memory میں رہتے ہیں۔ اگر آپ weights خود host کریں تو model کی memory بھی شامل کریں: qwen3:8b کو اکیلے تقریباً 8 GB درکار ہوتے ہیں، اس لیے all-in-one box کی شروعات اسی مقدار سے ہوتی ہے اور آپ کے منتخب کردہ model کے مطابق بڑھتی ہے۔

کیا میں AI assistant کو self-host کر کے اپنی گفتگو نجی رکھ سکتا ہوں؟

ہاں، لیکن ایک اہم شرط ہے جو پورا نتیجہ طے کرتی ہے۔ Open WebUI جیسا self-hosted front end accounts اور history آپ کے server پر رکھتا ہے۔ گفتگو واقعی نجی صرف اسی وقت رہتی ہے جب اس کے پیچھے چلنے والا model بھی local ہو۔ اسی front end کو hosted API سے منسلک کرنے پر ہر message کے ساتھ متن آپ کی machine سے باہر چلا جاتا ہے۔ اس صورت میں history تو آپ کے پاس رہتی ہے، privacy نہیں۔

AI agent اور chatbot میں کیا فرق ہے؟

Chatbot جواب دیتا ہے اور رک جاتا ہے۔ Agent اگلا کام طے کرتا ہے، کوئی tool call کرتا ہے، نتیجہ پڑھتا ہے اور دوبارہ فیصلہ کرتا ہے، یہاں تک کہ کام مکمل ہو جائے یا کوئی limit اسے روک دے۔ عملی معیار یہ ہے: اگر software جواب اور action کے درمیان کسی انسان کے button دبائے بغیر کوئی تبدیلی کر سکتا ہے تو وہ agent ہے، اور اسے hosting کے ساتھ آنے والی guardrails اور انتظامات درکار ہوتے ہیں۔