جداسازی درایورها از محیط اجرا؛ راهکار نهایی برای پایان «جهنم وابستگی‌ها» در

اگر هر بار برای پیکربندی یک ماشین لینوکس جهت یادگیری عمیق، ساعت‌ها وقت خود را تلف می‌کنید، تنها نیستید. طبق نظرسنجی مهندس حمزه (Engr. Hamza)، بیش از ۷۰٪ مهندسان MLOps هر بار در مواجهه با یک سیستم جدید، حداقل چهار ساعت را صرف حل تداخلات نرم‌افزاری می‌کنند. این ناکارآمدی سیستماتیک اغلب منجر به ایجاد محیط‌های غیرقابل بازتولید می‌شود که هنگام انتقال از یک کارت گرافیک RTX 4090 محلی به یک خوشه ابری در AWS یا GCP به‌طور ناگهانی کرش می‌کنند. نیمی از این تنظیمات در نهایت به محیط‌هایی ختم می‌شوند که هنگام انتقال به خوشه‌های استقرار (Staging) ابری، بدون هیچ هشدار قبلی و به‌صورت خاموش از کار می‌افتند.

راه‌اندازی محیط‌های هوش مصنوعی معمولاً به نبردی با درایورهای شکسته CUDA، تداخل کتابخانه‌های پایتون و خطاهای ناسازگاری glibc تبدیل می‌شود. بسیاری از توسعه‌دهندگان با سیستم‌های خود مثل یک محیط آزمایشگاهی (Sandbox) برخورد می‌کنند؛ یعنی دستور pip install را با دسترسی root اجرا می‌کنند یا اسکریپت‌های .run را مستقیماً از وب‌سایت انویدیا نصب می‌کنند. این کار یک شبکه شکننده از وابستگی‌ها می‌سازد که در آن یک به‌روزرسانی ساده درایور سیستم در پس‌زمینه، باعث عدم تطابق نسخه CUDA شده و خطاهای مبهمی مثل «نسخه درایور برای نسخه Runtime ناکافی است» (CUDA driver version is insufficient for CUDA runtime version) را ایجاد می‌کند.

مشکلی که همه نادیده می‌گیرند

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

• سطح سیستم: یک به‌روزرسانی هسته (Kernel Update) در اوبونتو باعث عدم تطابق درایور می‌شود. این چالش‌ها در نسخه‌های جدیدتر هسته لینوکس در حال بهینه‌تر شدن است؛ برای مثال لینوکس ۷.۲ با زمان‌بندی آگاه از حافظه پسماند تلاش کرده است تا اتلاف داده در پردازش‌های AI را کاهش دهد.
• سطح درایور: درایور سراسری NVIDIA یا CUDA Toolkit از کار می‌افتد.
• سطح اپلیکیشن: کتابخانه‌های PyTorch یا TensorFlow با کرش‌های خاموش یا خطای درایور متوقف می‌شوند.

این نبود ایزولاسیون به این معناست که محیط روی یک RTX 4090 محلی هیچ شباهتی به اهداف استقرار در AWS یا GCP ندارد. حتی تلاش‌ها برای استفاده از داکر (Docker) اغلب شکست می‌خورد؛ زیرا توسعه‌دهندگان همه چیز را در کانتینرهای عظیم و بهینه‌نشده بدون قلاب‌های (Hooks) درست درایور می‌ریزند. این امر منجر به شکست در Mountهای زمان اجرا، نبود حافظه مشترک IPC و کاهش شدید عملکرد GPU (Throttling) می‌شود.

راهکار، لایه‌بندی سخت‌گیرانه معماری و ایزولاسیون است. با تبدیل سیستم‌عامل پایه به یک پوشش نازک که فقط دسترسی سخت‌افزاری Bare-metal و خروجی تصویر پایدار را فراهم می‌کند و انتقال CUDA Toolkit به داخل کانتینرها، تضمین می‌کنید که به‌روزرسانی‌های میزبان هرگز وابستگی‌های پروژه را نمی‌شکنند. این رویکرد، صنعت را از «سیستم‌های شخصی» (Pet Workstations) به سمت «زیرساخت‌های اعلامی» (Declarative Infrastructure) می‌برد که در آن ماژول‌های هسته، APIهای درایور و محیط‌های پایتون به عنوان لایه‌های قابل جایگزین دیده می‌شوند.

