Neugestaltung des Kernels-Projekts bei Hugging Face: Verbesserungen in Sicherheit, Kompatibilität und Entwicklung

Kategorien:

No items found.

Freigegeben:

July 6, 2026

kostenlos testen Termin buchen

KI sauber im Unternehmen integrieren: Der 5-Schritte-Plan

Von der ersten Idee bis zur voll integrierten KI-Lösung – strukturiert, sicher und mit messbarem Erfolg

🎯

Strategie & Zieldefinition

Wir analysieren Ihre Geschäftsprozesse und identifizieren konkrete Use Cases mit dem höchsten ROI-Potenzial.

✓ Messbare KPIs definiert

🛡️

Daten & DSGVO-Compliance

Vollständige Datenschutz-Analyse und Implementierung sicherer Datenverarbeitungsprozesse nach EU-Standards.

✓ 100% DSGVO-konform

⚙️

Technologie- & Tool-Auswahl

Maßgeschneiderte Auswahl der optimalen KI-Lösung – von Azure OpenAI bis zu Open-Source-Alternativen.

✓ Beste Lösung für Ihren Fall

🚀

Pilotprojekt & Integration

Schneller Proof of Concept mit nahtloser Integration in Ihre bestehende IT-Infrastruktur und Workflows.

✓ Ergebnisse in 4-6 Wochen

👥

Skalierung & Team-Schulung

Unternehmensweiter Rollout mit umfassenden Schulungen für maximale Akzeptanz und Produktivität.

✓ Ihr Team wird KI-fit

Lassen Sie uns Ihren ersten Schritt planen

Inhaltsverzeichnis

mindverse studio – Ihre Plattform für digitale Effizienz

‍Optimieren Sie Prozesse, automatisieren Sie Workflows und fördern Sie Zusammenarbeit – alles an einem Ort.

Mehr über Mindverse Studio erfahren

Das Wichtigste in Kürze

Hugging Face hat das Kernels-Projekt umfassend überarbeitet, um die Entwicklung, Verteilung und Nutzung von Rechenkernen zu standardisieren und zu optimieren.
Ein neuer Repository-Typ "Kernel" auf dem Hugging Face Hub ermöglicht eine verbesserte Auffindbarkeit und spezifische Metadaten für Rechenkerne.
Die Sicherheit wurde durch die Einführung von "vertrauenswürdigen Publishern" und einer experimentellen Code-Signaturfunktion mittels Sigstore erheblich verstärkt.
Die Kommandozeilen-Tools (CLIs) für `kernels` und `kernel-builder` wurden neu strukturiert, um eine klarere Trennung von Aufgaben zu gewährleisten.
Die Unterstützung für Frameworks und Backends wurde erweitert, unter anderem durch die Implementierung des Torch Stable ABI und die Integration von Apache TVM FFI.
Die Neuerungen legen eine Grundlage für die Entwicklung agentenbasierter Kernel-Entwicklungsprozesse, die von der Erstellung bis zur Optimierung reichen.
Zusätzliche Verbesserungen umfassen vereinfachte Umgebungs-Setups, Systemkarten für Kernels und erweiterte Kompatibilitätsprüfungen.

Umfassende Neugestaltung des Hugging Face Kernels-Projekts: Sicherheit, Kompatibilität und agentenbasierte Entwicklung im Fokus

Die schnelle Entwicklung im Bereich der Künstlichen Intelligenz (KI) stellt Entwickler vor die Herausforderung, Rechenkerne schneller, sicherer und portabler zu gestalten. Angesichts der zunehmenden Komplexität von KI-Modellen muss die zugrunde liegende Infrastruktur entsprechend mithalten. Hugging Face hat nun eine der größten Aktualisierungen seines Kernels-Projekts vorgestellt. Diese Überarbeitung führt ein neu konzipiertes Ökosystem ein, das sich auf Sicherheit, Kompatibilität, Reproduzierbarkeit und die Zukunft der KI-gestützten Softwareentwicklung konzentriert.

Die vorliegende Aktualisierung stellt nicht nur eine einfache Funktionserweiterung dar, sondern eine vollständige Transformation der Art und Weise, wie Kernels verteilt, verifiziert, entwickelt und optimiert werden. Das Projekt schafft nun die Voraussetzungen für ein Ökosystem, in dem sowohl menschliche Entwickler als auch autonome Agenten effektiv zusammenarbeiten können, um optimale Leistung und Sicherheit zu gewährleisten.

Kernels als neuer Repository-Typ im Hub

Hugging Face hat einen spezifischen Repository-Typ namens "Kernel" im Hub eingeführt. Diese Neuerung ermöglicht es, den Anforderungen von Nutzern mit rechenbezogenen Besonderheiten gerecht zu werden. Beispielsweise können Anwender nun auf einen Blick erkennen, welche Beschleuniger, Betriebssysteme und Backend-Versionen für einen bestimmten Kernel unterstützt werden. Dies fördert eine verbesserte Übersicht und Auswahl der passenden Ressourcen. Die Verfügbarkeit dieser Kernels als erstklassige Komponenten im Hub trägt zudem zur Stärkung des KI-Ökosystems bei, indem sie Trends über Kernels, Modelle und deren Anwendungen hinweg sichtbar macht und die Auffindbarkeit für die Nutzer erhöht.

Verbesserte Sicherheitsarchitektur

Da Kernels nativen Code mit denselben Berechtigungen wie der ladende Python-Prozess ausführen, birgt ein bösartiger Kernel ein erhebliches Risiko. Aus diesem Grund wurde der Sicherheit im Kernels-Projekt von Anfang an höchste Priorität eingeräumt. Der Fokus lag dabei zunächst auf der Reproduzierbarkeit: Nutzer sollen in der Lage sein, einen Kernel selbst zu rekompilieren und zu überprüfen, ob er mit der öffentlich verfügbaren Quelle übereinstimmt. Hierfür wird Nix eingesetzt, welches reine Builds durch hermetische Evaluierung der Build-Rezepte und eine stark isolierte Sandbox ermöglicht. Die Herkunft wird zusätzlich durch die Einbettung des Quell-Git-SHA1 in den Kernel selbst verbessert.

In den letzten Monaten wurden zusätzliche Schutzebenen hinzugefügt, darunter vertrauenswürdige Kernel-Publisher und Code-Signierung.

Vertrauenswürdige Kernel-Publisher

Mit dem neuen Repository-Typ wurden "vertrauenswürdige Publisher" eingeführt. Da Kernels Code auf einem System mit denselben Berechtigungen wie der Python-Prozess ausführen, kann ein Angreifer potenziell Systeme kompromittieren, indem er einen bösartigen Kernel hochlädt und dessen Nutzung provoziert. Um solche bösartigen Kernels zu vermeiden, lädt das Kernels-Paket standardmäßig nur noch Kernels von vertrauenswürdigen Publishern. Ein vertrauenswürdiger Publisher ist eine Organisation, die von der Community als vertrauenswürdig eingestuft wird.

Das Laden von Kernels von Organisationen oder Nutzern, die keine vertrauenswürdigen Publisher sind, ist weiterhin möglich, erfordert jedoch eine explizite Zustimmung über das Argument trust_remote_code beim Laden eines Kernels aus dem Hub.

from kernels import get_kernel

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

Standardmäßig können Nutzer keine Kernel-Repositories im Hub veröffentlichen. Sie müssen den Zugang als Kernel-Publisher beantragen. Nutzer und Organisationen können den Zugang über ihre Kontoeinstellungen anfordern. Dies ermöglicht eine fallweise Prüfung dieser Anfragen.

Kernel-Signierung

Eine weitere Sicherheitsebene, die hinzugefügt wurde, ist die Code-Signierung. Die Code-Signierung schützt vor dem Szenario, dass ein Angreifer einen bösartigen Kernel in ein Kernel-Repo eines vertrauenswürdigen Publishers hochlädt, dessen Hub-Zugangsdaten kompromittiert wurden. Bei der Code-Signierung wird ein Kernel mit einem privaten Schlüssel signiert, der nur dem Kernel-Entwickler bekannt ist, und mit einem öffentlich verfügbaren Schlüssel validiert. Im Falle einer Hub-Kompromittierung kann ein Angreifer den bösartigen Kernel nicht signieren, da er den für die Signierung benötigten privaten Schlüssel nicht besitzt.

