Hugging Face wprowadził znaczące aktualizacje do swojego projektu Kernels, dodając dedykowany typ repozytorium, ulepszone zabezpieczenia, przeprojektowane interfejsy wiersza poleceń, rozszerzone wsparcie dla frameworków oraz fundamenty pod rozwój kernelów sterowany przez agentów.

Kernels stają się typem repozytorium pierwszej klasy

Hub Hugging Face ma teraz nowy typ repozytorium o nazwie „kernel”. Ta zmiana pozwala użytkownikom bezpośrednio widzieć obsługiwane akceleratory, systemy operacyjne i wersje backendów. Na przykład szczegóły kompatybilności kernela są teraz wyświetlane w widocznym miejscu:

Flash Attention 3 Kernel Page

Wszystkie dostępne kernele można przeglądać pod adresem https://huggingface.co/kernels. Uczynienie kernelów obywatelami pierwszej klasy na Hubie poprawia ich wykrywalność i pomaga ekosystemowi AI dostrzegać trendy wśród kernelów, modeli i aplikacji.

Bezpieczeństwo otrzymuje znaczący zastrzyk

Kernele uruchamiają natywny kod z tymi samymi uprawnieniami co proces Pythona, który je ładuje, co czyni bezpieczeństwo priorytetem. Projekt od dawna kładzie nacisk na odtwarzalność – użytkownicy mogą ponownie skompilować kernel i zweryfikować, czy pasuje do publicznego kodu źródłowego, używając Nix do hermetycznych kompilacji i izolowanych piaskownic. Źródłowy Git SHA1 jest osadzony w kernelu, aby poprawić pochodzenie.

Ostatnie dodatki obejmują zaufanych wydawców kernelów i podpisywanie kodu.

Zaufani wydawcy kernelów

Wraz z nowym typem repozytorium Hugging Face wprowadził „zaufanych wydawców”. Domyślnie pakiet kernels ładuje tylko kernele od organizacji, którym społeczność ufa. Użytkownicy mogą wyrazić zgodę na ładowanie kernelów z innych źródeł za pomocą argumentu trust_remote_code:

from kernels import get_kernel
kernel_module = get_kernel(  
   "Atlas-Inference/gdn", version=1, trust_remote_code=True  
)

Publikowanie repozytoriów kernelów jest domyślnie ograniczone. Użytkownicy i organizacje muszą poprosić o dostęp w ustawieniach swojego konta, co pozwala zespołowi na indywidualne rozpatrzenie każdej prośby.

Podpisywanie kernelów

Podpisywanie kodu chroni przed naruszeniem poświadczeń Hubu. Kernel jest podpisywany kluczem prywatnym znanym tylko deweloperowi i weryfikowany za pomocą klucza publicznego. Nawet jeśli atakujący naruszy poświadczenia zaufanego wydawcy, nie będzie mógł podpisać złośliwego kernela bez klucza prywatnego.

Projekt używa Sigstore cosign do podpisywania za pomocą efemerycznych kluczy prywatnych, które są ważne przez ograniczony czas. Weryfikuje również, że kernel został podpisany przez zaufany przepływ pracy GitHub z zaufanego repozytorium. Podpisywanie kernelów jest już obsługiwane przez kernel-builder, a polecenie kernels verify-signature jest dostępne. Weryfikacja podpisu podczas ładowania nie jest jeszcze wymuszona – czeka na dalsze testy. Wstępne notatki dotyczące konfiguracji znajdują się w notatkach do wydania kernels 0.16.0: https://github.com/huggingface/kernels/releases/tag/v0.16.0.

Przeprojektowane CLI

Narzędzia wcześniej mieszane między kernels a kernel-builder zostały rozdzielone. Biblioteka kernels skupia się teraz wyłącznie na ładowaniu i przygotowywaniu kernelów, podczas gdy kernel-builder zajmuje się budowaniem. To sprawia, że oba narzędzia są szczuplejsze i bardziej skoncentrowane.

Ulepszone CLI kładzie również podwaliny pod agentowe tworzenie kernelów.

Szersze wsparcie dla frameworków i backendów

