درون سازوکار FastFlowLM برای بهینه‌سازی NPUهای AMD در فدورا

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

طبق یک راهنمای فنی منتشر شده در ۲۸ ژوئن ۲۰۲۶، استنتاج (Inference) — که در واقع همان لحظه تولید جواب توسط مدل است و شبیه به خودِ آشپزی است، نه دوره آموزش آشپز — روی AMD Ryzen AI Max 390 (Strix Halo) اکنون مسیر اجرایی مشخصی در لینوکس دارد. با استفاده از FastFlowLM، کاربران می‌توانند گلوگاه‌های سنتی CPU و GPU را دور بزنند و مدل‌هایی مانند Gemma 4 را مستقیماً روی واحد پردازش عصبی (NPU) اجرا کنند.

این پیشرفت در حالی رخ می‌دهد که صنعت به سمت «AI PC»ها حرکت می‌کند؛ جایی که NPU به‌طور خاص برای مدیریت بارهای سنگین استنتاج طراحی شده است. در حالی که ما پیش‌تر بررسی کردیم که چگونه ارکستراسیون روی GPUهای سطح بالا مانند RTX 3090 اثر می‌گذارد، این پیکربندی تمرکز را به «لبه» (Edge) منتقل می‌کند و بهره‌وری و سیلیکون‌های اختصاصی را بر قدرت خام اولویت می‌دهد.

به نقل از مستندات این راهنما، راه‌اندازی این سامانه نیازمند چهار لایه نرم‌افزاری دقیق است تا به‌درستی عمل کند. نخست، هسته (Kernel) باید شامل درایور amdxdna باشد تا گره دستگاه /dev/accel/accel0 ایجاد و فریم‌ور NPU بارگذاری شود. دوم، پایه XRT (Xilinx Runtime) باید در مسیر /opt/xilinx/xrt نصب شود تا محیط زمان-اجرای لازم فراهم گردد. سوم، یک پلاگین XRT NPU (که از طریق یک بسته RPM ارائه می‌شود) مورد نیاز است تا فایل libxrt_driver_xdna.so را فراهم کند تا XRT بتواند NPU را شناسایی کند. در نهایت، FastFlowLM (flm) به‌عنوان زمان-اجرای مواجه با کاربر عمل کرده و مدل‌ها را اجرا می‌کند.

پشته سخت‌افزاری و سیستم‌عامل

این پیاده‌سازی روی یک دستگاه ASUS ROG Flow Z13 (مدل GZ302EA) با توزیع Fedora 44 و نسخه هسته ۷.۰.۱۲-۲۰۱.fc44.x86_64 اعتبارسنجی شده است. سخت‌افزار مورد استفاده در معماری Strix Halo و مدل Ryzen AI Max 390 با شناسه PCI شماره 1022:17f0 rev 11 و نسخه فریم‌ور NPU شماره ۱.۱.۲.۶۵ است.

این پشته همچنین با دیگر NPUهای معماری XDNA2، از جمله مدل‌های موجود در چیپ‌ست‌های Strix، Kraken و Gorgon Point سازگار است. برای مدل‌های Strix Halo (نسخه rev 11) به‌طور خاص، راهنما توصیه می‌کند که به‌جای ماژول داخلی (in-tree) هسته، از درایور DKMS خارج از درخت (out-of-tree) از مخزن xdna-driver استفاده شود تا پایداری سیستم بهبود یابد. برای تضمین استقرار موفق، محیط باید حداقل لینوکس ۷.۰+ (که فدورا ۴۴ به‌صورت پیش‌فرض عرضه می‌کند) با پشتیبانی داخلی از amdxdna داشته باشد.

موانع حیاتی در پیکربندی

فعال‌سازی NPU به دلیل دو چالش فنی غیربدیهی، به سادگی «وصل کن و استفاده کن» نیست:

• پیش‌نیاز IOMMU: بسیاری از کاربران GPU برای دستیابی به افزایش ۵ تا ۱۲ درصدی سرعت در llama.cpp، گزینه IOMMU را خاموش می‌کنند (amd_iommu=off). اما درایور NPU برای اشتراک فضای آدرس مجازی پردازش (SVA/PASID) به آن نیاز دارد. خاموش کردن کامل IOMMU باعث مرگ کامل پشتیبانی از NPU می‌شود. علائم رایج این مشکل شامل خطاهای [ERROR] No NPU device found و amdxdna_sva_init: SVA bind device failed, ret -19 و همچنین Open /dev/accel/accel0 failed (err=-22) است. برای رفع این مشکل، کاربران باید این پرچم را از فایل /etc/default/grub حذف کرده و پیکربندی را از طریق grub2-mkconfig بازسازی کنند. برای کسانی که به دنبال یک راه میانه هستند، می‌توان از iommu=pt استفاده کرد (توجه داشته باشید که دستور amd_iommu=pt نامعتبر است).
• قفل حافظه (Memory Locking): NPU برای عملکرد صحیح به حافظه قفل‌شده نیاز دارد. به‌صورت پیش‌فرض، مقدار ulimit -l ممکن است بسیار پایین باشد (مثلاً ۸ مگابایت). کاربران باید به‌صورت دستی محدودیت memlock را در فایل /etc/security/limits.d/99-memlock.conf به وضعیت «نامحدود» (unlimited) تغییر دهند تا از شکست‌های زمان-اجرا جلوگیری شود. این کار با افزودن خطوط * soft memlock unlimited و * hard memlock unlimited به فایل پیکربندی انجام می‌شود.

جزئیات نصب و فرآیند ساخت

به‌دلیل نبود PPAهای پیش‌ساخته در فدورا (برخلاف اوبونتو)، کل پشته باید از منبع (Source) ساخته شود. این فرآیند نیازمند آرایه عظیمی از وابستگی‌های ساخت است تا زنجیره ابزار بتواند لایه‌های XRT و FLM را کامپایل کند.

نصب وابستگی‌ها:

• ابزارهای پایه ساخت: بسته‌های ضروری شامل git، jq، dkms، kernel-devel-$(uname -r)، kernel-headers، gcc، gcc-c++، make، cmake و ninja-build هستند.
• کتابخانه‌های توسعه: ساخت سیستم به boost-devel (شامل boost-filesystem و boost-program-options)، boost-static، elfutils-devel، libdrm-devel، libuuid-devel، libcurl-devel، openssl-devel، zlib-static، glibc-static و libstdc++-static وابسته است.
• پروتوباف و کتابخانه‌های سیستم: الزامات شامل protobuf-devel، protobuf-compiler، json-glib-devel، libyaml-devel، libudev-devel، rpm-build، curl، pciutils و fftw-devel است.
• پشته OpenCL: فدورا ۴۴ به opencl-headers، opencl-filesystem و OpenCL-ICD-Loader-devel نیاز دارد.
• اتوماسیون: کاربران به‌صورت اختیاری می‌توانند اسکریپت‌های وابستگی AMD را که در مسیرهای ~/repos/xdna-driver/tools/amdxdna_deps.sh و ~/repos/xdna-driver/xrt/src/runtime_src/tools/scripts/xrtdeps.sh قرار دارند، برای ساده‌سازی فرآیند اجرا کنند.

ابزارهای ساخت و اصلاحات XRT:

• Wrapper برای CMake: فدورا ۴۴ نسخه CMake 4.x را با نام cmake ارائه می‌دهد، اما اسکریپت‌های ساخت XRT به‌طور خاص به‌دنبال cmake3 می‌گردند. کاربران باید یک Wrapper محلی در ~/.local/xrt-build/bin ایجاد کرده و آن را به PATH خود اضافه کنند تا تداخل سیم‌پیچ‌های سیستمی رخ ندهد. به‌طور مشخص، یک سیم‌پیچ با دستور ln -sf /usr/bin/cmake ~/.local/xrt-build/bin/cmake3 ایجاد می‌شود.
• بسته‌بندی OpenCL: فدورا ۴۴ به‌جای بسته قدیمی ocl-icd از OpenCL-ICD-Loader استفاده می‌کند. این موضوع می‌تواند باعث خطاهای کامپایل در ocl_icd_bindings.cpp به‌دلیل تفاوت‌های ساختار ICD در OpenCL 3.0 شود. اصلاح این مورد شامل وصله زدن (patch) به فایل ocl_icd_bindings.cpp و به‌روزرسانی cpackLin.cmake برای الزام OpenCL-ICD-Loader >= 3.0 است (دنبال کردن مشکل شماره ۹۱۶۳ در Xilinx/XRT).
• نصب XRT: ابزار XRT با پرچم‌های ./build.sh -npu -opt -disable-werror -noinit -j $(nproc) ساخته و از طریق RPMها (xrt-base-*.rpm و xrt-base-devel-*.rpm و xrt-npu-*.rpm) نصب می‌شود. توجه داشته باشید که استفاده از یک فاصله بعد از -j توصیه می‌شود زیرا برخی اسکریپت‌ها با -j$(nproc) دچار مشکل می‌شوند.
• ثبت کتابخانه‌ها: برای جلوگیری از خطای libxrt_coreutil.so.2: cannot open shared object file باید مسیر /opt/xilinx/xrt/lib64 به فایل /etc/ld.so.conf.d/xrt.conf اضافه شده و دستور sudo ldconfig اجرا گردد. تایید نهایی از طریق ldconfig -p | grep xrt انجام می‌شود.

لایه پلاگین و زمان-اجرا

• پلاگین NPU: ساخت این پلاگین منجر به تولید فایل libxrt_driver_xdna.so می‌شود. کاربران باید با بررسی modinfo -F filename amdxdna مطمئن شوند که ماژول DKMS فعال است؛ مسیر فایل باید شامل extra/ یا updates/dkms/ باشد و نه kernel/drivers/accel/. در صورت نصب تازه ماژول، ری‌بوت لازم است.
• FastFlowLM (flm): این ابزار از منبع با استفاده از پیش‌فرض linux-default (از طریق cmake --preset linux-default) ساخته شده و در مسیر /opt/fastflowlm/bin/flm نصب می‌شود و یک سیم‌پیچ به /usr/local/bin/flm ارائه می‌دهد. برای نصب، به کتابخانه‌های libavformat-devel، libavutil-devel، libavcodec-devel، libswresample-devel و libswscale-devel نیاز دارد.
• Wrapper برای XRT-SMI: ابزار xrt-smi به مسیر حساس است. سیم‌پیچ کردن آن به /usr/local/bin باعث شکست فراخوان‌های داخلی dirname "$0" در اسکریپت شده و خطای unwrapped/xrt-smi: No such file or directory را ایجاد می‌کند. راه حل، ساخت یک اسکریپت Wrapper پوسته است که /opt/xilinx/xrt/bin/xrt-smi "$@" را اجرا کند یا افزودن دائمی /opt/xilinx/xrt/bin به PATH در .bashrc است.

پروتکل اعتبارسنجی

قبل از اجرای مدل‌ها، راهنما یک فرآیند تأیید سه مرحله‌ای را اجباری می‌کند:
۱. flm validate: بررسی دستگاه DRM هسته، فریم‌ور NPU (که باید ۱.۱.۲.۶۵ باشد) و محدودیت‌های memlock (که باید infinity/نامحدود باشد). خروجی مورد انتظار تایید نسخه هسته (۷.۰.۱۲-۲۰۱.fc44.x86_64) و نسخه amdxdna شماره ۰.۱۵ است.
۲. xrt-smi examine: تایید اینکه لایه XRT دستگاه Strix Halo را شناسایی کرده است (به عنوان مثال در مسیر [0000:c5:00.1]).
۳. xrt-smi validate: انجام تست‌های خودکار سخت‌افزاری برای GEMM، تأخیر و توان عملیاتی. تمام این تست‌ها باید وضعیت PASSED را گزارش کنند.

بنچمارک و عملکرد

روی سخت‌افزار تست شده ROG Flow Z13 (با XRT 2.25.0 و فریم‌ور NPU ۱.۱.۲.۶۵)، مدل gemma4-it:e4b از طریق دستور flm run با فعال‌سازی /verbose عملکرد واقعی زیر را نشان داد:

• زمان تا نخستین توکن (TTFT): ۱.۲۱ ثانیه
• سرعت پیش‌پر (Prefill Speed): ۱۸ توکن در ثانیه
• سرعت رمزگشایی (Decoding Speed): ۱۱ توکن در ثانیه

برای بررسی سلامت سخت‌افزاری، ابزار xrt-smi validate مقدار ۴.۴ TOPS را برای عملیات GEMM، میانگین تأخیر ۵۲ میکروثانیه و توان عملیاتی حدود ۷۶ هزار عملیات در ثانیه گزارش کرد. اگرچه این اعداد سرعت فیزیکی سیلیکون را تایید می‌کنند، اما با معیارهای توکن-در-ثانیه مدل‌های LLM متفاوت هستند. کاربران می‌توانند برای دریافت بنچمارک‌های رسمی در طول‌های مختلف Context، از دستور flm bench gemma4-it:e4b استفاده کنند.

نظارت و مدیریت

در حال حاضر، لینوکس فاقد یک داشبورد یکپارچه مانند تب NPU در Task Manager ویندوز است. کاربران باید به مجموعه‌ای از ابزارهای پراکنده تکیه کنند:

۱. xrt-smi: ابزار اصلی سطح دستگاه. دستور xrt-smi examine اطلاعات دستگاه و توپولوژی را نشان می‌دهد و xrt-smi examine -r all -d 0000:c5:00.1 داده‌های مربوط به توان و پارتیشن‌ها را فراهم می‌کند. همچنین می‌توان حالت‌های توان (default, powersaver, balanced, performance, turbo) را از طریق xrt-smi configure --pmode performance تنظیم کرد.
۲. FLM Runtime: در طول یک جلسه تعاملی، کاربران می‌توانند با /verbose سرعت TTFT و prefill/decoding هر نوبت را مشاهده کنند، یا با /status خلاصه‌ای از تعداد توکن‌ها و توان عملیاتی را ببینند. مدل‌ها از طریق flm serve gemma4-it:e4b روی پورت ۵۲۶۲۵ برای دسترسی سازگار با OpenAI سرو می‌شوند.
۳. Kernel Debugfs: دسترسی ریشه به /sys/kernel/debug/accel/ و /sys/kernel/debug/dri/0/ به کاربران اجازه می‌دهد تا فایل‌های telemetry_profiling، powerstate و get_app_health را برای اشکال‌زدایی سطح پایین بخوانند. این‌ها رابط‌های «خواندن در زمان درخواست» هستند و نه یک داشبورد زنده.
۴. ابزارهای خارجی: ابزار amdgpu_top میزان استفاده از iGPU رادئون را ردیابی می‌کند اما استفاده از NPU را نشان نمی‌دهد. به همین ترتیب، htop تنها CPU و RAM را نظارت می‌کند. گره /sys/class/accel/accel0/ متادیتا را فراهم می‌کند اما نمودار بهره‌وری ندارد.

معماری: وابستگی لایه‌ای

NPU به‌عنوان یک شتاب‌دهنده مجزا از طریق یک پشته نرم‌افزاری طبقه‌بندی شده عمل می‌کند:

• لایه فوقانی: flm run / flm serve (برنامه کاربر-محور).
• لایه پلاگین: libxrt_driver_xdna.so از طریق RPM پلاگین xrt.
• زمان-اجرای پایه: libxrt_core.so از طریق RPM پایه xrt.
• لایه درایور: amdxdna.ko (درایور هسته DKMS) و فریم‌ور NPU در مسیر amdnpu/17f0_11/.
• رابط سخت‌افزاری: گره دستگاه DRM هسته /dev/accel/accel0 که برای عملکرد به IOMMU (PASID/SVA) و memlock نامحدود نیاز دارد.

عیب‌یابی مشکلات رایج

برای کاربرانی که با خطا مواجه می‌شوند، ماتریس زیر راهکارهایی را بر اساس تنظیمات تایید شده فدورا ۴۴ ارائه می‌دهد:

• کتابخانه‌های گم‌شده: اگر libxrt_coreutil.so.2 یافت نشد، کتابخانه‌های XRT در حافظه کش لودر نیستند. راه حل: افزودن /opt/xilinx/xrt/lib64 به ld.so.conf.d و اجرای ldconfig.
• دستگاه یافت نشد: اگر flm validate با خطای No NPU device found شکست خورد، بررسی کنید که IOMMU غیرفعال نباشد. amd_iommu=off را از خط فرمان GRUB حذف کنید.
• شکست‌های SVA: خطاهایی مانند amdxdna_sva_init: SVA bind device failed, ret -19 نتیجه مستقیم غیرفعال بودن IOMMU یا نبود پیکربندی‌های PASID است.
• شکست پلاگین: اگر xrt-smi تعداد صفر دستگاه را گزارش داد، احتمالاً پلاگین NPU گم شده است؛ RPM پلاگین xrt را مجدداً نصب کنید.
• عدم تطابق درایور: اگر /dev/accel/accel0 وجود دارد اما باز نمی‌شود (ENODEV)، احتمالاً درایور داخلی (in-tree) در شناسایی شکست خورده است. آن را با درایور DKMS جایگزین کنید.
• خطاهای ساخت: خطاهای لینک برای libfftw3 را می‌توان با دستور sudo dnf install fftw-devel حل کرد.

چک‌لیست سریع بازنشانی (Re-setup)

پس از یک نصب تازه فدورا یا ارتقای هسته، توالی زیر توصیه می‌شود:
۱. بررسی IOMMU: دستور grep -q 'amd_iommu=off' /proc/cmdline را اجرا کنید تا مطمئن شوید IOMMU فعال است.
۲. به‌روزرسانی DKMS: درایورها را با sudo dkms autoinstall -k "$(uname -r)" بازسازی کرده و سپس sudo depmod -a را اجرا کنید.
۳. تایید محدودیت: تایید کنید که ulimit -l مقدار unlimited را برمی‌گرداند.
۴. اعتبارسنجی نهایی: دستورات flm validate، xrt-smi examine و xrt-smi validate را به‌ترتیب اجرا کنید.

این فرآیند دستی نصب، شکاف فعلی بین در دسترس بودن سخت‌افزارهای AI و بلوغ اکوسیستم نرم‌افزاری لینوکس را برجسته می‌کند. در حالی که عملکرد امیدوارکننده است، تکیه بر ساخت از منبع، ویرایش‌های دستی GRUB و Wrapperهای سفارشی نشان می‌دهد که پذیرش گسترده این فناوری به بسته‌های توزیع رسمی از سوی AMD بستگی دارد.