Lokale KI auf einem Handy, einem Raspberry Pi oder einem einfachen Laptop ist heute keine bloße Bastelidee mehr. Die Gemma-4-Good-Gewinner zeigen jedoch auch, warum der Modellname allein wenig erklärt. Ob ein System im Alltag brauchbar ist, hängt an der ganzen Kette: an der Runtime, an der Vorverarbeitung von Bild oder Audio, am verfügbaren Speicher und daran, was bei Überlastung oder einer unsicheren Antwort geschieht.
Google stellte am 24. August die Gewinner seiner Gemma-4-Good-Challenge vor und spricht von mehr als 1.600 Einreichungen. Die Projekte reichen von Robotik und Unterricht bis zu lokaler Gebärdensprach-Unterstützung. Das ist ein belastbarer Hinweis darauf, wie breit sich kleine multimodale Modelle inzwischen einsetzen lassen. Ein gemeinsamer Beleg für fertige, dauerhaft stabile Produkte ist es nicht.
Die Gewinner zeigen ganze Systeme, keine isolierten Modelle
Die von TechZeitGeist verglichenen Projektberichte machen einen Punkt deutlich: Gemma ist in diesen Anwendungen nur ein Baustein. Beim Projekt GEM-4 steckt ein kleines Gemma-4-E2B-Modell in einer tragbaren Vision-Language-Action-Pipeline für körpernahe Assistenz. Dazu kommen Demonstrationsdaten, Annotation, Fine-Tuning und eine Roboter-Schnittstelle. Die Autoren bezeichnen den Aufbau selbst als Forschungsprototyp und grenzen ihn ausdrücklich von einem Medizinprodukt oder einer zertifizierten Assistenzhilfe ab.
Trido, eine sprachgesteuerte digitale Tafel, kombiniert einen Cloud-Pfad mit einem lokalen Offline-Pfad über gemma4:e2b in Ollama. Der Projektbericht beschreibt sechs Wochen Einsatz in einem Klassenzimmer in Bandung. Die dort genannten 4 GB RAM, rund 40 Prozent Offline-Nutzung und weniger als 500 Millisekunden Synchronisation auf 3G sind deshalb interessante Angaben über dieses eine System, keine allgemeine Leistungszusage für Gemma auf jedem günstigen Rechner.
Am anschaulichsten wird die Systemfrage bei KawanIsyarat. Der Android-Prototyp verarbeitet BISINDO-Gebärden lokal mit Gemma 4 E2B INT4 über Cactus. Ein Whisper-Base-INT8-Modell dient als speicherbewusster Ausweichpfad. Auf einem Pixel 6a nennt der Autor 1,7 bis 1,9 GB Laufzeit-RAM sowie 3,5 bis 4,5 Tokens pro Sekunde bei n_ctx=512, Batchgröße 1 und vier Threads. Nach Speicherfehlern kam ein Wächter für zu große Audiodateien hinzu. Gerade solche Grenzen entscheiden, ob eine Demo bei wechselnden Eingaben noch benutzbar bleibt.
Warum Runtime, Speicher und Fallback den Unterschied machen
Ein lokaler Ablauf beginnt oft nicht beim Sprachmodell. Kamera, Mikrofon, Video oder Text werden zunächst aufbereitet. Danach läuft das Modell über eine Runtime wie LiteRT-LM, Cactus, Ollama oder llama.cpp. Erst dann folgt eine Antwort, Sprachausgabe, ein Widget oder eine andere lokale Funktion. Wenn die Eingabe zu groß wird, Speicher fehlt oder eine Modellfunktion nicht passt, braucht die Anwendung einen Ausweichpfad oder einen sicheren Abbruch. Bei Robotik, Gesundheit oder sicherheitsnahen Aufgaben gehört zudem eine menschliche Entscheidung an eine klar benannte Stelle.
Die eigene redaktionelle Gegenüberstellung von Google-Ankündigung, drei Gewinner-Write-ups, Modellkarte, Runtime-Dokumentation und Raspberry-Pi-Quellen führt damit zu einer nüchternen Folgerung: Kleine Modelle verschieben die technische Grenze, aber sie ersetzen keine Systemintegration. Das gilt gerade für Anwendungen, die nicht nur Text ausgeben, sondern Audio, Bilddaten oder physische Aktionen verarbeiten.
Google nennt für Gemma 4 E2B und E4B 2,3 beziehungsweise 4,5 Milliarden effektive Parameter und 128K Kontext. Diese Werte beschreiben weder die Dateigröße noch den tatsächlichen RAM-Bedarf einer konkreten App. LiteRT-LM führt Gemma 4 E2B mit 2,58 GB auf und dokumentiert 8 Decode-Tokens pro Sekunde für ein Raspberry-Pi-5-Setup mit 16 GB RAM. Eine Raspberry-Pi-Demonstration mit anderer Konfiguration – Pi 5 mit 8 GB und vier CPU-Threads – nennt 9 Decode-Tokens pro Sekunde und 1.432 MB Spitzen-RAM. Die Zahlen dürfen nicht zu einem gemeinsamen Benchmark zusammengerechnet werden: Hardware, Quantisierung, Kontext und Messprotokoll unterscheiden sich.
„Läuft lokal“ ist noch kein Komfort- oder Betriebsnachweis
Ein unabhängiger Einzeltest auf einem Raspberry Pi 5 mit 8 GB RAM setzt den Partnerwerten eine wichtige Grenze. Der Autor berichtete mit Ollama für E2B ungefähr 8 bis 12 Tokens pro Sekunde und drei bis vier Sekunden bis zum ersten Token. E4B sei mit Swap nur noch eingeschränkt nutzbar; vom nominellen 128K-Kontext blieben in dieser Hardwareklasse eher 4K bis 8K praktisch. Auch dieser Test ist kein allgemeiner Gerätevergleich. Er zeigt aber, weshalb „Modell startet“ und „Anwendung reagiert unter realer Last angenehm“ zwei verschiedene Aussagen sind.
Für keines der Gewinnerprojekte liegt ein gemeinsames, unabhängiges Protokoll für Dauerlast, Thermik, Energieverbrauch, Fehlerraten und sichere Übergaben vor. Tridos Klassenzimmerbericht ist mehr als eine reine Bildschirmdemo, bleibt aber ein selbstberichtetes Projekt in einer konkreten Umgebung. Bei GEM-4 sind Fragen zu längeren Aufgaben, mehreren Nutzern und unterschiedlichen Robotersystemen ausdrücklich noch offen.
Der Offline-Vorteil ist technisch real, rechtlich aber kein Etikett
Für Deutschland und Europa ist lokale Verarbeitung vor allem dann interessant, wenn die Verbindung instabil ist oder Sprach-, Bild- und Gesundheitsdaten nicht unnötig in einen Cloud-Dienst wandern sollen. Werden Eingaben tatsächlich auf dem Gerät verarbeitet, kann sich die Transferfläche verringern. Daraus folgt keine automatische DSGVO-Konformität. Telemetrie, Logs, Backups, Modell-Downloads, Updates und Drittanbieter-SDKs können weiterhin Datenflüsse erzeugen.
Ob Pflichten aus Datenschutz, AI Act, Produktsicherheit oder gegebenenfalls Medizinprodukterecht greifen, hängt von Anwendung, Betreiberrolle und Einsatz ab. Ein Offline-Pfad macht einen Prototypen weder automatisch rechtskonform noch zu einem zugelassenen Hilfsmittel.
Was als Nächstes überzeugen würde
Die Gemma-4-Good-Gewinner sind ein guter Beleg dafür, dass lokale KI auf Alltags-Hardware konkreter geworden ist. Sie zeigen nicht, dass jedes kleine Modell ohne weiteres einen verlässlichen Alltagsworkflow trägt. Der nächste belastbare Schritt wäre ein unabhängiger, reproduzierbarer Test für exemplarische Pipelines: mit End-to-End-Latenz, RAM, nutzbarer Kontextlänge, Thermik, Energie, Fehlerrate, Fallbacks, menschlicher Übergabe und dokumentierten Telemetriepfaden. Erst dann lässt sich beurteilen, was von einer gelungenen Challenge-Demo im Regelbetrieb übrig bleibt.
Quellen und weiterführende Informationen
- Google: How developers build AI for good with Gemma 4, 24. August 2026.
- Kaggle: GEM-4 – Gemma Embodied 4 Physical Assistance.
- Kaggle: Trido.
- Kaggle: KawanIsyarat.
- Google: Gemma 4 model card.
- Google AI Edge: LiteRT-LM Overview.
- Raspberry Pi: Mastering edge AI on Raspberry Pi with LiteRT and Gemma.
- Alan West: Gemma 4 Runs on a Raspberry Pi. I Tested It.
- EUR-Lex: Verordnung (EU) 2024/1689 (AI Act).
Hinweis: Für diesen Artikel wurden KI-gestützte Recherche- und Editierwerkzeuge verwendet. Der Inhalt wurde redaktionell geprüft. Stand: 2026-08-25.