بررسی سلامت سخت‌افزار

قبل از هر اقدامی، اعتبارسنجی لایه انتزاع سخت‌افزار ضروری است. یک ساختار مستحکم از یک اسکریپت Bash برای بازرسی سیستم استفاده می‌کند. این اسکریپت باید حضور دستگاه‌های PCI انویدیا را از طریق lspci تایید کند، سلامت درایور میزبان را با nvidia-smi بسنجد و تخصیص حافظه مشترک (/dev/shm) را بررسی کند؛ این مورد برای فرآیندهای DataLoader در PyTorch که از چند GPU استفاده می‌کنند، حیاتی است.

جزئیات اعتبارسنجی سخت‌افزاری

برای اطمینان از آمادگی سیستم برای بارهای کاری هوش مصنوعی، اسکریپت اعتبارسنجی باید بررسی‌های زیر را انجام دهد:

• تایید گذرگاه PCI: استفاده از lspci | grep -i nvidia برای تایید اینکه سخت‌افزار به‌طور فیزیکی توسط سیستم شناسایی شده است.
• ابزارهای درایور: تایید حضور nvidia-smi برای استعلام نام GPU و نسخه درایور میزبان.
• بررسی حافظه مشترک: اجرای df -h /dev/shm برای بررسی اندازه حافظه مشترک تخصیص یافته، زیرا این بخش یک گلوگاه رایج برای PyTorch است.
• متغیرهای محیطی: تنظیم CUDA_DEVICE_ORDER="PCI_BUS_ID" و PYTHONUNBUFFERED="1" برای استانداردسازی نحوه مدیریت ترتیب GPUها توسط سیستم‌عامل و لاگ‌های پایتون.

زیربنا: پاک‌سازی و آماده‌سازی

فرآیند با پاک‌سازی کامل درایورهای قدیمی، مخازن شکسته CUDA و بسته‌های متداخل نمایش شروع می‌شود. نادیده گرفتن این مرحله دلیل اصلی لوپ‌های بوت (Boot Loops) و کرش‌های مدیریت نمایش است. شما باید تمام ماژول‌های نصب‌شده انویدیا — شامل *nvidia* ،*cuda* ،*cudnn* و *xserver-xorg-video-nvidia* — را حذف کنید تا منابع نرم‌افزاری به یک خط پایه پاک بازگردند. این شامل حذف ورودی‌های PPA شخص ثالث مانند /etc/apt/sources.list.d/nvidia-ml.list و /etc/apt/sources.list.d/cuda*.list است.

سپس باید هدرهای هسته (Kernel Headers) و ابزارهای ساخت (Build Essentials) را نصب کنید. چون ماژول‌های درایور انویدیا مستقیماً روی رابط هسته لینوکس فعال کامپایل می‌شوند، بسته‌های هدر متناظر (به‌طور خاص linux-headers-$(uname -r)) ضروری هستند. نصب build-essential ،curl ،wget و git در کنار DKMS (پشتیبانی پویا از ماژول هسته) تضمین می‌کند که به‌روزرسانی‌های آینده هسته، ماژول‌های درایور را به‌طور خودکار و بدون نقص بازکامپایل کنند. این کار ابزارهای لازم و فایل‌های منبع هدر را برای ساخت پویا ماژول‌های بومی هسته فراهم می‌کند.

ایزولاسیون سخت‌افزاری و نصب درایور

درایورهای متن‌باز Nouveau اغلب با درایورهای انحصاری انویدیا برای کنترل سخت‌افزار رقابت می‌کنند. این رقابت منجر به صفحه سیاه، فریز شدن سیستم یا شکست در هنگام بوت می‌شود. برای جلوگیری از این اتفاق، باید Nouveau را صراحتاً در تنظیمات modprobe (از طریق /etc/modprobe.d/blacklist-nouveau.conf) با قرار دادن blacklist nouveau و options nouveau modeset=0 به لیست سیاه اضافه کنید. سپس باید سیستم فایل RAM اولیه (initramfs) را با دستور sudo update-initramfs -u به‌روز کنید تا هسته لینوکس هرگز آن را در هنگام بوت بارگذاری نکند.

