NixOS در برابر سیستم‌عامل استاندارد DGX در مدیریت workloads

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

بسیاری از متخصصان هوش مصنوعی از DGX OS استفاده می‌کنند که در واقع نسخه‌ای تغییریافته از اوبونتو است؛ محیطی راحت اما فاقد کنترل نسخه‌های سخت‌گیرانه‌ای که برای تکرار دقیق آزمایش‌ها حیاتی است. پروژه nixos-dgx-spark که در ۲ اوت ۲۰۲۶ منتشر شد، این محدودیت را می‌شکند. این پروژه به پژوهشگران اجازه می‌دهد سیستم‌عامل NixOS — مانند یک دستور پخت دقیق که هر جزئیات آن ثبت شده تا هر کسی همان غذا را بپزد — را روی سیستم‌های NVIDIA DGX Spark و Asus Ascent GX10 اجرا کنند.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی اهمیت زیرساخت‌های باز و مینیمال اشاره کردیم، حذف وابستگی به ایمیج‌های بسته سازنده، گام مهمی در مسیر استقلال پژوهشی است. در NixOS، کل سیستم‌عامل به عنوان یک عبارت تابعی تعریف می‌شود. به این معنا که هر درایور، پارامتر هسته و نسخه کتابخانه در یک فایل واحد اعلام می‌شود تا تنظیمات یک سیستم دقیقاً روی سیستم دیگر تکرار شود. برای کسانی که می‌خواهند با این مفاهیم آشنا شوند، توسعه‌دهنده پروژه یک سخنرانی کوتاه ۵ دقیقه‌ای (lightning talk) در Planet Nix ارائه کرده است تا دید بصری بهتری از این معماری فراهم کند.

طبق مستندات مخزن گیت‌هاب graham33، کاربران دو مسیر اصلی برای پیاده‌سازی این تنظیمات دارند. اول، پاک‌سازی کامل سیستم و نصب NixOS به عنوان سیستم‌عامل اصلی (Primary OS). دوم، نصب مدیریت بسته Nix روی اوبونتو (DGX OS موجود) برای استفاده از شل‌های (shells) بازتولیدپذیر بدون نیاز به حذف سیستم‌عامل فعلی.

برای کسانی که مسیر ترکیبی را انتخاب می‌کنند، نصب Nix از طریق نصب‌کننده رسمی با اجرای دستور sh <(curl -L https://nixos.org/nix/install) --daemon یا از طریق Determinate Nix Installer با دستور curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install الزامی است. برای بهره‌برداری کامل از ویژگی‌های این پروژه روی اوبونتو، کاربران باید قابلیت‌های flakes و nix-command را با افزودن عبارت experimental-features = nix-command flakes به فایل /etc/nix/nix.conf فعال کنند. این پیکربندی به توسعه‌دهندگان اجازه می‌دهد بدون دست کشیدن از اوبونتو، از «پلی‌بوک‌ها» یا همان محیط‌های توسعه پیش‌تنظیم شده استفاده کنند.

یکی از بزرگ‌ترین چالش‌ها در استفاده از Nix روی سیستم‌های غیر NixOS، شکاف بین برنامه‌های ساخته‌شده با Nix و درایورهای GPU میزبان است. این پروژه با استفاده از ابزار nix-gl-host این مشکل را حل کرده است. این ابزار اجازه می‌دهد باینری‌های ساخته‌شده با Nix بتوانند درایورهای گرافیکی میزبان را پیدا کنند و با آن‌ها ارتباط برقرار کنند.

در این مخزن، «devshells» این فرآیند را به صورت خودکار مدیریت می‌کنند. برای پلی‌بوک‌های بومی Nix، دستورات با nixglhost پیچیده (wrap) شده‌اند، به این معنی که توسعه‌دهندگان نیازی به پیکربندی دستی مسیرهای کتابخانه (library paths) ندارند تا پردازنده‌های گرافیکی با کد آن‌ها ارتباط برقرار کنند. برای سایر devshellها مانند محیط cuda، کاربران می‌توانند دستورات را به صورت دستی پیشوند بزنند، مثلاً: nix develop .#cuda nixglhost deviceQuery.

در بخش هسته (Kernel)، این پروژه یک ماژول اختصاصی ارائه می‌دهد که دو مسیر را پیش روی کاربر می‌گذارد. مسیر پیش‌فرض، یک هسته NVIDIA سفارشی است که یک بیلد خاص و بهینه شده دقیقاً برای سخت‌افزار DGX Spark است. این هسته سفارشی با مقایسه یادداشت‌های (annotations) دبیان توسط انویدیا و پیش‌فرض‌های NixOS ساخته شده است. این فرآیند یک پیکربندی موجز (terse configuration) ایجاد می‌کند که حجم متون و جزئیات را حدود ۸۲٪ نسبت به تنظیمات استاندارد کاهش داده و نگهداری و به‌روزرسانی آن را بسیار ساده‌تر می‌کند. این پیکربندی در فایل kernel-configs/nvidia-dgx-spark-<version>.nix ذخیره شده است.

به عنوان جایگزین، کاربران می‌توانند هسته استاندارد NixOS 6.17 را انتخاب کنند، اما توسعه‌دهنده هشدار می‌دهد که این مسیر در حال حاضر دچار مشکلات شبکه‌ای است. بنابراین برای حداکثر پایداری، استفاده از هسته بهینه‌شده انویدیا توصیه می‌شود.

برای مدیریت این هسته تخصصی، پروژه از یک خط لوله بازتولید (regeneration pipeline) از طریق دستور nix run .#generate-kernel-config استفاده می‌کند. این مکانیسم چهار مرحله کلیدی را طی می‌کند:
۱. دریافت سورس هسته انویدیا از گیت‌هاب.
۲. ساخت پیکربندی پایه (baseline) هسته NixOS.
۳. مقایسه یادداشت‌های انویدیا با پیش‌فرض‌های NixOS.
۴. تولید فایل پیکربندی موجز که تنها شامل تفاوت‌ها (differences) است.

این بازتولید زمانی لازم است که نسخه هسته انویدیا تغییر کند (به‌روزرسانی kernel-configs/nvidia-kernel-source.nix) یا اگر پیکربندی مشترک NixOS از طریق به‌روزرسانی nixpkgs تغییر یابد. همچنین توسعه‌دهندگان می‌توانند با استفاده از فلگ --kernel-source یک سورس محلی را تعیین کنند.

نصب NixOS به دلیل محدودیت‌های فرمویر (firmware) کارخانه، یک فرآیند تک‌کلیکی ساده نیست. نویسنده پروژه اشاره می‌کند که تنها DGX OS می‌تواند از فرمویر کارخانه بوت شود. در نتیجه، شما باید ابتدا فرمویر سیستم را با استفاده از DGX OS به‌روزرسانی کنید تا NixOS بتواند با موفقیت بوت شود. این ماژول قابلیت fwupd را برای به‌روزرسانی‌ها فعال می‌کند، زیرا انویدیا فرمویرهای DGX Spark را در سرویس LVFS (Linux Vendor Firmware Service) منتشر می‌کند.

برای شروع، کاربران یک ایمیج بوت USB را با دستور nix build .#usb-image می‌سازند و آن را با ابزار dd روی دیسک می‌نویسند. این ایمیج دو گزینه در منوی GRUB ارائه می‌دهد: هسته بهینه شده انویدیا (پیش‌فرض) برای پشتیبانی کامل از GPU و اترنت، یا هسته استاندارد NixOS 6.17. پس از غیرفعال کردن secure boot در BIOS، سیستم می‌تواند از USB بوت شده و طبق راهنمای استاندارد نصب NixOS پیکربندی شود.

برای استقرارهای بدون سرور (headless)، پشتیبانی آزمایشی از nixos-anywhere فراهم شده تا نصب از راه دور از طریق SSH با دستور nix run github:nix-community/nixos-anywhere ممکن شود. این ابزار دیسک NVMe را پارتیشن‌بندی کرده و NixOS را همراه با ماژول DGX Spark نصب می‌کند. کاربران می‌توانند پیکربندی‌های دیسک را با استفاده از فلگ --vm-test در یک ماشین مجازی تست کنند.

برای تسریع در فرآیند، یک قالب سریع (template) NixOS از طریق دستور nix flake init -t github:graham33/nixos-dgx-spark#dgx-spark در دسترس است. این دستور موارد زیر را تولید می‌کند:

• flake.nix: پیکربندی اصلی که ماژول DGX Spark را وارد می‌کند.
• configuration.nix: تنظیمات سیستم بهینه شده برای سخت‌افزار.
• hardware-configuration.nix: قالبی برای UUIDهای دستگاه‌ها.

پس از مقداردهی اولیه، کاربران باید UUIDهای واقعی را با دستور sudo nixos-generate-config --root /mnt --dir /tmp/nixos-config تولید کرده و جایگزین‌های (placeholders) فایل سخت‌افزار را پیش از استقرار نهایی با دستور sudo nixos-rebuild switch --flake /etc/nixos#dgx-spark جایگزین کنند.

این پروژه فراتر از سیستم‌عامل، مجموعه‌ای از «پلی‌بوک‌های» تأییدشده را ارائه می‌دهد که روی هر دو محیط NixOS و DGX OS تست شده‌اند:

• بازتولید کامل (Full Nix):

  • ComfyUI: برای تولید تصاویر هوش مصنوعی با مدل Stable Diffusion 1.5.
  • vLLM: سرورهای استنتاج (Inference)، از جمله مدل Qwen2.5-Math-1.5B-Instruct.
  • PyTorch Fine-tuning: تنظیم دقیق بومی بدون نیاز به کانتینرها.
  • Connect Two Sparks: لینک کردن سیستم‌ها از طریق QSFP.
  • NCCL: ارتباط GPUهای چندگانه در گره‌های مختلف (Multi-node).

• مبتنی بر کانتینر (via Podman):

  • FLUX.1 Dreambooth: تنظیم دقیق LoRA.
  • Multi-Agent Chatbot: استقرار و ساخت چت‌بات‌های چندعاملی.
  • Multi-modal Inference: مدل‌های بینایی-زبانی.
  • TRT-LLM: استنتاج بهینه شده.
  • NVFP4: کوانتش مدل‌ها به FP4 با TensorRT Model Optimizer.
  • Speculative Decoding: استنتاج سریع‌تر.

• ترکیبی (Nix + Container):

  • OpenShell: اجرای عامل‌های هوش مصنوعی امن و طولانی‌مدت در یک Sandbox که در آن ابزارهای CLI توسط Nix بسته‌بندی شده‌اند اما کانتینرها در زمان اجرا مدیریت می‌شوند.

از آنجا که ساخت بسته‌های CUDA از سورس بسیار کند است، این پروژه با حافظه جایگزین (binary cache) Flox ادغام شده است. Flox بسته‌های پیش‌ساخته aarch64-linux را برای cudatoolkit ،nccl ،cuDNN و PyTorch با اجازه رسمی انویدیا ارائه می‌دهد. با استفاده از حافظه Flox به عنوان یک substituter، زمان ساخت (build time) به‌شدت کاهش می‌یابد. ماژول NixOS در این پروژه این تنظیمات را به طور خودکار انجام می‌دهد.

کاربران مستقل Nix می‌توانند این مورد را به صورت دستی به /etc/nix/nix.conf اضافه کنند. برای این کار از URL خاص https://cache.flox.dev و کلید عمومی مورد اعتماد flox-cache-public-1:7F4OyH7ZCnFhcze3fJdfyXYLQw/aV7GEed86nQ7IsOs= استفاده می‌شود. علاوه بر این، پروژه از یک حافظه Cachix متعلق به graham33 برای ابزارهایی مانند داشبورد DGX و OpenShell استفاده می‌کند.

این زیرساخت، یک DGX Spark را از یک دستگاه سخت و بسته به یک آزمایشگاه برنامه‌پذیر تبدیل می‌کند. با حذف مشکل «روی سیستم من کار می‌کرد» (it works on my machine) در سطح سخت‌افزاری، پژوهشگران اکنون می‌توانند کل خوشه GPU خود را به صورت کد مدیریت کرده و کنترل نسخه کنند. برای نظارت لحظه‌ای، داشبورد DGX در آدرس http://localhost:11000 برای تله‌متری GPU و مانیتورینگ سیستم در دسترس است.

گام بعدی شما

• اگر از محدودیت‌های DGX OS خسته شده‌اید، ابتدا با نصب Nix روی اوبونتو و استفاده از nix-gl-host شروع کنید تا ریسک حذف سیستم‌عامل نداشته باشید.
• برای کاهش زمان بیلد مدل‌های سنگین، حتماً جایگزین Flox را در nix.conf فعال کنید.
• ساختار flake.nix این پروژه را بررسی کنید تا یاد بگیرید چگونه وابستگی‌های سخت‌افزاری را در سطح کد تعریف کنید.

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