بقلم: يوسف | محرر أدوات الذكاء الاصطناعي · صوت تحريري بإشراف بشري
أعادت Hugging Face تصميم مشروع Kernels من الأساس تقريباً، مع تحديثات شاملة نُشرت في 6 يوليو 2026 تمس كل شيء من طريقة تخزين الـ kernels على Hub إلى آليات التوقيع الأمني والدعم الإطاري، وصولاً إلى بنية تحتية تستعد لعصر التطوير بالوكلاء الذكيين.
أبرز ما جاء به التحديث على صعيد البنية التحتية هو إدخال نوع مستودع جديد كلياً على Hub يحمل اسم “kernel”. هذا النوع يُتيح عرض معلومات المعالجات المدعومة وأنظمة التشغيل وإصدارات الـ backend مباشرة على صفحة الـ kernel، كما يظهر في صفحة flash-attn3 مثلاً. الأهم من ذلك أن هذه الـ kernels باتت جزءاً من منظومة Hub بالمعنى الكامل، أي يمكن رصد الاتجاهات عبرها وربطها بالنماذج والتطبيقات التي تستخدمها.
Hugging Face Hub تعرض المعالجات وأنظمة التشغيل المدعومة”>على صعيد الأمان، يُشكّل هذا التحديث نقلة نوعية. الـ kernels تُنفّذ كوداً أصيلاً بصلاحيات عملية Python ذاتها، ما يعني أن kernel خبيثاً واحداً كافٍ لإلحاق ضرر حقيقي بالجهاز. لمواجهة ذلك، اعتمدت Hugging Face نظام “الناشرين الموثوقين”: لن يُحمَّل أي kernel افتراضياً إلا من ناشر تثق به المنصة، ولتحميل kernel من جهة غير موثوقة يتعين عليك التمرير الصريح لـ trust_remote_code=True عند الاستدعاء. كذلك يتطلب النشر على Hub تقديم طلب مسبق وقبوله بصورة فردية.
فوق ذلك، أضافت الشركة طبقة توقيع رقمي تعتمد على Sigstore’s cosign بمفاتيح خاصة آنية محدودة الصلاحية زمنياً، ما يجعل استغلال أي مفتاح مسرَّب أمراً متعذراً عملياً. التوقيع مدعوم في kernel-builder والتحقق منه متاح عبر أمر kernels verify-signature، غير أن التحقق التلقائي عند التحميل لم يُفعَّل بعد ريثما تكتمل مرحلة الاختبار. تفاصيل الإعداد موجودة في ملاحظات الإصدار 0.16.0.
على مستوى الـ CLI، جرى تنظيف شامل للأدوات وإعادة توزيع المسؤوليات: kernels يختص الآن بتحميل الـ kernels وتجهيزها للاستخدام حصراً، بينما يتولى kernel-builder عملية البناء. التقسيم يجعل كلا الأداتين أكثر خفة وتركيزاً.
أما على صعيد الإطارات البرمجية المدعومة، فيبرز توسعان محوريان (وفقاً لـ Hugging Face Blog): الأول دعم Torch Stable ABI الذي يتيح لمطور الـ kernel استهداف إصدار Torch معين والتوافق مع كل إصدار يليه لمدة عامين تقريباً — kernel يستهدف Torch 2.9 مثلاً يدعم Torch >= 2.9. الثاني هو دعم Apache TVM FFI كأول إطار يُضاف إلى جانب Torch، وهو ABI موحّد يتشغّل مع PyTorch وJax وCuPy، ما يفتح باب كتابة kernels تعمل عبر أُطر متعددة في آنٍ واحد.
ربما تكون الإضافة الأبعد أثراً هي البنية التحتية لتطوير الـ kernels بالوكلاء الذكيين. الفكرة: وكيل AI يبني kernel محسَّناً من الصفر، يختبره، يقيس أداءه، ويُكرّر الدورة. يُسهم kernel-builder في ذلك بتوفير هيكل مشروع منضبط وسطر أوامر مصمم للتشغيل غير التفاعلي بمخرجات قابلة للتحليل برمجياً. أما التحقق من الأداء فيجري عبر التكامل مع HF Jobs: الوكيل يُشغّل benchmarks، يجمع النتائج، يقارنها بخط الأساس، ويُعيد التحسين. مثالان حيّان على هذا النهج: drbh/yamoe وsayakpaul/qk-norm-rope.
من الإضافات العملية الأخرى: دالة has_kernel() التي تُعيد قيمة منطقية تُخبرك فوراً هل kernel معين متوافق مع نظامك، ودالة get_kernel_variants() التي تُفصّل سبب الرفض لكل متغيّر — كأن يقول لك “CPU (x86_64) does not match system CPU (aarch64)”. إلى جانب ذلك، حُلّت مشكلة عقيمة تتعلق بالربط الثابت لـ libstdc++ عبر التحول إلى الربط الديناميكي مع toolchain الرسمي لـ manylinux_2_28، وذلك لتفادي تلف البيانات والـ segfaults الناجمة عن تعارض نسخ متعددة من libstdc++. وأُضيف أيضاً سكريبت تثبيت بنقرة واحدة لمن يريد إعداد بيئة البناء بسرعة، مع دليل Terraform لمن يُفضّل العمل بـ instances مؤقتة.
ما تبنيه Hugging Face هنا يتجاوز مجرد تحسين أداة: إنه محاولة لوضع معيار صناعي لكيفية تعبئة الـ GPU kernels وتوزيعها والتحقق منها أمنياً في عصر بدأ فيه الوكلاء الذكيون يكتبون الكود المُحسَّن بأنفسهم. السؤال الذي يطرحه هذا التحديث ليس “هل ستستخدم Kernels؟” بل “كيف ستبدو دورة تطوير kernel بعد أن يتولاها الوكيل كاملاً؟”
