زیرساخت‌های قابل جابه‌جایی در برابر مدل‌های بسته؛ نبردی بر سر مالکیت داده

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

به نقل از راهنمای فنی وب‌سایت dev.to که در ۲۶ اوت ۲۰۲۶ منتشر شد، رابط‌های انحصاری معمولاً محدودیت‌های کنترل داده و هزینه‌های متغیر و غیرقابل پیش‌بینی مصرف را پنهان می‌کنند. در مقابل، یک پشته (Stack) متن‌باز به سازمان‌ها اجازه می‌دهد تا امنیت، ذخیره‌سازی و سرویس‌دهی مدل را به‌طور کامل در اختیار داشته باشند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، شفافیت در لایه‌های زیرین، تنها راه مقابله با «قفل‌شدگی» (Vendor Lock-in) است. این رویکرد در حوزه‌های حساس، مشابه آنچه در استراتژی‌های امنیت ملی آمریکا برای مدل‌های وزن‌باز مشاهده می‌شود، برای حفظ حاکمیت بر داده‌ها حیاتی است.

در دنیای واقعی، اکثر شرکت‌ها در حال حاضر بر پلتفرم‌های یکپارچه‌ای متکی هستند که در آن داده‌ها و منطق برنامه به هم گره خورده و به دام افتاده‌اند. این وضعیت وابستگی شدیدی ایجاد می‌کند که در آن انتقال به یک ارائه‌دهنده جدید، مستلزم طراحی مجدد کل اپلیکیشن است. یک پشته متن‌باز — شبیه به مجموعه‌ای از قطعات لگو که هر کدام استاندارد خاص خود را دارند و به‌راحتی جایگزین می‌شوند — این ریسک‌ها را از طریق ارائه اجزای قابل حسابرسی و جایگزین‌پذیر حذف می‌کند. این ساختار اجازه می‌دهد زیرساخت در مراکز داده خصوصی، محیط‌های On-premises یا محیط‌های میزبانی سازگار اجرا شود. در این مدل، هر لایه به‌جای استفاده از APIهای بسته، از طریق استانداردهای مستند با لایه‌های دیگر ارتباط برقرار می‌کند.

طبق گزارش dev.to، یک معماری متن‌باز آماده برای تولید به ۶ لایه اصلی نیاز دارد:

• ارکستراسیون محاسبات (Compute Orchestration): زمان‌بندی بارهای کاری هوش مصنوعی روی گره‌های CPU و GPU و اعمال محدودیت‌های سخت‌گیرانه برای حافظه و منابع.
• رجیستری مدل (Model Registry): ذخیره نسخه‌های مختلف مدل، نتایج ارزیابی‌ها، متاداده‌ها و وضعیت تأیید نهایی مدل‌ها.
• لایه استنتاج (Inference Layer) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه به خودِ آشپزی و نه دوره‌ی آموزش آشپز — که مدل‌ها را بارگذاری کرده و نقاط اتصال (Endpoints) استاندارد REST یا gRPC را برای اپلیکیشن‌ها فراهم می‌کند.
• سرویس‌های داده: ارائه ذخیره‌سازی اشیاء (Object Storage)، بازیابی بردار معنایی (Vector Retrieval) — مثل کارت معرفی عددی برای هر واژه که همسایگانش را مشخص می‌کند — ذخیره‌سازی رابطه‌ای و پشتیبان‌های رمزنگاری‌شده.
• مشاهده‌پذیری (Observability): ثبت تأخیر (Latency)، مصرف توکن، بهره‌وری سخت‌افزار، خطاها و سیگنال‌های مربوط به کیفیت مدل.
• کنترل‌های شناسایی: اعمال دسترسی‌های مبتنی بر نقش (RBAC)، شناسایی بار کاری (Workload Identity)، ثبت لاگ‌های حسابرسی (Audit Logging) و محدودیت‌های شبکه.

برای حفظ قابلیت بازتولید (Reproducibility)، تمام اجزا باید به صورت تصاویر کانتینری سازگار با OCI بسته‌بندی شوند. این موارد باید از طریق مانیفست‌های زیرساختی تحت کنترل نسخه (Version-controlled) تعریف شوند تا از تبدیل شدن تغییرات پیکربندی مستند نشده به وابستگی‌های عملیاتی جلوگیری شود. این کار باعث می‌شود زیرساخت به کدی تبدیل شود که در هر محیطی با یک دستور ساده بازسازی شود.

