تیم CrewAI شما روی لپتاپتان عالی کار میکند. ایجنتها با هم حرف میزنند، پژوهشگر کار را به نویسنده تحویل میدهد، کل ماجرا زمزمه میکند — درست تا لحظهای که در را میبندید و همهچیز متوقف میشود. یا وایفای شما وسط کار میافتد. یا ریبوت میکنید و فراموش میکنید دوباره راهش بیندازید.
تیمی که فقط وقتی نگاهش میکنید کار میکند خودکارسازی نیست. یک دموست. منتقل کردنش به یک VPS همان چیزی است که آن را به چیزی تبدیل میکند که واقعاً در حالی که میخوابید کار میکند.
چرا یک سرور، نه دستگاه خودتان
پیشنهاد ساده است: یک VPS کامپیوتری است که هرگز درش را نمیبندد. یک IP ثابت دارد، نمیخوابد، و اگر پروسه بمیرد میتواند خودش را برگرداند. برای یک تیم چند-ایجنتی — که ذاتاً کارهای طولانی، پرحرف و چندمرحلهای اجرا میکند — این تفاوت میان «یک بار کار کرد» و «سه هفته است در حال اجراست» است.
یک دلیل دوم هم هست که مردم را بهشکل خوبی غافلگیر میکند: به یک دستگاه قدرتمند نیاز ندارید. در ادامه بیشتر دربارهٔ آن، چون این سؤالی است که همه اول میپرسند.
نه، به یک GPU نیاز ندارید
این همان بخشی است که مردم دربارهٔ میزبانی ایجنتها اشتباه میفهمند. CrewAI یک هماهنگکننده (orchestrator) است. تصمیم میگیرد کدام ایجنت عمل کند، به چه ترتیبی، با چه زمینهای — و بعد از یک مدل زبانی میخواهد استدلال واقعی را انجام دهد. آن مدل تقریباً همیشه پشت یک API زندگی میکند: یک درخواست به OpenAI یا Anthropic میفرستید، آنها روی GPUهای خودشان اجرایش میکنند، و شما متن پس میگیرید.
پس سرور شما سه کار میکند: Python را اجرا میکند، وضعیت (state) تیم را نگه میدارد، و تماسهای HTTPS میگیرد. هیچکدام از اینها به یک GPU دست نمیزند. یک VPS ساده با CPU دقیقاً درست است. تنها زمانی این تغییر میکند که بخواهید مدل را هم بهصورت محلی اجرا کنید — اما آن یک پروژهٔ جدا و سنگینتر است، و اغلب تیمها این کار را نمیکنند.
عملاً: یک پلن ۱ تا ۲ گیگابایتی یک تیم کوچک را بدون آنکه عرق کند اجرا میکند. اگر چند تیم را همزمان اجرا میکنید، تاریخچههای بزرگ مکالمه را در RAM نگه میدارید، یا یک پایگاهدادهٔ برداری برای حافظهٔ بلندمدت ایجنت به آن میبندید، به ۴ گیگابایت بروید.
راهاندازی واقعی
یک ماشین تازهٔ 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
# your project
mkdir ~/mycrew && cd ~/mycrew
# copy your crew.py and .env up here (scp / git clone)
فایل .env شما تنها رازی را نگه میدارد که مهم است — کلید API مربوط به LLM:
OPENAI_API_KEY=sk-...
# or ANTHROPIC_API_KEY, etc.
سپس یک python crew.py معمولی آن را اجرا میکند. آن نسخهٔ دستی است. کار میکند، اما همان لحظه که نشست SSH شما بسته میشود میمیرد — که ما را به نکتهٔ اصلی یک سرور میرساند.
با systemd زنده نگهش دارید
tmux برای یک تست سریع خوب است. برای هر چیز جدی، از systemd استفاده کنید — اگر تیم کرش کند دوباره راهش میاندازد و روی ریبوت بالایش میآورد. این را در /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 # watch it work
حالا تیم روی بوت اجرا میشود، در صورت خرابی دوباره راه میافتد، و همهجا لاگ میگذارد که بتوانید بخوانید. لپتاپتان را ببندید — اهمیتی نمیدهد.
پرداختش
ثبتنام یک ایمیل و یک کد یکبارمصرف است — بدون کارت، بدون مدرک شناسایی. یک موجودی را با USDC یا USDT روی Base، Ethereum یا Polygon شارژ میکنید (Base از نظر کارمزد ارزانترین است)، و سفارشها از آن برداشت میشوند. برای تیمی که بیشتر تماسهای خروجیِ API میگیرد، پلن پیشفرض NAT خوب و ارزانتر است؛ فقط اگر تیم به IPv4 عمومی خودش برای سرویسهای ورودی نیاز دارد یک پلن -ip بگیرید.
یک ترفند خوب: EQVPS یک سرور MCP در mcp.eqvps.com/mcp دارد. اگر فراهمسازی خودش یکی از کارهای تیم شماست، یک ایجنت با موجودی شارژشده میتواند order_vps را صدا بزند و خودش یک ماشین بالا بیاورد — بدون هیچ انسانی در صندوق پرداخت.
چه چیزی صادقانه است که بگوییم
کلیدهای API مربوط به LLM را خودتان میآورید. ما تیم را میزبانی میکنیم، نه مدل را. صورتحساب OpenAI/Anthropic شما جداست و برای یک تیم پرمشغله معمولاً هزینهٔ بزرگتر است — VPS بخش ارزان ماجراست.
فقط CPU است، یک دیتاسنتر در آلمان. بدون استنتاج GPU محلی، و تأخیر (latency) بهترین حالت را دارد اگر کاربران یا APIهای شما نزدیک اروپا باشند. برای تیمی که به APIهای LLM میزبان در آمریکا میرسد، پرش اضافه چند میلیثانیه است — در برابر تأخیر مدل بیاهمیت — اما خوب است بدانید.
اندازه را بر اساس حافظهتان انتخاب کنید، نه مدلتان. چیزی که واقعاً مصرف RAM شما را بالا میبرد تاریخچهٔ مکالمه و هر vector storeای است که اضافه میکنید، نه تعداد ایجنتها. یک روز journalctl و htop را زیر نظر بگیرید و اگر لازم شد تغییر اندازه بدهید.
جمعبندی
یک تیم CrewAI به چیزی تعلق دارد که نمیخوابد. کوچ کوتاه است: یک VPS با CPU، pip install crewai، یک unit مربوط به systemd، کلید API شما در یک .env. ده دقیقه و تیم شما بهجای «هر وقت لپتاپ باز است» بهصورت ۲۴/۷ در حال اجراست. root در حدود یک دقیقه، پرداخت با رمزارز، تغییر اندازه وقتی حافظه گفت — و بگذارید ایجنتها کارشان را پیش ببرند.
نظرات
هنوز نظری نیست. اولین نفر باشید.