وقتی سرویس استنتاج مدل‌های زبانی را به‌صورت بدون سرور (Serverless) پیاده‌سازی می‌کنید، قابلیت اسکیل به صفر هزینه‌ها را در زمان‌های بی‌باری به‌شدت کاهش می‌دهد. اما چالش اصلی درست در زمان بازگشت ترافیک رخ می‌دهد: راهاندازی یک نود خام، دانلود ده‌ها گیگابایت وزن مدل و بارگذاری آن‌ها در حافظه می‌تواند 3 تا 8 دقیقه طول بکشد که عملاً برای کاربر نهایی به معنای قطعی سرویس است.
اگر برای فرار از این تاخیر سرورها را همیشه روشن نگه دارید، هزینه‌های سرسام‌آور اجاره‌ی GPU توجیه اقتصادی معماری شما را نابود میکند. از طرفی تهیه و اجاره مستقیم کارت‌های گرافیک حرفه‌ای از ارائه‌دهندگان خارجی چالش‌ها و هزینه‌های ارزی سنگینی به همراه دارد، بنابراین بهینهسازی حداکثری منابع موجود ضرورتی دوچندان پیدا میکند.
در این درس یاد می‌گیرید که چگونه با ترکیب 5 لایه‌ی مهندسی—از ایمیج‌های ازپیش‌آماده و استریمینگ وزنها تا اسنپ‌شات‌های حافظه و وارم‌پول‌های بهینه—زمان راهاندازی سرد را از چند دقیقه به چند ثانیه برسانید و تعادل میان تعهدات سطح کیفیت خدمات (SLA) و هزینه‌های عملیاتی را حفظ کنید.
راهاندازی یک مدل بزرگ از حالت سرد تا پاسخ‌دهی چند دقیقه طول میکشد: یک مدل 70B روی نودی تازه، تقریباً 3 تا 8 دقیقه زمان میبرد تا اولین توکن را تولید کند. در دنیای واقعیِ بدون سرور (Serverless)، این زمان یک «گرم‌کردن اولیه» نیست، بلکه یک «قطعی کامل سرویس» است. راهکارهای کاهش این زمان در پنج لایه عمل می‌کنند: ایمیج‌های ازپیش‌آماده‌ی نود (Bottlerocket در AWS با معماری دو جلدی)، استریمینگ مدل (NVIDIA Run:ai Model Streamer که به‌صورت توکار در vLLM وجود دارد)، اسنپ‌شات‌های حافظه‌ی GPU (چک‌پوینت‌های Modal با راهاندازی مجدد تا 10 برابر سریعتر)، وارم‌پول‌ها (
min_workers=1)، بارگذاری لایه‌ای (پایپ‌لاین NVMe→DRAM→HBM در ServerlessLLM با کاهش 10 تا 200 برابری تاخیر)، به‌همراه الگوی ششم امتیازی: مهاجرت زنده که به‌جای کش کلید-مقدار (چند گیگابایت)، توکنهای ورودی (چند کیلوبایت) را جابهجا میکند. Modal حداقل زمان راهاندازی سرد را 2 تا 4 ثانیه اعلام کرده است؛ Baseten این زمان را به‌طور پیش‌فرض 5 تا 10 ثانیه و با پیش‌گرم‌کردن زیر یک ثانیه ارائه می‌دهد. در این درس یاد می‌گیرید این پنج لایه را بسنجید، برای هزینه‌شان برنامه‌ریزی کنید و آن‌ها را روی هم سوار کنید.
اهداف یادگیری
- پنج لایه‌ی کاهش زمان راهاندازی سرد را نام ببرید و برای هر لایه یک ابزار یا الگو مثال بزنید.
- مجموع زمان راهاندازی سرد را از حاصل‌جمع (تخصیص نود) + (دانلود وزنها) + (بارگذاری وزنها در HBM) + (راهاندازی موتور پردازشی) برای یک مدل 70B محاسبه کنید.
- توضیح دهید چرا در مهاجرت زنده به‌جای کش کلید-مقدار (چند گیگابایت)، توکنهای ورودی (چند کیلوبایت) منتقل میشوند و جریمه‌ی این کار (محاسبهی دوباره) چیست.
- موازنه‌ی موجود در وارم‌پول (پرداخت هزینه برای GPU بیکار در برابر پذیرش تاخیر انتهای طیفِ راهاندازی سرد) و آستانه‌ی SLA را که در آن مقدار
min_workers > 0اجباری میشود، مشخص کنید.
صورت مسئله
اندپوینت بدون سرور مدل زبانی شما شب‌ها به صفر اسکیل میکند (Scale-to-zero). ساعت 8 صبح ترافیک ناگهان اوج می‌گیرد. اولین درخواست در صف انتظار می‌ماند تا این مراحل طی شوند:
- ابزار Karpenter یک نود GPU اختصاص می‌دهد: 45 تا 60 ثانیه.
- کانتینر ایمیجی 30 گیگابایتی حاوی وزنها را پول میکند: 120 تا 300 ثانیه.
- موتور پردازشی وزنها را روی HBM بارگذاری میکند: بسته به اندازه‌ی مدل و سرعت فضای ذخیره‌سازی، 45 تا 120 ثانیه.
- ابزار vLLM یا TRT-LLM بخش‌هایی مثل گراف‌های CUDA، استخر کش کلید-مقدار و توکنایزر را راهاندازی اولیه میکند: 10 تا 30 ثانیه.
در مجموع: 220 تا 510 ثانیه (تقریباً 3 تا 8 دقیقه) زمان میبرد تا حتی یک توکن برگردد، در حالی که SLA شما 2 ثانیه است. یک وارم‌پول با min_workers=1 بالا می‌آورید و مشکل به‌ظاهر محو میشود؛ اما حالا باید هزینه‌ی یک GPU بیکار را به‌صورت 24/7 بپردازید. اگر سرویس شما 5 محصول مختلف داشته باشد و برای هر کدام یک نمونه‌ی گرم نگه دارید، یعنی در ماه 3,600 = 30 × 24 × 5 ساعت هزینه برای GPU می‌دهید، چه حتی یک کاربر درخواست داده باشد و چه نداده باشد.
کاهش زمان راهاندازی سرد یعنی حفظ صرفه‌ی اقتصادی معماری بدون سرور، هم‌زمان با نزدیک‌شدن به تاخیر سیستم‌های همیشه‌روشن.
مفاهیم پایه
لایه‌ی 1 — ایمیج‌های ازپیش‌آماده‌ی نود (Bottlerocket)
روی AWS، معماری دو جلدی (Dual-volume) در Bottlerocket سیستم‌عامل را از داده‌ها جدا میکند. از دیسک داده که ایمیج کانتینر از قبل روی آن پول شده یک اسنپشات بگیرید؛ سپس شناسه اسنپشات را در EC2NodeClass ثبت کنید. نودهای جدید طوری بوت میشوند که وزنها از قبل روی NVMe محلی قرار دارند؛ با این کار مرحله‌ی 2 و بخشی از مرحله‌ی 3 حذف میشوند. این روش به‌خوبی و به‌شکل توکار با Karpenter کار میکند. دستاورد معمول آن: 2 تا 4 دقیقه صرفه‌جویی در هر راهاندازی سرد برای مدل‌های بزرگ.
معادل این کار در GCP: ساخت ایمیج‌های سفارشی VM با لایه‌های کانتینری ازپیش‌پخته‌شده (Pre-baked). در Azure: استفاده از اسنپ‌شات‌های دیسک مدیریت‌شده (Managed disk) با همین الگو.
لایه‌ی 2 — استریمینگ مدل (Run:ai Model Streamer)
به‌جای اینکه پیش از پاسخ به اولین درخواست صبر کنید تا تمام فایل بارگذاری شود، وزنها را لایه‌به‌لایه در حافظه‌ی GPU استریم کنید و پردازش را به‌محض مستقر شدن اولین بلوک ترنسفورمر شروع کنید. ابزار NVIDIA Run:ai Model Streamer به‌صورت توکار در نسخه‌ی 2026 فریم‌ورک vLLM ارائه میشود. این ابزار با S3، GCS و NVMe محلی کار میکند و با هم‌پوشانی ورودی/خروجی و آماده‌سازی محاسباتی، زمان بارگذاری وزنها را برای مدل‌های بزرگ تقریباً نصف میکند.
لایه‌ی 3 — اسنپ‌شات‌های حافظه‌ی GPU (پلتفرم Modal)
Modal بعد از اولین بارگذاری، یک چکپوینت از وضعیت GPU (وزنها، گراف‌های CUDA و ناحیه‌ی کش کلید-مقدار) تهیه میکند. ری‌استارت‌های بعدی داده‌ها را مستقیماً در HBM دی‌سریالایز (Deserialize) می‌کنند که 10 برابر سریعتر از راهاندازی اولیه است. این روش نزدیک‌ترین تجربه به «بوت‌کردن یک GPU آماده در 2 ثانیه» است. نکته‌ی موازنه: اسنپ‌شات‌ها وابسته به توپولوژی هر GPU هستند؛ یعنی اگر Karpenter شما را به مدل متفاوتی از سختافزار (SKU) منتقل کند، باید دوباره چکپوینت بسازید.
لایه‌ی 4 — وارم‌پول‌ها (min_workers=1)
ساده‌ترین راهکار: همیشه یک نمونه آماده نگه دارید. هزینه‌ی آن برابر با نرخ ساعتی یک GPU در طول 24/7 است. حساب‌وکتاب این روش برای مدل‌های کوچک بی‌رحمانه است (ساعتی 0.85 تا 1.50 دلار می‌پردازید تا جلوی یک راهاندازی سرد 30 ثانیه‌ای را بگیرید)، اما برای مدل‌های بزرگ به‌صرفه است (پرداخت 4 دلار در ساعت برای جلوگیری از راهاندازی سرد 5 دقیقه‌ای). آستانه‌ی SLA که در آن داشتن وارم‌پول اجباری میشود، معمولاً رسیدن به TTFT P99 زیر 60 ثانیه روی یک مدل 70B یا بزرگ‌تر است.
لایه‌ی 5 — بارگذاری لایه‌ای (ServerlessLLM)
پروژه‌ی ServerlessLLM با حافظه مثل یک ساختار سلسله‌مراتبی برخورد میکند: NVMe (سریع اما حجیم)، DRAM (متوسط اما طبقه‌بندی‌شده)، HBM (بسیار کم‌حجم اما آنی). وزنها ابتدا در DRAM بارگذاری میشوند؛ سپس بر اساس نیاز به HBM انتقال می‌یابند. مقاله‌ی این پروژه گزارش داده است که در بارگذاری‌های سرد، این روش تاخیر را در مقایسه با روش ساده‌ی دیسک به HBM، بین 10 تا 200 برابر کاهش می‌دهد. استفاده از این روش در محیط عملیاتی (پروداکشن) هنوز در مراحل اولیه است، اما هماهنگی‌هایی برای آن با vLLM وجود دارد.
لایه‌ی 6 — مهاجرت زنده (الگوی امتیازی)
وقتی نودی از دسترس خارج میشود (به دلیل لغو نمونه‌های اسپات یا تخلیه‌ی نود)، رویکرد سنتی این است که نمونه‌ی دیگری به‌صورت سرد راهاندازی شده و صف درخواست‌ها خالی شود. در مهاجرت زنده، توکنهای ورودی (چند کیلوبایت) به مقصدی که مدل را آماده در حافظه دارد منتقل میشوند و کش کلید-مقدار روی مقصد دوباره محاسبه میشود. محاسبهی دوباره بسیار ارزانتر از انتقال چند گیگابایت کش کلید-مقدار از طریق شبکه است. این روش برای معماری‌های استقرار مجزا (Disaggregated deployments) کاربرد دارد.
محاسبات اقتصادی وارم‌پول
برای سرویسی با SLA تاخیر P99 TTFT برابر با 2 ثانیه، سوال این نیست که «وارم‌پول داشته باشیم یا نه»، بلکه این است که «چند نمونه‌ی آماده نگه داریم و به کدام مسیرها اختصاص دهیم».
- مسیرهای تعاملی باارزش (چت زنده، ایجنت صوتی):
min_workers=1-2. - مسیرهای پردازش دسته‌ای پس‌زمینه (دسته‌بندی شبانه): اسکیل به صفر پذیرفته میشود و راهاندازی سرد 5 تا 10 دقیقه‌ای قابل‌تحمل است.
- پلن‌های ویژه: تعیین
min_workersاختصاصی برای هر مشتری سازمانی با ظرفیت رزروشده.
اول بسنجید، بعد بهینهسازی کنید
کالبدشکافی راهاندازی سرد برای یک مدل 70B روی نودی تازه (نمونه‌ی تقریبی):
| مرحله | زمان | راهکار کاهش زمان |
|---|---|---|
| تخصیص نود | 50 ثانیه | Bottlerocket به‌همراه ایمیج ازپیش‌آماده، وارم‌پول |
| پول‌کردن ایمیج | 180 ثانیه | دیسک داده‌ی ازپیش‌آماده (حذف کامل) |
| انتقال وزنها به HBM | 75 ثانیه | استریمر مدل (نصف‌کردن زمان)؛ اسنپشات GPU (حذف کامل) |
| راهاندازی موتور پردازشی | 20 ثانیه | کش دائمی گراف‌های CUDA |
| اولین عبور رفت (Forward) | 3 ثانیه | حداقل تاخیر ذاتی پردازش |
| کل زمان سرد | 328 ثانیه | |
| کل زمان با اعمال راهکارها | حدود 15 ثانیه | 22 برابر کاهش |
اعدادی که باید به خاطر بسپارید
- راهاندازی سرد در Modal: بین 2 تا 4 ثانیه (با اسنپ‌شات‌های GPU).
- راهاندازی سرد پیش‌فرض در Baseten: بین 5 تا 10 ثانیه؛ با پیش‌گرم‌کردن زیر یک ثانیه.
- راهاندازی سرد مدل 70B در حالت خام: 3 تا 8 دقیقه.
- ابزار Run:ai Model Streamer: حدود 2 برابر سرعت بیشتر در بارگذاری وزنها.
- بارگذاری لایه‌ای در ServerlessLLM: کاهش 10 تا 200 برابری تاخیر (بر اساس ارقام مقاله).
استفاده در عمل
فایل code/main.py مسیر راهاندازی سرد را در دو حالتِ بدون راهکارها و همراه با هر یک از آن‌ها مدل‌سازی میکند. این اسکریپت مجموع زمان راهاندازی سرد، هزینه‌ی وارم‌پول، و نرخ درخواستی را گزارش می‌دهد که در آن، هزینه‌ی وارم‌پول با صرفه‌جویی حاصل سر‌به‌سر میشود.
تحویل پروژه
در این درس فایل outputs/skill-cold-start-planner.md ساخته میشود. این ابزار بر اساس SLA، اندازه‌ی مدل و الگوی ترافیک، مشخص میکند کدام راهکارها باید با هم ترکیب شوند.
تمرین‌ها
- اسکریپت
code/main.pyرا اجرا کنید. نرخ درخواستی را محاسبه کنید که بالاتر از آن، داشتن یک نمونه‌ی آماده ارزانتر از پرداخت هزینه‌ی تاوان راهاندازی سرد از طریق ریزش درخواست‌ها فراتر از SLO تمام شود. - می‌خواهید مدلی 13B را با SLA تاخیر P99 TTFT برابر با 3 ثانیه مستقر کنید. ساده‌ترین پشته‌ی راهکارها (با کمترین لایه‌های ممکن) را برای رسیدن به این هدف انتخاب کنید.
- استفاده از ایمیج ازپیش‌آماده در Bottlerocket مرحله‌ی پول‌کردن ایمیج را حذف میکند، اما وزنها همچنان باید از اسنپشات روی HBM بارگذاری شوند. اگر دیسک NVMe متصل به اسنپشات با سرعت 7 گیگابایت بر ثانیه بخواند، زمان واقعی بارگذاری را برای یک مدل 70B حساب کنید.
- ارائه‌دهنده‌ی بدون سرور شما اسنپ‌شات‌های GPU (مشابه Modal) ارائه می‌دهد و تیم شما مخالفت میکند چون «اسنپ‌شات‌ها باعث نشت داده‌های حساس کاربران (PII) میشوند». از هر دو دیدگاه دفاع کنید؛ خطر واقعی چیست و چه راهکاری (اسنپ‌شات‌های کوتاه‌مدت، رمزنگاری، ایزولاسیون با Namespace) برای آن وجود دارد؟
- یک خط‌مشی سلسله‌مراتبی برای وارم‌پول طراحی کنید: برای کاربران پولی، کاربران نسخه‌ی آزمایشی و تسک‌های دسته‌ای به چه تعداد نمونه‌ی آماده نیاز است؟ محاسبات خود را نشان دهید.
اصطلاحات کلیدی
| اصطلاح | چیزی که در مکالمات می‌گویند | معنای دقیق فنی |
|---|---|---|
| راهاندازی سرد (Cold start) | «مکث بزرگ اولیه» | زمان از رسیدن درخواست تا اولین توکن روی نمونه‌ای تازه |
| وارم‌پول (Warm pool) | «حداقل همیشه روشن» | تنظیم min_workers >= 1 برای آماده نگه‌داشتن حداقل یک نمونه |
| ایمیج ازپیش‌آماده (Pre-seeded image) | «امی پخته‌شده (Baked AMI)» | ایمیج نود که وزن‌های کانتینر از قبل در آن قرار دارد |
| باتل‌راکت (Bottlerocket) | «سیستم‌عامل نودهای AWS» | سیستم‌عامل بهینه‌شده‌ی کانتینری AWS با پشتیبانی از اسنپشات دیسک دو جلدی |
| استریمر مدل (Model streamer) | «بارگذاری استریمینگ» | هم‌پوشانی ورودی/خروجی وزنها با راهاندازی محاسبات |
| اسنپشات GPU (GPU snapshot) | «چکپوینت روی HBM» | سریالایز وضعیت GPU پس از بارگذاری؛ دی‌سریالایز مستقیم هنگام ری‌استارت |
| بارگذاری لایه‌ای (Tiered loading) | «استفاده از NVMe + DRAM + HBM» | سلسله‌مراتب لایه‌های ذخیره‌سازی؛ بارگذاری بر حسب تقاضا |
| مهاجرت زنده (Live migration) | «انتقال توکن‌ها» | انتقال ورودی (چند کیلوبایت)، محاسبهی دوباره‌ی کش کلید-مقدار در مقصد |
min_workers |
«نمونه‌های آماده» | حداقل تعداد نمونه‌های زنده در معماری بدون سرور |
| اسکیل به صفر (Scale-to-zero) | «معماری کاملاً بدون سرور» | بدون هزینه در زمان بیکاری؛ پذیرش کامل تاوان راهاندازی سرد |
برای مطالعه‌ی بیشتر
- Modal — Cold start performance — بنچمارک‌های منتشرشده و معماری چکپوینت در پلتفرم Modal.
- AWS Bottlerocket — الگوی اسنپشات دیسک داده‌ی ازپیش‌آماده.
- NVIDIA Run:ai Model Streamer — هم‌پوشانی بارگذاری وزنها با آماده‌سازی محیط محاسباتی.
- Baseten — Cold starts — راهنمای عملی پیش‌گرم‌کردن سرورها.
- مقاله‌ی ServerlessLLM در USENIX OSDI'24 — طراحی بارگذاری لایه‌ای.
- NVIDIA — Disaggregated LLM Inference on Kubernetes — مهاجرت زنده در سیستم‌های استقرار مجزا.