زیرساخت ابری برای پروژه‌های هوش مصنوعی؛ از آزمایش تا استقرار

بیشتر تیم‌ها پروژه هوش مصنوعی را با یک نوت‌بوک روی لپ‌تاپ شروع می‌کنند و تا مدتی همه‌چیز خوب پیش می‌رود. مشکل از جایی شروع می‌شود که داده‌ها بزرگ‌تر می‌شوند، چند نفر هم‌زمان روی یک مدل کار می‌کنند و مدیر محصول می‌پرسد «کی می‌توانیم این را به مشتری‌ها نشان دهیم؟». از این نقطه به بعد، زیرساخت هوش مصنوعی دیگر موضوعی فرعی نیست؛ تصمیم‌هایی که درباره سرور، ذخیره‌سازی، شبکه و روش استقرار می‌گیرید، مستقیم روی سرعت تیم، کیفیت سرویس و هزینه ماهانه اثر می‌گذارد.

در این راهنما مسیر پروژه را از اولین آزمایش تا سرویس پایدار دنبال می‌کنیم و برای هر مرحله توضیح می‌دهیم چه منابعی لازم است و کجا می‌شود صرفه‌جویی کرد؛ بدون خرید زودهنگام سخت‌افزار گران.

چرا پروژه هوش مصنوعی زیرساخت متفاوتی می‌خواهد؟

یک وب‌سایت معمولی الگوی مصرف نسبتاً قابل پیش‌بینی دارد: چند سرور برنامه، یک پایگاه‌داده و مقداری فایل. پروژه‌های هوش مصنوعی از چند جهت با این الگو فرق دارند. اول، مصرف منابع در آن‌ها جهشی است؛ یک دوره آموزش یا تنظیم دقیق (Fine-tuning) ممکن است چند ساعت یا چند روز منابع سنگین بخواهد و بعد تا هفته‌ها نیازی به آن نباشد. دوم، حجم داده‌ها معمولاً خیلی بیشتر از نرم‌افزارهای عادی است و این داده باید نسخه‌بندی، پاک‌سازی و بارها خوانده شود. سوم، خود مدل یک دارایی حساس است: فایل وزن‌های مدل، داده آموزشی و سوابق پرسش و پاسخ کاربران همه باید محافظت شوند.

پس به‌جای کپی کردن معماری یک فروشگاه اینترنتی، هر مرحله از چرخه عمر مدل را جدا ببینید و برای همان مرحله منبع مناسب بگیرید.

سه مرحله، سه نیاز متفاوت

چرخه عمر بیشتر پروژه‌های هوش مصنوعی را می‌توان در سه مرحله خلاصه کرد که هر کدام منابع و هزینه متفاوتی دارند.

مرحله آزمایش و نمونه اولیه

در این مرحله تیم داده را بررسی می‌کند، مدل‌های آماده را امتحان می‌کند و ایده را روی نمونه کوچک می‌سنجد. برای این کار یک سرور ابری با پردازنده و حافظه کافی، یک دیسک ابری جدا برای داده‌ها و محیطی مانند JupyterLab معمولاً کافی است. بسیاری از مدل‌های کوچک و فشرده‌شده، به‌ویژه برای دسته‌بندی متن، استخراج اطلاعات یا ساخت بردار معنایی (Embedding)، روی پردازنده هم با سرعت قابل‌قبول اجرا می‌شوند. با پرداخت ساعتی، سرور آزمایشی را وقتی لازم نیست حذف کنید و داده‌هایش را روی دیسک جدا یا در فضای ذخیره‌سازی فایل نگه دارید.

مرحله آموزش و تنظیم دقیق

اگر قرار است مدلی را روی داده‌های خودتان تنظیم کنید، به توان پردازشی بالا و دسترسی سریع به داده نیاز پیدا می‌کنید. برای مدل‌های بزرگ این کار عملاً به GPU نیاز دارد؛ اما پیش از آن بپرسید آیا واقعاً به آموزش نیاز دارید یا روش‌هایی مثل RAG و طراحی دقیق پرامپت مسئله را حل می‌کنند. روش‌های سبک مانند LoRA و QLoRA هزینه آموزش را بسیار کم می‌کنند. در هر حال، کار آموزش را یک کار زمان‌دار ببینید: منابع را برای مدت مشخص بگیرید، نقاط ذخیره (Checkpoint) را مرتب در فضای ذخیره‌سازی فایل بنویسید و بعد از پایان کار منابع را آزاد کنید.

مرحله استقرار و سرویس‌دهی

