Hugging Face hat am 1. September @huggingface/kernels veröffentlicht, eine JavaScript-Loader-Bibliothek zum Herunterladen, Vorbereiten und Ausführen optimierter WebGPU-Kernel aus dem Hub. Gleichzeitig gingen 207 bereits durchoptimierte GPU-Kernel online, die Matrixmultiplikation, Normalisierung, Faltung, Attention-Primitive, Quantisierungsoperationen und Datenlayout-Umwandlungen über verschiedene ML-Architekturen hinweg abdecken. Lizenziert ist das Ganze unter Apache-2.0.
Die Organisationsform ist das eigentlich Ungewöhnliche an dem Projekt: Jeder Kernel erscheint als eigenständiges Repository mit eigener Interface-Definition, eigenen Shader-Templates, Korrektheitstests und Benchmark-Daten. Einmal im Hub, laufen ein Kernel und ein Modell über dieselbe Versionierungs-, Download- und Referenzierungslogik.
809 Vergleichstests
Die Leistung wurde direkt gegen ORT WebGPU 1.30.0-dev gemessen, auf Basis von 809 Testfällen: geometrisches Mittel 2,57-mal schneller, Median 1,90-mal schneller, Bilanz 629 Siege, 176 Niederlagen, 4 Unentschieden. Auf einzelne Kernel heruntergebrochen: Add 3,52-mal schneller, Softmax 2,11-mal schneller, LayerNormalization 2,22-mal schneller.
Grob gerechnet liegt die Erfolgsquote bei 78 %. Dass das geometrische Mittel von 2,57 deutlich über dem Median von 1,90 liegt, zeigt eine nach rechts verschobene Verteilung der Beschleunigungswerte – wenige Kernel sind extrem viel schneller und ziehen den Durchschnitt nach oben. Der Geschwindigkeitsgewinn, den man bei realen Workloads tatsächlich spürt, liegt vermutlich näher am Median als an der auffälligsten Zahl aus der Ankündigung. Das ändert nichts an der Grundaussage, rückt die Erwartung aber zurecht.
Dazu kommt ein browserinternes Benchmark-Tool namens Fleet, das auf Crowdsourcing setzt: Wessen Maschine mitläuft, dessen Leistungs- und Korrektheitsdaten fließen zurück. WebGPU ist auf Hardwareebene deutlich fragmentierter als serverseitiges CUDA – integrierte GPUs, dedizierte GPUs, mobile GPUs und unterschiedliche Browser-Implementierungen liefern stark abweichende Ergebnisse, die sich mit ein paar Labormaschinen nicht erfassen lassen. Die Tests auf die Nutzer zu verteilen, ist dafür der pragmatische Weg.
Warum der Engpass genau bei den Kerneln liegt
Der Reiz, Modelle direkt im Browser laufen zu lassen, war schon immer klar: Die Berechnung findet auf dem Gerät der Nutzer statt, der Server zahlt keine Rechenkosten, und Daten müssen das Gerät nicht verlassen. Woran es in der Praxis meist hakt, ist weder das Modellformat noch das Inferenz-Framework, sondern die darunterliegende Kernel-Ebene – bei derselben Softmax-Funktion entscheidet eine gute gegenüber einer mittelmäßigen Implementierung darüber, ob Echtzeit machbar ist oder nicht.
Bisher ließ sich diese Ebene nur zusammen mit dem gesamten Inferenz-Runtime aktualisieren. Wer eine schnellere Attention-Implementierung wollte, musste in der Regel auf eine neue Framework-Version warten. Als eigenständige Repositories werden Kernel jetzt zu Einheiten, die sich einzeln austauschen, einzeln zurückrollen und einzeln verbessern lassen. Ein für eine bestimmte GPU-Klasse optimierter Matrixmultiplikations-Kernel lässt sich für ein Modell austauschen, ohne theoretisch den Rest des Codes anzufassen.
Der Aufruf ist entsprechend kompakt gehalten – man holt sich das Kernel-Objekt und benutzt es direkt wie eine Funktion:
const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });Voraussetzung ist ein Browser mit WebGPU-Unterstützung, geprüft mit einer einzigen Zeile: "gpu" in navigator.
Was das für On-Device-Tools bedeutet
Die Nutznießer dieses Updates sind ziemlich konkret: Teams, die reine Browser-Bildbearbeitung, lokale Transkription, Offline-Übersetzung oder datenschutzsensible Tools bauen. Deren Geschäftsmodell beruht darauf, dass der Server nur statische Dateien ausliefert und keine Rechenkosten trägt – wie groß ein Modell sein darf, das noch in den Browser passt, hängt direkt von der Kernel-Performance ab. Sind die Kernel im Schnitt doppelt so schnell, rutscht die machbare Modellgröße eine Stufe höher, und eine Aktion, die vorher drei Sekunden brauchte, passt in eine Sekunde.
Zur Einordnung gehört aber auch das Vorsichtige. Verglichen wurde gegen eine Dev-Version von ORT WebGPU, und auch die Konkurrenz entwickelt sich weiter; 207 Kernel klingen nach viel, decken aber vor allem gängige Operationen ab – bei ungewöhnlichen Architekturen muss weiterhin selbst geschrieben werden. Die WebGPU-Unterstützung ist zwar mittlerweile in allen großen Browsern verfügbar, doch die Implementierungsqualität auf Mobilgeräten ist uneinheitlich, und geräteübergreifendes Verhalten muss man sich mit Tools wie Fleet selbst erarbeiten.
Kernel zu adressierbaren, versionierten und crowdsourced verifizierten Ressourcen zu machen, wirkt langfristig bedeutsamer als die reine Verdopplung der Geschwindigkeit. Modellgewichte werden schon lange so gehandhabt – dass die Infrastruktur für den Code nachzieht, war nur eine Frage der Zeit.
Quellen: offizieller Hugging-Face-Blog, CocoLoop, Hugging-Face-Hub-Repositories; die Zahl von 207 Kerneln, 809 Testfällen, das geometrische Mittel von 2,57 und der Median von 1,90 sowie die Bilanz von 629:176:4 und die kernel-spezifischen Faktoren wurden anhand der offiziellen Ankündigung geprüft, die Erfolgsquote und die Einschätzung zur Verteilungsschiefe sind eine grobe redaktionelle Einordnung.