تصور کنید می‌خواهید زیرساختی بسازید که هزاران عامل هوش مصنوعی را در محیط‌های کاملاً ایزوله و سریع اجرا کند؛ در این سطح از پیچیدگی، کتابخانه‌های آماده دیگر پاسخگو نیستند. برای دستیابی به این سطح از کنترل، BoxLite در ۱۱ اکتبر ۲۰۲۶ اعلام کرد که برای مدیریت دقیق‌تر میکرو-VMها، کتابخانه libkrun را کنار گذاشته و یک مانیتور ماشین مجازی (VMM) اختصاصی توسعه می‌دهد تا قدرت سخت‌افزاری ایزولاسیون را به حداکثر برساند.
BoxLite محیطی سبک است که در آن هر «باکس» یک تصویر OCI را اجرا کرده و وضعیت خود را در هر نوبت (Turn) حفظ می‌کند. برای تحقق این هدف، سیستم به یک VMM نیاز دارد؛ یعنی فرآیندی که حافظه مهمان را مدیریت می‌کند، vCPUها را می‌سازد و دستگاه‌ها را شبیه‌سازی می‌کند تا بتواند با هایپروایزرهایی مثل KVM در لینوکس یا Hypervisor.framework در مک ارتباط برقرار کند. این رویکرد بهینه‌سازی لایه‌های مجازی‌سازی یادآور است که چگونه داکر از سال ۲۰۱۶ برای بهبود عملکرد کانتینرها از microVMها استفاده کرده است.
زمینه: نقش VMM در معماری
در معماری BoxLite، محیط اجرا برای هر باکس یک boxlite-shim ایزوله ایجاد می‌کند. درون این شیم، VMM وظیفه اجرای میکرو-VM را بر عهده دارد. در حالی که هایپروایزر (KVM یا Hypervisor.framework) مسئول اجرای دستورات مهمان روی CPU است، VMM به عنوان یک فرآیند معمولی در اطراف آن عمل می‌کند. این VMM مسئول تخصیص رم مهمان از حافظه میزبان، بارگذاری هسته (Kernel) و شبیه‌سازی تک‌تک دستگاه‌هایی است که مهمان با آن‌ها تعامل دارد.
در مراحل اولیه، BoxLite از libkrun استفاده می‌کرد چون API ساده‌ای بر پایه زبان C داشت و بدون نیاز به یک دیمون (Daemon) پس‌زمینه، روی هر دو سیستم‌عامل مک و لینوکس کار می‌کرد. این رویکرد کتابخانه‌ای به BoxLite اجازه می‌داد تا مستقیماً در یک اپلیکیشن جاسازی شود بدون اینکه به دسترسی روت (Root) نیاز باشد. libkrun همچنین هسته مهمان (libkrunfw) را به همراه ابزارهایی مثل virtio-fs ،virtio-blk و vsock به صورت یک بسته ارائه می‌داد.
جزئیات: چرا libkrun جایگزین شد؟
به گزارش تیم توسعه، با رشد پلتفرم، محدودیت‌های طراحی libkrun به گلوگاه تبدیل شد. در مستندات libkrun صراحتاً ذکر شده است که «تبدیل شدن به یک VMM عمومی» و «سازگاری با انواع بار کاری» جزو اهداف این پروژه نیستند؛ و نیازهای BoxLite دقیقاً از این مرزها فراتر رفت.
بر اساس تحلیل‌های فنی، سه مشکل ساختاری وجود داشت:
- خروجی فرآیند (Process Outcomes): libkrun خودش فرآیند را می‌بندد، به این معنی که فراخواننده هیچ وضعیت خروجی (Exit Status) دریافت نمی‌کند. هرگونه شکست در شروع به کار صرفاً با کد
-EINVALبازمی‌گردد. - پایداری هسته: بارگذاری هسته مهمان (
libkrunfw) از طریقdlopenانجام می‌شود که باعث شکست‌های مکرر در میزبان‌های مختلف شده است؛ در Issue #1512 شش مورد از این اتفاقات ثبت شده است. - کمبود منابع دستگاه (Device Exhaustion): هر حجم دایرکتوری به دستگاه مجزایی نیاز دارد. وقتی یک باکس سعی می‌کند از سه حجم استفاده کند، با خطای
IrqsExhaustedمتوقف شده و استارت نمی‌شود (Issue #935).
برای پیشروی در پیاده‌سازی قابلیت‌های با کارایی بالای عامل‌های هوش مصنوعی، تیم به VMMی نیاز دارد که کنترل کامل آن در دست خودشان باشد. این استقلال اجازه می‌دهد قابلیت‌های زیر پیاده‌سازی شوند:
- یکپارچگی با GPU: که برای شتاب‌دهی به بارهای کاری عامل‌محور (Agentic Workloads) ضروری است. در این راستا، انتخاب موتور مناسب برای اجرای مدل‌ها نیز حیاتی است، مشابه آنچه در مقایسه vLLM و Ollama برای مدیریت همزمانی مدل‌ها بررسی شده است.
- اسنپ‌شات حافظه: فعال‌سازی قابلیت AutoPause (Issue #1003) برای مدیریت بهینه و سریع وضعیت.
- تغییر اندازه زنده (Live Resizing): اجازه می‌دهد تا نقاط اتصال (Mounts) بدون نیاز به توقف سیستم، به صورت Hot-plug اضافه یا تغییر اندازه دهند.
پیاده‌سازی: توسعه در فضای باز
توسعه این VMM به صورت مجموعه‌ای از Pull Requestهای عمومی پیش می‌رود. تیم BoxLite قصد فورک کردن یا وصله زدن به libkrun را ندارد؛ بلکه libkrun بدون تغییر باقی می‌ماند تا زمانی که VMM جدید به پیش‌فرض تبدیل شود. سپس برای یک نسخه به عنوان جایگزین (Fallback) باقی می‌ماند و در نهایت حذف خواهد شد.
تیم کار را با یک مهمان ۷ بایتی بسیار ساده برای تست بک‌اند KVM شروع کرد. این مهمان از دستورات زیر استفاده می‌کرد: mov dx, 0x3f8 (برای پورت سریال COM1)، mov al, 'K'، out dx, al (برای تحریک یک KVM exit به سمت VMM) و در نهایت hlt. این آزمایش ساده ثابت کرد که حلقه اجرای vCPU تا زمان خروج، مدیریت آن خروج و شروع مجدد حلقه به درستی کار می‌کند.
نقشه راه و نقاط عطف
طبق گزارش blog.boxlite.ai، نقشه راه این پروژه به پنج مرحله (Milestone) تقسیم شده است:
- M1 (اولین بوت): تمرکز بر اولین بوت روی تراشه‌های اپل (Apple Silicon)، رمزگشایی خروجی‌ها و اطمینان از اینکه یک هسته واحد روی سه میزبان مختلف کار می‌کند.
- M2–M3 (اولین باکس): پیاده‌سازی
virtioاز صفر، دیسک‌ها، سوکت‌ها، شبکه و یک دستگاهvirtio-fsبرای هر حجم. این مرحله شامل قرار دادن عامل (Agent) به عنوان PID 1 است. - M4–M5 (عرضه نهایی): مقاوم‌سازی سیستم به گونه‌ای که ورودی‌های مهمان هرگز باعث Panic میزبان نشود، اندازه‌گیری عملکرد در برابر libkrun و حذف کامل libkrun.
تا ۱۱ اکتبر ۲۰۲۶، طراحی و قرارداد هایپروایزر برای KVM و Hypervisor.framework تکمیل شده است. آن‌ها KVM را روی x86_64 (شامل I/O completion، kicks و MSRs) با موفقیت پیاده کرده‌اند و یک بیلد بازتولیدپذیر از هسته پین‌شده لینوکس ۶.۱۲ را ساخته‌اند. در حال حاضر، تمرکز روی M1 برای معماری arm64 در مک و لینوکس است.
این چرخش نشان‌دهنده ترندی بزرگ‌تر در زیرساخت‌های AI است؛ جایی که مجازی‌سازی «به اندازه کافی خوب» جای خود را به زیرساخت‌های تخصصی می‌دهد. با مالکیت VMM، BoxLite می‌تواند مرز بین میزبان و مهمان را بهینه کند و سربار (Overhead) را برای عامل‌هایی که باید سریعاً اجرا و متوقف شوند، کاهش دهد.
برای توسعه‌دهندگان، این یعنی VMM جدید برای استفاده از کنترل‌کننده وقفه داخلی در Hypervisor.framework به macOS 15 یا نسخه‌های جدیدتر نیاز دارد. کاربرانی که از نسخه‌های ۱۲ تا ۱۴ مک استفاده می‌کنند، تا زمان انتقال نهایی از libkrun استفاده خواهند کرد.
مشارکت‌کنندگان علاقه‌مند می‌توانند پیشرفت پروژه را از طریق گیت‌هاب، به‌ویژه وظایف باز در Issue #1698 (مانند بک‌اند Hypervisor.framework، پشتیبانی از KVM arm64 و بارگذارهای هسته) دنبال کنند.
گام بعدی شما
- اگر از محیط‌های ایزوله برای اجرای عامل‌ها استفاده می‌کنید، تغییرات Issue #1698 در گیت‌هاب را دنبال کنید.
- سیستم خود را به macOS 15 به‌روزرسانی کنید تا از قابلیت‌های جدید Hypervisor.framework بهره‌مند شوید.
- عملکرد VMM جدید را در برابر libkrun در بنچمارک‌های آینده مقایسه کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو