پیش از سفارش تجهیزات Private AI باید ظرفیت بودجه زمان اجرا و مسئول عملیات روشن شوند

این مقاله مسیر یک جلسه نیازسنجی مدیریتی را توضیح می‌دهد. هدف، تهیه Bill of Materials نیست؛ سازمان باید پیش از آن درباره نوع مصرف، سطح خدمت، بودجه، زمان، مالکیت و توسعه آینده تصمیم بگیرد. مشخصات فنی پس از این تصمیم‌ها دقیق‌تر و قابل دفاع‌تر می‌شوند.

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

از کاربرد اولیه شروع کنیم

عبارت «زیرساخت AI» دامنه بسیار بزرگی دارد. ممکن است سازمان محیط آزمایش برای چند تیم، ظرفیت تحلیل اسناد، پردازش تصویر یا سرویس داخلی پرتکرار بخواهد. هر سناریو الگوی مصرف، حساسیت داده و زمان پاسخ متفاوت دارد. بدون فهرست کاربردهای اولیه، Capacity Planning به مقایسه نام پردازنده‌ها محدود می‌شود.

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

تیم‌ها و ساعات مصرف را بشناسیم

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

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

Baseline را با اندازه‌گیری بسازیم

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

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

ظرفیت شتاب‌دهنده تنها ظرفیت مهم نیست

در گفت‌وگوی Private AI توجه معمولاً روی GPU یا شتاب‌دهنده است، اما داده باید از Storage به پردازش برسد و نتیجه در شبکه منتقل شود. CPU، RAM، IOPS، Throughput و Latency می‌توانند گلوگاه بسازند. زیرساخت نامتوازن باعث می‌شود گران‌ترین منبع منتظر بماند.

تست باید مسیر کامل را بسنجد. زمان آماده‌سازی داده، بارگذاری، اجرای Job، ذخیره نتیجه و آزادکردن منبع کنار هم قرار می‌گیرند. طراحی شبکه و Storage باید با الگوی مصرف هماهنگ باشد. بزرگ‌کردن یک جزء همیشه عملکرد کل را بهتر نمی‌کند.

بودجه را به فازهای تصمیم متصل کنیم

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

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

زمان تأمین با زمان بهره‌برداری فرق دارد

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

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

دیتاسنتر باید توان میزبانی واقعی را داشته باشد

تجهیزات پرتراکم ممکن است برق و خنک‌سازی متفاوتی بخواهند. ظرفیت اسمی دیتاسنتر با ظرفیت قابل استفاده در Rack یکسان نیست. مسیر برق، PDU، وزن، جریان هوا، فضای فیزیکی و کابل‌کشی باید بررسی شوند. این موارد اگر دیر دیده شوند، پروژه با وجود تحویل تجهیزات متوقف می‌ماند.

تیم Facility باید از مرحله نیازسنجی حضور داشته باشد. برنامه توسعه ظرفیت و محدودیت‌های نگهداری نیز ثبت شوند. گاهی انتخاب تعداد بیشتر Node کم‌تراکم یا استفاده از سرویس، از بازطراحی فوری سایت عملی‌تر است.

شبکه باید داده و مدیریت را جدا ببیند

زیرساخت اختصاصی به شبکه مدیریت، دسترسی کاربران، انتقال داده و ارتباط میان Nodeها نیاز دارد. پهنای باند و Latency هر مسیر متفاوت است. همچنین Segment و سیاست امنیتی باید دسترسی واحدها را محدود کند. یک شبکه عمومی برای همه نقش‌ها دامنه آسیب را افزایش می‌دهد.

اتصال به سامانه‌های داخلی، Directory، مخزن داده و ابزار Monitoring از پیش مشخص می‌شود. مسیرهای خروج نیز باید بر اساس سیاست سازمان کنترل شوند. تغییرات فایروال و DNS بخشی از برنامه اجرا هستند، نه کارهای پس از نصب.

Storage را بر اساس جریان داده طراحی کنیم

سازمان باید بداند داده از کجا می‌آید، در چه قالبی نگهداری می‌شود، چه مقدار فعال است و نتیجه تا چه زمانی باقی می‌ماند. Dataset فعال، فضای موقت پردازش، Artifactها و Backup نیاز یکسانی ندارند. قرار دادن همه روی سریع‌ترین لایه هزینه را بالا می‌برد.