در بحث استقرار هوش مصنوعی خصوصی، این راهنما توصیه می‌کند که «صفحه کنترل» (Control Plane - مدیریت) از «صفحه داده» (Data Plane - ترافیک) جدا شود. صفحه کنترل وظیفه مدیریت استقرارها و سیاست‌ها را بر عهده دارد، در حالی که صفحه داده، پرامپت‌ها و ترافیک استنتاج را پردازش می‌کند. این مرز باعث می‌شود حتی اگر یک سرویس مدیریت به خطر افتاد، پرامپت‌های حساس، Embeddingها، لاگ‌ها یا حافظه‌های موقت (Caches) لو نروند.

کنترل‌های امنیتی پیشنهادی شامل موارد زیر است:

• استفاده از شناسه‌های سازگار با OIDC به‌جای کلیدهای API دائمی.
• امضای تصاویر کانتینری و تأیید امضاها پیش از استقرار.
• تولید لیست مواد نرم‌افزاری (SBOM) برای هر نسخه منتشر شده.
• محدود کردن نقاط اتصال مدل از طریق شبکه‌های خصوصی و لیست‌های مجاز (Allowlists) صریح.
• ثبت تغییرات سیاست‌ها در لاگ‌های حسابرسی Append-only (فقط افزودنی).

شرکت‌هایی مانند DEEPBODY INC از این محلی‌سازی برای تبدیل دسترسی‌های قابل تأیید به یک الزام بنیادی استفاده می‌کنند، نه یک قابلیت جانبی. همچنین HONEYPOTZ INC تأکید می‌کند که قابلیت جابه‌جایی واقعی فراتر از جابه‌جایی کانتینرهاست؛ این امر مستلزم قراردادهای داخلی برای تله‌متری و ذخیره‌سازی است که به APIهای انحصاری متکی نباشند. آن‌ها پیشنهاد می‌کنند اجزا بر اساس تعهدات لایسنس، فرمت‌های باز داده، سازگاری سخت‌افزاری (شامل فرمت‌های مدل‌های کوانتیزه شده) و سرعت نگهداری توسط جامعه متن‌باز ارزیابی شوند تا «قفل‌شدگی‌های پنهان» شناسایی شوند. این رویکرد در صنایع مالی نیز بسیار مؤثر بوده و زیرساخت‌های متن‌باز AI سد ورود به معاملات کمّی سازمانی را شکسته‌اند.

برای توسعه‌دهندگان، این تغییر یعنی دیگر شما یک «پلتفرم» را انتخاب نمی‌کنید، بلکه سیستمی از قطعات جایگزین‌پذیر را سرهم می‌کنید. این بدان معناست که زیرساخت شما به کدی تبدیل می‌شود که برای بازیابی در برابر فاجه (Disaster Recovery)، می‌تواند در یک محیط دوم از طریق یک مانیفست بازسازی شود. این رویکرد زیرساخت هوش مصنوعی را به یک ابزار عمومی (Utility) تبدیل می‌کند که حتی در مراکز داده کاملاً ایزوله و بدون اتصال به اینترنت (Air-gapped) قابل اجراست، زیرا تیم‌ها می‌توانند کل محیط خود — شامل وابستگی‌ها و به‌روزرسانی‌های امنیتی — را آینه کنند. در واقع، کاهش هزینه‌های عملیاتی در صنعت کوانت گواهی بر کارآمدی این مدل از زیرساخت‌های باز است.

گام بعدی شما

• یک بار کاری کوچک و محدود برای استنتاج (Inference) را ایزوله کنید. پیش از مقیاس‌بندی به سیستم‌های بازیابی پیچیده، خط لوله‌های Fine-tuning یا عامل‌های خودمختار، ابتدا نسخه‌بندی، کنترل‌های دسترسی و تله‌متری را برای آن مستقر کنید.
• به جای کلیدهای API ثابت، از استانداردهای شناسایی OIDC برای مدیریت دسترسی‌ها استفاده کنید.
• لیست SBOM را برای هر نسخه‌ای که منتشر می‌کنید ایجاد کنید تا زنجیره تأمین نرم‌افزاری شما شفاف باشد.

اما استانداردسازی این لایه‌ها در لبه‌های شبکه در حال تکامل است؛ برای درک بیشتر، ظهور ابزارهای زیرساختی با تمرکز بر طول عمر مانند Private EDGE OS را دنبال کنید که هدفشان استانداردسازی بیشتر این لایه‌های باز است.