Technischer Kontext
Ich habe mir selbst den Space auf Hugging Face angesehen, und der Kern ist keine schöne Demo, sondern dass Gemma 4 tatsächlich on-device via WebGPU läuft. Für einige Aufgaben der KI-Integration kann man also plötzlich Inferenz ganz ohne Backend betreiben.
Diese WebGPU-Kernel wurden, der Beschreibung und den Diskussionen zufolge, von Fable 5 geschrieben. Im Wesentlichen handelt es sich um eine Reihe von Low-Level-Compute-Shadern, die die schwere Arbeit der Inferenz direkt im Browser übernehmen – ohne Server-Roundtrip.
An diesem Punkt hielt ich inne und überdachte die Architektur: Prompts, Aktivierungen und Generierung bleiben lokal auf dem Gerät. Für Anwendungsfälle mit sensiblen Daten ist das kein Marketing mehr, sondern eine praktische Weggabelung.
Aktuell geht es vor allem um Gemma 4 E2B, da die 12B- und 27B-Modelle nicht in die VRAM-Grenzen des Browsers passen. In den Anleitungen tauchen Empfehlungen für INT4-Quantisierung, reduzierte Kontextfenster und textbasierten Modus auf, obwohl die Demo auch das Laden von Bildern erwähnt.
Die Leistungsdaten sind lebendig, nicht synthetisch: In den Browser-Materialien werden etwa 40–80 Tokens/s beim Prefill und 40–180 Tokens/s beim Dekodieren genannt, und die Community diskutierte etwa 255 Tokens/s auf einem M4. Ich sehe das nicht als Versprechen, sondern als obere Grenze für eine gelungene Kombination aus Browser, GPU und Build.
Wichtig ist: Das ist nicht einfach nur „LLM in einem Tab“. Es ist ein Baustein für eine neue Klasse von Anwendungen, bei denen das Modell direkt in die Benutzeroberfläche gebracht werden kann: Chrome, Edge, lokaler Cache, PWA, schwaches Netz – null Abhängigkeit von einer Cloud-API während des Betriebs.
Was das für die Automatisierung bedeutet
Der erste Vorteil liegt auf der Hand: Der Einstieg in die KI-Implementierung wird günstiger. Wenn ich keinen Server-seitigen Inferenzbedarf habe, entfällt ein Teil von DevOps, Latenz und laufenden API-Kosten für bestimmte Szenarien.
Der zweite Punkt ist subtiler: Es ergeben sich echte Offline-Workflows. Interne Assistenten, Feld-Schnittstellen, Kioske, gesicherte Arbeitsplätze – Bereiche, in denen KI-Automatisierung zuvor an Netzwerk- oder Datenschutzanforderungen scheiterte.
Aber nicht alle profitieren gleichermaßen. Projekte mit langen Kontexten, starker Multimodalität und strenger Qualitätsvorhersagbarkeit bleiben weiterhin auf eine hybride oder serverbasierte Architektur angewiesen.
Ich sehe das ständig bei Kunden: Das Problem liegt selten im Modell selbst, sondern darin, wo die Grenze zwischen Browser, Gerät und Cloud verläuft. Bei Nahornyi AI Lab entwerfen wir KI-Architektur für reale Prozesse, nicht für schöne Screenshots. Wenn Sie ein Produkt haben, das lokale KI-Automatisierung ohne zusätzlichen Server-Aufwand benötigt, können wir gemeinsam ausloten, was heute schon sinnvoll in den Browser verlagert werden kann.