Kategorie: KI-News

Du sitzt an deinem Schreibtisch und steuerst eine Flotte von KI-Agenten, die selbstständig Code schreiben und ausführen. Bisher ging das über Smartphone oder Desktop-App – umständlich und unübersichtlich. OpenAI will das mit der Codex Micro ändern, einer 230 Dollar teuren Tastatur für den KI-Coding-Assistenten Codex. Co-designt mit Work Louder, soll sie als physische Kommandozentrale für agentische Arbeit dienen.

Die Tastatur ist beleuchtet und hat sogenannte Agent Keys, die den Status deiner KI-Agenten anzeigen. Leuchten sie grün, läuft alles. Bei Rot musst du eingreifen. Dazu gibt es Command Keys, programmierbare Tasten für wiederkehrende Aktionen, einen Joystick zum Starten von Workflows und einen Drehregler für die Reasoning-Stufe – also wie viel Rechenzeit ein Agent in eine Aufgabe investieren soll. Das erinnert an ein Cockpit: Statt über Bildschirme und Mausklicks navigierst du live und fühlst physische Rückmeldungen. Ein klarer Ansatz, der KI greifbar macht.

Der Tech-Journalist Lucas Ropek beschreibt die Codex Micro bei TechCrunch als limitierte Kollaboration. OpenAI selbst bezeichnet sie als „Novelty-Item“ – ein glänzendes Spielzeug, weniger für den Massenmarkt, sondern als Türöffner für die Hardware-Strategie. Die Tastatur ist über die ChatGPT-Desktop-App steuerbar und anpassbar. Für knapp 230 Euro bekommst du ein spezialisiertes Werkzeug, das sichtbar macht, wohin die Reise geht. Die eigentliche Hardware-Offensive von OpenAI steckt noch in den Startlöchern.

Laut einem Bloomberg-Bericht arbeitet OpenAI an einem weiteren Gerät: einem tragbaren, bildschirmlosen Smart Speaker mit ChatGPT-Integration und mechanischen Elementen, die sich eigenständig bewegen können. Ein Lautsprecher ohne Bildschirm, der interagiert und sich physisch verändert. Die Entwicklung wird von ehemaligen Apple-Ingenieuren vorangetrieben – ein heikler Punkt. Apple verklagt OpenAI wegen des Vorwurfs des Diebstahls von Geschäftsgeheimnissen. OpenAI soll vertrauliche Informationen aus Apple abgeschöpft haben, um die eigene Hardware-Entwicklung zu beschleunigen. OpenAI weist die Vorwürfe zurück. Die Klage zeigt, wie ernst der Hardware-Rechtsstreit geworden ist.

Warum der Aufwand um eine Tastatur? Auf den ersten Blick wirkt die Codex Micro überteuert und nischig. 230 Dollar sind kein Pappenstiel, und viele Entwickler nutzen ihre normale Tastatur. Aber dahinter steckt ein Muster: OpenAI möchte verändern, wie wir mit KI interagieren. Bisher war das meist textbasiert: Du tippst einen Prompt ein, der Agent arbeitet und liefert ein Ergebnis. Die Codex Micro macht diesen Prozess physisch erfahrbar. Du siehst, welcher Agent arbeitet, passt die Arbeitslast über den Drehregler an und startest Workflows mit dem Joystick – alles ohne den Blick vom Code zu nehmen. Ein Werkzeug für Produktivität und die Verbindung von Mensch und Maschine.

Eine Tastatur allein macht noch keinen Paradigmenwechsel. Das zweite Gerät, der bildschirmlose Speaker, verspricht mehr. Wenn OpenAI ein portables Gerät mit beweglichen Teilen auf den Markt bringt, das Sprache und physische Interaktion vereint, betreten wir Neuland. Stell dir vor, du unterhältst dich mit einem Gerät, das sich dir zuwendet, nickt oder die Lautstärke durch eine Drehung anpasst. Eine neue Schnittstelle – intuitiv, fast menschlich. Das Gerät steckt laut Bloomberg noch in der Entwicklung und kann sich ändern. OpenAI äußert sich nicht dazu.

Für Entwickler und Tech-Enthusiasten ist die Codex Micro ein Statement. OpenAI nimmt Hardware ernst, experimentiert aber noch. Der Preis von 230 Dollar ist hoch, aber für ein Spezialwerkzeug nicht ungewöhnlich. Die Frage ist, ob die Tastatur hält, was sie verspricht: eine echte Produktivitätssteigerung oder ein Lifestyle-Accessoire? Lucas Ropek deutet an, dass es sich um ein begrenztes Modell handelt – vielleicht ein Signal an die Konkurrenz. Die Apple-Klage wirft einen Schatten auf diese Pläne, aber vielleicht treibt der Druck die Innovation voran.

Was bedeutet das konkret für dich? Wenn du viel mit KI-Coding-Agenten arbeitest, könnte die Codex Micro deine Arbeit flüssiger machen. Wenn du gelegentlich einen Prompt tippst, investierst du das Geld besser in Rechenzeit. Der wahre Wert liegt möglicherweise in der Entwicklungsumgebung insgesamt: OpenAI bereitet sich darauf vor, nicht nur Software, sondern auch Hardware zu liefern. Die Tastatur ist der erste Schritt, der Speaker der nächste. Der Rechtsstreit mit Apple erinnert daran, dass dieser Weg nicht ohne Konflikte verläuft.

Quelle: techcrunch.com

Apple wirft einem ehemaligen Ingenieur vor, nach seinem Ausscheiden wochenlang auf interne Systeme zugegriffen zu haben. Chang Liu soll entdeckt haben, dass sein alter Firmenlaptop noch Zugriff auf Apples Netzwerk hatte. Grund war ein Authentifizierungsfehler, den Apple als Zero-Day-Bug einstufte. Das Unternehmen reichte Anfang des Jahres Klage ein. Der Vorfall wirft Fragen auf: Wie schützen Firmen sensible Daten, wenn Mitarbeiter gehen? Was bedeutet das für die Sicherheitskultur in KI-Unternehmen?

Laut Klageschrift fand Liu nach seinem Wechsel zu OpenAI im Februar 2026 heraus, dass sein alter Laptop immer noch Zugriff hatte. Der Grund: ein seltener, zuvor unbekannter Authentifizierungsfehler. Apple hat die Lücke inzwischen geschlossen. Die Serverprotokolle zeigen, dass Liu der Einzige war, der sie ausnutzte. „LOL… so funny“ schrieb er einem noch bei Apple angestellten Bekannten. Der Satz steht in der Klage.

Was Liu mitnahm: Dutzende Dateien mit Details zu unveröffentlichten Produkten, technische Präsentationen, Spezifikationen und Projektdaten. Er lud sie herunter, während er bereits für OpenAI arbeitete. OpenAI erklärte, man habe kein Interesse an Geschäftsgeheimnissen anderer Firmen. Apple verlangt ein Schwurgerichtsverfahren.

Viele Unternehmen gehen davon aus, dass mit dem Ausscheiden eines Mitarbeiters die Zugriffe enden. In der Praxis gibt es Lücken: VPN-Zugänge, die nicht deaktiviert wurden, Passwörter, die nicht zurückgesetzt wurden. Apple wirft Liu vor, den Bug nicht gemeldet zu haben. Er gab seinen Firmenlaptop nicht zurück und nutzte sogar den Rechner eines Kollegen. Unternehmen brauchen regelmäßige Audits und automatisierte Prozesse. Ausgeschiedene Mitarbeiter müssen physisch und digital vollständig getrennt werden.

Der Fall zeigt die Verflechtung der Belegschaften großer Tech-Firmen. Insidwissen ist im Wettlauf um KI-Innovationen wertvoll. Wenn ein Ingenieur von Apple zu OpenAI wechselt und Daten mitnimmt, entsteht ein Risiko für die Wettbewerbsposition. Apples Klage ist daher konsequent. Der Schaden durch kompromittierte Hardware-Dokumentationen oder Software-Architekturen kann enorm sein.

Sicherheit ist ein Prozess, keine einmalige Maßnahme. Wer sensible Daten verwaltet, sollte fragen: Was passiert, wenn ein Teammitglied geht? Sind alle Zugänge sofort gesperrt? Gibt es einen Plan zur Löschung lokaler Dateien? Der Fall Liu zeigt, dass ein vergessener Authentifizierungstoken ausreicht. Hinter KI-Modellen stecken Menschen, die von einem Unternehmen zum nächsten wechseln. Entscheidend ist, wie Unternehmen ihre Systeme so robust machen, dass selbst ein „LOL“-Moment nicht zu einem Datenleck führt.

Der Schlüssel zur Vergangenheit sollte nach dem Auszug nicht mehr passen. Digitale Zugänge müssen sofort gesperrt werden. Die Daten, die Unternehmen schützen, können mehr wert sein als eine Wohnung – sie können die Zukunft eines ganzen Unternehmens bestimmen.

Quelle: techcrunch.com

Stell dir vor, du arbeitest an einer Website. Du hast eine klare Vorstellung, tippst Änderungen ein, und nach wenigen Sekunden erscheint eine neue Version. Dann öffnest du das Menü, prüfst die Einstellungen und klickst auf „Veröffentlichen“. Bei fünfzehn kleinen Anpassungen sind das fünfzehn manuelle Schritte. Die Auto-Publish-Funktion von Manus macht diesen letzten Schritt überflüssig. Der Entwickler, ein Anbieter KI-gestützter Website-Erstellung, hat einen Schalter eingebaut, der das manuelle Veröffentlichen ersetzt.

Die Idee ist simpel. Legst du den Schalter im Veröffentlichungs-Popover um, wird jeder erfolgreiche Build automatisch auf deine Live-URL ausgeliefert. Keine Bestätigung, kein manuelles Eingreifen. Deine Seite bleibt synchron mit der letzten von dir akzeptierten Version. Bisher war die Veröffentlichung ein eigener Schritt, der Aufmerksamkeit erforderte. Mit Auto-Publish wird sie zum Nebenprodukt des Bauens. Du änderst etwas, der Build läuft, und sobald er erfolgreich ist, ist die Änderung live. Kein Warten, kein extra Klick.

Der Schalter ist standardmäßig ausgeschaltet. Das ist Absicht. Nicht jede Iteration ist für die Öffentlichkeit bestimmt. Vielleicht experimentierst du mit einem Layout, das du noch nicht zeigen willst, oder testest eine Farbpalette. Auto-Publish ist für die Momente gedacht, in denen du genau weißt, wohin die Reise geht, und die Distanz zwischen „sieht gut aus“ und „es ist live“ Null sein soll. Du schaltest es jederzeit im selben Popover wieder aus. Dein bisheriger Workflow ändert sich nicht, solange du nicht aktiv zustimmst.

Ein Beispiel: Ein Freiberufler baut eine Portfolio-Seite für eine Fotografin. In der ersten Session entsteht die Struktur: eine Galerie, eine Über-mich-Seite, ein Kontaktformular. Er veröffentlicht manuell und teilt den Link. Über Nacht kommt Feedback. Am nächsten Morgen sitzt er mit einer Liste da: Schriftart austauschen, Kundenstimmen ergänzen, Bilder komprimieren, Footer mit Social Links aktualisieren, den mobilen Nav-Breakpoint anpassen. Er ist nicht mehr im Experimentiermodus, sondern im Fertigstellungsmodus. Jetzt schaltet er Auto-Publish ein. Jede Änderung, die Manus abschließt, geht sofort live. Die Fotografin kann die Seite zwischen seinen Nachrichten aktualisieren und die Entwicklung in Echtzeit verfolgen. Die Seite ist fertig und veröffentlicht – ohne einen einzigen Besuch des Publizier-Menüs.

Die Funktion entfernt die Zeremonie des Veröffentlichens. Statt nach jedem kleinen Schritt innezuhalten, konzentrierst du dich auf das Wesentliche. Das ist praktisch in agilen Arbeitsabläufen mit vielen kleinen Änderungen. Der Arbeitsfluss wird flüssiger, die Feedback-Schleife kürzer. Du bleibst im Gespräch mit deinem Kunden oder Team, während die Seite parallel wächst.

Die Bedienung ist einfach. Öffnest du dein WebDev-Projekt, klickst oben rechts auf „Veröffentlichen“, scrollst im Popover nach unten und legst den Schalter „Auto publish when it’s ready“ um. Ab dann wird jeder erfolgreiche Build automatisch auf deine öffentliche URL ausgespielt. Zum Deaktivieren öffnest du dasselbe Popover und schaltest sie wieder aus. Der nächste Build wartet dann wieder auf manuelle Bestätigung. Die Funktion ist auf Web, iOS und Android verfügbar.

Ein Detail: Du kannst Änderungen in eine Warteschlange stellen, während Manus noch am aktuellen Build arbeitet. Kombiniert mit Auto-Publish bedeutet das: Du schreibst deine To-Do-Liste in den Chat, schließt den Laptop, und kommst zu einer fertigen, live geschalteten Seite zurück. Manus verarbeitet die Anfragen der Reihe nach, erstellt die neue Version und veröffentlicht sie – alles ohne dein Zutun. Das ermöglicht einen asynchronen Arbeitsstil.

Natürlich tauchen Fragen auf. Ist Auto-Publish standardmäßig aktiv? Nein, du musst es explizit einschalten. Können Kunden während des Bauens halbfertige Arbeit sehen? Nein, nur erfolgreiche Builds werden veröffentlicht. Fehlgeschlagene oder laufende Builds beeinflussen die Live-Seite nicht – sie bleibt auf der letzten stabilen Version. Kann man eine laufende Veröffentlichung abbrechen? Ja, die Oberfläche bietet während des Deployments eine Abbruch-Option. Funktioniert das auch auf dem Smartphone? Ja, auf iOS und Android ist der Schalter im selben Popover verfügbar.

Mit Auto-Publish entfernt Manus die letzte manuelle Hürde zwischen Erstellung und Auslieferung. Der Nutzer muss nicht mehr zwischen Bauen und Veröffentlichen wechseln. In der Summe vieler kleiner Iterationen spart das Zeit und kognitive Belastung. Die Technologie tritt in den Hintergrund und macht den Weg frei für die Arbeit selbst. Für alle, die schon wissen, was sie wollen, wird das Veröffentlichen zum unsichtbaren Teil des Prozesses.

Quelle: manus.im

Du übernimmst ein großes Open-Source-Projekt. Tausende Zeilen Code, dutzende Contributor. Manuelle Code-Reviews sind gründlich, aber zeitaufwendig. Automatisierte Scanner finden oft nur bekannte Muster. Ein neues Toolkit von Google setzt genau hier an: Mantis. Es ist ein modulares Set von Fähigkeiten – Skills – für KI-gesteuerte Coding-Agenten. Diese Agenten finden Schwachstellen, reproduzieren sie und erstellen Patches. Die richtige Anwendung ist entscheidend.

Mantis ist kein einfaches Sicherheitstool. Es ist ein Baukasten, ein Rahmenwerk, das du an deine Umgebung anpassen kannst – für Webanwendungen, Hardware-Beschreibungen in SystemVerilog, Cloud-Infrastruktur oder kompilierte Binärdateien. Es ist als „entkoppelt, sequenziell und sicherheitsfokussiert“ konzipiert. Du kannst einzelne Schritte gezielt ausführen, musst nicht die gesamte Pipeline nutzen, und die Sicherheit hat oberste Priorität. Denn Mantis generiert und führt autonom Code aus – Code, der potenziell instabil oder schädlich sein kann.

Wichtig: Google stellt klar, dass dieses Toolkit nur in isolierten, restriktiven Umgebungen verwendet werden darf. Niemals auf Maschinen mit Zugriff auf Produktionssysteme, sensible Daten oder interne Netzwerke. Die Verantwortung liegt bei dir. Jeder Fund muss von einem Sicherheitsexperten manuell überprüft werden. KI kann halluzinieren oder falsche Patches generieren. Massenhaft ungeprüfte Reports an Maintainer zu schicken, ist nicht nur unprofessionell, sondern potenziell schädlich.

Mantis funktioniert wie eine Sicherheitsfirma: Jeder Mitarbeiter hat eine spezielle Aufgabe, und sie arbeiten in einer definierten Reihenfolge zusammen. Insgesamt besteht die Pipeline aus sechzehn Komponenten: einem Supervisor und fünfzehn Ausführungsstufen. Der Supervisor – das Meta-Agent – startet die Schleife, überwacht den Fortschritt, behandelt Fehler und archiviert die Ergebnisse zwischen den Durchläufen. Das geschieht in einem kontinuierlichen Kreislauf, sodass das System aus vorherigen Analysen lernen kann.

Die erste Stufe ist optional und analysiert die Versionsgeschichte des Repositorys. Sie extrahiert vergangene Schwachstellen, Sicherheitsfixes und Muster. Diese Informationen werden in einer JSONL-Datei gespeichert. Danach kommt der Summarizer, der für jedes Verzeichnis eine Zusammenfassung erstellt – wiederum optional, aber hilfreich für die Planung. Der Knowledge Base Architect untersucht den Code und baut eine permanente, verknüpfte Wissensdatenbank auf. Sie enthält Entitäten, Datenflüsse und historische Schwachstellenklassen. Diese Wissensdatenbank ist das Gedächtnis der Pipeline.

Anschließend erstellt der Threat Modeler ein Bedrohungsmodell. Es identifiziert Vertrauensgrenzen und Angreiferprofile. Der Strategist, genannt Mantis Plan, scannt die Workspace-Grenzen und liest die Indizes der Wissensdatenbank, um eine gezielte Review-Strategie zu entwerfen. Diese wird in einer JSON-Datei gespeichert. Jetzt beginnt die eigentliche Suche: Der Researcher führt eine dateiweise Triage und tiefgehende Sicherheitsanalysen durch. Er erstellt für jeden Hotspot eine separate JSON-Datei im Findings-Ordner.

Duplikate werden vom Deduplicator zusammengeführt. Der Validator filtert falsch-positive Ergebnisse mit strengen pragmatischen Einschränkungen. Der Critic überprüft, ob ein Fund in einem Release-Build reproduzierbar ist – Debug-Asserts zählen nicht. Der Reproducer schreibt Proof-of-Concept-Skripte und führt sie in isolierten Umgebungen wie gVisor oder virtuellen Maschinen aus. Das ist der Moment, in dem die Gefahr am größten ist: Der Code wird tatsächlich ausgeführt. Deshalb betont Google die „No-Host-Run“-Regel – Skripte laufen nur im Sandkasten.

Danach analysiert der Chainer einzelne Funde und kombiniert sie zu komplexen Angriffsketten. Der Patcher generiert und wendet Code-Fixes an, gefolgt von Validierungstests. Der Risk Calibrator berechnet einen numerischen Risikoscore von 1 bis 10 für jeden Fund. Der Reflector schließlich parst die Ausführungspfade der Agenten und extrahiert falsche Annahmen, Werkzeugfehler und Erfolge. Diese Erkenntnisse fließen zurück in die Lernschleife. Der Reporter erstellt am Ende einen menschenlesbaren Sicherheitsbericht im Markdown-Format.

Mantis ist komplex, aber du musst nicht alle Schritte auf einmal ausführen. Du kannst interaktiv vorgehen, Schritt für Schritt, mit menschlicher Bestätigung vor jeder kritischen Aktion. Google empfiehlt den „Interaktiven Modus“ für Einsteiger. Dabei startest du die CLI normal und gibst die Slash-Befehle einzeln ein. Das System pausiert dann und fragt nach Erlaubnis, bevor es Sandbox-Befehle ausführt oder Dateien schreibt. So hast du die Kontrolle.

Die möglichen Anwendungen gehen weit über generische Web-Schwachstellen hinaus. Du kannst Mantis anpassen für Hardware-Reviews von RTL-Designs, für Infrastructure-as-Code wie Terraform oder Kubernetes RBAC, für Data-Pipelines mit Modell-Serialisierungsformaten wie Pickle, oder sogar für kompilierte Binärdateien im Gray-Box-Stil. Dabei emulieren die Tools einen externen Forscher, der nur die veröffentlichten Binaries hat. Das zeigt dir genau, welche Schwachstellen ein Angreifer ohne Quellcode finden könnte.

Ein entscheidender Punkt ist die Lernschleife. Mantis speichert Erkenntnisse aus jedem Durchlauf in einer learnings.jsonl-Datei. Der Reflector fügt strukturierte Einsichten hinzu – was hat funktioniert, was nicht. Diese Informationen werden im nächsten Zyklus von der Architektur- und Planungsstufe gelesen. So passt sich das System an, vermeidet redundante Analysen und wird mit der Zeit effizienter. Das ist kein statischer Scanner, sondern ein lernendes System.

Was bedeutet das konkret für dich? Wenn du in der Sicherheitsforschung oder im DevSecOps-Bereich arbeitest, eröffnet Mantis neue Möglichkeiten. Du kannst große Codebasen systematisch und wiederholbar prüfen, ohne jedes Mal von Null zu beginnen. Die Automatisierung übernimmt die mühsame Arbeit des Suchens und der ersten Reproduktion. Aber die letzte Verantwortung bleibt beim Menschen. Du musst die Ergebnisse validieren, patchen und entscheiden, ob ein Fund relevant ist. Kein Tool der Welt ersetzt fundierte Sicherheitskenntnisse.

Die Modelle sind nicht deterministisch, sie können halluzinieren, Fehler machen. Mantis ist ein Werkzeug, kein Wundermittel. Es erfordert Disziplin, Isolation und eine kritische Haltung. Wer das beachtet, erzielt echte Mehrwerte – vor allem in Umgebungen, die manuell kaum noch zu bewältigen sind.

Die Zukunft der Sicherheitsanalyse wird automatischer, bleibt aber auf menschliches Urteilsvermögen angewiesen. Mantis zeigt, wie das modular und lernend aussehen kann. Der Fokus liegt auf sicherer Ausführung. Verantwortungsvoller Einsatz ist entscheidend.

Quelle: github.com

Dein Smartphone kann dir sofort sagen, was das für ein Käfer auf dem Blatt ist, oder eine lange Besprechung zusammenfassen – auch ohne Empfang. Das verspricht Googles neues KI-Modell für die nächste Pixel-Generation. Am 14. Juli 2026 kündigte Google auf der I/O Connect India das Modell Gemma 4 E2B for TPU an. Es läuft nativ auf dem Tensor Processing Unit (TPU) des kommenden Pixel 10 und seiner Geschwister. Der Autor Abner Li von 9to5Google berichtete darüber.

Gemma ist eine Familie offener, leichter KI-Modelle von Google, die direkt auf dem Gerät laufen – Daten bleiben lokal. Gemma 4 wurde im April 2026 vorgestellt und gilt als Basis für Gemini Nano 4, das ebenfalls auf dem Pixel 10 laufen soll. Google beschrieb es als hochmodern, leistungsfähig und schlank. Diese Kombination ist entscheidend für den Einsatz auf einem Smartphone mit begrenztem Rechenstrom und Energie.

Stell dir ein Schweizer Taschenmesser vor: Ein kompaktes Werkzeug für viele Aufgaben. Gemma 4 vereint mehrere Fähigkeiten in einem kleinen Modell, das in den Tensor G5-Chip des Pixel 10 passt. Es ist multimodal – verarbeitet Text, Bilder, Audio und Videoströme. Und das passiert lokal. Dadurch entstehen Anwendungen, die bisher nur mit Internetverbindung denkbar waren.

Ein konkretes Beispiel: Der Chat mit der KI funktioniert auch im Flugzeug ohne WLAN. Du machst ein Foto, die KI fragt: „Was ist das für eine Pflanze?“ oder „Wo ist der Schaden an diesem Bauteil?“, und sie antwortet, ohne dass ein Server antworten muss. Ebenso möglich: private, lokale Transkription von Audioaufnahmen – nützlich für Vorlesungen oder Meetings. Google zeigte auch „Mobile Actions“: Du steuerst Kernfunktionen des Telefons per Sprach- oder Texteingabe – WLAN einschalten, Karten-App öffnen – alles ohne Datenübertragung nach außen.

Die Anwendungen gehen über das Privatleben hinaus. Im Handel könnte ein Verkäufer ein Rezeptfoto in eine Einkaufsliste im Laden umwandeln – offline. In der Werkstatt macht ein Mechaniker ein Foto von einem defekten Getriebeteil, die KI gibt eine Diagnose, ohne dass er eine Suchmaschine befragen muss. On-Device-KI beschleunigt Arbeitsabläufe und adressiert Datenschutzbedenken – Daten verlassen nie das Gerät.

Bisher waren leistungsfähige KI-Modelle oft an Cloud-Dienste gebunden. Große Modelle wie GPT-4 oder Gemini laufen auf Serverfarmen, brauchen schnelles Internet und verursachen Latenz. Für Echtzeitanwendungen oder Situationen ohne Netz war das eine Hürde. Mit Gemma 4 E2B schließt Google diese Lücke. Der Name „E2B“ symbolisiert, dass das KI-Gehirn direkt am Rand des Netzes auf deinem Gerät sitzt.

Die Optimierung auf den Tensor G5 und seine TPU ist entscheidend. TPUs sind spezialisierte Chips für die Matrixberechnungen neuronaler Netze. Google hat sie für Rechenzentren entwickelt und bringt sie nun aufs Smartphone. Gemma 4 ist darauf zugeschnitten: weniger Stromverbrauch, schnellere Antwortzeiten, komplexere Modelle laufen lokal. Unterstützt werden Pixel 10, 10 Pro, 10 Pro XL und 10 Pro Fold. Frühere Pixel oder andere Android-Geräte werden vorerst offiziell nicht bedient.

Google positioniert Gemma als offenes Modell. Entwickler können es herunterladen, anpassen und in eigene Apps integrieren. Das erinnert an die Strategie hinter TensorFlow Lite: eine KI-Plattform für viele Geräte, eng mit Googles Hardware verzahnt. Apps von Drittanbietern könnten diese lokale KI nutzen, ohne eigene Server zu betreiben – Fotobearbeitung erkennt Objekte, Notiz-Apps transkribieren handschriftliche Notizen. Alles offline und datenschutzkonform.

Es gibt Grenzen. On-Device-KI erreicht nie die Rechenleistung eines Rechenzentrums. Die Modelle müssen leichter sein, was Abstriche bei Genauigkeit oder Wissensumfang bedeuten kann. Google betont die Leichtigkeit – eine bewusste Einschränkung. Für komplizierte Reasoning-Aufgaben oder große Textmengen bleibt die Cloud nötig. Die Stärke liegt in der Kombination: schnelle, private Aufgaben laufen lokal; komplexe Anfragen gehen in die Cloud. Das ist Googles hybride KI-Vision.

Für Pixel-10-Käufer bedeutet das: Ihr Telefon bringt eine KI-Fähigkeit mit, die über das Google Assistant-Niveau hinausgeht. Es erkennt Bilder, transkribiert Audio und schlägt kontextbezogene Aktionen vor – ohne Serververzögerung. Wer viel reist, in Gebieten mit schlechtem Netz arbeitet oder Wert auf Datenschutz legt, bekommt ein Werkzeug, das bisher Science-Fiction war. Die Technologie steckt noch in den Kinderschuhen. Erste Demos zeigen vielversprechende Ansätze, die Alltagstauglichkeit wird sich erst in den nächsten Monaten zeigen.

Mit Gemma 4 E2B setzt Google einen Meilenstein für On-Device-KI. Die Kombination aus maßgeschneiderter Hardware und einem schlanken Modell könnte das Smartphone-Erlebnis verändern. Es ist kein sofortiger Umbruch, aber ein Schritt in eine Zukunft, in der KI nicht nur in der Cloud lebt, sondern auch in der Hosentasche. Für Nutzer bedeutet das mehr Privatsphäre, mehr Unabhängigkeit von der Internetverbindung und ein Werkzeug, das im Alltag unterstützt. Die Konkurrenz wird reagieren müssen.

Quelle: 9to5google.com