وقتی مدل آماده شد، باید پشت یک API پایدار قرار بگیرد تا چند کاربر یا چند نرم‌افزار هم‌زمان از آن استفاده کنند. اینجا اولویت‌ها عوض می‌شود: زمان پاسخ، پایداری، مقیاس‌پذیری، پایش و امنیت مهم‌تر از توان خام هستند. این مرحله معمولاً بیشترین هزینه بلندمدت را دارد، چون سرویس باید همیشه در دسترس بماند و با رشد کاربران بزرگ شود.

سرور برای هوش مصنوعی: پردازنده، GPU یا هر دو؟

یکی از رایج‌ترین اشتباه‌ها این است که همه بخش‌های پروژه هوش مصنوعی روی سخت‌افزار گران اجرا شود. در عمل، بخش بزرگی از کار هر سیستم هوشمند روی پردازنده معمولی انجام می‌شود:

• پیش‌پردازش داده، تبدیل فرمت فایل‌ها، پاک‌سازی متن و تقسیم اسناد به قطعه‌های کوچک روی پردازنده انجام می‌شود و بیشتر به حافظه و سرعت دیسک وابسته است.
• API‌های واسط، صف پیام، پایگاه‌داده، سرویس احراز هویت و داشبوردها هیچ نیازی به GPU ندارند و روی سرور ابری معمولی کم‌هزینه‌تر و ساده‌تر اجرا می‌شوند.
• مدل‌های کوچک، مدل‌های Embedding سبک و مدل‌های فشرده‌شده برای بار کم را اغلب می‌توان روی پردازنده اجرا کرد.
• اجرای مدل‌های زبانی بزرگ با تعداد زیاد کاربر هم‌زمان و آموزش مدل‌های سنگین معمولاً به GPU نیاز دارد.

پیشنهاد عملی این است که بخش‌های سبک را از بخش‌های سنگین جدا کنید. به این ترتیب منابع گران فقط برای کاری استفاده می‌شود که واقعاً به آن نیاز دارد و بقیه سیستم روی سرور ابری یا سرور اختصاصی اجرا می‌شود. سرورهای ابری ابر درسا برای بخش‌های پردازنده‌محور مناسب‌اند؛ اگر پروژه‌تان به GPU نیاز دارد، آن را جداگانه تأمین کنید و بقیه اجزا را کنار آن بچینید.

ذخیره‌سازی داده هوش مصنوعی؛ هر چیز را کجا نگه داریم

جای نگهداری داده در پروژه هوش مصنوعی به اندازه خود مدل اهمیت دارد. سه نوع ذخیره‌سازی در این پروژه‌ها نقش‌های متفاوتی دارند:

• فضای ذخیره‌سازی فایل (Object Storage) برای داده‌های خام، مجموعه‌داده‌های نسخه‌بندی‌شده، فایل وزن‌های مدل، نقاط ذخیره آموزش و آرشیو لاگ‌ها مناسب است. این فضا جدا از سرور رشد می‌کند و چند سرور می‌توانند هم‌زمان از آن بخوانند.
• دیسک ابری برای داده‌ای مناسب است که باید با سرعت بالا و نزدیک به پردازش خوانده و نوشته شود؛ مثلاً فضای موقت آموزش یا نسخه محلی مدل روی سرور سرویس‌دهی.
• پایگاه‌داده مدیریت‌شده برای متادیتا، نتایج ارزیابی، سوابق کاربران و در پروژه‌های RAG برای نگهداری متن و بردارها کاربرد دارد. PostgreSQL همراه افزونه‌ای مانند pgvector یکی از انتخاب‌های رایج برای بردارهاست؛ پیش از انتخاب، در دسترس بودن افزونه را در نسخه موردنظر بررسی کنید.

یک قاعده ساده کمک زیادی می‌کند: داده اصلی هیچ‌وقت فقط روی دیسک یک سرور نماند. سرور ممکن است حذف یا جایگزین شود، اما مجموعه‌داده و مدل باید مستقل از آن باقی بمانند. نسخهٔ پشتیبان منظم و اسنپ‌شات پیش از تغییرات مهم را هم از روز اول جدی بگیرید.

شبکه، جداسازی و دسترسی

سرویس‌های هوش مصنوعی معمولاً به داده‌های حساس سازمان دسترسی دارند؛ از اسناد داخلی تا سوابق مشتری. بهتر است سرور مدل، پایگاه‌داده و پردازش‌های داخلی از طریق شبکهٔ خصوصی پروژه با هم ارتباط داشته باشند و فقط یک ورودی کنترل‌شده از اینترنت در دسترس باشد. فایروال را طوری تنظیم کنید که درگاه‌های مدیریتی و API داخلی مدل فقط از نشانی‌های مجاز قابل دسترسی باشند و برای ورودی عمومی از توزیع‌کنندهٔ بار استفاده کنید تا بتوانید چند نمونه از سرویس را پشت آن اجرا کنید.