از نصب‌کننده‌های مستقل .run وب‌سایت انویدیا دوری کنید. این فایل‌ها فاقد ردیابی مدیریت بسته هستند، در هنگام ارتقای سیستم به‌راحتی می‌شکنند و فایل‌های رها شده‌ای در /usr/local باقی می‌گذارند. در عوض، مخزن رسمی انویدیا را ثبت کنید (مانند cuda-keyring_1.1-1_all.deb برای اوبونتو ۲۲.۰۴) و شاخه درایور هدف، مانند nvidia-driver-535 را از طریق APT نصب کنید. این کار باعث می‌شود درایور توسط مدیریت بسته سیستم ردیابی شود.

پس از نصب، ری‌بوت اجباری است تا ماژول جدید هسته بارگذاری شود. سپس می‌توانید با nvidia-smi ارتباط سخت‌افزاری، VRAM، بازبینی‌های ساخت درایور و هندل‌های فعال دستگاه در مسیر /dev/nvidia* را تایید کنید. یک اعتبارسنجی درست شامل استعلام نام GPU، نسخه درایور، کل حافظه و محدودیت‌های توان در قالب CSV است تا از فعال بودن گره‌های کنترل میزبان اطمینان حاصل شود.

کانتینرسازی و مدیریت محیط اجرا

برای اینکه سیستم‌عامل میزبان پاک بماند، SDKهای CUDA یا کتابخانه‌های توسعه cuDNN را مستقیماً روی سیستم نصب نکنید. در عوض، مدیریت محیط اجرا را به داکر در ترکیب با NVIDIA Container Toolkit بسپارید. این ساختار اجازه می‌دهد کانتینرهای مجزا از سخت‌افزار GPU مستقیماً از طریق درایور میزبان استفاده کنند و نسخه‌های مختلف CUDA را بدون تداخل درایور در کنار هم اجرا کنید.

نصب این سیستم نیازمند راه‌اندازی موتور داکر و nvidia-container-toolkit و سپس پیکربندی Runtime از طریق دستور sudo nvidia-ctk runtime configure --runtime=docker و ری‌استارت کردن سرویس داکر است. این کار اجازه می‌دهد بارهای کاری کانتینر دستورات را مستقیماً به GPUهای میزبان ارسال کنند.

جزئیات محیط اجرای کانتینر

برای اطمینان از عملکرد کامل محیط کانتینری، این مراحل اعتبارسنجی را دنبال کنید:

• تست عبور (Passthrough): اجرای یک ایمیج رسمی CUDA (مثلاً nvidia/cuda:12.1.1-base-ubuntu2204) و اجرای nvidia-smi داخل کانتینر برای تایید اینکه GPU قابل مشاهده است.
• اعتبارسنجی حافظه IPC: استفاده از فلگ --ipc=host هنگام اجرای کانتینرها. با اجرای df -h /dev/shm داخل کانتینر تایید کنید که به حافظه مشترک میزبان دسترسی دارد و محدود به ۶۴ مگابایت پیش‌فرض نیست.
• پیکربندی Runtime: اطمینان از ثبت درست nvidia-container-toolkit به عنوان Runtime داکر برای جلوگیری از خطاهای "unknown runtime" در هنگام اجرای دستورات docker run.

محیط‌های پایتون با کارایی بالا

برای توسعه خارج از داکر، از پایتون سیستم یا ابزارهای کند محیط مجازی استفاده نکنید. uv — یک مدیریت بسته با کارایی بالا که با زبان Rust نوشته شده — درخت وابستگی‌های پیچیده ML را در چند ثانیه حل کرده و از آلودگی بسته‌های میزبان جلوگیری می‌کند. این ابزار اجازه می‌دهد محیط‌های ایزوله (مثلاً پایتون ۳.۱۱) را بدون نیاز به دسترسی root ایجاد کنید و خطرات مربوط به نصب‌های سراسری pip را حذف کنید.

هنگام نصب PyTorch، از دستورات عمومی pip دوری کنید زیرا اغلب منجر به نسخه‌های CPU-only یا عدم تطابق Wheelها می‌شوند. شما باید صراحتاً ایندکس‌های Runtime CUDA (مثلاً APIهای CUDA 12.1 از طریق https://download.pytorch.org/whl/cu121) را هدف قرار دهید تا با قابلیت‌های سخت‌افزاری شما مطابقت داشته باشد. برای استنتاج (Inference) مدل‌های زبانی بزرگ (LLM) محلی، باید کتابخانه‌های با کارایی بالا مانند transformers ،accelerate ،datasets ،bitsandbytes و flash-attn را با فلگ --no-build-isolation نصب کنید تا رپرهای شتاب‌دهنده سخت‌افزاری C++ به‌درستی مپ شوند.

اعتبارسنجی نهایی و تله‌های رایج

یک محیط تا زمانی که یک محاسبه تنسوری واقعی را اجرا نکند، «آماده» نیست. یک اسکریپت تایید باید تنسورهای تصادفی را روی GPU تخصیص داده و یک ضرب ماتریسی ۴۰۹۶ در ۴۰۹۶ را انجام دهد تا تایید شود خط لوله محاسباتی فعال است. این اسکریپت باید نسخه پایتون، نسخه PyTorch، در دسترس بودن CUDA و قابلیت حافظه دستگاه را قبل از اجرای torch.matmul و اندازه‌گیری زمان سپری شده به ثانیه تایید کند. استفاده از torch.cuda.synchronize() برای اطمینان از تکمیل خط لوله محاسباتی قبل از ثبت زمان ضروری است.

چند اشتباه بحرانی که اغلب این تنظیمات را مختل می‌کند:

• بسته‌های عمومی APT CUDA: این‌ها اغلب از به‌روزرسانی‌های اصلی عقب‌ترند یا دایرکتوری‌های کتابخانه سیستم مانند /usr/lib را آلوده می‌کنند. درایورها را روی میزبان و توسعه را در کانتینر نگه دارید.
• محدودیت‌های حافظه مشترک: کانتینرهای پیش‌فرض داکر حافظه مشترک را به ۶۴ مگابایت محدود می‌کنند. DataLoaderهای PyTorch برای انتقال دسته‌های داده بین پردازش‌های چندگانه از حافظه مشترک استفاده می‌کنند؛ عدم استفاده از فلگ --ipc=host یا عدم پیکربندی صریح --shm-size باعث کرش کردن کارهای آموزشی با خطای SIGBUS می‌شود. برای مدیریت پیشرفته‌تر این فشارها بر VRAM، می‌توان از سازوکار BullMQ برای کنترل بارهای سنگین هوش مصنوعی بهره برد تا از اتمام حافظه گرافیکی جلوگیری شود.
• ترکیب مدیریت‌ها: ترکیب conda، pip و پایتون سیستم باعث جایگزینی‌های باینری خاموش و سردرگمی در مسیرها (Path) می‌شود. فقط از یک ابزار مانند uv استفاده کنید.

چک‌لیست تولید (Production)

قبل از استقرار هر بار کاری یادگیری ماشین، این الزامات نهایی را رعایت کنید:

• تثبیت شاخه‌های درایور: از درایورهای LTS (پشتیبانی بلندمدت) استفاده کنید تا به‌روزرسانی‌های غلتان (Rolling Updates) غیرمنتظره باعث شکست تولید نشود.
• پیکربندی IPC: برای فرآیندهای Batch Loader با توان عملیاتی بالا، حتماً --ipc=host را تنظیم کنید تا از کرش‌های SIGBUS جلوگیری شود.
• ذخیره‌سازی خارجی: هرگز وزن‌های مدل را داخل لایه‌های ریشه کانتینر ذخیره نکنید؛ حجم‌های ذخیره‌سازی سریع خارجی (NVMe/SSD) را مستقیماً به مسیرهای هدف کانتینر متصل (Mount) کنید.
• Wheelهای صریح: همیشه ایندکس‌های معماری CUDA (مثلاً cu121) را مشخص کنید و به ایندکس‌های عمومی PyPI اعتماد نکنید.

گام بعدی شما

• تمام درایورهای قدیمی را پاک کرده و از روش نصب مبتنی بر APT به جای فایل‌های .run استفاده کنید.
• ابزار uv را جایگزین pip و conda کنید تا سرعت مدیریت وابستگی‌ها را تجربه کنید.
• در اجرای کانتینرهای PyTorch، همیشه فلگ --ipc=host را برای جلوگیری از خطاهای حافظه به کار ببرید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.