File، Block یا Object بر اساس روش دسترسی انتخاب می‌شوند. Lifecycle می‌تواند داده کم‌مصرف را به لایه اقتصادی‌تر منتقل کند. ظرفیت قابل استفاده، رشد Metadata و دوره نگهداری در برآورد دیده می‌شوند. پاک‌کردن خودکار نیز باید با مالک داده هماهنگ باشد.

امنیت از روز طراحی وارد می‌شود

Private AI اختصاصی به معنای امنیت خودکار نیست. هویت، نقش، شبکه، رمزنگاری، مدیریت کلید، Patch، ثبت فعالیت و جداسازی محیط‌ها باید طراحی شوند. حساب مدیریتی مشترک یا مسیر دسترسی بدون MFA می‌تواند مزیت کنترل داخلی را تضعیف کند.

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

Backup و بازیابی را بر اساس ارزش داده تعریف کنیم

همه اجزای محیط نیازمند Backup یکسان نیستند. بعضی Nodeها را می‌توان از روی الگو بازسازی کرد، اما Dataset، تنظیمات، Metadata یا خروجی تأییدشده ممکن است حیاتی باشند. RPO و RTO برای هر گروه مشخص می‌شوند و روش بازیابی آزمایش می‌گردد.

مخزن Backup بهتر است از دامنه مدیریتی تولید جدا و در برابر حذف یا تغییر محافظت شود. ظرفیت و پنجره بکاپ با حجم داده هماهنگ می‌شوند. بازیابی یک نمونه قبل از بهره‌برداری، اطمینان بیشتری از گزارش Job موفق می‌دهد.

Availability را به اهمیت کاربرد وصل کنیم

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

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

مدل عملیات را پیش از تحویل تعریف کنیم

چه کسی ظرفیت را تخصیص می‌دهد، کاربران را می‌سازد، Patch را اجرا می‌کند، رخداد را پاسخ می‌دهد و مصرف را گزارش می‌کند؟ اگر پاسخ همه موارد «تیم زیرساخت» باشد، باید ظرفیت و مهارت این تیم سنجیده شود. زیرساخت AI به عملیات منظم و چندرشته‌ای نیاز دارد.

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

Chargeback یا Showback رفتار مصرف را شفاف می‌کند

وقتی منابع برای کاربران رایگان و نامرئی به نظر می‌رسند، Jobهای رهاشده و رزروهای طولانی افزایش می‌یابند. Showback می‌تواند مصرف هر واحد را بدون دریافت هزینه نشان دهد. Chargeback در صورت سیاست سازمان هزینه را به مرکز مربوط تخصیص می‌دهد.

هدف تنبیه استفاده نیست؛ مدیران باید بدانند ظرفیت کجا مصرف می‌شود و کدام پروژه برای توسعه اولویت دارد. گزارش مصرف باید قابل فهم، منظم و مرتبط با بودجه باشد. داده آن به Capacity Planning فاز بعد کمک می‌کند.

مدل اختصاصی را با سرویس Multi Tenant مقایسه کنیم

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

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

معیار پذیرش را پیش از سفارش بنویسیم

معیار تحویل نباید فقط روشن‌شدن تجهیزات باشد. دریافت ظرفیت توسط کاربر مجاز، اجرای بار نماینده، عملکرد Storage و Network، ثبت مانیتورینگ، Backup، Failover و پاسخ تیم عملیات باید آزموده شوند. هر معیار عدد یا نتیجه قابل تأیید دارد.

مسئول پذیرش نیز مشخص است. تیم فنی سلامت اجزا را تأیید می‌کند و مالک کاربرد نتیجه کار را می‌سنجد. موارد باز با تاریخ اصلاح ثبت می‌شوند. پرداخت و تحویل می‌توانند به نقاط مشخص پروژه متصل شوند.

ریسک‌های وابستگی و توسعه آینده را ببینیم

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

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

نقش راگا در جلسه نیازسنجی اختصاصی

