Maya Bennett
Hugging Face a déployé des mises à jour majeures de son projet Kernels, avec un nouveau type de dépôt dédié, des mesures de sécurité renforcées, des interfaces en ligne de commande repensées, une prise en charge élargie des frameworks, et les bases pour le développement de kernels par agents.
Les kernels deviennent un type de dépôt de première classe
Le Hub Hugging Face propose désormais un nouveau type de dépôt appelé « kernel ». Ce changement permet aux utilisateurs de voir directement les accélérateurs, systèmes d'exploitation et versions de backend pris en charge. Par exemple, les détails de compatibilité d'un kernel sont désormais affichés de manière visible :
Tous les kernels disponibles peuvent être consultés sur https://huggingface.co/kernels. Faire des kernels des citoyens de première classe sur le Hub améliore leur découvrabilité et aide l'écosystème IA à repérer les tendances à travers les kernels, modèles et applications.
La sécurité reçoit un coup de pouce majeur
Les kernels exécutent du code natif avec les mêmes privilèges que le processus Python qui les charge, ce qui fait de la sécurité une priorité absolue. Le projet a toujours mis l'accent sur la reproductibilité : les utilisateurs peuvent recompiler un kernel et vérifier qu'il correspond à la source publique en utilisant Nix pour des constructions hermétiques et des environnements isolés. Le SHA1 Git de la source est intégré dans le kernel pour améliorer la traçabilité.
Les ajouts récents incluent les éditeurs de kernels de confiance et la signature de code.
Éditeurs de kernels de confiance
Avec le nouveau type de dépôt, Hugging Face a introduit les « éditeurs de confiance ». Par défaut, le package kernels ne charge que les kernels provenant d'organisations auxquelles la communauté fait confiance. Les utilisateurs peuvent choisir de charger des kernels d'autres sources en utilisant l'argument trust_remote_code :
from kernels import get_kernel
kernel_module = get_kernel(
"Atlas-Inference/gdn", version=1, trust_remote_code=True
)
La publication de dépôts de kernels est restreinte par défaut. Les utilisateurs et organisations doivent demander l'accès depuis leurs paramètres de compte, ce qui permet à l'équipe d'examiner chaque demande individuellement.
Signature des kernels
La signature de code protège contre les compromissions des identifiants du Hub. Un kernel est signé avec une clé privée connue uniquement du développeur et validé avec une clé publique. Même si un attaquant compromet les identifiants d'un éditeur de confiance, il ne peut pas signer un kernel malveillant sans la clé privée.
Le projet utilise cosign de Sigstore pour signer avec des clés privées éphémères valables pour une durée limitée. Il vérifie également que le kernel a été signé par un workflow GitHub de confiance provenant d'un dépôt de confiance. La signature des kernels est déjà prise en charge par kernel-builder, et la commande kernels verify-signature est disponible. La vérification de la signature au chargement n'est pas encore imposée, en attendant des tests supplémentaires. Des notes préliminaires de configuration se trouvent dans les notes de version de kernels 0.16.0 : https://github.com/huggingface/kernels/releases/tag/v0.16.0.
CLI remaniées
Les utilitaires auparavant mélangés entre kernels et kernel-builder ont été séparés. La bibliothèque kernels se concentre désormais uniquement sur le chargement et la préparation des kernels, tandis que kernel-builder s'occupe de la construction. Cela rend les deux outils plus légers et plus ciblés.
La CLI améliorée jette également les bases du développement de kernels par agents.
Prise en charge élargie des frameworks et backends
La prise en charge des frameworks a été étendue. Les changements clés incluent :
Prise en charge de l'ABI stable de Torch, permettant aux développeurs de kernels de cibler une version spécifique de Torch ou toute version publiée après celle-ci pendant environ deux ans. Par exemple, un kernel ciblant Torch 2.9 Stable ABI prend en charge Torch >= 2.9.
L'interface FFI d'Apache TVM est désormais prise en charge en plus de Torch. TVM FFI est une ABI standardisée qui fonctionne avec PyTorch, Jax, CuPy et d'autres, permettant aux kernels de fonctionner sur plusieurs frameworks.
Base pour le développement de kernels par agents
kernel-builder et kernels prennent en charge le développement de kernels par agents, où un agent crée un kernel optimisé à partir de zéro. Ensemble, ils permettent un workflow pour que les agents échafaudent, construisent, benchmarkent et optimisent itérativement les kernels.
Le développement de kernels par agents est encore nouveau, donc des bases simples et claires sont importantes. kernel-builder impose une structure reproductible pour l'échafaudage et la construction des kernels, donnant aux agents une disposition de projet prévisible. Sa CLI est optimisée pour les agents avec des commandes non interactives et des sorties faciles à interpréter par programme. Des compétences spécifiques aux backends aident les agents à naviguer dans les idiosyncrasies des différents backends.
Construire un kernel avec succès n'est que la première étape : il doit apporter des accélérations réelles par rapport à une référence sur le matériel cible. L'intégration avec HF Jobs facilite le benchmarking, permettant aux agents d'exécuter des suites de benchmarks, de collecter les résultats de performance et de les comparer à une référence sur différentes configurations matérielles.
Voici quelques exemples de kernels augmentés par agent qui illustrent les types de kernels pouvant être développés et évalués via ce workflow.
Mises à jour diverses
Configuration de l'environnement
Un script d'installation offre désormais une configuration en un clic pour construire des kernels avec kernel-builder. Pour les instances éphémères, un guide de configuration Terraform est disponible.
Carte système pour les kernels
Après la construction des kernels, une carte système est créée pour chaque kernel, exposant des informations utiles, notamment comment l'utiliser et ses interfaces. Lorsqu'elle est poussée sur le Hub, cette carte devient la page de présentation du kernel :
Vérifications de compatibilité des kernels
Utilisez la méthode has_kernel() pour vérifier si un kernel est compatible sur votre système :
from kernels import has_kernel
print(has_kernel("kernels-community/activation", version=1))
Elle renvoie un booléen. Pour plus de détails sur les raisons pour lesquelles un kernel n'est pas pris en charge, utilisez get_kernel_variants() :
from kernels import get_kernel_variants, VariantAccepted
for decision in get_kernel_variants("kernels-community/activation", version=1):
name = decision.variant.variant_str
if isinstance(decision, VariantAccepted):
print(f"{name}: compatible")
else:
print(f"{name}: rejected ({decision.reason})")
Cela devrait afficher (selon votre machine) :
torch212-cxx11-cu130-aarch64-linux: compatible
torch210-cu128-x86_64-windows: rejected (CPU (x86_64) does not match system CPU (aarch64))
torch211-cu128-x86_64-windows: rejected (CPU (x86_64) does not match system CPU (aarch64))
torch212-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
torch211-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
torch210-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
torch29-metal-aarch64-darwin: rejected (OS (darwin) does not match system OS (linux))
…
Amélioration du support manylinux_2_28
Kernel-builder a ciblé manylinux_2_28 presque depuis le début. Auparavant, il utilisait une chaîne d'outils gcc moderne compilée avec glibc 2.28 et libstdc++ liée statiquement. Cependant, cela causait des problèmes lorsque plusieurs versions de libstdc++ étaient impliquées — comme celle liée dynamiquement par PyTorch et celle liée statiquement par un kernel. Certains kernels utilisant des fonctionnalités comme les expressions régulières C++ déclenchaient des initialisations globales, entraînant des données corrompues et des segfaults.
Pour résoudre ce problème, l'équipe a mis à jour l'approche pour éviter ces conflits, garantissant une plus grande stabilité.
Ces mises à jour positionnent le projet Kernels pour une adoption plus large et des cas d'utilisation plus avancés, y compris les workflows d'optimisation par agents. Avec une sécurité, une découvrabilité et une prise en charge multi-frameworks améliorées, Hugging Face jette les bases d'un écosystème de kernels plus robuste et flexible.
