Maya Bennett
Hugging Face ha rilasciato aggiornamenti significativi al suo progetto Kernels, introducendo un tipo di repository dedicato, misure di sicurezza potenziate, interfacce a riga di comando ridisegnate, supporto ampliato per framework e le basi per lo sviluppo di kernel guidato da agenti.
I Kernel diventano un tipo di repository di prima classe
L'Hugging Face Hub ora include un nuovo tipo di repository chiamato "kernel". Questo cambiamento permette agli utenti di vedere direttamente gli acceleratori supportati, i sistemi operativi e le versioni del backend. Ad esempio, i dettagli di compatibilità di un kernel vengono ora visualizzati in primo piano:
Tutti i kernel disponibili possono essere consultati su https://huggingface.co/kernels. Rendere i kernel cittadini di prima classe sull'Hub migliora la loro reperibilità e aiuta l'ecosistema AI a individuare tendenze tra kernel, modelli e applicazioni.
La sicurezza riceve un grande impulso
I kernel eseguono codice nativo con gli stessi privilegi del processo Python che li carica, rendendo la sicurezza una priorità assoluta. Il progetto ha sempre sottolineato la riproducibilità: gli utenti possono ricompilare un kernel e verificare che corrisponda al codice sorgente pubblico utilizzando Nix per build ermetiche e sandbox isolati. Il Git SHA1 del sorgente è incorporato nel kernel per migliorare la provenienza.
Le aggiunte recenti includono editori di kernel fidati e firma del codice.
Editori di kernel fidati
Con il nuovo tipo di repository, Hugging Face ha introdotto gli "editori fidati". Per impostazione predefinita, il pacchetto kernels carica solo kernel provenienti da organizzazioni di cui la comunità si fida. Gli utenti possono scegliere di caricare kernel da altre fonti utilizzando l'argomento trust_remote_code:
from kernels import get_kernel
kernel_module = get_kernel(
"Atlas-Inference/gdn", version=1, trust_remote_code=True
)
La pubblicazione di repository di kernel è limitata per impostazione predefinita. Utenti e organizzazioni devono richiedere l'accesso dalle impostazioni del proprio account, consentendo al team di esaminare ogni richiesta individualmente.
Firma dei kernel
La firma del codice protegge da credenziali dell'Hub compromesse. Un kernel viene firmato con una chiave privata nota solo allo sviluppatore e convalidato con una chiave pubblica. Anche se un attaccante compromette le credenziali di un editore fidato, non può firmare un kernel malevolo senza la chiave privata.
Il progetto utilizza Sigstore's cosign per firmare con chiavi private effimere valide per un tempo limitato. Verifica anche che il kernel sia stato firmato da un workflow GitHub fidato proveniente da un repository fidato. La firma dei kernel è già supportata da kernel-builder, e il comando kernels verify-signature è disponibile. La verifica della firma al caricamento non è ancora imposta, in attesa di ulteriori test. Le note preliminari di configurazione sono nelle note di rilascio di kernels 0.16.0: https://github.com/huggingface/kernels/releases/tag/v0.16.0.
CLI rinnovate
Le utility precedentemente mescolate tra kernels e kernel-builder sono state separate. La libreria kernels ora si concentra esclusivamente sul caricamento e la preparazione dei kernel, mentre kernel-builder gestisce la compilazione. Questo rende entrambi gli strumenti più snelli e focalizzati.
La CLI migliorata getta anche le basi per lo sviluppo di kernel agentici.
Supporto più ampio per framework e backend
Il supporto per i framework è stato esteso. Le modifiche principali includono:
Supporto per Torch Stable ABI, che consente agli sviluppatori di kernel di puntare a una versione specifica di Torch o a qualsiasi versione successiva per circa due anni. Ad esempio, un kernel che punta a Torch 2.9 Stable ABI supporta Torch >= 2.9.
Apache TVM FFI è ora supportato insieme a Torch. TVM FFI è un ABI standardizzato che funziona con PyTorch, Jax, CuPy e altri, consentendo ai kernel di funzionare su più framework.
Fondamenta per lo sviluppo di kernel agentici
kernel-builder e kernels supportano lo sviluppo di kernel agentici, dove un agente crea un kernel ottimizzato da zero. Insieme, abilitano un flusso di lavoro per gli agenti per impalcare, compilare, fare benchmark e ottimizzare iterativamente i kernel.
Lo sviluppo di kernel agentici è ancora nuovo, quindi sono importanti fondamenta semplici e chiare. kernel-builder impone una struttura riproducibile per l'impalcatura e la compilazione dei kernel, dando agli agenti un layout di progetto prevedibile. La sua CLI è ottimizzata per agenti con comandi non interattivi e output facili da interpretare a livello programmatico. Competenze specifiche per backend aiutano gli agenti a navigare le idiosincrasie dei diversi backend.
Costruire con successo un kernel è solo il primo passo: deve fornire reali accelerazioni rispetto a una baseline sull'hardware target. L'integrazione con HF Jobs rende il benchmarking facile, consentendo agli agenti di eseguire suite di benchmark, raccogliere risultati di performance e confrontarli con una baseline su diverse configurazioni hardware.
Di seguito sono riportati alcuni esempi di kernel potenziati da agenti che illustrano i tipi di kernel che possono essere sviluppati e valutati attraverso questo flusso di lavoro.
Aggiornamenti vari
Configurazione dell'ambiente
Uno script di installazione ora fornisce una configurazione con un clic per compilare kernel con kernel-builder. Per istanze effimere, è disponibile una guida di configurazione Terraform.
Scheda di sistema per kernel
Dopo aver compilato i kernel, viene creata una scheda di sistema per ogni kernel, che espone informazioni utili tra cui come usarlo e le sue interfacce. Quando viene inviata all'Hub, questa scheda diventa il front matter del kernel:
Controlli di compatibilità dei kernel
Usa il metodo has_kernel() per verificare se un kernel è compatibile sul tuo sistema:
from kernels import has_kernel
print(has_kernel("kernels-community/activation", version=1))
Restituisce un booleano. Per maggiori dettagli sul perché un kernel non è supportato, usa 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})")
Dovrebbe stampare (a seconda della tua macchina):
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))
…
Supporto migliorato per manylinux_2_28
Kernel-builder ha puntato a manylinux_2_28 quasi dall'inizio. In precedenza, utilizzava una toolchain gcc moderna compilata con glibc 2.28 e libstdc++ collegata staticamente. Tuttavia, ciò causava problemi quando erano coinvolte più versioni di libstdc++ — come quella collegata dinamicamente da PyTorch e quella collegata staticamente da un kernel. Alcuni kernel che utilizzavano funzionalità come le regex C++ attivavano inizializzazioni globali, portando a dati corrotti e segfault.
Per risolvere questo problema, il team ha aggiornato l'approccio per evitare tali conflitti, garantendo maggiore stabilità.
Questi aggiornamenti posizionano il progetto Kernels per un'adozione più ampia e casi d'uso più avanzati, inclusi flussi di lavoro di ottimizzazione guidati da agenti. Con una sicurezza migliorata, una maggiore reperibilità e un supporto cross-framework, Hugging Face sta gettando le basi per un ecosistema di kernel più robusto e flessibile.