راگا می‌تواند جلسه را از کاربرد، الگوی مصرف، حساسیت داده و زمان کسب‌وکار آغاز کند. سپس ظرفیت Compute، Network، Storage، Backup و Security به‌صورت یک معماری واحد سنجیده می‌شوند. خروجی شامل سناریوهای ظرفیت، فاز اجرا، برآورد مسئولیت و معیار پذیرش خواهد بود.

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

قطعه یدکی و زمان تعمیر را پیش‌بینی کنیم

Availability فقط با افزونگی نرم‌افزاری تأمین نمی‌شود. خرابی شتاب‌دهنده، منبع تغذیه یا جزء شبکه ممکن است به قطعه جایگزین نیاز داشته باشد. دسترسی محلی، زمان تحویل و مهارت تعویض باید در طراحی دیده شوند. برای جزء حیاتی، نگهداری Spare یا قرارداد پاسخ سریع می‌تواند توجیه داشته باشد.

همه قطعات به ذخیره محلی نیاز ندارند. تحلیل اثر خرابی و Lead Time تعیین می‌کند کدام مورد ارزش سرمایه‌گذاری دارد. فهرست قطعات و Firmware سازگار نیز با تغییر پلتفرم به‌روز می‌شود.

انرژی و نرخ استفاده را در اقتصاد پروژه ببینیم

منبعی که بیشتر زمان بیکار است، همچنان برق، خنک‌سازی و سرمایه مصرف می‌کند. گزارش Utilization به مدیریت نشان می‌دهد آیا ظرفیت باید بین تیم‌ها به اشتراک گذاشته، زمان‌بندی یا آزاد شود. نرخ استفاده پایین ممکن است مدل Multi Tenant را برای فاز اولیه جذاب‌تر کند.

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

فرایند خرید باید امکان آزمون و اصلاح داشته باشد

پیشنهاد می‌تواند فاز طراحی، پایلوت، تأمین و تحویل را جدا کند. نتیجه پایلوت ممکن است نسبت اجزای Compute و Storage را تغییر دهد. اگر همه سفارش پیش از اندازه‌گیری قطعی شود، امکان اصلاح کم می‌شود. شروط پذیرش و تغییر دامنه باید در قرارداد دیده شوند.

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

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

این تصمیم بازبینی می‌شود.

تصمیم پیش از سفارش

مدیرعامل سازمان سفارش را متوقف نمی‌کند، اما آن را به تکمیل یک Assessment کوتاه مشروط می‌سازد. دو کاربرد اولیه و یک سناریوی رشد انتخاب می‌شوند. تیم مصرف، زیرساخت، امنیت، دیتاسنتر و مالی هرکدام فرض‌های خود را ثبت می‌کنند. یک پایلوت کوچک نیز Baseline مصرف را می‌سازد.

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

چک‌لیست تصمیم‌گیری

• نیاز و مالک کسب‌وکاری مشخص باشد.
• نوع داده و محدودیت دسترسی ثبت شود.
• ظرفیت پایه و اوج مصرف جدا محاسبه شوند.
• مدل اختصاصی یا Multi‑Tenant با معیار مشترک مقایسه شود.

سؤالات متداول

Private AI را از کجا شروع کنیم؟

از یک نیاز تأییدشده، مالک مشخص، نوع داده، الگوی مصرف و معیار موفقیت شروع کنید؛ نه از فهرست تجهیزات.

زیرساخت اختصاصی بهتر است یا سرویس Multi‑Tenant؟

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

ظرفیت Private AI چگونه تعیین می‌شود؟

هم‌زمانی، زمان پاسخ، حجم داده، دسترس‌پذیری، رشد و ظرفیت رزرو باید کنار هم سنجیده شوند.

منابع

[۱] NIST — چارچوب مدیریت ریسک هوش مصنوعی مشاهده منبع

[۲] Microsoft Learn — ملاحظات هزینه و مصرف در راهکارهای Multi Tenant مشاهده منبع

مطالب مرتبط در سایت راگا

برای تکمیل این مسیر، راهنمای Private AI روی VCF و مقاله «در اختلال Private AI زیرساخت باید مسئولیت و سطح خدمت روشن باشد» را ببینید.