خلاصه اجرایی: طراحی Private AI از Use Case و حساسیت داده آغاز میشود. سپس مدل سرویس، Runtime، GPU allocation، VKS/Kubernetes، شبکه، Storage، Registry، Observability، Security و Capacity مشخص میشوند. VCF میتواند زیرساخت یکپارچه را فراهم کند، اما موفقیت به Operating Model، تیم و کنترل چرخه عمر AI وابسته است.
چرا GPU Server بهتنهایی پلتفرم AI نیست؟
GPU توان محاسباتی میدهد، اما سرویس AI به مسیر داده، Model registry، Runtime، Scheduling، Secret، Network، Storage، Monitoring و فرایند Release نیاز دارد. اگر این اجزا طراحی نشوند، GPU گرانقیمت میتواند با Utilization پایین، صف نامعلوم و ریسک امنیتی بالا باقی بماند.
همچنین Training، Fine-tuning، RAG و Inference نیازهای متفاوتی دارند. یک معماری واحد بدون تفکیک این Workloadها معمولاً یا بیشازحد گران است یا SLO را پوشش نمیدهد.
Use Case → Data classification → Service model → Runtime → Capacity → Hardware. شروع از مدل کارت GPU، تصمیمهای قبلی را به یک خرید قفل میکند.
Use Case و حساسیت داده نقطه شروعاند
| Use Case | الگوی غالب | داده کلیدی | سؤال معماری |
|---|---|---|---|
| RAG سازمانی | Inference + retrieval | اسناد داخلی و Vector index | داده کجا میماند و دسترسی چگونه کنترل میشود؟ |
| Fine-tuning | Compute burst و Dataset نسخهدار | Training data و Checkpoint | GPU scheduling و reproducibility چگونه است؟ |
| Model serving | Latency و Availability | Model artifact و request log | SLA، autoscaling و rollback مدل چیست؟ |
| تحلیل Batch | Throughput و زمانبندی | حجم زیاد داده | Data locality و پنجره پردازش چگونه مدیریت میشود؟ |
برای هر Use Case باید Owner، کاربران، سطح محرمانگی، Latency، Throughput، Availability، retention و روش پذیرش مدل مشخص شود. عبارت «چتبات داخلی» بدون این دادهها قابل Sizing نیست.
لایههای معماری Private AI روی VCF
Infrastructure
VCF، Compute، GPU، Network، vSAN/Storage و Availability.
Platform
VKS/Kubernetes، GPU Operator/Driver، Registry، Secret و Observability.
AI Runtime
Framework، Model server، Pipeline، Vector database و API gateway.
Governance
Identity، Data policy، Model approval، Audit، Cost و Responsible AI controls.
مرز مسئولیت باید روشن باشد. تیم زیرساخت GPU و Cluster را اداره میکند؛ Platform team Runtime و Delivery را؛ Data/AI team مدل و Dataset را؛ Security نیز Policy و Audit را تعریف میکند. اگر همه مسئولاند، عملاً هیچکس Owner نیست.
Kubernetes و Runtime؛ پلتفرم توسعه را فراموش نکنید
VKS میتواند مبنای اجرای Workloadهای Containerized باشد، اما Cluster creation پایان کار نیست. Namespace/Tenant، quota، image policy، registry، network policy، persistent storage، secret management، logging و upgrade cadence باید طراحی شوند.
برای VM-based AI نیز همین اصول وجود دارد، فقط ابزار متفاوت است. انتخاب Container یا VM باید از نیاز Vendor، Isolation، Portability، Skill و Operations بیاید.
پلتفرم AI باید Version matrix داشته باشد: VCF/ESXi، Driver، CUDA یا Runtime، Kubernetes، Operator، Framework و Model server. تغییر یک لایه میتواند کل زنجیره را تحت تأثیر قرار دهد.
مدل تخصیص GPU
Dedicated GPU، Sharing، Partitioning و Scheduling هرکدام Trade-off دارند. Workload حساس به Latency ممکن است Isolation بیشتری بخواهد؛ محیط تحقیق ممکن است از اشتراکگذاری و صفبندی ارزش بگیرد. Entitlement، پشتیبانی Hardware/Driver و محدودیت نسخه باید در همان Design بررسی شوند.
| مدل | مزیت | ریسک | مناسب برای |
|---|---|---|---|
| اختصاصی | Isolation و Performance قابل پیشبینی | Utilization پایینتر | Inference بحرانی یا Workload خاص |
| اشتراکی/زمانبندیشده | استفاده بهتر از ظرفیت | Noisy neighbor و پیچیدگی Scheduling | تحقیق، Batch و تیمهای متعدد |
| Partitioned | مرز منابع روشنتر | وابستگی به Hardware/Software support | سرویسهای استاندارد با اندازه مشخص |
Storage و Data Path
داده Training، Document corpus، Vector index، Model artifact، Checkpoint و Log نیازهای متفاوتی دارند. Throughput ترتیبی، IOPS کوچک، ظرفیت، retention، encryption و immutability باید برای هر کلاس مشخص شوند.
Data locality میتواند Performance را بهتر کند اما Governance و Backup را سختتر کند. Object، File و Block باید براساس API و Lifecycle انتخاب شوند. اگر قابلیتی در وضعیت Tech Preview است، نباید بدون تأیید Support وارد Production baseline شود.
Network و Security برای AI
ترافیک East-West میان Workerها، دسترسی به Data source، Model registry، API مصرفکننده و ابزار Monitoring باید روی نقشه باشد. Bandwidth، latency، MTU، firewall و egress policy روی زمان Training و کیفیت سرویس اثر دارند.
- جداسازی Management، Data، Training و Serving در حد نیاز؛
- کنترل Egress برای Download مدل و Package؛
- ثبت منشأ Artifact و جلوگیری از Model/Container نامعتبر؛
- Secret و Service account با کمترین سطح دسترسی؛
- رمزنگاری و Audit برای داده حساس؛
- Rate limit و API authentication برای Model serving.
Governance فقط امنیت شبکه نیست
باید معلوم باشد چه کسی اجازه ورود Dataset، استفاده از Model، انتشار Endpoint و نگهداری Prompt/Response log را دارد. Data retention و حق دسترسی میتواند با قوانین داخلی یا قرارداد مشتری محدود شود.
Register
Dataset، Model، License، Owner و Source ثبت میشوند.
Evaluate
کیفیت، امنیت، Bias، Performance و محدودیت Use Case سنجیده میشوند.
Approve
نسخه قابل انتشار و دامنه مصرف مشخص میشود.
Observe
Drift، latency، cost، error و رفتار سرویس پایش میشوند.
Retire
Endpoint، Artifact و داده طبق فرایند کنترلشده جمعآوری میشوند.
Observability از GPU Utilization فراتر است
GPU memory و utilization مهماند، اما SLO سرویس با latency، queue time، token/throughput، error rate، model quality، data freshness و cost per request سنجیده میشود. زیرساخت و AI telemetry باید به یک Service view متصل شوند.
Runbookهای Day-۲ شامل Driver/Runtime upgrade، Node failure، capacity exhaustion، model rollback، registry outage، secret rotation و incident data handling هستند.
Capacity Planning و رشد
برای هر Workload باید Concurrency، Model size، precision، context/input size، batch، latency target و ساعات Peak ثبت شود. Benchmark باید با Model و Dataset نماینده انجام شود. نتیجه یک مدل یا کارت را نمیتوان به همه Use Caseها تعمیم داد.
Demand
کاربر، درخواست، Job، زمان و رشد.
Supply
GPU، CPU، RAM، Storage و Network قابل استفاده.
Policy
Quota، Priority، Reservation و Admission.
Trigger توسعه باید با Lead time خرید GPU و سرور هماهنگ باشد. ظرفیت رزرو بدون Owner هزینه ایجاد میکند؛ نبود ظرفیت رزرو نیز SLA را شکننده میکند.
Private AI در محیط Disconnected
در محیط قطع از اینترنت، مسئله فقط انتقال Model نیست. Container image، package، driver، chart، vulnerability data و license artifact باید با منشأ، checksum، تأیید و مسیر خروج مشخص وارد شوند. Registry و Repository داخلی به همراه Quarantine zone لازماند.
بهروزرسانی دورهای، Emergency patch، ثبت استثنا و انتقال Support bundle نیز باید در Operating Model تعریف شود. مقاله VCF در محیط Disconnected این چرخه را کاملتر توضیح میدهد.
سناریوی نمونه: سرویس RAG داخلی
سازمان میخواهد اسناد محرمانه را بدون خروج داده جستوجو و خلاصه کند. ابتدا سندها طبقهبندی و ACLها به Retrieval منتقل میشوند. سپس Model serving، Embedding، Vector store، API و Logging طراحی میشوند. Pilot با گروه کاربری محدود و سؤالهای مرجع اجرا میشود.
معیار پذیرش فقط سرعت پاسخ نیست: جلوگیری از دسترسی متقاطع، Citation درست، latency، نرخ پاسخ نامعتبر، هزینه ظرفیت و روش حذف سند نیز سنجیده میشوند. پس از Pilot، GPU sizing و Scale-out بر مبنای Demand واقعی انجام میشود.
پرسشهای متداول
آیا برای Private AI حتماً Kubernetes لازم است؟
نه برای هر Use Case؛ اما برای سرویسدهی چندتیمی و Containerized، Kubernetes میتواند Operating Model منسجمتری بدهد. انتخاب به Workload و Skill بستگی دارد.
آیا داده در Private AI هیچوقت از سازمان خارج نمیشود؟
این نتیجه فقط با طراحی Egress، Integration، Support و Supply chain قابل اثبات است. کلمه Private بهتنهایی تضمین فنی نیست.
چند GPU لازم است؟
بدون Model، concurrency، latency، batch و benchmark نماینده، عدد معتبر نیست.
آیا همه مدلهای متنباز برای استفاده سازمانی مجازند؟
خیر. License، منشأ، امنیت و محدودیت تجاری هر Model باید بررسی شود.
منابع رسمی و یادداشت فنی
- معرفی رسمی VCF ۹.۱ و تمرکز Private Cloud/AI
- اعلام رسمی VCF ۹.۱.۱ و قابلیتهای AI/Operations
- مقایسه رسمی قابلیتهای VCF
پشتیبانی GPU، Driver، Runtime و قابلیتهای AI باید براساس Compatibility و Entitlement همان زمان تأیید شود.
برای مطالعه بعدی
Private AI را از Use Case و داده طراحی کنید
پیش از خرید GPU، معماری Data، Runtime، Security، Capacity و عملیات را به یک تصمیم قابل سنجش تبدیل کنید.