Wsparcie dla frameworków zostało rozszerzone. Kluczowe zmiany obejmują:

  • Wsparcie dla Torch Stable ABI, umożliwiające deweloperom kernelów targetowanie konkretnej wersji Torch lub dowolnej wersji wydanej po niej przez około dwa lata. Na przykład kernel targetujący Torch 2.9 Stable ABI obsługuje Torch >= 2.9.

  • Apache TVM FFI jest teraz obsługiwany obok Torch. TVM FFI to standaryzowane ABI, które działa z PyTorch, Jax, CuPy i innymi, umożliwiając kernelom działanie w wielu frameworkach.

Fundamenty pod agentowe tworzenie kernelów

kernel-builder i kernels obsługują agentowe tworzenie kernelów, gdzie agent tworzy zoptymalizowany kernel od podstaw. Razem umożliwiają przepływ pracy, w którym agenci mogą szkieletować, budować, benchmarkować i iteracyjnie optymalizować kernele.

Agentowe tworzenie kernelów jest wciąż nowe, dlatego ważne są proste, jasne podstawy. kernel-builder narzuca odtwarzalną strukturę do szkieletowania i budowania kernelów, dając agentom przewidywalny układ projektu. Jego CLI jest zoptymalizowane dla agentów dzięki nieinteraktywnym poleceniom i wynikom łatwym do interpretacji programistycznej. Umiejętności specyficzne dla backendów pomagają agentom nawigować po osobliwościach różnych backendów.

Pomyślne zbudowanie kernela to dopiero pierwszy krok – musi on zapewnić rzeczywiste przyspieszenie w porównaniu z bazą na docelowym sprzęcie. Integracja z HF Jobs ułatwia benchmarkowanie, pozwalając agentom uruchamiać zestawy testów wydajnościowych, zbierać wyniki i porównywać z bazą w różnych konfiguracjach sprzętowych.

Poniżej znajduje się kilka przykładów kernelów wspomaganych przez agentów, które ilustrują rodzaje kernelów, jakie można opracowywać i oceniać w tym przepływie pracy.

Różne aktualizacje

Konfiguracja środowiska

Skrypt instalacyjny zapewnia teraz konfigurację jednym kliknięciem do budowania kernelów za pomocą kernel-builder. Dla instancji efemerycznych dostępny jest przewodnik konfiguracji Terraform.

Karta systemowa dla kernelów

Po zbudowaniu kernelów tworzona jest karta systemowa dla każdego kernela, ujawniająca przydatne informacje, w tym jak go używać i jego interfejsy. Po wypchnięciu na Hub karta staje się metryką kernela:

System card for a kernel

Sprawdzanie kompatybilności kernelów

Użyj metody has_kernel(), aby sprawdzić, czy kernel jest kompatybilny z twoim systemem:

from kernels import has_kernel
print(has_kernel("kernels-community/activation", version=1))

Zwraca wartość bool. Aby uzyskać więcej szczegółów, dlaczego kernel nie jest obsługiwany, użyj 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})")

Powinno wydrukować (w zależności od twojego komputera):

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))  
…

Ulepszone wsparcie dla manylinux_2_28

Kernel-builder od samego początku celował w manylinux_2_28. Wcześniej używał nowoczesnego toolchaina gcc skompilowanego z glibc 2.28 i statycznie linkowanym libstdc++. Jednak powodowało to problemy, gdy zaangażowanych było wiele wersji libstdc++ – jak ta linkowana dynamicznie przez PyTorch i ta linkowana statycznie przez kernel. Niektóre kernele używające funkcji takich jak wyrażenia regularne C++ wyzwalały globalne inicjalizacje, prowadząc do uszkodzenia danych i segfaultów.

Aby to naprawić, zespół zaktualizował podejście, aby uniknąć takich konfliktów, zapewniając większą stabilność.

Te aktualizacje pozycjonują projekt Kernels do szerszego przyjęcia i bardziej zaawansowanych przypadków użycia, w tym przepływów pracy zoptymalizowanych przez agentów. Dzięki ulepszonemu bezpieczeństwu, wykrywalności i wsparciu międzyframeworkowemu Hugging Face kładzie podwaliny pod bardziej solidny i elastyczny ekosystem kernelów.