آپ کا CrewAI crew آپ کے لیپ ٹاپ پر زبردست چلتا ہے۔ agents ایک دوسرے سے بات کرتے، researcher writer کو ہینڈ آف کرتا، پوری چیز گنگناتی ہے — بالکل اُس وقت تک جب آپ ڈھکن بند کریں اور سب رک جائے۔ یا آپ کی wifi کام کے بیچ گرے۔ یا آپ ری بوٹ کریں اور اسے restart کرنا بھول جائیں۔
ایک crew جو صرف آپ کے دیکھتے چلتا ہے وہ automation نہیں۔ یہ ایک demo ہے۔ اسے ایک VPS پر منتقل کرنا وہ ہے جو اسے کسی ایسی چیز میں بدلتا ہے جو دراصل کام کرتی ہے جب آپ سوئیں۔
ایک سرور کیوں، آپ کی مشین نہیں
پیشکش سادہ ہے: ایک VPS ایک ایسا کمپیوٹر ہے جو کبھی اپنا ڈھکن بند نہیں کرتا۔ اس کا ایک مقررہ IP ہے، یہ سوتا نہیں، اور اگر process مرے تو یہ خود کو واپس لا سکتا ہے۔ ایک multi-agent crew کے لیے — جو ڈیزائن کے لحاظ سے طویل، باتونی، multi-step کام چلاتا ہے — یہ "یہ ایک بار چلا" اور "یہ تین ہفتے سے چل رہا ہے" کے بیچ فرق ہے۔
ایک دوسری وجہ ہے جو لوگوں کو اچھے طریقے سے چونکاتی ہے: آپ کو ایک طاقتور مشین نہیں چاہیے۔ اگلے پر اس کے بارے میں مزید، کیونکہ یہ وہ سوال ہے جو ہر کوئی پہلے پوچھتا ہے۔
نہیں، آپ کو ایک GPU نہیں چاہیے
یہ وہ حصہ ہے جسے لوگ agents host کرنے کے بارے میں غلط سمجھتے ہیں۔ CrewAI ایک orchestrator ہے۔ یہ فیصلہ کرتا ہے کون سا agent کام کرے، کس ترتیب میں، کس context کے ساتھ — اور پھر یہ ایک language model سے دراصل reasoning کرنے کو کہتا ہے۔ وہ ماڈل تقریباً ہمیشہ ایک API کے پیچھے رہتا ہے: آپ OpenAI یا Anthropic کو ایک request بھیجتے، وہ اسے اپنے GPUs پر چلاتے، آپ کو text واپس ملتا ہے۔
تو آپ کا سرور تین چیزیں کرتا ہے: Python چلاتا، crew کی state رکھتا، اور HTTPS calls بناتا ہے۔ ان میں سے کوئی ایک GPU کو نہیں چھوتا۔ ایک سادہ CPU VPS بالکل درست ہے۔ واحد وقت جب وہ بدلتا ہے اگر آپ ماڈل بھی locally چلانا چاہیں — لیکن یہ ایک الگ، بھاری project ہے، اور زیادہ تر crews نہیں چلاتے۔
عملی طور پر: ایک 1–2 GB پلان ایک چھوٹا crew بغیر پسینہ بہائے چلاتا ہے۔ 4 GB پر جائیں اگر آپ ایک ساتھ کئی crews چلا رہے، بڑی گفتگو-تاریخیں RAM میں رکھ رہے، یا طویل-مدتی agent memory کے لیے ایک vector database جوڑ رہے ہوں۔
دراصل سیٹ اپ
تازہ Ubuntu باکس، آرڈر کرنے کے تقریباً ایک منٹ بعد root۔ یہ رہی پوری چیز:
# Python + venv
apt update && apt install -y python3-venv python3-pip
python3 -m venv ~/crew && source ~/crew/bin/activate
# CrewAI
pip install crewai crewai-tools
# آپ کا project
mkdir ~/mycrew && cd ~/mycrew
# اپنی crew.py اور .env یہاں کاپی کریں (scp / git clone)
آپ کا .env وہ ایک secret رکھتا ہے جو اہم ہے — LLM API key:
OPENAI_API_KEY=sk-...
# یا ANTHROPIC_API_KEY، وغیرہ
پھر ایک عام python crew.py اسے چلاتا ہے۔ یہ دستی ورژن ہے۔ یہ چلتا ہے، لیکن یہ اُس لمحے مرتا ہے جب آپ کا SSH سیشن بند ہو — جو ہمیں ایک سرور کے دراصل نکتے تک لاتا ہے۔
اسے systemd سے زندہ رکھیں
tmux ایک فوری test کے لیے ٹھیک ہے۔ کسی حقیقی چیز کے لیے، systemd استعمال کریں — یہ crew کو کریش ہونے پر restart کرتا اور ری بوٹ پر اوپر لاتا ہے۔ اسے /etc/systemd/system/mycrew.service میں ڈالیں:
[Unit]
Description=CrewAI crew
After=network-online.target
[Service]
WorkingDirectory=/root/mycrew
ExecStart=/root/crew/bin/python /root/mycrew/crew.py
Restart=always
RestartSec=5
EnvironmentFile=/root/mycrew/.env
[Install]
WantedBy=multi-user.target
systemctl daemon-reload
systemctl enable --now mycrew
journalctl -u mycrew -f # اسے کام کرتا دیکھیں
اب crew boot پر چلتا، ناکامی پر restart ہوتا، اور ہر جگہ logs کرتا ہے جہاں آپ انہیں پڑھ سکیں۔ اپنا لیپ ٹاپ بند کریں — اسے پرواہ نہیں۔
اس کے لیے ادائیگی
Signup ایک ای میل اور ایک one-time code ہے — کوئی کارڈ، کوئی ID نہیں۔ آپ Base، Ethereum یا Polygon پر USDC یا USDT سے ایک بیلنس fund کرتے ہیں (Base فیس پر سستا ترین)، اور آرڈرز اس سے کھینچتے ہیں۔ ایک ایسے crew کے لیے جو زیادہ تر outbound API calls بناتا ہے، ڈیفالٹ NAT پلان ٹھیک اور سستا ہے؛ ایک -ip پلان صرف تب چنیں اگر crew کو inbound سروسز کے لیے اپنا public IPv4 چاہیے۔
ایک اچھا trick: EQVPS کا mcp.eqvps.com/mcp پر ایک MCP server ہے۔ اگر provisioning خود آپ کے crew کے کاموں میں سے ایک ہو، تو ایک funded بیلنس والا agent order_vps کال کر اور ایک باکس خود کھڑا کر سکتا ہے — checkout پر کوئی انسان نہیں۔
ایمانداری سے کیا کہنا ہے
آپ LLM API keys لاتے ہیں۔ ہم crew host کرتے ہیں، ماڈل نہیں۔ آپ کا OpenAI/Anthropic بل الگ ہے اور، ایک مصروف crew کے لیے، عموماً بڑی لاگت — VPS سستا حصہ ہے۔
یہ CPU-only ہے، جرمنی میں ایک datacenter۔ کوئی local GPU inference نہیں، اور latency بہترین اگر آپ کے صارفین یا APIs یورپ کے قریب ہوں۔ US-hosted LLM APIs کو مارتے ایک crew کے لیے اضافی hop milliseconds ہے — model latency کے پہلو میں غیر متعلق — لیکن جاننا فائدہ مند۔
اپنی memory کے لیے size کریں، اپنے ماڈل کے لیے نہیں۔ وہ چیز جو دراصل آپ کا RAM استعمال بڑھاتی ہے وہ گفتگو-تاریخ اور کوئی vector store جو آپ جوڑیں ہے، agents کی تعداد نہیں۔ ایک دن journalctl اور htop دیکھیں اور اگر ضرورت ہو تو resize کریں۔
مختصر بات
ایک CrewAI crew کسی ایسی چیز پر ہے جو سوتی نہیں۔ اقدام مختصر ہے: ایک CPU VPS، pip install crewai، ایک systemd unit، ایک .env میں آپ کی API key۔ دس منٹ اور آپ کا crew "جب بھی لیپ ٹاپ کھلا ہو" کے بجائے 24/7 چل رہا ہے۔ تقریباً ایک منٹ میں root، کرپٹو میں ادا، جب memory کہے resize کریں — اور agents کو اپنا کام کرنے دیں۔
تبصرے
ابھی کوئی تبصرہ نہیں۔ پہلے بنیں۔