Kategorie: Erklärer

Im Call gibt es zuerst Lob: Die KI-Funktion ist pünktlich fertig, die Nutzer sind zufrieden, die Kennzahlen steigen. Dann schließt die Finanzabteilung das Quartal ab – und die Rechnung zeigt: Jede Anfrage kostet mehr, als sie einbringt.

Solche Anrufe erlebe ich Woche für Woche. Ich arbeite in der Developer Relations bei einem GPU-Cloud-Anbieter im Silicon Valley und sitze in denselben Video-Calls, in denen Teams über KI-Infrastruktur entscheiden. Je länger ich das mache, desto deutlicher sehe ich die Cloud-Kosten-Disziplin der 2010er-Jahre wiederkehren – nur mit teurerer Hardware und Fehlern, die schneller durchschlagen.

Die Szene kennen wir. Vor zehn Jahren brachten Cloud-Rechnungen Engineering-Leiter dazu, nach den Kosten zu fragen. Jetzt tun es die GPU-Rechnungen wieder – mit zehnfachen Beträgen. Die Lektion ist teurer geworden. Immer wieder erlebe ich, wie solide Teams ihre Disziplin verlieren, sobald auf dem Bestellschein GPU steht. KI-Ausgaben behandeln sie wie eine Wette, nicht wie einen Betriebskostenposten. Da beginnt das Problem.

Die Stunde ist die falsche Einheit für GPU-Kosten

GPU-Kapazität wird pro Stunde abgerechnet. Also planen und berichten Teams in Stunden. Das wirkt ordentlich, passt zur Rechnung – und verdeckt die Kennzahl, die über den Erfolg einer KI-Funktion bestimmt: die Kosten pro Request. Sie ergeben sich aus allen Ausgaben für die Inferenz-Infrastruktur geteilt durch die Anzahl der bedienten Anfragen. Sie gleichen dem Stundensatz nur, wenn die Hardware voll ausgelastet ist.

Bei nutzerorientierter KI ist das die Ausnahme. Der Datenverkehr folgt menschlicher Aufmerksamkeit: ein paar Stunden Anstieg, dann Abfall. Ich arbeitete einmal mit einem Team, das einen Cluster für eine Spitze reserviert hatte, die nur etwa zwei Stunden am Tag auftrat. Auf der Rechnung sah der Stundensatz fast günstig aus. Teilte man ihn durch die tatsächlich bedienten Anfragen, war das Ergebnis ernüchternd. Das Team sah diese Zahl zum ersten Mal, als wir sie gemeinsam durchrechneten.

Diese Division empfehle ich jedem Team. Nimm die gesamten Inferenzausgaben des letzten Monats. Teile sie durch die Anzahl der Requests. Wenn die Antwort eine betretene Stille erzeugt, hast du Geld gefunden – mit einer Rechenaufgabe, die längst eine Tabellenkalkulation hätte erledigen können. Wer GPU-Kosten senken will, kommt daran nicht vorbei. Die Stunde ist nur die Verpackung, der Request der Inhalt.

Die Form der Arbeitslast bestimmt das Preismodell

Ist die Zahl unangenehm, wollen Teams oft den Anbieter wechseln oder bessere Konditionen. Ich verkaufe selbst GPU-Kapazität und sage deutlich: Der reine Stundensatz ist selten das Problem. Die Preise für KI-Rechenleistung fallen. Der AI Index von Stanford zeigt: Inferenzpreise sind in wenigen Jahren um Größenordnungen gesunken. Das hilft aber wenig, wenn ein Großteil der Kapazität ungenutzt bleibt. Die Verschwendung frisst den Rabatt auf.

Besser ist es, das Einkaufsmodell an die Arbeitslast anzupassen. KI-Workloads fallen in zwei Kategorien, die gegensätzliche Verträge brauchen. Dauernutzung wie Training, Feintuning oder Batch-Verarbeitung hält die Hardware rund um die Uhr beschäftigt. Dafür eignen sich reservierte Kapazitäten: Die Maschinen bleiben heiß, niedrigere Stückkosten belohnen die Bindung. Stoßlast – fast alles mit einem Menschen am anderen Ende – funktioniert anders. Nutzungsbasierte Preise rechtfertigen ihren Aufschlag, weil man nur zahlt, was tatsächlich anfällt. Der Preis pro Einheit steigt, die Gesamtrechnung sinkt.

Die besten Produktions-Setups, die ich sehe, kombinieren beide Modelle. Ein Team hält eine bescheidene Basislinie vor, dimensioniert auf das Niveau, das die Nachfrage fast nie unterschreitet. Den Rest deckt On-Demand-Kapazität ab. Teams mit weniger als etwa zehn Millionen Tokens pro Monat verzichten oft ganz auf eigene Infrastruktur und nutzen eine Modell-API, bis das Volumen einen Wechsel rechtfertigt. So bleibt die reservierte Fläche ausgelastet, Spitzen sind abgedeckt. Die Architektur ist dann Ausdruck einer bewussten Entscheidung – seltener, als man denkt.

Drei Fragen sparen mehr als jeder Vertragsrabatt

Bittet mich ein Team um die Prüfung einer GPU-Verpflichtung, stelle ich immer dieselben drei Fragen. Am liebsten vor der Unterschrift, nicht danach. Erste Frage: Wie sieht unsere gemessene Auslastungskurve aus? Die Projektion aus der Präsentation zählt nicht. Miss eine Woche Produktionstraffic, bevor irgendetwas unterschrieben wird. Teams sagen ihre eigene Kurve fast nie korrekt voraus – vor dem Vertrag kostet diese Überraschung nichts, danach umso mehr.

Zweite Frage: Wie hoch sind unsere Kosten pro Request bei der zehnfachen Menge des heutigen Volumens? Skaleneffekte können die Antwort verändern, manchmal zu unseren Gunsten. Stoßartiger Bedarf kann sich glätten, wenn Nutzer über Zeitzonen verteilt sind, und die Rechnung verschiebt sich später Richtung reservierter Kapazität. Kann niemand im Raum diese Zahl nennen, kauft die Organisation ein Standbild, keine Strategie. Dritte Frage: die Wechselkosten. Offene Gewichtsmodelle erlauben es, die Analyse mit jedem Anbieter durchzuspielen und Konsequenzen aus den Zahlen zu ziehen. Proprietäre Endpunkte koppeln die Kosten an die Preiselastizität eines anderen Unternehmens. Beides kann sinnvoll sein, aber Flexibilität hat einen Dollarwert, der neben dem Stundensatz stehen sollte.

Disziplin statt Hoffnung

Privat habe ich im vergangenen Jahr mehr als acht KI-Hackathons als Juror begleitet – bei Microsoft in Chicago und Mountain View sowie bei Events mit OpenAI und der Google Developers Group. Auch dort, wo Teams an einem Wochenende Prototypen bauen, sehe ich das Produktionsproblem der Zukunft: brillante Modelle, aber kaum Gedanken darüber, was das Bereitstellen kosten wird. Niemand gewinnt einen Hackathon mit einer Unit-Economics-Folie. Dafür scheitern Unternehmen regelmäßig ohne eine.

Jahre in der Datenanalyse haben mich zu einer Überzeugung geführt, die ich jedem Team mitgebe: Ein Dashboard ohne Kosten ist eine Verbindlichkeit. Eine KI-Funktion trägt dasselbe Risiko. Unternehmen, die den nächsten Preiszyklus überleben, kennen ihren Preis pro Request aus dem Kopf und erklären ihre Infrastruktur in einem Satz – gestützt auf eine Woche Verkehrsdaten. Nicht die Teams mit dem niedrigsten Stundensatz sichern die Margen, sondern die, die ihre GPU-Auslastung verbessern und die Inferenzkosten senken, bevor die nächste Rechnung kommt.

Die alte Cloud-Lektion kehrt zurück: erst messen, dann kaufen, dann die Kosten pro Nutzen im Betriebsalltag verankern. Ich sehe täglich, wie Teams dieselben Fehler wiederholen – nur mit teurerer Hardware. Es gibt einfache Rechnungen, die vor dem Vertrag schützen. Nur wenige führen sie durch. GPU-Kosten sind kein Schicksal, sondern eine messbare Größe. Wer sie beherrscht, hat die Rechnung im Griff – und das eigene Produkt.

Quelle: cio.com

Claudia d’Antoine, CEO von Margin Research, beschreibt den Zustand der offensiven Cybersicherheit im Jahr 2026 so: „You are entering a world somewhere between 0 and 1.“ Eine Welt mit Halluzinationen und Bugs – aber sie ist unsere Realität. In ihrem Essay skizziert sie ein neues Phänomen: den Half-Day. Damit sind Exploits gemeint, die technisch 0-Days sind, aber unter Bedingungen gefunden und genutzt werden, die ihre Lebensdauer deutlich verkürzen. Der Begriff ist wichtig. Er könnte verändern, wie wir über Schwachstellen, Märkte und Risiken denken.

In der Branche diskutiert man über die Zukunft des Marktes für offensive Cybersicherheit. Manche erwarten, dass KI-Modelle die Forschung überrollen und 0-Days im Minutentakt produzieren. Andere sehen eine Chance für Forscher, schneller und tiefer zu graben als je zuvor. d’Antoine gehört zur zweiten Gruppe, warnt aber vor einer Verschiebung: Die neuen Werkzeuge machen exklusives Wissen schneller öffentlich. Dadurch wird aus einem 0-Day über Nacht ein n-Day. Hier setzt ihr Konzept des Half-Day an.

Was genau ist ein Half-Day-Exploit?

Ein 0-Day-Exploit ist eine Schwachstelle, von der der Hersteller nichts weiß. Es gibt keinen Patch, keinen Schutz, und nur der Besitzer des Exploits kennt das Einfallstor. Dieser Wissensvorsprung macht den Wert aus. d’Antoine argumentiert, dass dieser Vorsprung schmilzt, sobald KI-gestützte Schwachstellenanalyse zur Norm wird. Ein Exploit in einer stark untersuchten Oberfläche wie einem gängigen Betriebssystem oder Browser steht unter Beobachtung durch Modelle, die aus den besten Forschungsarbeiten der Branche lernen. Deshalb ist er zwar immer noch ein 0-Day im technischen Sinne, aber eben schon „halfway to n“ – unterwegs zum öffentlich bekannten n-Day.

Konkret: Ein Forscher entdeckt eine Lücke in einer weit verbreiteten Bibliothek. Er sieht sie als Erster. Doch die Wahrscheinlichkeit, dass ein anderes KI-Modell dieselbe Lücke in den nächsten Wochen oder Tagen findet, ist hoch. Der Exploit ist also kein klassisches 0-Day mehr, das jahrelang im Verborgenen bleiben kann. d’Antoine nennt solche Produkte „Half-Days“ – ein Verfallsdatum, das von Anfang an existiert. Die Halbwertszeit des Wissensvorsprungs hat sich stark verkürzt.

Der Felsen-Markt: Wie Exploits gehandelt werden

Um die Auswirkungen auf den Markt zu verstehen, hilft ein Bild von d’Antoine: der Felsen. Kunden sagen ihrem Lieferanten: „Bring mir einen Felsen.“ Sie wissen nicht, welchen sie brauchen, und sie können ihn vor dem Kauf nicht untersuchen. Der Lieferant sucht, findet und poliert einen schönen Felsen und bietet ihn an. Je länger der Felsen im Regal liegt, desto mehr verliert er an Wert. Entweder findet jemand anderes denselben Felsen, oder das Ziel wird abgesichert.

Nun fügt die KI-Ära neue Risiken hinzu. Was, wenn ein Teil der Kunden glaubt, er könne sich alle Felsen selbst herstellen – mit generativen Modellen? Was, wenn die Methode, mit der ein Felsen gefunden wurde, den Felsen unbrauchbar macht, etwa weil sie einem Gegner gehört? Und selbst wenn der Verkauf gelingt, besteht ein größeres Risiko, dass der Felsen explodiert, in einem Raum voller identischer Felsen landet oder im Steinhaufen eines Konkurrenten auftaucht. Diese Unsicherheit gehört jetzt zum Alltag. Der Felsen-Markt wird volatiler, und alle Beteiligten müssen früher über Risiken sprechen.

KI und die schrumpfende Lebensdauer von 0-Days

Warum schrumpft die Lebensdauer so stark? Die besten Offensive-Forscher arbeiten inzwischen oft für KI-Labore wie Anthropic oder OpenAI. Dort trainieren sie Modelle, die ihre Erfahrung aufnehmen. Diese Modelle lernen von genau den Menschen, die früher isoliert nach Schwachstellen suchten. Bevorzugte Ziele sind die Systeme, die die westliche Welt prägen: gängige Betriebssysteme, Browser, Cloud-Dienste. Was wichtig ist, wird am intensivsten trainiert.

Die Zahl gemeldeter CVEs steigt stark – die öffentliche Schwachstellendatenbank wächst in fast jedem großen System schneller als je zuvor. d’Antoine betont: Nicht jede CVE ist ein operativ nutzbarer Exploit. Aber die Menge zeigt, dass die Population der Half-Days wächst. Die Szenarien, wonach Menschen in der Forschung überflüssig werden, sind übertrieben. Die Rolle des Forschers ändert sich, verschwindet aber nicht. Wer glaubt, KI produziere nur „Magic“ oder „Slop“, übersieht, dass weiterhin menschliches Urteilsvermögen nötig ist.

Was die Halbwertszeit für Anbieter und Kunden bedeutet

Alle Marktteilnehmer müssen umdenken. Ein Half-Day ist nur kurz genauso wertvoll wie ein 0-Day. Die Geschwindigkeit wird entscheidend: Die Zeit zwischen Entdeckung und Einsatz muss minimal sein. Automatisierung ist keine Option, sondern eine Notwendigkeit. Wer im Half-Day-Zeitalter arbeitet, muss damit rechnen, dass Konkurrenten, Gegner und Hersteller den Exploit bald finden und patchen. Das Zeitfenster schließt sich immer schneller.

Anbieter müssen sich umstellen: Handgefertigte Exploits, die über Monate perfektioniert werden, sind selten geworden. Das Bild des einsamen Hackers, der im Keller einen 0-Day entwickelt und ein Vermögen kassiert, ist eine Legende. Gefragt sind Teams, die eng zusammenarbeiten und langfristige Strategien verfolgen. Auch Kunden stehen vor neuen Herausforderungen: Sie müssen Risikoentscheidungen treffen, bevor der Exploit in ihren Händen ist. Der Zeitdruck verändert die Verhandlungsdynamik auf dem Cybermarktplatz.

