تصور کنید یک برنامه‌نویس است برای اولین بار می‌خواهد سرعت اجرای مدل خود را با کدهای سفارشی افزایش دهد، اما با کابوسی از خطاهای کامپایل و فایل‌های باینری مشکوک روبروست. این دقیقاً همان جایی است که پروژه جدید Hugging Face وارد عمل می‌شود تا فاصله میان کدهای سطح بالای پایتون و اجرای واقعی در سخت‌افزار را از بین ببرد. موتورهای نادیده‌ای که مدل‌هایی مانند Llama یا GPT-4 را به طور بهینه اجرا می‌کنند، همان کرنل‌های GPU سفارشی هستند. با وجود حیاتی بودن این کرنل‌ها برای عملکرد سیستم، اشتراک‌گذاری آن‌ها از نظر تاریخی یک کابوس امنیتی بوده است.
طبق اعلام Hugging Face در ۶ جولای ۲۰۲۶، این شرکت پروژه 🤗 Kernels را به یک سامانه توزیع استاندارد برای کدهای محاسباتی بومی تبدیل کرد. سال‌ها بود که توسعه‌دهندگان مجبور بودند کرنل‌ها را به صورت دستی کامپایل کنند یا به فایل‌های باینری تصادفی اعتماد کنند، که این امر شکاف عظیمی بین کد پایتون و اجرای سطح پایین GPU ایجاد کرده بود. این اقدام در واقع ایجاد یک «اپ‌استور» برای کدهای سطح پایین است؛ درست مثل تفاوت میان دانلود یک فایل .exe ناشناس از یک تالار گفتگو با نصب یک برنامه تأییدشده از اپ‌استور که تضمین می‌کند کد روی سخت‌افزار شما کار می‌کند و سیستمتان را تخریب نمی‌کند یا دایرکتوری ریشه (root) شما را پاک نمی‌کند.
همان‌طور که در تحلیل قبلی ما درباره‌ی نقش‌های تکامل‌یافته‌ی عامل‌ها در پشته‌های نرم‌افزاری اشاره کردیم، این حرکت تمرکز صنعت را از صرفاً «پرامپت‌نویسی» به بهینه‌سازی ریاضیات زیربنایی مدل‌ها تغییر می‌دهد. برای رسیدن به این هدف، Hugging Face زیرساخت‌های جدیدی را معرفی کرده است:
زیرساخت جدید Hub
این پلتفرم اکنون نوع جدیدی از مخزن به نام «kernel» را پشتیبانی می‌کند. این قابلیت به پلتفرم اجازه می‌دهد تا به نیازهای خاص کاربران در زمینه محاسبات پاسخ دهد. به عنوان مثال، یک کاربر اکنون می‌تواند دید واضحی داشته باشد که کدام شتاب‌دهنده‌ها (Accelerators)، کدام سیستم‌عامل‌ها و کدام نسخه‌های Backend برای یک کرنل خاص، مانند kernels-community/flash-attn3 پشتیبانی می‌شوند.
با تبدیل کرنل‌ها به شهروندان درجه‌یک Hub، اکنون پلتفرم می‌تواند روندهای مربوط به کرنل‌ها، مدل‌ها و اپلیکیشن‌هایی که از آن‌ها استفاده می‌کنند را ردیابی کند. این امر باعث می‌شود بهینه‌سازی‌های با عملکرد بالا برای کل اکوسیستم هوش مصنوعی بسیار قابل‌کشف‌تر شوند. کاربران اکنون می‌توانند تمامی کرنل‌های موجود را مستقیماً در آدرس huggingface.co/kernels مشاهده و مرور کنند.
سخت‌سازی امنیت و اصالت
به دلیل اینکه کرنل‌ها کدهای بومی (native) را با همان سطح دسترسی‌هایی اجرا می‌کنند که فرآیند پایتونِ بارگذاری‌کننده دارد، یک کرنل مخرب می‌تواند آسیب‌های واقعی و جدی بزند. برای مقابله با این تهدید، Hugging Face لایه‌های دفاعی متعددی را پیاده کرده است:
- بازتولیدپذیری مبتنی بر Nix: این پروژه از Nix برای خالص نگه داشتن ساخت‌ها (builds) از طریق یک سندباکس به شدت ایزوله و ارزیابی هرمتیک (hermetic evaluation) دستورالعمل‌های ساخت استفاده می‌کند. این ویژگی به کاربران اجازه می‌دهد خودشان کرنل را دوباره کامپایل کنند تا تأیید کنند که فایل باینری با سورس کد عمومی مطابقت دارد.
- ناشران مورد اعتماد: از آنجایی که مهاجمان می‌توانند با ترغیب کاربران به بارگذاری کرنل‌های مخرب، ماشین‌ها را تحت کنترل بگیرند، بسته
kernelsاکنون به صورت پیش‌فرض فقط کرنل‌های ارائه‌شده توسط «ناشران مورد اعتماد» را بارگذاری می‌کند. ناشر با اعتماد، سازمانی است که جامعه بر حسن نیت آن صحه گذاشته است. - تأیید صریح (Opt-in): کاربران همچنان می‌توانند کرنل‌ها را از سازمان‌ها یا افرادی که ناشر مورد اعتماد نیستند بارگذاری کنند، اما باید صراحتاً با استفاده از آرگومان
trust_remote_code=Trueاین اجازه را بدهند. به عنوان مثال:kernel_module = get_kernel("Atlas-Inference/gdn", version=1, trust_remote_code=True) - امضای کد: با بهره‌گیری از ابزار cosign متعلق به Sigstore و استفاده از کلیدهای خصوصی موقت (ephemeral)، سیستم در برابر سناریوهایی که در آن اعتبارنامه‌های یک ناشر مورد اعتماد در Hub لو می‌رود، محافظت می‌کند. چون کلیدهای امضا فقط برای مدت محدودی معتبر هستند، مهاجم حتی در صورت دسترسی به کلید، نمی‌تواند یک کرنل مخرب را امضا کند.
- ردیابی اصالت: شناسه Git SHA1 سورس کد مستقیماً در فایل باینری کرنل جاسازی می‌شود تا یک مسیر بازرسی (audit trail) تغییرناپذیر ایجاد شود. همچنین سیستم تأیید می‌کند که کرنل‌ها توسط یک گردش‌کار (workflow) مورد اعتماد در گیت‌هاب و از یک مخزن مورد اعتماد امضا شده‌اند.
برای پشتیبانی از این ساختار، ابزار kernel-builder در حال حاضر از امضا پشتیبانی می‌کند و دستور kernels verify-signature امکان تأیید اعتبار یک کرنل را به کاربر می‌دهد. یادداشت‌های اولیه درباره راه‌اندازی امضای کد در یادداشت‌های انتشار نسخه ۰.۱۶.۰ موجود است.
بازطراحی رابط‌های خط فرمان (CLI)
ساختار CLI پروژه برای ایجاد تفکیک بهتر وظایف بازطراحی شده است. پیش از این، ابزارها بین kernels و kernel-builder درهم‌تنیده بودند. اکنون مدل ذهنی سیستم شفاف است: kernels یک کتابخانه اختصاصی برای بارگذاری و آماده‌سازی کرنل‌ها جهت استفاده است و دیگر شامل هیچ مورد مربوط به «ساخت» یا Build کرنل‌ها نیست. این تفکیک باعث شد هر دو ابزار kernels و kernel-builder سبک‌تر، متمرکزتر و برای توسعه‌دهنده کاربردی‌تر شوند.
گسترش پشتیبانی از چارچوب‌ها
این سامانه اکنون از Torch Stable ABI پشتیبانی می‌کند. این استاندارد به توسعه‌دهندگان کرنل اجازه می‌دهد تا یک نسخه خاص از Torch یا هر نسخه‌ای که پس از آن تا حدود دو سال منتشر می‌شود را هدف قرار دهند. برای مثال، کرنلی که ABI پایدار Torch 2.9 را هدف قرار داده است، از تمام نسخه‌های Torch >= 2.9 پشتیبانی خواهد کرد.
علاوه بر PyTorch، این پروژه اکنون از Apache TVM FFI پشتیبانی می‌کند. این اولین چارچوبی است که در کنار Torch پشتیبانی می‌شود. TVM FFI یک ABI استاندارد برای کرنل‌ها فراهم می‌کند که با سایر چارچوب‌ها از جمله Jax و CuPy تعامل دارد و به توسعه‌دهندگان اجازه می‌دهد کرنل‌هایی بسازند که در چندین چارچوب مختلف قابل اجرا باشند.
توسعه عامل‌محور کرنل‌ها
هدف نهایی Hugging Face، تبدیل ابزارهای kernel-builder و kernels به زیربنای «توسعه عامل‌محور» (Agentic Kernel Development) است؛ جایی که از یک عامل هوش مصنوعی برای خلق یک کرنل بهینه از صفر استفاده می‌شود. این ابزارها یک گردش‌کار کامل را پشتیبانی می‌کنند که در آن عامل‌ها می‌توانند کد را ساختاردهی (scaffold)، بیلد، بنچمارک و به صورت تکرارشونده بهینه کنند.
مکانیزم‌های گردش‌کار عامل‌ها عبارت‌اند از:
- ساختار پیش‌بینی‌پذیر: ابزار
kernel-builderیک ساختار مشخص برای نحوه چیدمان سورس کد کرنل را تحمیل می‌کند و به عامل‌ها یک گردش‌کار تکرارپذیر و چیدمان پروژه قابل پیش‌بینی می‌دهد. - CLI بهینه‌شده برای عامل‌ها: رابط خط فرمان از دستورات غیرتعاملی و خروجی‌هایی استفاده می‌کند که تفسیر برنامه‌نویسی آن‌ها برای یک عامل بسیار ساده است.
- مهارت‌های خاص Backend: پروژه شامل مهارت‌هایی است که به عامل‌ها کمک می‌کند تا پیچیدگی‌های مختلف Backendها، شامل زنجیره‌های ابزار خاص، مسیرهای کامپایل و ملاحظات عملکردی را مدیریت کنند.
- اعتبارسنجی سخت‌افزاری: از آنجایی که یک بیلد موفق تنها اولین قدم است، سیستم با HF Jobs یکپارچه شده است. عامل‌ها از این ابزار برای اجرای مجموعه بنچمارک‌ها روی سخت‌افزارهای مختلف (تولیدکنندگان و نسل‌های متفاوت) استفاده می‌کنند تا اطمینان حاصل کنند که سرعت واقعی نسبت به خط پایه (Baseline) افزایش یافته است.
این حلقه تکرارشونده (ساخت، بنچمارک از طریق HF Jobs و بهینه‌سازی) اجازه می‌دهد عامل‌ها دقیقاً شناسایی کنند چه چیزی باید تغییر کند. نمونه‌هایی از کرنل‌های تقویت‌شده توسط عامل‌ها شامل drbh/yamoe و sayakpaul/qk-norm-rope در Hub هستند.
ابزارهای یکپارچه‌سازی عملی
برای کاهش دشواری‌های مربوط به تنظیمات محیطی (environment setup)، تیم یک اسکریپت نصب تک‌کلیکی منتشر کرده است. برای کسانی که نمایش‌های موقت (ephemeral instances) را ترجیح می‌دهند، یک راهنمای تنظیمات Terraform در دسترس است.
توسعه‌دهندگان اکنون می‌توانند از بررسی‌های سیستمی برای برنامه‌ریزی استقرارهای خود استفاده کنند:
- بررسی سازگاری: متد
has_kernel()یک مقدار Boolean برمی‌گرداند تا بررسی کند آیا یک کرنل با سیستم فعلی سازگار است یا خیر. (مثال:has_kernel("kernels-community/activation", version=1)) - عیب‌یابی‌های دقیق: اگر یک کرنل رد شود، متد
get_kernel_variants()دلیل دقیق آن را ارائه می‌دهد. برای مثال، ممکن است نشان دهد که نسخهtorch210-cu128-x86_64-windowsرد شده چون CPU سیستم به جایx86_64از نوعaarch64است، یا اینکه نسخهtorch212-metal-aarch64-darwinشکست خورده چون سیستم‌عامل به جایdarwinلینوکس است.
حل تداخل Libstdc++
ابزار Kernel-builder از مراحل اولیه خود هدف را روی manylinux_2_28 قرار داده بود. پیش از این، تیم با استفاده از یک زنجیره ابزار gcc مدرن که با glibc 2.28 کامپایل شده بود و با لینک استاتیک libstdc++ برای اجتناب از مشکلات سازگاری، این هدف را دنبال می‌کرد.
با این حال، این روش باعث شکست‌های بحرانی شد. از آنجایی که برخی از عملکردهای libstdc++ از مقداردهی اولیه سراسری (global initialization) استفاده می‌کنند، داشتن هم‌زمان یک نسخه لینک‌شده به صورت دینامیک (از طریق PyTorch) و یک نسخه لینک‌شده به صورت استاتیک (از طریق کرنل) منجر به فساد داده‌ها می‌شد. این موضوع باعث بروز Segfaultها می‌شد، به‌ویژه زمانی که کرنل‌ها از Regexهای C++ استفاده می‌کردند. برای حل این مشکل، اکنون کرنل‌ها libstdc++ را به صورت دینامیک لینک می‌کنند و با زنجیره ابزار رسمی manylinux_2_28 کامپایل می‌شوند.
این تحول، کرنل‌های GPU را از قطعات شکننده و دستی به دارایی‌هایی نسخه‌دار، امضا شده و قابل کشف تبدیل می‌کند. برای یک توسعه‌دهنده متوسط، فاصله میان یک مقاله پژوهشی با سرعت نظری بالا و استقرار در محیط تولید، اکنون تنها چند خط کد پایتون است.
توسعه‌دهندگان می‌توانند با بررسی لیست کرنل‌های جامعه در huggingface.co/kernels شروع کنند تا ببینند کدام بهینه‌سازها با پشته سخت‌افزاری فعلی آن‌ها سازگار است.
گام بعدی شما
- لیست کرنل‌های جامعه را در huggingface.co/kernels بررسی کنید تا بهینه‌سازهای متناسب با سخت‌افزار خود را بیابید.
- اگر توسعه‌دهنده هستید، ابزار
kernel-builderرا برای استانداردسازی توزیع کدهای سطح پایین خود تست کنید. - مستندات نسخه ۰.۱۶.۰ را برای پیاده‌سازی امضای دیجیتال (Code Signing) مطالعه کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو