Kleine Modelle sind die neue Edge

Die spannendste Verschiebung in der Agenten-Architektur ist derzeit kein größeres Modell. Es ist die wachsende Praxistauglichkeit kleiner, spezialisierter Modelle, die genau dort laufen, wo der Agent operiert. Wenn ein Prognosemodell in vier Größen bis hinunter zu 5 Millionen Parametern erscheint und explizit auf CPU-Effizienz und Zero-Shot-Fähigkeit ausgelegt ist, ist die Botschaft an Entwickler klar: Man braucht kein Rechenzentrum mehr, um State-of-the-Art-Verhalten für eine eng umrissene Aufgabe zu bekommen [1].

Das verändert, was ein Agent ist. In den letzten zwei Jahren galt die Standardannahme, dass jede sinnvolle Fähigkeit über ein großes Frontier-Modell laufen muss. Latenz, Kosten und Datenschutz-Kompromisse nahm man in Kauf, weil es keine Alternative gab. Ein 5M-Parameter-Modell, das auf der CPU läuft, bricht mit dieser Annahme. Es bedeutet, dass die Prognosekomponente eines Agenten im selben Prozess wie der Rest der Anwendung leben kann – ohne Netzwerkaufruf, ohne Token-Abrechnung und ohne dass Daten die Maschine verlassen.

Der Governance-Aspekt

Das ist für Governance auf eine Weise relevant, die nicht sofort offensichtlich ist. Wenn ein Modell lokal läuft, ändert sich die Evaluierungsgeschichte. Man kann es vor dem Deployment mit den eigenen Daten in der eigenen Umgebung testen. Man kann die exakte Version pinnen. Man kann auditieren, was es sieht und was es ausgibt. Nichts davon ist einfach, wenn das Modell eine entfernte API ist, die sich unter der Haube ändern kann.

Googles kürzlich veröffentlichte Sicherheitsdokumentation für Gemini 4 Argon unterstreicht, wie viel Arbeit nötig ist, um ein großes Modell sicher genug für eine breite Bereitstellung zu machen [2]. Diese Arbeit ist notwendig, aber sie ist auch eine Erinnerung: Jede Fähigkeit, die man an ein Frontier-Modell auslagert, bringt eine Governance-Angriffsfläche mit sich, die man nicht kontrolliert. Je mehr man auf kleine, lokale, auditierbare Modelle verlagern kann, desto kleiner wird diese Fläche.

Der Browser als Agentengrenze

Die Nachricht zur Chrome-Erweiterung von ChatGPT weist aus der entgegengesetzten Richtung in dieselbe Richtung. Die Erweiterung kann jetzt die offenen Tabs lesen und den Chat in die gerade angezeigte Seite einbringen [3]. Das ist ein Komfortmerkmal, aber auch ein Statement darüber, wo der Agentenkontext lebt. Der Browser wird zur primären Schnittstelle für agentengestütztes Arbeiten, und die relevanten Daten sind bereits da: die offenen Tabs, die gelesene Seite, die Aufgabe, in der man gerade steckt.

Für Entwickler ist das eine Warnung. Wenn der Kontext des eigenen Agenten aus einer Browser-Erweiterung stammt, die Tabs liest, muss man sorgfältig darüber nachdenken, was das für Einwilligung, Datensparsamkeit und Nutzerverständnis bedeutet. Ein Nutzer, der eine Erweiterung für eine einzelne Funktion installiert, realisiert möglicherweise nicht, dass sie jetzt alles sieht, was er im Browser macht. Das ist kein Grund, Browser-Integration zu vermeiden. Es ist ein Grund, die Grenze explizit und das Verhalten inspizierbar zu machen.

Was jetzt zu bauen ist

Die praktische Schlussfolgerung: Schauen Sie sich die Architektur Ihres Agenten an und fragen Sie, welche Fähigkeiten tatsächlich ein Frontier-Modell benötigen. Prognosen, Klassifikation, Extraktion, Routing – das gibt es zunehmend als kleine, lokale Modelle, die Sie ehrlich evaluieren und ohne Netzwerkabhängigkeit deployen können. Reservieren Sie die großen Modelle für die wirklich ergebnisoffenen Denkaufgaben, bei denen sie ihre Kosten und ihre Governance-Last wert sind.

Fangen Sie mit einer Komponente an. Nehmen Sie eine einzelne Fähigkeit, die derzeit über eine Remote-API läuft, und testen Sie, ob ein kleines Modell sie lokal erledigen kann. Messen Sie Latenz, Kosten und Genauigkeit anhand Ihrer eigenen Daten. Wenn es standhält, haben Sie gerade Ihre Angriffsfläche, Ihre Rechnung und Ihre Abhängigkeit von einem Anbieter reduziert, den Sie nicht kontrollieren. Das ist kein Kompromiss. Das ist die Richtung, in die sich das Feld bewegt.