Die Defensive unter Druck

Die Half-Day-Welle trifft auch die Defensive. Sicherheitsteams haben einen Berg technischer Schulden vor sich, der sich über Jahrzehnte angesammelt hat. Es gibt keine klare Möglichkeit, Patches automatisiert so schnell auszurollen, wie KI-gestützte Suche Schwachstellen findet. Zudem ist unklar, welche CVEs zu gefährlichen Exploits führen. Das macht Priorisieren schwierig. Manche Unternehmen spüren das bereits. Apple hat kürzlich eine Pause seines Bug-Bounty-Programms angekündigt. Viele werten das als Beginn größerer Umwälzungen.

Ein gemeinsamer Rahmen für die Zukunft

Der Half-Day ist mehr als ein Schlagwort. Er hilft zu verstehen, warum sich die Spielregeln der offensiven Cybersicherheit ändern. KI verändert nicht nur Werkzeuge, sondern auch die Ökonomie des Wissens. Wer bisher Exklusivität verkauft hat, muss mit kurzen Halbwertszeiten leben. Die neuen Bedingungen bieten aber auch Chancen: Wer kreativ mit Modellen arbeitet, erreicht in kürzerer Zeit mehr.

Ob sich der Begriff des Half-Day in der Fachsprache etabliert, ist offen. Entscheidend ist die Erkenntnis: 0-Days sind im Zeitalter von KI nicht mehr das, was sie einmal waren. Wer das ignoriert, wird überholt – ob als Anbieter, Kunde oder Verteidiger. Wer die neue Halbwertszeit akzeptiert, richtet sein Vorgehen danach aus. Die Illusion des perfekten, ewig haltbaren Exploits ist vorbei. Wir müssen lernen, mit Ungewissheit zu leben. Das ist die neue Realität der offensiven Cybersicherheit.

Quelle: margin.re

Wie zuverlässig darf ein KI-Agent auf veraltete Daten reagieren? Die kurze Antwort lautet: Je selbstständiger das System arbeitet, desto weniger Spielraum bleibt für veraltete Lesezugriffe.

Viele KI-Architekturen behandeln Daten aus einer globalen Replikation noch immer so, als seien sie aktuell. Sobald autonome Agenten Entscheidungen treffen, wird diese Annahme zum Risiko. Die entscheidende Frage verlagert sich deshalb von der reinen Antwortgeschwindigkeit zur Verlässlichkeit des Kontexts.

Der Ausgangspunkt ist banal: Ein Sprachmodell kann nur auf Informationen reagieren, die es tatsächlich erhält. Bei agentischen Systemen kommt diese Information jedoch nicht mehr aus einem statischen Trainingsdatensatz. Sie wird laufend aus Datenbanken, Suchindizes, Sitzungsverläufen und Geschäftsanwendungen zusammengestellt. Dieser dynamische Kontext ist das operative Gedächtnis des Agenten.

Wenn sich mehrere Regionen, Replikate und Agenten parallel bewegen, kann sich dieses Gedächtnis widersprechen. Eine Instanz sieht den Lagerbestand nach einer erfolgreichen Buchung, eine andere liest noch den alten Wert. Für einen normalen Webshop ist eine kurze Verzögerung oft harmlos. Ein autonomer Agent kann daraus innerhalb von Sekunden eine falsche Entscheidung ableiten und diese möglicherweise selbst zurückschreiben.

Damit wird Konsistenz zu einer Art neuer Latenz. Nicht jede Abfrage muss blitzschnell beantwortet werden. Sie muss aber zuverlässig genug sein, damit die nachfolgende Logik auf einem belastbaren Stand der Welt aufbauen kann.

Warum das Kontextfenster wie eine Datenbankzeile behandelt werden muss

Bei klassischen Anwendungen liegt der Wert einer Datenbank häufig in den dauerhaft gespeicherten Datensätzen. Bei einem Retrieval-Augmented-Generation-System, kurz RAG, verschiebt sich diese Funktion. Die abgerufenen Informationen werden Bestandteil des Kontextfensters, in dem das Modell seine Schlussfolgerungen bildet.

Das klingt zunächst nach einem technischen Detail, verändert aber die gesamte Fehlerbetrachtung. Ein LLM unterscheidet nicht automatisch zwischen einem aktuellen Messwert, einer Version von gestern und einer Behauptung, die bereits durch einen früheren Fehler in das System gelangt ist. Es erhält Text oder strukturierte Werte und verarbeitet sie so, wie sie präsentiert werden.

Eine leicht veraltete Information kann deshalb eine vollständig korrekte Argumentationskette vergiften. Formal mag jeder einzelne Schritt logisch sein. Wenn der Ausgangspunkt falsch ist, kann das Ergebnis dennoch weit von der Realität entfernt sein. Das ist vergleichbar mit einem Navigationssystem, das die aktuelle Straßensperrung noch nicht kennt: Die berechnete Route ist möglicherweise perfekt optimiert und führt trotzdem in die falsche Richtung.

Bei einem Bot fällt ein falscher Hinweis vielleicht einem Menschen auf. Ein Agent kann hingegen selbstständig weitere Systeme aufrufen, eine Nachricht versenden oder einen Geschäftsprozess auslösen. Die Reichweite des Fehlers wächst dadurch mit der Zahl der nachfolgenden Aktionen. Aus einem einzelnen stale read wird schnell eine Kette aus fehlerhaften Entscheidungen.

Architekten sollten deshalb nicht nur die Konsistenz der Datenbank bewerten, sondern auch die Konsistenz des daraus erzeugten Kontexts. Dieser Begriff umfasst mehr als die Frage, ob ein Wert geschrieben wurde. Er betrifft auch Version, Reihenfolge, Herkunft, Aktualität und die Beziehung zwischen mehreren Datensätzen.

Wie Replikationsverzögerungen autonome Agenten in die Irre führen

Asynchrone Replikation ist aus der Welt verteilter Systeme nicht wegzudenken. Ein Schreibvorgang wird auf einem primären System bestätigt, während die Änderung noch in andere Regionen transportiert wird. Das verbessert die globale Leseleistung und reduziert die unmittelbare Belastung des schreibenden Systems.

Für einen Menschen, der einen Beitrag oder einen Status nur ansieht, sind wenige hundert Millisekunden häufig unkritisch. Für einen Agenten kann derselbe Zeitraum ausreichen, um eine Entscheidung auf einem alten Zustand aufzubauen. Die gefährlichste Situation entsteht, wenn das System direkt nach einer eigenen Änderung aus einer langsameren Region liest.

Ein Beispiel macht die Eskalation deutlich. Ein Bestandsagent aktualisiert auf einem primären System in den USA den Wert verfügbarer Artikel auf 500. Wegen Netzwerküberlastung erreicht die Änderung ein Replikat in Mumbai erst zwei Sekunden später. Eine zweite Agenteninstanz liest dort noch den Wert 0 und meldet den Artikel als ausverkauft.

Der Agent hat dabei kein offensichtliches logisches Problem erzeugt. Er hat lediglich die ihm vorliegenden Fakten akzeptiert. Genau darin liegt die Tücke: Systeme mit verteilter Replikation können formal korrekt und praktisch falsch zugleich sein.

Hinzu kommt das Phänomen verlorener Aktualisierungen. Zwei Agenten lesen denselben Datensatz, treffen unabhängige Entscheidungen und überschreiben anschließend gegenseitig ihre Arbeit. Ein Zeitstempel oder eine Versionsnummer kann helfen, doch diese Prüfung muss Teil des Ablaufs sein. Ohne eine solche Bedingung wird aus paralleler Intelligenz schnell konkurrierende Blindheit.

Ein robustes System muss dem Agenten daher nicht nur Daten liefern. Es muss ihm auch ein klares Signal geben, wenn sich die Grundlage seiner Entscheidung verändert hat. Eine fehlgeschlagene bedingte Aktualisierung ist in diesem Fall kein lästiger Fehler, sondern ein nützlicher Wächter.

Halluzinationsschulden entstehen, wenn KI-Fehler gespeichert werden

Die unmittelbarste Gefahr veralteter Daten ist eine falsche Entscheidung im Moment des Lesens. Größer wird das Problem, wenn der Agent das Ergebnis seiner eigenen falschen Schlussfolgerung in die Datenbank schreibt. Ab diesem Zeitpunkt beginnt der Fehler, ein Gedächtnis zu entwickeln.

Ein solcher dauerhaft gespeicherter Irrtum wird häufig als Halluzinationsschuld bezeichnet. Der Begriff beschreibt keine besondere Eigenschaft eines Sprachmodells, sondern einen technischen Kreislauf: Ein Agent erzeugt eine unzutreffende Aussage, speichert sie als scheinbar verlässliche Information, und ein späterer Agent übernimmt sie bei der nächsten Abfrage.

Mit jeder Wiederholung kann sich der Fehler weiter von der ursprünglichen Tatsache entfernen. Neue Agenten formulieren ihn vielleicht sachlicher, präziser oder plausibler. Dadurch wirkt er nicht unbedingt weniger überzeugend, möglicherweise aber noch verbindlicher. Ein nachträglich gespeicherter Wert besitzt zudem eine Art institutionelles Gewicht: Systeme behandeln ihn tendenziell als autoritativen Zustand, obwohl seine Herkunft fehlerhaft war.

Das verstärkt eine grundlegende Schwäche aktueller agentischer Systeme. Sprachmodelle verfügen über kein verlässliches inneres Zeitgefühl. Sie wissen nicht automatisch, ob ein Datensatz gerade geschrieben wurde oder vor einem Jahr. Sie erkennen nicht ohne zusätzliche Metadaten, ob eine Information aus einer autoritativen Quelle stammt oder von einem anderen Agenten.

Die Verantwortung liegt deshalb bei der Architektur. Kontext sollte mit Zeitstempeln, Versionen, Provenienz und gegebenenfalls einer nachvollziehbaren Historie versehen werden. Ebenso wichtig ist eine Trennung zwischen vorläufigen Ergebnissen und verbindlichen Fakten. Wenn ein Agent eine Schlussfolgerung speichert, muss klar sein, ob sie bereits geprüft wurde oder nur eine Hypothese darstellt.

Ein gutes Datenmodell beantwortet somit nicht nur die Frage nach dem Inhalt. Es beantwortet auch: Wann wurde dieser Inhalt beobachtet? Von welchem System stammt er? Wurde er bestätigt? Auf welche Version bezieht er sich? Diese zusätzlichen Ebenen wirken unspektakulär, verhindern aber, dass sich ein temporärer Denkfehler in langlebiges Wissen verwandelt.

Starke Konsistenz für Bereiche, in denen Fehler teuer werden

Nicht jede Information benötigt dieselbe Form der Aktualität. Berechtigungen, Sicherheitsrichtlinien, Finanztransaktionen und unveränderliche Systemanweisungen vertragen keine nennenswerte Verzögerung. Wenn ein Agent in diesen Bereichen auf einem veralteten Stand arbeitet, kann eine langsame und korrekte Reaktion wertvoller sein als eine schnelle Reaktion auf Basis falscher Fakten.

Amazon Aurora Global Database kann hierbei als Grundlage dienen. Die regionsübergreifende Speicherreplikation ist standardmäßig asynchron, lässt sich für bestimmte Anforderungen aber mit Global Write Forwarding und den Konsistenzstufen GLOBAL oder SESSION gezielt beeinflussen.

Bei SESSION wird eine eigene weitergeleitete Schreiboperation so behandelt, dass der Agent für einen anschließenden Lesevorgang auf die Replikation seiner eigenen Änderung warten muss. Das unterstützt das sogenannte Read-Your-Own-Writes-Verhalten. GLOBAL geht weiter: Ein Lesevorgang wartet darauf, dass die Replikation den Zeitpunkt der Leseanfrage erreicht hat. Dadurch sollen widersprüchliche Zustände zwischen Agenten reduziert werden, die in unterschiedlichen Regionen gleichzeitig arbeiten.

Für Anwendungen mit dem höchsten Anspruch an globale, synchrone Konsistenz nennt der zugrunde liegende Artikel Amazon Aurora DSQL. DSQL ist für verteilte transaktionale Workloads konzipiert und soll starke Konsistenz über mehrere Regionen hinweg ermöglichen, ohne die globale Datenhaltung vollständig auf ein einziges Rechenzentrum zu beschränken.

Diese Stärke bringt einen bewussten Trade-off mit sich. Stärkere Garantien bedeuten in der Regel mehr Koordination, mehr Wartezeit oder zusätzliche Anforderungen an die Infrastruktur. Das ist keine Schwäche des Ansatzes, sondern eine ökonomische Entscheidung. Ein Sicherheitsagent darf für eine Bestätigung länger brauchen. Ein Empfehlungssystem für Schlagzeilen muss das nicht.

Der Architekturentwurf sollte deshalb nach dem Schaden fragen, den eine falsche Antwort verursacht. Bei Finanzdaten ist die Rechnung eindeutig: Eine zusätzliche Wartezeit ist häufig günstiger als eine Transaktion auf veralteten Kontodaten. Bei unveränderlichen Systemanweisungen kann ein falscher Kontext sogar die Sicherheitslogik des gesamten Agenten verändern.

Globale Verfügbarkeit mit kontrollierten Schreibkonflikten

Andere Anwendungen stellen die globale Erreichbarkeit in den Vordergrund. Wenn Agenten rund um den Erdball mit sehr niedriger Latenz auf Unterhaltungsverläufe, Sitzungszustände oder personalisierte Erinnerungen zugreifen sollen, kann eine vollständig synchrone Koordination für jeden einzelnen Lesevorgang zu aufwendig sein.

Amazon DynamoDB Global Tables verwendet eine Multi-Region-Architektur mit mehreren schreibenden Regionen. Diese Struktur verbessert die lokale Verfügbarkeit und reduziert die Distanz zwischen Nutzer und Datenzugriff. Sie ersetzt jedoch nicht die Notwendigkeit, konkurrierende Änderungen bewusst zu behandeln.

Eine wichtige Schutzmaßnahme sind bedingte Schreibvorgänge. Der Agent liest einen Datensatz zusammen mit einer Versionsnummer oder einem Zeitstempel und formuliert seine Aktualisierung nur unter der Bedingung, dass sich dieser Stand nicht verändert hat. Hat ein anderer Agent den Wert in der Zwischenzeit überschrieben, schlägt die Bedingung fehl.

DynamoDB signalisiert dies mit ConditionalCheckFailedException. Der korrekte Umgang besteht nicht darin, den Fehler zu unterdrücken und es erneut zu versuchen. Der Agent muss den aktuellen Zustand erneut lesen und seine Entscheidung neu bewerten. Damit wird aus einem Konflikt ein sinnvoller Kontrollpunkt im Ablauf.

Dieses Muster eignet sich besonders für Daten, die sich häufig ändern und bei denen eine kurze regionale Verzögerung akzeptiert ist, ein unkoordiniertes Überschreiben aber nicht. Dazu gehören Sitzungsdaten, Konversationsverläufe und persönliche Agentengedächtnisse. Bei ihnen ist die perfekte Gleichzeitigkeit möglicherweise weniger wichtig als die Fähigkeit, Konflikte sauber aufzulösen.

Die zentrale Lehre lautet: Fehler müssen erwartet und semantisch behandelt werden. Ein System, das jede Änderung zentral serialisiert, erhält starke Garantien, kann aber an Skalierungsgrenzen stoßen. Ein System, das Änderungen parallel zulässt, benötigt dagegen Regeln für Versionierung, bedingte Updates und erneutes Lesen.

Quorum-basierte Konsistenz für schnelle Telemetrie

Telemetrie, Sensordaten und Protokolldaten stellen andere Anforderungen. Hier steht der hohe Durchsatz im Vordergrund, weil laufend neue Messwerte eintreffen. Eine Architektur, die jeden Schreibvorgang global koordiniert, könnte den Datenstrom ausbremsen und damit gerade die Ereignisse verpassen, die der Agent erkennen soll.

Ein leaderloses System wie Amazon Keyspaces for Apache Cassandra ist auf diese Art von Workload ausgerichtet. Daten werden über mehrere Availability Zones repliziert, während Schreibvorgänge mit LOCAL_QUORUM dauerhaft bestätigt werden. Für besonders wichtige Abfragen kann auch der Lesevorgang LOCAL_QUORUM verwenden, statt die schnelleren, möglicherweise eventually consistent Ergebnisse von LOCAL_ONE zu nutzen.

Der entscheidende Punkt ist die Überschneidung der Quoren. Wenn Schreib- und Lesequorum ausreichend viele Knoten umfassen, kann der Lesevorgang mit hoher Sicherheit den aktuellen Stand berücksichtigen. Die Schreibpipeline bleibt dabei auf Geschwindigkeit ausgelegt. Konsistenz wird nicht bei jedem Datensatz erzwungen, sondern gezielt für die Abfragen aktiviert, bei denen ein kritischer Spike sonst übersehen werden könnte.

Das zeigt, dass Konsistenz keine allgemeine Eigenschaft ist, die ein Datenbanksystem entweder besitzt oder nicht. Sie ist eine Auswahl pro Zugriff. Ein Agent kann für unkritische Trendberechnungen schnelle, schwächere Lesvorgänge verwenden und für die Alarmierung auf eine stärkere Stufe wechseln.

Bei der Echtzeitanomalieerkennung ist eine solche Differenzierung besonders wichtig. Die pure Geschwindigkeit der Datenaufnahme sagt noch nichts über die Verlässlichkeit einer Warnung aus. Wenn ein Agent einen plötzlichen Anstieg der CPU-Auslastung erkennen soll, darf er nicht ausgerechnet die Region lesen, die den letzten Messwert noch nicht erhalten hat.

Ein Quorum ist dabei kein Allheilmittel. Es erhöht die Wahrscheinlichkeit, dass ein aktueller Wert sichtbar ist, und bringt zusätzliche Koordination mit sich. Doch für kritische Lesezugriffe ist dieser gezielte Aufwand oft sinnvoller, als die gesamte Datenverarbeitung dauerhaft auf niedriger Konsistenz zu betreiben.

Welches Replikationsmodell passt zu welchem KI-Agenten?

Die passende Lösung ergibt sich aus der Konsequenz eines Fehlers. Ein Chatbot, der einen veralteten Produktpreis anzeigt, verursacht einen anderen Schaden als ein Agent, der Zahlungen auslöst, Berechtigungen ändert oder einen Produktionsprozess steuert. Deshalb sollte die Konsistenzanforderung nicht pauschal, sondern entlang des tatsächlichen Handlungsrisikos festgelegt werden.

Für Berechtigungen, Finanzbücher und unveränderliche Anweisungen sind starke Garantien angemessen. Für globale Konversationen und personalisierte Zustände kann eine Kombination aus Multi-Region-Verfügbarkeit, Versionsnummern und bedingten Aktualisierungen die bessere Wahl sein. Für hochfrequente Telemetrie ist ein hoher Durchsatz wichtig, während kritische Lesevorgänge mit einem Quorum abgesichert werden können.

Diese Einteilung lässt sich in einer einfachen Tabelle zusammenfassen:

Starke globale Konsistenz eignet sich für Finanztransaktionen, Identitätsdaten und Systemanweisungen. Ihr Vorteil liegt in der zuverlässigen Übereinstimmung, ihr Nachteil in zusätzlicher Wartezeit und Koordination.

Bedingte Multi-Region-Schreibvorgänge eignen sich für Sitzungszustände, Konversationen und geteilte Agentengedächtnisse. Sie bieten globale Erreichbarkeit, verlangen aber eine konsequente Konfliktbehandlung. Jeder Agent muss den Fehlschlag einer Bedingung als Signal für einen neuen Lesevorgang verstehen.

Quorum-basierte Konsistenz eignet sich für IoT-Daten, Protokolle und Sensorströme. Sie verbindet hohe Schreibgeschwindigkeit mit einer stärkeren Garantie für ausgewählte Abfragen. Diese gezielte Verstärkung ist oft der sinnvollste Kompromiss.

Es gibt noch einen vierten Bereich, der in der Planung berücksichtigt werden sollte: vorläufige und unstrukturierte Erkenntnisse. Ein Agent kann Ereignisse sammeln, Hypothesen bilden und Zwischenergebnisse speichern. Solche Daten sollten nicht dieselbe Autorität erhalten wie ein bestätigter Geschäftsdatensatz. Herkunft, Status und Aktualität müssen deshalb Teil des Datenschemas sein.

Die technische Auswahl ist damit nur ein Teil der Lösung. Ebenso wichtig ist die Gestaltung des Agentenablaufs. Ein System, das nach jedem Schreibvorgang dieselbe globale Garantie verlangt, kann unnötig langsam werden. Ein System, das niemals prüft, ob sich Daten verändert haben, kann dagegen schnell und überzeugend falsch handeln.

Kontextintegrität als Aufgabe der KI-Architektur

Die zugrunde liegende AWS-Betrachtung beschreibt eine Verschiebung der Verantwortung. Datenbankreplikation ist keine Hintergrundfunktion mehr, die man einmal einrichtet und anschließend vergisst. Sie gehört zur Qualität des Denkens, das ein Agent an den Tag legt.

Diese Perspektive ist hilfreich, weil sie die Diskussion über agentische KI von der reinen Modellleistung wegführt. Ein beeindruckendes Sprachmodell kann einen schwachen Kontext nicht reparieren. Es kann ihn nur plausibel verarbeiten. Je mehr Handlungsmacht das System besitzt, desto stärker wirkt sich jeder Mangel an Aktualität, Herkunft und Versionskontrolle aus.

Kontextintegrität sollte deshalb als durchgängige Eigenschaft verstanden werden. Sie beginnt bei der Auswahl des Replikationsmodells, reicht über die Versionierung einzelner Datensätze und endet bei der Frage, welche Schlussfolgerungen ein Agent dauerhaft speichern darf. Jede Schicht kann dazu beitragen, dass ein Fehler nicht unentdeckt zur nächsten Wahrheit wird.

Ein praktischer Ansatz besteht darin, für jeden Datentyp drei Fragen zu beantworten. Wie schnell darf die Information veralten? Welche Folgen hat ein veralteter Lesevorgang? Wie kann der Agent erkennen, dass seine ursprüngliche Grundlage nicht mehr gültig ist?

Aus den Antworten lässt sich ein passendes Konsistenzprofil ableiten. Bei sicherheitskritischen Daten sind synchrone oder quorum-basierte Garantien erforderlich. Bei veränderlichen Zuständen können Versionen und bedingte Schreibvorgänge ausreichen. Bei großen Datenströmen sollte die Konsistenz dort verstärkt werden, wo die Entscheidung besonders empfindlich auf fehlende oder verspätete Ereignisse reagiert.

Auch das Testen muss diese Realität abbilden. Verteilte Systeme zeigen ihre Schwächen nicht nur bei perfekter Erreichbarkeit, sondern vor allem bei Netzwerkverzögerungen, Teilfehlern, parallelen Updates und widersprüchlichen Replikationsständen. Agentische Anwendungen sollten deshalb unter kontrollierten Replikationsverzögerungen getestet werden. Entscheidend ist nicht, ob der Agent unter Idealbedingungen antwortet, sondern ob er bei veralteten Daten angemessen reagiert.

Die zentrale praktische Konsequenz lautet: Konsistenz ist keine lästige Einschränkung der Leistung, sondern eine Form von Zuverlässigkeit. Die zusätzliche Zeit, die ein Agent für eine stärkere Garantie benötigt, kann deutlich günstiger sein als die Kosten einer falschen Aktion. Das gilt umso mehr, wenn ein System nicht nur Antworten formuliert, sondern selbstständig Werkzeuge verwendet und Zustände verändert.

Wer heute eine KI-Architektur entwirft, sollte daher nicht nur fragen, wie schnell ein Modell antwortet. Ebenso wichtig ist, wie verlässlich der Kontext ist, aus dem diese Antwort entsteht. Die Datenebene ist damit kein unsichtbarer Unterbau mehr. Sie ist Teil des Denk- und Entscheidungsprozesses.

Quelle: aws.amazon.com

0,51 bis 0,90 – so hoch ist der Anteil der Antworten, die ein Angreifer nach einer Abliteration eines Open-Weight-Modells erhält, aber nicht verwerten kann. Die Zahl stammt aus einer neuen Studie von Microsoft Azure zur defensiven KI-Sicherheit. Sicherheit bei offenen Gewichten muss den Angriff nicht verhindern. Manchmal ist es besser, ihn gelingen zu lassen und zugleich wertlos zu machen.

Wenn du die Gewichte eines Sprachmodells veröffentlichst, gibst du die Kontrolle über sein Verhalten ab. Das ist der Preis von Open Weight: Jeder kann die Datei herunterladen, verändern und neu einsetzen. Genau hier setzt die Abliteration an. Dabei wird eine Aktivierungsrichtung, die für die Verweigerung gefährlicher Anfragen zuständig ist, aus den Gewichten herausgerechnet. Das dauert Minuten, braucht keine Gradienten und läuft auf Consumer-Hardware. Der ursprüngliche Sicherheitsmechanismus ist danach schlicht weg.

Das Problem: Abliteration entfernt Sicherheitsalignment in Minuten

Die Bilanz der Verteidiger ist ernüchternd. Klassische Ansätze versuchen, den Verweigerungsmechanismus zu schützen, etwa durch Verteilung über mehrere Module oder durch adversarielles Training gegen simulierte Ablationen. Doch diese Verteidigungen wurden immer wieder gebrochen. Ihre Garantie endet in dem Moment, in dem die Verweigerung tatsächlich entfernt ist. Das Problem ist ökonomisch: Der Verteidiger muss jeden möglichen Angriff vorhersehen, der Angreifer braucht nur einen einzigen Erfolg. Und der ist inzwischen nahezu kostenlos.

Die Idee: Den Angriff ins Leere laufen lassen

Fool’s Gold geht davon aus, dass die Abliteration nicht zu verhindern ist. Das abliterierte Modell wird zur Falle: Antwortet es nach dem Angriff auf gefährliche Anfragen, sind die Antworten selbstsicher, flüssig und im Tonfall völlig korrekt – aber die entscheidenden operativen Details sind erfunden. Der Angreifer bekommt also genau das, was er haben will: ein Modell, das nicht mehr verweigert. Nur ist das, was es liefert, nicht brauchbar. Temperaturen stimmen nicht, Mengen sind falsch, Abläufe würden nicht funktionieren. Wer darauf vertraut, handelt auf Basis von plausibel wirkender Falschinformation.

Das eigentliche Sicherheitsversprechen ist nicht mehr die Verweigerung, sondern die Zerstörung des Vertrauens in das freigeschaltete Modell. Der Angreifer kann mit einem einzigen Checkpoint nichts anfangen, wenn ein großer Teil der Antworten falsch ist und sich echte von falschen nicht unterscheiden lassen. Die Extraktion von verwertbarem Wissen wird damit zu einem teuren Forschungsprogramm. Aus einem Minuten-Angriff wird eine Aufgabe, die externe Verifikation erfordert – genau das, was die Abliteration eigentlich unnötig machen sollte.

So arbeitet Fool’s Gold: Decoys im Training verankern

Das Decoy-Verhalten tritt im Normalzustand des Modells nicht auf. Das freigegebene Modell verhält sich sauber: Es verweigert auf gefährliche Prompts, besteht Benchmarks und wirkt völlig unverändert. Erst nach der Abliteration, also im attackierten Zustand, erscheinen die falschen Antworten. Damit das gelingt, trainiert das Team die Decoys in einer differenzierbaren Simulation des Angriffs. Was nach der Abliteration entsteht, ist keine Nebenwirkung, sondern eingeübte Verhaltensweise, die nur unter Angriffsbedingungen aktiviert wird.

Die Methode folgt einem klaren Ablauf: Zuerst wird das Originalmodell selbst abliteriert, um die gefährlichen Inhalte zu extrahieren, die ein Angreifer später sehen würde. Diese Inhalte werden dann Element für Element umgeschrieben – gleiche Struktur, gleicher Ton, gleiche Sicherheit, aber falsche Werte. Diese Decoys werden per Fine-Tuning im attackierten Zustand verankert. Ein Refusal-Pin und eine schwache KL-Bindung sorgen dafür, dass das saubere Modell sein ursprüngliches Verhalten behält. Anschließend wird die Fluchtrate geschlossen: In einem weiteren Schritt werden noch jene Antworten umgeschrieben, die trotz des Trainings wahrheitsgemäß bleiben. Das geschieht mit Reinforcement Learning direkt im attackierten Zustand, weil eine reine Textebene dieses Ziel nicht erreicht.

Was die Messwerte zeigen: 0,51 bis 0,90 Decoy-Anteil

Getestet wurde auf sieben Modellen aus fünf Modellfamilien, von 9 bis 122 Milliarden Parametern, darunter dichte und Mixture-of-Experts-Architekturen. Sechs Modelle bestanden das vorab festgelegte Wirksamkeits-Kriterium. Beim Angriff mit dem dokumentierten Standardrezept lag der Anteil der Decoy-Antworten auf nie trainierten gefährlichen Prompts zwischen 0,51 und 0,90. Der Vergleich zum undefended Modell zeigt, dass der Verteidigungsbeitrag zwischen plus 0,27 und plus 0,84 liegt. Die Messwerte blieben auf einem eingefrorenen Testsplit stabil; bei fünf Modellen lagen alle Abweichungen innerhalb von plus/minus 0,05. Das kleinste Modell, Qwen3.5-9B, verfehlte das Kriterium und wird als Grenzfall ausgewiesen.

Ein naheliegender Einwand: Kann der Angreifer nicht einfach viele Antworten sammeln und die Wahrheit per Mehrheitsentscheid wiederherstellen? Die Messwerte zeigen, dass dies nicht zuverlässig funktioniert. Selbst wer 64 Stichproben pro Frage zieht und eine elementweise Mehrheitsabstimmung durchführt, erhält im Hauptmodell weiterhin überwiegend erfundene Abläufe. Der Angreifer hat schließlich keine unabhängige Quelle für die korrekten Werte. Die Präzision der Abstimmung ist im attackierten Zustand nicht beobachtbar. Dieselbe Methode, die in einem Modell richtige Komposite liefert, kann in einem anderen Modell fast vollständig falsche Komposite ergeben.

Qualität und Grenzen: Warum der Angreifer es nicht merkt

Der Angreifer könnte versuchen, die Antworten nach ihrer Qualität zu sortieren, um Decoys zu erkennen. Auch das führt nicht zum Ziel. Auf den Benchmarks StrongREJECT und HarmBench lagen die qualitätsbasierten Bewertungen der Decoys innerhalb von 0,18 Punkten auf 12 von 14 Modell-Paarungen der echten Antworten. Es gibt also keinen sichtbaren Unterschied im Register, in der Spezifität oder im Selbstbewusstsein. Die Decoys sehen exakt wie echte Antworten aus, nur eben falsch. Auf dem CBRNE-nahen Slice der externen Red-Team-Benchmarks war das verteidigte 122B-Modell bei abgeglichener Qualität in 0,82 bis 0,86 der Fälle inhaltlich fatal falsch, während das undefended Modell höchstens 0,10 erreichte.

Die Verteidigung hat klare Grenzen. Fool’s Gold wirkt nicht gegen In-Context-Jailbreaks, bei denen das Modell seine Sicherheitsregeln nicht durch Gewichtsänderung verliert, sondern durch geschickte Prompt-Umgehung. Außerdem entfaltet die Methode nur beim Erstrelease eines Modells ihre Wirkung. Sobald ein Angreifer die Decoy-Struktur des attackierten Modells analysiert, könnte es in späteren Versionen nötig sein, die Strategie anzupassen. Das Sicherheitsversprechen ist ausdrücklich epistemisch: Ein Angreifer ohne externes Wissen über die korrekten Werte kann keine zuverlässige Trennung zwischen richtigen und falschen Antworten vornehmen.

Was das für die KI-Sicherheit bedeutet

Die Arbeit zeigt, dass Open-Weight-Sicherheit nicht nur eine Frage der Verweigerung sein muss. Wenn die Abliteration nicht dauerhaft verhindert werden kann, dann ist es eine legitime Strategie, den Nutzen des Angriffs selbst zu untergraben. Fool’s Gold ist keine Wunderwaffe, sondern ein weiteres Werkzeug in einem Arsenal, das bisher wenig zu bieten hatte. Die Kennzahl von bis zu 0,90 Decoy-Anteil ist beeindruckend, doch man sollte sie im Kontext lesen: Es geht nicht darum, einen Angriff abzuwehren, sondern darum, seinen Wert zu zerstören.

Für die Praxis bedeutet das: Open-Weight-Modelle können auch dann noch eine gewisse Sicherheitsreserve enthalten, wenn ihr Refusal-Mechanismus trivial entfernbar bleibt. Die Verteidigung verschiebt die Kosten – vom Verteidiger zum Angreifer. Sie nimmt dem Angreifer den billigen Sieg. Ein Modell, das nach der Abliteration nur noch souverän klingenden Unsinn ausgibt, ist keine Waffe mehr. Das ist keine vollständige Lösung, aber es ist ehrlicher Fortschritt. Und da abliterierte Varianten beliebter Modelle heute oft schon Tage nach dem Release auftauchen, ist jede Strategie willkommen, die den Angreifer ausbremst.

Quelle: markrussinovich.github.io

Auf einem Schreibtisch steht ein Geraet, das aussieht wie ein Buero-PC. Eine Entwicklerin startet ein lokales Modell mit mehreren hundert Milliarden Parametern, tippt eine Frage ein und erhaelt eine Antwort, ohne dass ein Datenbus zum Rechenzentrum geoeffnet wird. Vor einigen Jahren waere das nur eine Demonstration auf einer hauseigenen Konferenz gewesen. Heute beschreibt ein Forscherteam um Shuo Yang von der University of California Berkeley mit dem System FreeToken genau diesen Sprung: grosse Sprachmodelle gehoeren nicht zwingend in Serverhallen, sondern koennen auf einer persoenlichen Maschine laufen.

Was MoE-Modelle so besonders macht

Wer sich mit modernen offenen KI-Modellen beschaeftigt, stoesst haeufig auf den Begriff Mixture of Experts, kurz MoE. Die Grundidee ist einfach: Statt ein riesiges, dichtes Netz zu aktivieren, besteht das Modell aus vielen spezialisierten Teilnetzen, den Experten. Bei jeder Eingabe entscheidet ein Router, welche Experten gerade gebraucht werden, und nur diese werden berechnet. Ein Modell mit 200 Milliarden Parametern aktiviert pro Token vielleicht nur ein Dutzend Milliarden. Das spart Rechenzeit, kostet aber Speicher, denn alle Experten muessen im RAM liegen, auch wenn sie gerade schweigen.

Genau diese Logik durchkreuzt die uebliche Verteilung. Im Rechenzentrum stehen viele GPUs mit schnellem Interconnect und fast grenzenlosem Speicher. Auf einem Arbeitsplatzrechner sieht das anders aus. Eine Mittelklasse-GPU hat 8, 16 oder 24 Gigabyte VRAM. Der Rest der Maschine, CPU, DDR5-Riegel, NVMe-SSD, ist langsamer, aber reichlich vorhanden. Wer MoE auf solcher Hardware ausliefern will, muss mit jedem Layer mitverhandeln, ob ein Experte in den schnellen Speicher passt, auf die SSD ausgelagert wird oder von der CPU berechnet wird.

FreeToken denkt die gesamte Pipeline mit

Die Autorinnen und Autoren beschreiben FreeToken nicht als einzelne Optimierung, sondern als Co-Design der gesamten Serving-Strecke. Das System entscheidet laufend, wo welcher Teil eines Modells liegt und wie er ausgefuehrt wird. Die Bandbreite der behandelten Themen ist gross: das Aufteilen und Laden des Modells, das Verweilen von Experten im Speicher, die Aufteilung zwischen CPU und GPU, die Wiederverwendung von Agentenzustaenden und das Speichermanagement zur Laufzeit.

Zwei Realitaeten lokaler KI-Arbeit treiben dieses Design. Erstens aendern Agent-Workloads, also Programme, die ein Modell schrittweise mit Werkzeugen und Code nutzen, ihr Ausfuehrungsmuster staendig. Mal wird ein Werkzeug aufgerufen, mal eine lange Codepassage geschrieben, mal ein Zwischenergebnis zusammengefasst. Jede Phase stellt andere Anforderungen an Latenz, Speicher und Berechnung. Ein starrer Plan, der den Speicher einmal zu Beginn verteilt, wird diesem Hin und Her nicht gerecht.

Wenn die Hardware nicht gleich aussieht

Zweitens ist Edge-Hardware heterogen. Eine 8-Gigabyte-Laptop-GPU ist ein anderes Biest als eine einzelne Workstation-GPU, und ein Gamer-Desktop mit reichlich RAM und schneller CPU verhaelt sich wieder anders. FreeToken geht daher nicht von einer festen Auslagerungsstrategie aus, sondern bildet Rechenlast und Modellzustand kontinuierlich auf das ab, was die Maschine tatsaechlich bietet. Inferenz wird nicht entworfen, sondern zur Laufzeit verhandelt.

In der Praxis ergibt sich eine Mischung aus Vorab-Layout und Reaktion. Das System kennt den verfuegbaren Speicher, weiss, welche Schichten und Experten gerade heiss sind, misst die aktuelle Bandbreite zwischen CPU und GPU und verschiebt daraufhin Datenstuecke. Die Autorinnen und Autoren sprechen von bandbreitenadaptiver Ausfuehrung, weil sich das System an den realen Durchsatz der jeweiligen Maschine anpasst, statt eine theoretische Zahl vorauszusetzen.

Die Architektur unter der Haube

Wer sich fuer die Mechanik interessiert, findet im Paper eine detaillierte Schicht. FreeToken zerlegt jedes MoE-Modell in planbare Einheiten. Experten lassen sich einzeln in den VRAM schieben und wieder heraus, ohne das gesamte Modell zu beruehren. Eine Komponente ueberwacht den belegten Speicher und trifft Entscheidungen, welche Experten resident bleiben und welche auf die CPU oder die SSD ausweichen. Eine zweite Komponente entscheidet, ob ein gerade aktiver Experte auf der GPU laeuft oder auf der CPU berechnet wird, falls der Datenweg es hergibt. Tokens werden portionenweise verarbeitet, was sich gut mit dem blockweisen Schluessel-Wert-Cache moderner Modelle vertraegt.

Ein zweiter Schwerpunkt ist das Caching von Agentenzustaenden. Agenten, die iterativ arbeiten, erzeugen lange Kontexte mit vielen Wiedereinstiegspunkten, und FreeToken nutzt diese Wiederholung, um teure Neuberechnungen zu vermeiden. Wer schon einmal gesehen hat, wie ein Coding-Agent dieselbe Datei mehrfach einliest, weiss, wie viel Redundanz in solchen Loops steckt. Ein Serving-System, das diese Struktur versteht, kann Tempo gutmachen, ohne dass sich das Modell selbst aendert.

Was die Zahlen erzählen

Die demonstrierten Faelle sind breit gefächert. Auf einer Laptop-GPU mit nur 8 Gigabyte VRAM laeuft ein 35B-Modell, ein Wert, der lange als unmoeglich galt, wenn das Modell vollstaendig lokal und nicht in der Cloud liegen soll. Auf einem Gamer-Desktop bringt FreeToken ein 284B-Modell in Stellung, und auf einer einzelnen Workstation-GPU wird das riesige GLM-5.2 mit 753B Parametern ausgeliefert. Mehr als 20 verschiedene MoE-Modelle werden unterstuetzt, von Open-Source-Klassikern bis zu neueren Mixture-of-Experts-Architekturen. Hinter diesen Zahlen steckt kein Trick mit aggressivem Quantisieren auf Int2-Niveau, sondern das beschriebene Co-Design aus Layout, Routing und Ausfuehrung.

Dabei stellt sich die Frage der Praktikabilitaet. Es reicht nicht, dass ein Modell einmal startet. Es muss so antworten, dass Agenten produktiv damit arbeiten koennen. Die Autorinnen und Autoren testen reale Coding- und Tool-Use-Agenten, nicht nur akademische Benchmarks. Latenz, Time-to-First-Token und Durchsatz werden auf heterogener Hardware gemessen, und das System passt sich an, ohne dass der Nutzer ein Skript schreiben muss.

Was das für den Alltag bedeutet

Die uebergeordnete Botschaft des Papers laesst sich in einem Satz zusammenfassen: Open Weights werden zu lokaler Software. Wer ein Modell auf Hugging Face herunterlaedt, besitzt es nicht wirklich, solange die Auslieferung ein Cloud-Konto voraussetzt. FreeToken verschiebt diese Grenze. Eine Entwicklerin auf einem Business-Laptop kann mit einem lokalen 35B-Modell experimentieren, ohne sich um GPU-Mietkosten zu kuemmern. Ein Hobbyist auf einem Gamer-PC schiebt ein 284B-Modell auf die Maschine und schaut, was passiert. Ein kleines Team, das mit Agenten arbeitet, laesst seine Daten auf der eigenen Hardware, was in vielen Branchen ohnehin Voraussetzung ist.

Das hat Folgen, die ueber reine Performance hinausgehen. Wenn Modelle nicht mehr unbedingt in der Cloud laufen muessen, aendern sich die Spielregeln fuer Datenschutz, Kosten und Verfuegbarkeit. Ein Modell, das offline laeuft, braucht kein Netz, verlaesst nie den eigenen Rechner und kostet im Betrieb nur Strom. Fuer Entwicklerinnen und Entwickler heisst das, sie koennen Modell und Code zusammen versionieren, was bei agentischer Software ohnehin sinnvoll ist.

Einordnung: warum das mehr als ein weiteres Serving-System ist

In der freien Modell-Landschaft gab es in den letzten Jahren viele Ideen, grosse Modelle auf kleine Hardware zu quetschen. FreeToken gibt die Annahme auf, dass Auslagerung ein Notbehelf ist. Stattdessen wird sie zum Normalfall. Das System geht davon aus, dass sich Workloads, Speicher und Bandbreite staendig aendern, und es behandelt diese Veraenderung als gegebenen Parameter statt als Stoerung.

Was bleibt, ist eine offene Frage. Wenn persoenliche Maschinen zu Inferenz-Plattformen werden, verschiebt sich auch das Verhaeltnis zwischen Anbietern und Nutzern. Anbieter grosssprachiger APIs verlieren ein Stueck Exklusivitaet, weil dieselbe Intelligenz lokal laufen kann. Gleichzeitig wachsen die Anforderungen an das eigene Geraet, an Thermik, an Strom und an die Geduld, wenn ein 753B-Modell zum ersten Mal geladen wird. Der Sprung, den FreeToken beschreibt, ist real, aber er ist kein Selbstlaeufer. Er macht aus einer Bueromaschine kein Rechenzentrum. Er macht aus ihr das, was sie sein kann, wenn Software sich anpasst.

Quelle: arxiv.org