تصور کنید برای رندر گرفتن از یک مدل هوش مصنوعی هزینه پردازشی می‌پردازید و با خیال راحت دکمهٔ توقف را می‌زنید، اما صبح روز بعد می‌بینید موجودی حسابتان منفی شده است. این دقیقاً همان تله‌ای است که یک تیم کوچک تولید محتوا هنگام اجاره GPU از پلتفرم Vast.ai برای کارهای ویدئویی هوش مصنوعی تجربه کردند.
به گزارش این تیم، توقف یک نمونه (Instance) در این پلتفرم، شمارندهٔ هزینه‌های مربوط به فضای ذخیره‌سازی را متوقف نمی‌کند. طبق تجربه آن‌ها، باقی گذاشتن یک دیسک ۹۰ گیگابایتی در حالت «متوقف شده» (STOPPED)، ساعتی حدود ۰.۰۱۶۷ دلار یا روزانه ۰.۴۰ دلار هزینه دارد. این مبلغ شاید در ابتدا ناچیز به نظر برسد، اما در طول زمان می‌تواند منجر به تخلیه حساب کاربر شود.
بسیاری از فعالان حوزه هوش مصنوعی تصور می‌کنند توقف یک ماشین مجازی، تمام هزینه‌ها را منجمد می‌کند. در واقعیت، ارائه‌دهندگان ابری بین محاسبات (Compute) — که مثل اجارهٔ یک آشپزخانه صنعتی برای پخت غذاست — و ذخیره‌سازی تفاوت قائل می‌شوند. در حالی که هزینه واحد پردازش گرافیکی (GPU) بلافاصله پس از توقف متوقف می‌شود، فضای دیسک برای کاربر رزرو می‌ماند تا در صورت بازگشت، داده‌ها موجود باشند و به همین دلیل هزینهٔ آن به‌صورت مستمر کسر می‌شود. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی مدیریت هزینه‌های زیرساخت ابری اشاره کردیم، این تفاوت یکی از رایج‌ترین نقاط شکست برای تیم‌هایی است که از سخت‌افزار محلی به خوشه‌های ابری مهاجرت می‌کنند و با منطق متفاوت صورت‌حساب‌ها آشنا نیستند. این چالش‌ها در مقیاس بزرگ‌تر می‌تواند فاجعه‌بار باشد، همان‌طور که برخی عامل‌های کدنویسی هوش مصنوعی ریسک ایجاد صورت‌حساب‌های نجومی را به همراه دارند.
هزینه یک اشتباه ساده
این اشتباه ساده منجر به منفی شدن موجودی حساب تیم مذکور شد. پیامد این اتفاق این بود که آن‌ها دیگر نتوانستند نمونه را برای بازیابی نتایج آموزش‌دیده مجدداً راه‌اندازی کنند، زیرا سیستم برای حساب‌های با موجودی منفی، دسترسی را مسدود می‌کند. چون داده‌ها هنوز دانلود نشده بودند، عملاً تمام خروجی‌های تولیدشده از دست رفتند. این اتفاق یک ریسک حیاتی را آشکار کرد: هزینهٔ از دست دادن خروجی‌های تولیدشده و ساعت‌ها زمان پردازش، بسیار بیشتر از دقت اندک مورد نیاز برای پاک‌سازی درست سیستم است.
برای جلوگیری از تکرار این فاجعه، تیم مذکور یک توالی خاموشی جدید را پیاده کرد که امنیت داده‌ها را بر دستورات سیستم اولویت می‌دهد. آن‌ها اکنون ترتیب سخت‌گیرانه‌ای را دنبال می‌کنند: ابتدا کپی نتایج، سپس پشتیبان‌گیری و در نهایت تأیید کامل کپی پیش از دست زدن به کنترل‌های نمونه. آن‌ها بین دو اقدام اصلی تفاوت قائل شده‌اند:
- توقف (Stop): جلسهٔ GPU را پایان می‌دهد اما نمونه و ذخیره‌سازی را حفظ می‌کند. این حالت فقط زمانی استفاده می‌شود که نیاز واقعی و آگاهانه به حفظ دیسک برای ادامه کار در آینده وجود داشته باشد.
- تخریب (Destroy): نمونه را به‌طور کامل حذف می‌کند. این اقدام در پایان هر دسته از کارها، پس از اطمینان از ایمن شدن خروجی‌ها، انجام می‌شود.
توقف زمانی مفید است که قصد داشته باشید با همان دیسک کار را ادامه دهید، اما جایگزین مناسبی برای پاک‌سازی نیست. این تیم اکنون پیش از انتخاب گزینه Stop، از خود می‌پرسند که آیا داده‌های روی دیسک ارزش پرداخت هزینهٔ مستمر را دارند یا خیر و آیا برنامه مشخصی برای بازگشت به آن دیسک وجود دارد یا نه.
در یک مورد خاص، آن‌ها برای اطمینان، تأیید کردند که ۵۳۴۲ فایل و ۱.۳۷۹ گیگابایت داده به‌طور دقیق با نسخه محلی مطابقت دارد و سپس اقدام به تخریب کردند. آن‌ها تأکید می‌کنند که صرفاً دریافت پیام «کپی موفق» از سوی سیستم کافی نیست؛ کاربر باید شخصاً تعداد فایل‌ها و حجم کل را در مقصد بررسی کند تا مطمئن شود هیچ داده‌ای خراب نشده یا جا نمانده است. تخریب نمونه، هر راه بازگشتی به داده‌های باقی‌مانده روی دیسک را می‌بندد و این عمل غیرقابل بازگشت است.
گردش‌کار فنی پاک‌سازی
پس از تأیید داده‌ها، تیم از Vast CLI برای تخریب صریح نمونه استفاده می‌کند. این رابط خط فرمان دستوری برای انتقال نتایج از نمونه به دایرکتوری محلی دارد:
vastai copy "$REMOTE_SOURCE" "$LOCAL_DESTINATION"
پس از کپی، نتایج در یک فضای ابری پشتیبان شده و سپس نمونه تخریب می‌شود. چون CLI معمولاً برای تأیید (y/N) توقف می‌کند و منتظر پاسخ کاربر می‌ماند، آن‌ها برای اتوماسیون اسکریپت‌ها و اجرای بدون نظارت، از دستور لوله‌کشی (Piped) استفاده می‌کنند:
echo y | vastai destroy instance "$INSTANCE_ID"
آن‌ها اشاره می‌کنند که در نسخه‌های جدیدتر CLI ممکن است گزینه -y برای تأیید خودکار وجود داشته باشد، اما آن‌ها همچنان از روش لوله‌کشی استفاده می‌کنند چون با رفتار پرامپتی که تأیید کرده‌اند مطابقت دارد. همچنین هشدار می‌دهند که پیام «دستور اجرا شد» (command ran) لزوماً به معنای پاک بودن حساب نیست. خطاهای شبکه، خطاهای CLI یا لیست‌های قدیمی (stale listings) می‌توانند نمونه‌های فعال را در پنل پنهان کنند.
آن‌ها با یک مورد بسیار گیج‌کننده مواجه شدند که در آن، یک لیست قدیمی از نسخه v0 منسوخ شده بود و خطایی برگرداند که شبیه به «۰ نمونه» (0 instances) بود. این تجربه ثابت کرد که دریافت یک خطا، دلیلِ نبودِ نمونه یا حذف موفق آن نیست.
برای اطمینان کامل، آن‌ها مستقیماً از طریق curl و نقطه انتهایی (Endpoint) نسخه v1 استعلام می‌گیرند تا مطمئن شوند شناسه نمونه واقعاً از سیستم حذف شده است. آن‌ها کلید API را در یک متغیر محیطی نگه می‌دارند تا از چاپ شدن آن در لاگ‌ها جلوگیری کنند:
: "${VAST_API_KEY:?Set VAST_API_KEY in your environment}" curl -fsS \ -H "Authorization: Bearer ${VAST_API_KEY}" \ "https://console.vast.ai/api/v1/instances/" | python -m json.tool
آن‌ها پاسخ دریافتی را برای یافتن شناسه نمونه‌ای که تخریب کرده‌اند بررسی می‌کنند. همچنین چک می‌کنند که درخواست با موفقیت ارسال شده و پاسخ معتبری دریافت شده است، پیش از آنکه نبودِ شناسه را به عنوان تأیید نهایی بپذیرند. اگر شناسه همچنان در لیست باشد، آن‌ها علت را بررسی کرده و مجدداً تلاش می‌کنند.
نگهبان خودکار تخریب (Auto-Destroy Watchdog)
برای محافظت در برابر کرش‌هایی که باعث فعال ماندن شمارنده GPU می‌شود، این تیم یک اسکریپت نگهبان (Watchdog) مجزا با زبان Bash توسعه دادند. این اسکریپت در ابتدای هر جلسه با دستور nohup اجرا می‌شود تا در صورت بسته شدن ترمینال یا قطع اتصال، متوقف نشود. اسکریپت تا یک ضرب‌الاجل (Deadline) مشخص منتظر می‌ماند و سپس تا سه بار تلاش می‌کند تا نمونه را تخریب کند.
منطق اسکریپت watchdog.sh به این صورت است:
#!/usr/bin/env bash
set -u
instance_id=${1:?Pass an instance ID}
deadline_seconds=${2:?Pass a deadline in seconds}
retry_wait_seconds=${3:?Pass a retry wait in seconds}
case "$deadline_seconds:$retry_wait_seconds" in
*[!0-9:]* | :* | *:) exit 2 ;;
esac
sleep "$deadline_seconds"
for attempt in 1 2 3; do
if echo y | vastai destroy instance "$instance_id"; then
exit 0
fi
if [ "$attempt" -lt 3 ]; then
sleep "$retry_wait_seconds"
fi
done
exit 1
آن‌ها این اسکریپت را به این شکل اجرا می‌کنند:
nohup bash watchdog.sh "$INSTANCE_ID" "$RUN_SECONDS" "$RETRY_WAIT_SECONDS" >./vast-watchdog.log 2>&1 </dev/null &
این نگهبان یک لایه حفاظتی (Safety Backstop) است، نه ابزار اصلی پاک‌سازی. آن‌ها ضرب‌الاجل را بر اساس هزینه ساعتی پیشنهاد (Offer) و حداکثر ضرر قابل قبول خود — که در مورد آن‌ها سقف ۱ دلار بود — تعیین می‌کنند. آن‌ها زمان لازم برای راه‌اندازی و رندر را در نظر می‌گیرند، اما یادآور می‌شوند که تایمری بر اساس ساعات GPU، تمام هزینه‌ها از جمله ترافیک ورودی یا ذخیره‌سازی پس از توقف را پوشش نمی‌دهد.
یک فرآیند مجزا (Detached Process) می‌تواند پس از خروج از شل کنترل‌کننده زنده بماند، اما اگر ماشین میزبان خاموش شود، اعتبارنامه‌ها از کار بیفتند یا دسترسی به Vast قطع شود، کمکی نخواهد کرد. به همین دلیل است که بررسی نهایی لیست v1 ضروری است. آن‌ها لاگ نگهبان را تا زمان تکمیل بررسی نهایی API حفظ می‌کنند تا ببینند آیا ضرب‌الاجل فعال شده یا تلاش برای تخریب شکست خورده است.
بهینه‌سازی هزینه‌های راه‌اندازی
تیم متوجه هزینه‌های پنهان در مرحله راه‌اندازی شد. آن‌ها اکنون پیش از اجرا، جزئیات پیشنهادها را بررسی می‌کنند و به‌طور خاص مقدار inet_down_cost را چک می‌کنند. ترافیک ورودی می‌تواند هزینه قابل توجهی داشته باشد؛ برای مثال، دریافت ۲۴۵ گیگابایت وزن‌های مدل برای تست RTX PRO 6000 Blackwell، مبلغ ۰.۶۴ دلار هزینه ترافیک داشت. در حالی که هزینه GPU برابر ۱.۴۷ دلار بود و مجموعاً ۲.۱۸ دلار هزینه شد. این نوع مدیریت دقیق منابع، یادآور تلاش‌های پیشرفته‌تر برای بهره‌گیری از عامل‌های هوش مصنوعی در مدیریت زنجیره تأمین سخت‌افزار و خرید بهینه GPU است.
برای به حداقل رساندن این هزینه‌ها و جلوگیری از اشتباهات در راه‌اندازی، آن‌ها این موارد را رعایت می‌کنند:
- هزینه‌های ترافیک: جست‌وجو برای پیشنهاداتی با ترافیک ورودی رایگان تا از هزینه‌هایی مانند آن ۰.۶۴ دلار در تست Blackwell اجتناب کنند.
- سازگاری: تأیید سازگاری درایور و CUDA. آن‌ها از یک پیشنهاد A100 در سوئد به دلیل قدیمی بودن درایور (نسخه ۵۳۵) که با ایمیج آن‌ها سازگار نبود، صرف‌نظر کردند.
- تخصیص دیسک: اختصاص حداقل ۱۵۰ گیگابایت فضا برای دانلود مدل‌های بزرگ. متوجه شدند که دیسک کوچک، بدترین مکان برای کشف این است که یک دانلود جا نمی‌شود.
- راه‌اندازی تکرارپذیر: استفاده از ایمیج‌های عمومی Docker از طریق GitHub Actions و اسکریپت‌های شروع (on-start scripts) برای دانلود تنها گروه‌های ضروری وزن‌ها (مثلاً با استفاده از
DL_GROUPS=h3).
این فرآیند بهینه حدود ۹ تا ۱۱ دقیقه زمان می‌برد که در رندرهای کوتاه، سهم زیادی از زمان اجاره را تشکیل می‌دهد. آن‌ها توصیه می‌کنند جزئیات قیمت‌ها را شخصاً بررسی کنید، زیرا قیمت‌های جلسات قبلی تضمینی برای کارهای آینده نیست.
وضعیت تأیید نهایی
از نظر این تیم، یک پروژه تنها زمانی «تمام شده» است که سه شرط برقرار باشد: نتایج محلی باشند، پشتیبان مطابقت داشته باشد و نبودِ نمونه در لیست API نسخه v1 تأیید شود. یک نمونه متوقف شده (Stopped)، هیچ‌کدام از این شرایط را برآورده نمی‌کند. نگهبان خودکار تنها یک ضرب‌الاجل فراموش‌شده را پوشش می‌دهد و جایگزینی برای بررسی داده‌ها یا حساب کاربری نیست.
هزینه‌های مشاهده‌شده توسط آن‌ها معیاری برای گردش‌کارهای مشابه است:
- تست Blackwell: مجموعاً ۲.۱۸ دلار (۱.۴۷ دلار GPU و ۰.۶۴ دلار ترافیک ورودی برای ۲۴۵ گیگابایت وزن مدل).
- جلسه تبدیل تصویر به ویدیو: تولید ۸۲ کلیپ در حدود ۳ ساعت (شامل راه‌اندازی)، مجموعاً ۳.۵۹ دلار.
- نشتی ذخیره‌سازی: ۰.۰۱۶۷ دلار در ساعت (۰.۴۰ دلار در روز) برای دیسک ۹۰ گیگابایتی.
این رویکرد عملی، پاک‌سازی را از یک اقدام ثانویه به بخشی اصلی از خط تولید هوش مصنوعی تبدیل می‌کند. رندر تنها زمانی تمام شده است که فایل‌های آن ایمن باشند و اجاره GPU به‌طور کامل لغو شده باشد.
گام بعدی شما
- اگر از Vast.ai یا سرویس‌های مشابه استفاده می‌کنید، همین حالا لیست نمونه‌های فعال خود را در API نسخه v1 چک کنید تا نمونه‌ای به‌اشتباه در حالت Stop نمانده باشد.
- یک اسکریپت ساده برای تأیید تعداد فایل‌های دانلودشده (File Count) بنویسید تا پیش از تخریب نمونه، از سلامت داده‌ها مطمئن شوید.
- در هنگام انتخاب GPU، حتماً هزینه ترافیک ورودی (
inet_down_cost) را بررسی کنید تا غافلگیر نشوید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو