به گزارش از وبسایت cncf، مایکل تروتمن در 16 ژوئیه 2026 مطلبی منتشر کرد که در آن به پروژه‌های LINBIT و CNCF اشاره شده است و اجرای بارهای کاری مدل‌های زبان بزرگ (LLM) به‌صورت محلی را بررسی می‌کند. 🧠

سرویس‌های API مدیریت‌شده برای بسیاری از بارهای کاری مناسب هستند، اما میزبانی شخصی (self-hosting) به‌عنوان گزینه‌ای مکمل برای برخی تیم‌ها جذاب است؛ به‌ویژه زمانی که پیش‌بینی هزینه در حجم درخواست بالا، نیاز به کنترل بیشتر روی تأخیر، یا الزام به نگهداری داده‌ها از منظر قراردادی یا نظارتی مطرح باشد. ☁️🔒

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

در مثال این مطلب، انتخاب‌ها شامل vLLM برای استنتاج و LINSTOR® برای ذخیره‌سازی دائمی هستند. هدف نشان دادن چگونگی راه‌اندازی این پشته در محیط خوشه‌ای Kubernetes است.

پیشینه vLLM: vLLM یک موتور استنتاج منبع باز و با کارایی بالا برای LLMها است که برای ارائه همزمانی بالا در محیط خوشه طراحی شده است. یکی از ویژگی‌های کلیدی vLLM در این سناریو، ارائه یک REST API سازگار با OpenAI است؛ بنابراین هر ابزاری که پیش‌تر با OpenAI API کار کرده باشد (مانند LangChain، LlamaIndex، یا کدهایی که OpenAI SDK را فراخوانی می‌کنند) را می‌توان تنها با تغییر URL به یک نمونه vLLM میزبانی‌شده ارجاع داد. این سازگاری، معماری ترکیبی را به گزینه‌ای عملی تبدیل می‌کند.

نمای کلی: دستورالعمل‌های راه‌اندازی در این مقاله از یک خوشه Kubernetes استفاده می‌کنند که LINSTOR ذخیره‌سازی دائمی را از طریق درایور Container Storage Interface (CSI) فراهم می‌آورد. Kubernetes نقش لایه ارکستراسیون را برای کل پشته ایفا می‌کند و ادغام ذخیره‌سازی از استاندارد CSI که در اکوسیستم Cloud Native رایج است پیروی می‌کند.

LINSTOR راه‌حلی متن‌باز و تعریف‌شده با نرم‌افزار است که بر پایه DRBD® ساخته شده و ذخیره‌سازی بلوک تکراری را در سراسر نودها فراهم می‌کند. این ذخیره‌سازی تکراری برای نگهداری وزن‌های مدل بزرگ مناسب است، زیرا در مواجهه با راه‌اندازی مجدد پاد یا خرابی نود، دسترسی به فایل‌ها حفظ می‌شود. 💾

مدلی که در این راهنما استفاده شده meta-llama/Llama-3.2-1B-Instruct است؛ یک مدل کوچک اما توانمند از Meta که برای پیروی از دستورالعمل‌های کاربر تنظیم شده است. با حدود 1B پارامتر می‌تواند روی CPU اجرا شود که برای آزمایشگاه‌هایی بدون نودهای GPU اختصاصی مهم است، در حالی که برای آزمون و تنظیمات مفید باقی می‌ماند.

پیش‌نیازها: پیش از استقرار در Kubernetes لازم است به خود مدل دسترسی داشته باشید. مدل‌های Meta Llama روی Hugging Face میزبانی می‌شوند و پیش از دانلود باید دسترسی آنها دریافت شود. مراحل کلی عبارت‌اند از: ایجاد حساب در huggingface.co، مراجعه به صفحه مدل Llama-3.2-1B-Instruct و ارسال درخواست دسترسی، و پس از تأیید، ایجاد یک token دسترسی با مجوز خواندن در تنظیمات حساب Hugging Face. آن توکن را در دسترس داشته باشید زیرا در مراحل بعدی لازم خواهد شد.

علاوه بر این برای درخواست PersistentVolumeClaims به LINSTOR در Kubernetes و تعریف StorageClass مناسب برای بارهای Kubernetes به پیکربندی نیاز دارید. اپراتور Piraeus که منبع‌باز است، LINSTOR و درایور LINSTOR CSI را در Kubernetes فراهم می‌کند و راه‌اندازی را مستند می‌کند. در ادامه یک PersistentVolumeClaim از StorageClass ای به‌نام linstor-csi-lvm-thin-r2 ایجاد خواهد شد.

استقرار شامل سه منبع Kubernetes می‌شود: یک PersistentVolumeClaim برای ذخیره‌سازی مدل، یک Secret برای توکن Hugging Face، و یک Deployment و Service برای اجرای سرور استنتاج. این PVC از کلاس ذخیره‌سازی linstor-csi-lvm-thin-r2 استفاده می‌کند که یک حجم LVM نازک با دو کپی (replica) در سراسر خوشه ارائه می‌دهد؛ این ویژگی هم افزونگی و هم استفاده بهینه از فضای دیسک را تضمین می‌کند، که در شرایطی که وزن مدل‌ها می‌تواند ده‌ها گیگابایت باشد اهمیت زیادی دارد.

mountPath کانتینر بر روی /root/.cache/huggingface تنظیم می‌شود؛ این مسیر محلی است که vLLM وزن‌های مدل دانلودشده را ذخیره می‌کند. با پشتیبان‌گذاری این مسیر روی یک حجم دائمی، مدل تنها یک‌بار از Hugging Face بارگیری می‌شود و پس از آن حتی پس از راه‌اندازی مجدد پادها، نیازی به دانلود دوباره نیست زیرا فایل‌ها روی ذخیره‌سازی دائمی تامین‌شده توسط LINSTOR باقی می‌مانند.

دستور زیر برای ایجاد Secret و PVC (نمونه‌ای از دستور) آورده شده است:

cat