Zur weiteren Verbesserung der Sicherheit wird Sigstore's Cosign verwendet, um mit ephemeren privaten Schlüsseln zu signieren. Da diese Signaturschlüssel nur für eine begrenzte Zeit gültig sind, kann ein Angreifer den privaten Schlüssel in der Regel nicht verwenden, selbst wenn er bekannt wird. Es wird zudem überprüft, ob der Kernel von einem vertrauenswürdigen GitHub-Workflow aus einem vertrauenswürdigen GitHub-Repository signiert wurde.

Die Kernel-Signierung wird bereits von kernel-builder unterstützt, und der Befehl kernels verify-signature wurde zur Verifizierung eines Kernels bereitgestellt. Die Kernels-Bibliothek verifiziert die Signatur beim Laden eines Kernels noch nicht vollständig, da diese neue Funktionalität weiteren Tests unterzogen werden soll, bevor sie vollständig ausgerollt wird. Vorläufige Hinweise zur Einrichtung der Code-Signierung für eigene Kernels finden sich in den Release Notes von Kernels 0.16.0.

Überarbeitete Kommandozeilen-Schnittstellen (CLIs)

Zuvor waren verschiedene Dienstprogramme zwischen kernels und kernel-builder miteinander verknüpft. Es wurde nun eine klarere Trennung der Aufgaben zwischen den CLIs von kernels und kernel-builder etabliert. Das zugrunde liegende Konzept besagt, dass kernels eine Bibliothek zum Laden und Vorbereiten von Kernels für die Nutzung ist. Daher sollte es keine Funktionen enthalten, die sich auf das "Bauen" von Kernels beziehen.

Als Ergebnis dieser Umstrukturierung sind sowohl kernels als auch kernel-builder nun schlanker und spezifischer. Weitere Informationen hierzu finden sich in der Dokumentation.

Erweiterte Abdeckung von Frameworks und Backends

Die Unterstützung für Frameworks wurde erweitert, wobei die sichtbarsten Änderungen wie folgt sind:

Es wurde Unterstützung für das Torch Stable ABI in Kernels und Kernel-Builder hinzugefügt. Das Torch Stable ABI ermöglicht Kernel-Entwicklern, eine bestimmte Torch-Version oder jede nachfolgend veröffentlichte Version für etwa zwei Jahre zu adressieren. Ein Kernel, der beispielsweise das Torch 2.9 Stable ABI verwendet, unterstützt Torch >= 2.9.
Apache TVM FFI ist das erste Framework, das neben Torch unterstützt wird. TVM FFI ist ein standardisiertes ABI für Kernels, das mit anderen Frameworks wie PyTorch, Jax und CuPy interoperiert. Dies ermöglicht Kernel-Entwicklern, Kernels zu erstellen, die über verschiedene Frameworks hinweg lauffähig sind.

Grundlagen für agentenbasierte Kernel-Entwicklung

kernel-builder und kernels ergänzen die aufkommende agentenbasierte Kernel-Entwicklung, bei der ein Agent genutzt wird, um einen (optimierten) Kernel von Grund auf zu entwickeln. Zusammen unterstützen sie einen Workflow, in dem Agenten Kernels gerüstet, gebaut, bewertet und iterativ optimieren können.

Die agentenbasierte Kernel-Entwicklung befindet sich noch in einem frühen Stadium, und die optimalen Entwicklungszyklen werden sich weiterentwickeln. Dies macht einfache, klare Grundlagen besonders wichtig, wobei die Werkzeuge leicht in beliebige Agenten-Workflows oder Frameworks integriert werden sollten, die von den Nutzern gewählt werden.

kernel-builder hilft dabei, eine Struktur für die Gerüstung und reproduzierbare Erstellung von Kernel-Quellcode durchzusetzen. Dies bietet Agenten ein vorhersagbares Projektlayout und einen wiederholbaren Workflow, in dem sie agieren können. Seine CLI ist zudem auf Agenten optimiert. Dies kann beispielsweise nicht-interaktive Befehle und Ausgaben bedeuten, die für einen Agenten programmatisch einfach zu interpretieren sind. Zu diesem Zweck gibt es auch backend-spezifische Fähigkeiten, die Agenten dabei helfen, die Besonderheiten verschiedener Backends zu navigieren. Diese Fähigkeiten können backend-spezifische Toolchains, Kompilierungspfade und Leistungsüberlegungen erfassen.

Ein erfolgreicher Kernel-Build ist nicht das einzige Ziel; es muss sichergestellt werden, dass er tatsächliche Geschwindigkeitsvorteile gegenüber einer Baseline auf der Zielhardware liefert. Ein erfolgreicher Build ist daher nur der erste Validierungsschritt. Typischerweise kann diese Zielhardware viele verschiedene Beschleuniger umfassen, sogar verschiedene Familien desselben Beschleunigers.

Dies macht es wichtig, Ergebnisse über Hardware-Anbieter und -Generationen hinweg zu bewerten, wo relevant. Die enge Integration mit HF Jobs kann diesen Benchmarking-Prozess vereinfachen. Agenten können diese Integration nutzen, um Benchmark-Suiten auszuführen, Leistungsergebnisse zu sammeln und sie mit einer definierten Baseline zu vergleichen.

Auf diese Weise können Agenten Tests über verschiedene Hardwarekonfigurationen hinweg durchführen, um zuverlässiges Feedback zur Leistung der generierten Kernels zu erhalten und zu identifizieren, was getan werden muss. Dieses Feedback kann dann die nächste Optimierungsiteration beeinflussen.

Beispiele für agenten-augmentierte Kernels, die durch diesen Workflow entwickelt und evaluiert werden können, sind:

Weitere Verbesserungen

Umgebungs-Setup

Das Einrichten der Umgebung für die Erstellung von Kernels mit kernel-builder kann eine komplexe Aufgabe darstellen. Um diesen Prozess für die Nutzer zu vereinfachen, steht nun ein Installationsskript zur Verfügung, das die Einrichtung einer Umgebung mit einem einzigen Klick ermöglicht. Für Nutzer, die lieber mit temporären Instanzen arbeiten, empfiehlt sich die Terraform-Setup-Anleitung.

Systemkarte für Kernels

Nach der Erstellung der Kernels wird für jeden Kernel eine Systemkarte generiert, um nützliche Informationen offenzulegen, einschließlich der Nutzung und der bereitgestellten Schnittstellen. Wenn der Kernel in den Hub hochgeladen wird, dient diese Systemkarte als Startseite für den Kernel.

Kompatibilitätsprüfung von Kernels

Die Frage nach der Systemkompatibilität eines Kernels ist häufig relevant. Hierfür dient die Methode has_kernel():

from kernels import has_kernel

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

Diese Methode gibt einen booleschen Wert zurück. Für detailliertere Erklärungen, warum ein bestimmter Kernel nicht unterstützt wird, kann get_kernel_variants() verwendet werden:

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})")

Die Ausgabe kann je nach System variieren und detaillierte Gründe für die Inkompatibilität liefern.

Verbesserte manylinux_2_28 Unterstützung

Kernel-builder zielte fast von Anfang an auf manylinux_2_28 ab. Zuvor wurde manylinux durch die Verwendung einer modernen GCC-Toolchain, die mit glibc 2.28 kompiliert wurde, angestrebt. Um Kompatibilitätsprobleme mit älteren Versionen von libstdc++ zu vermeiden, wurde libstdc++ statisch verknüpft.

Dieser Ansatz führte jedoch kürzlich zu einigen Problemen. Einige libstdc++-Funktionen verwenden globale Initialisierungen. Dies kann zu korrupten Daten führen, wenn mehrere libstdc++-Versionen ins Spiel kommen, wie z.B. die libstdc++, die dynamisch von PyTorch verknüpft wird, und die libstdc++, die statisch von einem Kernel verknüpft wird. Einige neuere Kernels verwenden Funktionen (z.B. C++-Regexe), die globale Initialisierungen auslösen, was zu solchen korrupten Daten führt und Segmentierungsfehlern und anderen Problemen verursachen kann.

Um dieses Problem zu lösen, verknüpfen Kernels libstdc++ nun dynamisch. Um die Kompatibilität mit alten libstdc++-Versionen zu gewährleisten, werden Kernels nun mit der offiziellen manylinux_2_28-Toolchain kompiliert.

Fazit

Das Kernels-Projekt hat zum Ziel, sowohl Kernel-Entwickler als auch Nutzer von benutzerdefinierten Kernels zu unterstützen. Feedback aus der Community zur kontinuierlichen Verbesserung des Projekts ist stets willkommen. Eine aktive Beteiligung wird ausdrücklich gefördert.