برای سازمان‌هایی که به دلیل الزامات قانونی یا سیاست داخلی نمی‌خواهند داده از دیتاسنتر خودشان خارج شود، پلتفرم ابر خصوصی سازمانی امکان می‌دهد همین الگوهای ابری (پرتال درخواست، سهمیه، مراحل تأیید و آماده‌سازی خودکار) روی سرورهای خود سازمان پیاده شوند.

استقرار مدل هوش مصنوعی در محیط اصلی

استقرار مدل هوش مصنوعی در محیط اصلی بیش از اجرای یک دستور ساده است. مدل باید در کانتینر بسته‌بندی شود، نسخه‌اش مشخص باشد، با افزایش بار تعداد نمونه‌هایش بیشتر شود و اگر نسخه جدید مشکل داشت، بتوان سریع به نسخه قبل برگشت. کوبرنتیز دقیقاً برای همین کارها ساخته شده است: زمان‌بندی کانتینرها روی سرورها، بررسی سلامت، مقیاس‌دهی خودکار و به‌روزرسانی تدریجی.

اگر نرم‌افزار را روی کوبرنتیز اجرا می‌کنید، سرویس انتشار خودکار نرم‌افزار ابر درسا کد و تنظیمات را از مخزن Git برمی‌دارد و روی کوبرنتیز منتشر می‌کند؛ همیشه معلوم است کدام نسخه در حال اجراست و بازگشت به نسخه قبل از پنل ممکن است. این قابلیت پیگیری برای مدل‌ها اهمیت زیادی دارد.

پیش از استقرار، معیارهای زمان پاسخ، درخواست هم‌زمان قابل‌تحمل، نرخ خطا و هزینه هر هزار درخواست را تعریف کنید تا بدانید زیرساخت کافی است یا بیش از اندازه بزرگ.

چک‌لیست راه‌اندازی زیرساخت هوش مصنوعی

• هدف کسب‌وکاری و معیار موفقیت پروژه را پیش از تهیه هر منبعی مکتوب کنید.
• مشخص کنید کدام بخش‌ها واقعاً به GPU نیاز دارند و کدام روی پردازنده اجرا می‌شوند.
• داده‌های خام و مدل‌ها را در فضای ذخیره‌سازی فایل با نام‌گذاری و نسخه‌بندی روشن نگه دارید.
• سرور مدل و پایگاه‌داده را در شبکهٔ خصوصی قرار دهید و فقط ورودی لازم را باز کنید.
• برای محیط آزمایش و محیط اصلی پروژه‌های جدا بسازید.
• برای مدل و داده بکاپ منظم و پیش از تغییرات مهم اسنپ‌شات داشته باشید.
• زمان پاسخ، نرخ خطا و هزینه را از روز اول پایش کنید.
• منابع آزمایشی بلااستفاده را حذف کنید.

پرسش‌های متداول

برای شروع پروژه هوش مصنوعی حتماً به GPU نیاز داریم؟

نه لزوماً. بسیاری از پروژه‌ها با مدل‌های آماده، مدل‌های کوچک یا فراخوانی API یک مدل بیرونی شروع می‌شوند و مرحله آزمایش روی سرور ابری معمولی انجام می‌شود. GPU وقتی لازم می‌شود که مدل بزرگ را خودتان اجرا یا آموزش دهید یا تعداد کاربران هم‌زمان زیاد باشد.

ابر عمومی بهتر است یا ابر خصوصی؟

به حساسیت داده و الزامات سازمان بستگی دارد. استارتاپ‌ها و تیم‌های کوچک معمولاً با ابر عمومی سریع‌تر و کم‌هزینه‌تر شروع می‌کنند. بانک‌ها و سازمان‌هایی که داده‌شان نباید از دیتاسنتر خودشان خارج شود، معمولاً ابر خصوصی یا ترکیبی از هر دو را انتخاب می‌کنند.

هزینه زیرساخت هوش مصنوعی را چطور برآورد کنیم؟

منابع هر مرحله را جدا حساب کنید: سرورهای آزمایشی بر اساس مدت نگهداری، فضای ذخیره‌سازی بر اساس حجم داده و سرویس اصلی بر اساس بار پیش‌بینی‌شده. برای بخش‌های ابری می‌توانید از ابزار محاسبهٔ قیمت ابر درسا کمک بگیرید و بعد با داده واقعی مصرف، برآورد را اصلاح کنید.