Kategorie: Erklärer

Stell dir vor, du sitzt vor einem Safe, der als unknackbar gilt. Du hast alle Werkzeuge – aber niemand hat sie je in dieser Kombination ausprobiert. Genau das ist passiert, als Anthropic zwei neue kryptanalytische Ergebnisse veröffentlichte. Der Blogbeitrag stammt von einem bekannten Kryptografie-Experten. Er zeigt, wie KI-Modelle wie Claude Mythos – ein noch nicht veröffentlichtes Modell – bestehende Werkzeuge geschickt kombinieren. Es geht nicht um übernatürliche Intelligenz, sondern um gründlichere Anwendung des Bekannten. Das macht die Ergebnisse spannend und unheimlich zugleich.

Die zwei Resultate könnten unterschiedlicher nicht sein. Eines betrifft ein vorgeschlagenes Signaturschema namens HAWK, basierend auf dem Module Lattice Isomorphism Problem (module-LIP). Das andere ist ein Angriff auf eine abgeschwächte Version des AES-Verschlüsselungsstandards. Beide stammen von Claude Mythos, einem internen KI-Modell von Anthropic. Der Autor des Artikels betont: Qualität und Relevanz der Ergebnisse sind sehr unterschiedlich. Das muss man verstehen, bevor man in Panik verfällt.

Der Angriff auf HAWK: Ein echter Warnschuss

HAWK ist kein Standard, sondern ein Vorschlag. Es gehört zur Familie der Post-Quanten-Signaturen – Algorithmen, die gegen Quantencomputer-Angriffe sicher sein sollen. Claude Mythos fand einen Key-Recovery-Angriff. Ein Angreifer kann den geheimen Schlüssel aus öffentlichen Informationen ableiten. Der Angriff ist exponentiell in der Laufzeit, aber er halbiert die Sicherheit in Bits. Das klingt dramatisch – und ist es auch, zumindest für HAWK.

Der Clou: Der Angriff braucht keine neuen mathematischen Entdeckungen. Der Autor schreibt: „Was diesen Angriff wirklich interessant macht – und ehrlich gesagt ein bisschen peinlich für die Fachwelt – ist, dass keine der Zutaten exotisch ist.“ Alle Werkzeuge lagen bereit. Niemand hatte sie in dieser Kombination und mit dieser Gründlichkeit eingesetzt. Genau das können KI-Modelle besonders gut: Sie arbeiten sich durch alle Kombinationen, ohne müde zu werden, und entdecken Muster, die Menschen übersehen.

Der Angriff wurde an einer abgeschwächten Challenge-Instanz von HAWK demonstriert. Die Autoren der ursprünglichen Arbeit hatten diese Instanz für Testzwecke bereitgestellt. In einigen Stunden war die Key-Recovery abgeschlossen. Für die echten Parameter würde der Angriff ebenfalls funktionieren, aber deutlich langsamer – nicht praktikabel, aber nah genug, um das Sicherheitsniveau massiv zu senken. Die Folge: HAWK wird vermutlich nicht standardisiert, da es seinen Hauptvorteil – die Effizienz – verlieren würde, wenn man die Schlüsselgrößen verdoppelt. Das ist ein echter Erfolg für die KI-gestützte Kryptoanalyse.

Der Angriff auf AES: Weniger spektakulär, aber nicht bedeutungslos

Der zweite Angriff betrifft reduziertes AES. AES ist ein Blockverschlüsselungsstandard, der seit 2001 überall eingesetzt wird. Der vollständige AES läuft über 10, 12 oder 14 Runden – je nach Schlüssellänge. Der neue Angriff von Anthropic attackiert eine abgeschwächte Version mit nur 7 Runden. Nüchtern betrachtet: Angriffe auf 7-Runden-AES gibt es schon lange. Der neue Angriff ist eine moderate Verbesserung eines Ergebnisses aus dem Jahr 2013.

Der Autor beschreibt die Zahlen nüchtern: Der Angriff benötigt 2^89 Verschlüsselungsoperationen. Noch unrealistischer ist die Voraussetzung: Man müsste einen legitimen Verschlüssler dazu bringen, 2^105 Verschlüsselungen von ausgewählten Klartexten unter seinem geheimen Schlüssel zu erzeugen. Beides ist in der Praxis völlig unmöglich. Der angebliche Geschwindigkeitsvorteil ist nur auf dem Papier nachweisbar – ob der Angriff tatsächlich schneller laufen würde, ist unklar.

Trotzdem ist das Ergebnis nicht wertlos. Aus wissenschaftlicher Sicht ist jeder Fortschritt, so klein er auch ist, interessant. Der Autor betont: Dies ist ein kleiner Schritt im Verständnis der AES-Struktur, aber kein praktischer Durchbruch. Der eigentliche Wert liegt in der Methodik: KI-Modelle können subtile Verbesserungen an etablierten Angriffen finden, selbst wenn diese marginal sind.

Wie Anthropic zu diesen Ergebnissen kam

Der Blogbeitrag gibt einen erstaunlich transparenten Einblick in den Forschungsprozess. Und der ist, wie der Autor schreibt, „irgendwie witzig“. Es war kein Team von Krypto-Experten, das monatelang das Modell feinjustierte. Stattdessen gaben sie der KI einfache Anweisungen wie: „Finde einen Angriff auf HAWK.“ Dann ließen sie sie arbeiten. Die Prompts waren extrem simpel – fast so, als würde man einem Praktikanten sagen: „Geh und mach was Nützliches.“

Der Autor zitiert einige Prompts aus dem Anthropic-Blog: Bilder von Instruktionen, die im Grunde besagen: „Hier ist die Spezifikation, hier sind die bekannten Techniken – finde einen Angriff.“ Und das Modell lieferte. Es verstand die existierenden Resultate, synthetisierte sie und erweiterte sie zu neuen Angriffen. Ohne detaillierte menschliche Anleitung. Das ist beeindruckend, auch wenn es noch keine Superintelligenz ist. Es zeigt aber: KI kann echte kryptanalytische Arbeit leisten – Arbeit, die bisher nur hochspezialisierten Wissenschaftlern vorbehalten war.

Das Problem der Verifizierbarkeit

Der Autor hat als Forscher selbst Erfahrung mit KI-Modellen. Er berichtet, dass er in den letzten Monaten immer wieder überraschende „Ergebnisse“ von Modellen bekommen hat. Aber dann kommt die Ernüchterung: Nur weil ein Modell ein Ergebnis ausspuckt, heißt das nicht, dass es korrekt ist. KI-Modelle sind hervorragend darin, Ergebnisse zu produzieren, die echt aussehen, aber in die Irre führen. Das ist ein wachsendes Problem.

Für Angriffe wie den auf HAWK ist die Verifikation einfach: Man kann den Code ausführen und prüfen, ob er Schlüssel wiederherstellt. Für subtilere Verbesserungen, wie beim AES-Angriff, ist das schwieriger. Formale Beweise in Lean können helfen, aber solche Beweise hängen davon ab, wie die Theoremaussage formuliert ist. Das erfordert menschliche Experten. Der Autor prognostiziert, dass dieser Bedarf an menschlicher Prüfung den Fortschritt verlangsamen wird – zumindest solange die KI nicht ihre eigenen Beweise überprüfen kann.

Was bedeutet das für die reale Welt?

Die Antwort hängt davon ab, wen man fragt. Für die Nutzer von Kryptografie gibt es zwei gute Nachrichten und eine gemischte. Erstens: Symmetrische Chiffren wie AES sind extrem robust. Der Autor vergleicht sie mit einem Bauern, der einen Traktor in Treibsand zieht und dann mit Zement bedeckt. Die Struktur ist absichtlich chaotisch und schwer zu entwirren. KI mag viele Rechenstunden haben, aber ihr fehlt die revolutionäre Intuition, um solche Systeme grundlegend zu brechen. Und selbst wenn sie diese Intuition entwickelt, könnte sie gleichzeitig bessere Chiffren entwerfen.

Die zweite gute Nachricht: Wir befinden uns mitten in einem historischen Übergang von traditionellen Public-Key-Verfahren wie RSA und ECC hin zu Post-Quanten-Verfahren. Es gibt viele Standards in der Entwicklung – genau der perfekte Zeitpunkt für eine massive neue Kryptoanalyse-Fähigkeit. Wenn KI Schwachstellen in diesen neuen Verfahren findet, können wir sie beheben, bevor sie eingesetzt werden. Im besten Fall gewinnen wir echtes Vertrauen in die Sicherheit dieser Verfahren.

Die gemischte Nachricht betrifft die Public-Key-Kryptografie selbst. Diese basiert auf wenigen, sorgfältig konstruierten mathematischen Problemen. Es gab nie genügend menschliche Forscher, um alle möglichen Angriffe auszuschöpfen. Hier bietet sich viel Raum für KI, um neue Schwachstellen zu entdecken. Das ist beunruhigend, aber auch eine Chance: Wenn KI diese Schwachstellen findet, bevor sie ausgenutzt werden, sind wir besser geschützt.

Für Wissenschaftler ist die Lage eher aufregend. Sie haben nun einen „plastischen Kollegen“ – einen, der über Probleme diskutieren kann, aber noch nicht schlauer ist als sie. Das beschleunigt die Forschung. Offene Fragen bleiben: Wer bekommt die Anerkennung für KI-generierte Resultate? Und wer wird all diese neuen Ergebnisse überprüfen? Der Autor zeigt sich noch nicht alarmiert, aber er warnt: Wer denkt, KI sei nur ein „verherrlichtes Autocomplete“ oder dass der Fortschritt nachlasse, irrt gewaltig.

Abschließend eine ernüchternde Einsicht: Die Ergebnisse von Anthropic sind kein Grund zur Panik, aber ein Weckruf. Sie zeigen, dass KI echte kryptanalytische Arbeit leisten kann – Arbeit, die bisher hochspezialisierten Experten vorbehalten war. Der Autor selbst ist beeindruckt, aber auch nachdenklich. Die kommenden Jahre werden entscheiden, ob KI die Kryptografie revolutioniert oder ob wir sie kontrollieren können. Die Zeit, in der wir uns auf die Langsamkeit menschlicher Forschung verlassen konnten, ist vorbei.

Für alle, die sich fragen, ob sie ihr Bitcoin-Wallet leeren sollten: Der Autor beruhigt. Der HAWK-Angriff betrifft ein nicht standardisiertes Verfahren. AES bleibt für alle praktischen Zwecke sicher. Die eigentliche Botschaft ist eine andere: Wir müssen umdenken. Kryptoanalyse wird schneller, automatisierter und umfassender. Das ist, wenn man genau hinschaut, eher eine Chance. Denn wenn KI die Löcher findet, können wir sie stopfen – bevor die Bösen es tun.

Quelle: blog.cryptographyengineering.com

Canva betreibt eine Online-Plattform mit Hunderten Millionen Nutzern. Hunderttausende Anfragen pro Sekunde. Jede muss prüfen: Wer ist der Nutzer? Darf er das? Das Team stand vor der Aufgabe, die Sitzungsverwaltung zu verbessern. Normalerweise würde man bei jedem Request in einer Datenbank nachschlagen – zu langsam und teuer. Canva setzt auf verschlüsselte Browser-Cookies mit allen Sitzungsinformationen: User-ID, Berechtigungen, Rollen. Die Gateways entschlüsseln diese Cookies und prüfen die Legitimität sofort, ohne einen Netzwerkservice zu fragen.

Das Problem: Wenn Sitzungen ungültig werden

Was passiert bei Abmeldung oder Rechteänderung? Alte Cookies müssen in Echtzeit ungültig werden. Canva speichert widerrufene Sitzungen (Revocations) im Arbeitsspeicher der Gateways. Das ist schnell und zuverlässig. Der Haken: Bei jedem Deployment starten Hunderte Gateway-Instanzen neu. Jede lädt alle Revocations aus der MySQL-Datenbank. Das führte zu einer Stampede – Millionen Abfragen pro Instanz. Der Datenbankcluster ächzte unter der Last. Read-Replicas halfen kurzfristig, aber nicht nachhaltig.

Die Idee: S3 als Zwischenspeicher

Die Ingenieure Joeby Neil und Martin Doms suchten eine Lösung, die das Deployment nicht verlangsamt und die Datenbank schont. Ein Zwischenspeicher wie Redis wäre naheliegend, aber Redis ist nicht vollständig dauerhaft. Die Konsistenzprobleme hätten sich nur verschoben. Sie wählten Amazon S3. S3 eignet sich für günstige, schnelle Downloads großer, dauerhafter Dateien. Das Problem: Revocations sind kein statischer Block, sondern ein gleitendes Fenster von 12 Stunden (Cookies erneuern sich regelmäßig). Wie lässt sich ein dynamisches Fenster in S3 abbilden?

30-Minuten-Blöcke als Bausteine

Die Lösung: Sie teilten das 12-Stunden-Fenster in 30-Minuten-Blöcke auf. Jeder Block ist ein separates S3-Objekt. Der Dateiname enthält den Startzeitstempel. Ein Gateway lädt beim Start nur die jüngsten 24 Blöcke herunter – insgesamt wenige Dutzend Megabyte pro Instanz. Jede Revocation ist ein binärer Eintrag von 16 Bytes: 8 Bytes für die Nutzerkennung (Principal), 8 Bytes für den Zeitstempel der Gültigkeit. Dank Sortierung und binärer Suche finden die Gateways Revocations extrem schnell, ohne Java-Objekte zu erzeugen. Speicherverbrauch sank um 87,5 Prozent gegenüber dem alten System.

Die Herausforderung: Aktualisierung der Blöcke

Wie hält man die S3-Blöcke aktuell, ohne bei jeder neuen Revocation den gesamten Block neu zu schreiben? Canva nutzt einen asynchronen Worker, der regelmäßig die Datenbank abfragt, den passenden Block aus S3 lädt, neue Einträge in das sortierte Array einfügt und ihn wieder hochlädt. Mehrere Worker laufen parallel, um Ausfälle zu überbrücken. Das kann zu Datenkonflikten führen. Sie verwenden bedingte PUT-Requests (Conditional PUT) von S3: Vor dem Schreiben prüfen sie, ob sich der Block seit dem Lesen geändert hat. Falls ja, wiederholen sie die Operation. Zusätzlich sorgt ZooKeeper für eine Leader Election, um unnötige Konflikte zu minimieren.

Theoretisch ist die Skalierung problematisch: Jede Batch-Hinzufügung sortiert den gesamten Block – O(N²). In der Praxis arbeiten sie mit Batches von mehreren Hundert Revocations und erreichen über 2000 Schreiboperationen pro Sekunde. Das reicht. Moderne CPUs verarbeiten dichte Arrays so effizient, dass die Netzwerklatenz der Flaschenhals ist, nicht die Sortierung.

Der Effekt: Schnellere Deployments, weniger Datenbanklast

Seit der Umstellung hat Canva die Read-Replicas für die Session-Revocation-Datenbank auf zwei reduziert. Deployments laufen schneller. Gateways streamen Revocations direkt aus S3, statt die Datenbank zu überlasten. Die Systemlast skaliert vorhersagbar mit Schreibrate und Traffic, nicht mit der Anzahl der Gateway-Neustarts.

Das Projekt zeigt: Scheinbar ineffiziente Ansätze können in der Praxis die besten sein. Ein einzelner Worker sortiert Hunderttausende Datensätze immer wieder – klingt nach Verschwendung. Wegen der kompakten Daten und schnellen Rechner ist es die einfachste und stabilste Lösung. Canva testete mehrere Ansätze auf echter Infrastruktur und wählte den pragmatischsten.

Quelle: canva.dev

Du bestellst online ein Buch. Klick auf „Kaufen“ startet eine Kette: Bestellung speichern, Bestätigungsmail versenden, Lager benachrichtigen, Statistik aktualisieren. Läuft alles glatt, fällt nichts auf. Doch wenn die Mail nicht rausgeht oder das Lagersystem überlastet ist, steht die Bestellung infrage – obwohl das Geschäftsereignis „Bestellung aufgegeben“ bereits aufgezeichnet wurde.

Der Autor des ursprünglichen Artikels zeigt an einem Workflow, wie aus einer einfachen Transaktion ein undurchsichtiger Block zusammenhängender Aktionen wird. Zunächst nur zwei Schritte: Bestellung speichern, Mail senden. Dann kommen Fulfillment-Benachrichtigung und Analyse hinzu. Jeder neue Schritt wird an die bestehende Liste angehängt. Problem: Die Geschäftstatsache – „Eine Bestellung wurde aufgegeben“ – gerät zwischen den technischen Details in den Hintergrund. Der Kunde wird von externen Systemen abhängig. Schlägt die Mail-Zustellung fehl, kann die gesamte Operation scheitern, obwohl die Bestellung im System sicher ist. Das führt zu doppelten Bestellungen oder unvollständigen Prozessen. Jeder Schritt braucht eigene Fehlerbehandlung, Wiederholungslogik und Toleranz. Wird die Bestellung an mehreren Stellen im Code aufgegeben, muss jeder Aufrufer dieselbe Kette nachbilden – ein Wartungsproblem.

Die Lösung: eine Trennung von Fakten und Reaktionen. Ein Domain Event beschreibt eine bereits eingetretene Tatsache in der Sprache des Fachbereichs. Nicht: „SendeBestätigungsMail“ (Befehl), sondern: „BestellungAufgegeben“ (Fakt). Die Vergangenheitsform zeigt, dass das Ereignis nicht rückgängig gemacht werden kann. Ein Handler kann „BestellungAufgegeben“ nicht ablehnen; er entscheidet nur, wie er reagiert. Ein Event ist unveränderlich. Ändert sich die Bestellung später, ist das ein neuer Fakt, der ein neues Event verdient.

Ein Domain Event trägt Informationen, die nötig sind, um den Fakt zu verstehen: meist die ID der Entität, relevante Werte zum Zeitpunkt des Ereignisses und einen Zeitstempel. Die genaue Zusammensetzung ist eine Designentscheidung. Manche Handler reichen mit einer ID aus, um Daten aus einer Read-Projection zu holen; andere brauchen einen vollständigen Schnappschuss. Der Autor rät, Events schlank zu halten und nur das Nötigste mitzugeben. Die innere Repräsentation des Aggregats sollte man nicht aus Bequemlichkeit preisgeben.

Damit wird der Unterschied zum Command deutlich. Ein Command drückt eine Absicht aus: „BestellungAufgeben“ fordert das Modell auf, etwas zu tun – und kann abgelehnt werden. Ein Domain Event zeichnet das Ergebnis auf: Akzeptiert das Modell den Command, wird „BestellungAufgegeben“ ausgelöst. Das Event entsteht im Arbeitsspeicher, während die Transaktion läuft. Erst nach erfolgreichem Abschluss wird das Event an die interessierten Handler verteilt.

Wo wird ein Domain Event erzeugt? Dort, wo die Entscheidung fällt. In einem reichen Domänenmodell ist das das Aggregat, das die relevanten Regeln durchsetzt. Die Sequenz: Geschäftsregeln prüfen, Zustand ändern, Event aufzeichnen. Das Aggregat hält das Event so lange bei sich, bis die Unit of Work es einsammelt. Kein Code außerhalb des Aggregats darf „BestellungAufgegeben“ konstruieren. Der Anwendungsdienst bittet das Modell, die Arbeit zu tun, und persistiert das Ergebnis. Das löst ein Problem des ursprünglichen Transaktionsskripts: Egal ob die Bestellung aus dem Shop, einem Admin-Tool oder einem Datenimport kommt – jeder Aufruf von order.place() zeichnet dasselbe Event auf. Neue Reaktionen wie Analyse oder Fulfillment lassen sich später hinzufügen, ohne jeden Aufrufer ändern zu müssen.

Die Reaktionen selbst leben in Event-Handlern. Jeder Handler hat eine Verantwortung: „Wenn dies passiert ist, tue jenes.“ Der Handler für die Bestätigungsmail nimmt das Event entgegen und versendet die Mail. Ein anderer Handler kümmert sich um die Fulfillment-Benachrichtigung. Handler wissen nichts voneinander und können hinzugefügt werden, ohne das Modell zu ändern, das das Event ausgelöst hat. Die geordnete Liste zusammenhangloser Arbeit wird zu einem Satz unabhängiger Aktionen, die jeweils eigene Fehlerbehandlung und Wiederholungslogik haben können.

Wer ruft die Handler auf? Das Aggregat selbst nicht – das ist Infrastrukturaufgabe. Die Unit of Work ist ein natürlicher Ort, weil sie weiß, welche Aggregate beteiligt waren und ob die Transaktion erfolgreich war. Der Autor skizziert eine einfache synchrone Schleife, warnt aber: Diese Implementierung verbessert die logische Trennung, bleibt aber synchron – die Anfrage wartet auf jeden Handler, die Zustellung ist nicht beständig. Ein fehlschlagender Handler kann die anderen beeinträchtigen. Für asynchrone, zuverlässige Zustellung empfiehlt er das Transactional Outbox-Pattern. Handler sollten trotzdem idempotent sein – also bei Wiederholung keine unerwünschten Seiteneffekte erzeugen.

Manche Handler rufen externe Systeme auf, andere lösen Verhalten in anderen Aggregaten aus. Wenn ein Handler die Reservierung von Lagerbestand anstoßen soll, muss er das Inventory-Aggregat laden, dessen Methode reserve() aufrufen und eine neue Transaktion abschließen. Das ist eine zweite Transaktion, keine Erweiterung der ersten. Für einen kurzen Moment existiert die Bestellung, ohne dass der Lagerbestand reserviert ist – die beiden Aggregate sind eventuell konsistent. Eine einzelne Transaktion über beide Aggregate hinweg mag manchmal gerechtfertigt sein, koppelt aber ihre Lebenszyklen. Die Faustregel lautet: Ein Aggregat pro Transaktion. Werden zwei Aggregate in derselben Transaktion geändert, deutet das eher auf ein Designproblem im Domänenmodell hin. Die lose Kopplung verbessert auch die Verfügbarkeit: Der Bestellvorgang kann weiter Bestellungen annehmen, während das Inventory über Engpässe entscheidet – nicht verfügbarer Bestand verzögert dann die Auslieferung, führt aber nicht zur Ablehnung der Bestellung.

Sobald ein Event die Grenze eines Bounded Context überschreitet, wird daraus ein Integration Event. Ein Domain Event gehört zum Modell, das es erzeugt hat. Sein Name und seine Struktur können Annahmen enthalten, die im Ordering-Kontext Sinn ergeben, im Fulfillment-Kontext aber nicht. Deshalb übersetzt der empfangende Kontext das Integration Event an seiner Grenze in einen lokalen Befehl – etwa PrepareOrder. Er muss weder die Aggregate noch das interne Event-Modell des Ordering-Kontexts verstehen. Diese Übersetzung muss nicht eins zu eins sein: Ein Kontext kann mehrere Domain Facts kombinieren und für verschiedene Empfänger unterschiedliches Verhalten auslösen. Bounded Contexts sind oft als separate Dienste deployed, aber das muss nicht sein. Sind sie es, werden Integration Events typischerweise asynchron über Messaging-Infrastruktur wie Kafka, RabbitMQ oder Azure Service Bus zugestellt. Das bringt Serialisierung, Zustellungsfehler, Duplikate und versionierte Verträge mit sich. Eine zuverlässige Veröffentlichung erfordert dann meist das Transactional Outbox oder einen gleichwertigen Mechanismus.

Nicht jede Zustandsänderung verdient ein Event. Der Autor warnt davor, für jeden Setter oder Datenbank-Update ein Event zu erzeugen – das erzeugt Rauschen statt eines nützlichen Modells. Ein direkter Aufruf über einen Domänen- oder Anwendungsdienst ist vorzuziehen, wenn die Abhängigkeit Teil einer klaren Operation ist und nichts davon profitiert, getrennt zu werden. Domain Events sollten bedeutsame Fakten im Geschäftsbereich abbilden und keine Abhängigkeiten verstecken, die explizit besser zu verstehen wären.

Praktisch heißt das: Domain Events übersetzen die Logik deines Systems in die Sprache des Fachbereichs und reduzieren gleichzeitig die technische Kopplung. Sie zwingen dich, die Frage „Was ist eigentlich passiert?“ präzise zu beantworten und jede Reaktion unabhängig zu behandeln. Starte mit dem Fakt, den das Geschäft interessiert. Erzeuge das Domain Event genau dort, wo die Entscheidung fällt. Reagiere mit fokussierten Handlern. Übersetze an Kontextgrenzen in Integration Events. Wähle die Zustellungsart – synchron oder asynchron – erst, wenn die Anforderungen an Transaktionen, Konsistenz und Fehlertoleranz klar sind. Der Domain-Fakt bleibt explizit, jede Konsequenz hat ihren eigenen Ort zum Scheitern, Wiederholen und Weiterentwickeln – die Tür zur Verteilung über mehrere Prozesse oder Dienste bleibt offen, wenn das System es verlangt.

Quelle: deniskyashif.com

Ein großes Update für ein Spiel herunterladen – mehrere Hundert Gigabyte. Der Download startet, man holt Kaffee, und beim Zurückkommen läuft er immer noch. Irgendwann ist die Datei da, aber Entpacken und Installieren dauern. Bis zum Spielen ist der Abend vorbei. So fühlt es sich an, wenn ein großes KI-Modell startet. Die Gewichte – die gelernten Parameter – sind oft hunderte Gigabyte schwer. Sie müssen nicht nur einmal, sondern immer wieder bewegt werden: beim ersten Start (Cold Start), beim Hochskalieren neuer Repliken, bei Updates, beim Reinforcement Learning. Jedes Mal liegt das Modell brach, während die Daten transportiert werden.

NVIDIA hat mit ModelExpress (MX) eine Lösung vorgestellt, die diesen Flaschenhals verkürzt. Die Kernidee: Bevor du Gewichte aus der Cloud holst, frag erst, ob irgendwo im Cluster schon eine passende Kopie in GPU-Speicher existiert. Warum etwas herunterladen, wenn du es von einem Nachbarn per Direct Memory Access abholen kannst? ModelExpress baut eine Hierarchie von Transferwegen auf – und wählt für jede Situation den schnellsten aus.

Das Problem: Jedes Byte kostet Zeit

Modelle wie DeepSeek-V4-Pro wiegen rund 800 Gigabyte. Wenn zehn Repliken gleichzeitig starten, müssen insgesamt acht Terabyte durch die Leitung. Selbst bei schnellem Netzwerk dauert das Minuten. Während des Transfers kann kein Token inferiert werden. Das ist nicht nur bei der Erstbereitstellung ärgerlich, sondern auch bei Autoscaling-Events oder wenn nach einem Training neue Gewichte verteilt werden. Der Autor des NVIDIA-Blogs beschreibt diese Zeitsteuer als „das Gleiche: Zeit, die mit dem Bewegen von Gewichten vergeht, bevor nützliche Arbeit beginnt.“

Herkömmliche Ansätze laden jedes Modell unabhängig – jeder Pod zieht sich die Daten aus dem Object Store, schreibt sie auf die Festplatte und lädt sie dann in den GPU-Speicher. Das ist redundant und langsam. ModelExpress behandelt das gesamte Cluster als einen verteilten Cache für Modellgewichte.

Wie ModelExpress den schnellsten Weg findet

Das System besteht aus zwei Ebenen: der Control Plane und der Data Plane. Die Control Plane sucht nach kompatiblen Quellen – zum Beispiel über Redis-Metadaten oder Kubernetes-Custom-Resources. Sie entscheidet, ob ein Peer im GPU-Speicher die passenden Gewichte hat. Die Data Plane führt den eigentlichen Transfer durch, über eine priorisierte Kette von Methoden, die automatisch durchprobiert werden.

Die Priorität: P2P RDMA von einem Serving-Peer über NIXL (NVIDIA Inference Xfer Library) ist am schnellsten. Danach kommt ModelStreamer, der direkt aus einem Object Store streamt, ohne die lokale Festplatte zu belasten. Dann GPUDirect Storage (GDS), falls verfügbar. Als letztes der Fallback auf host-staged POSIX I/O. Das System testet bei jedem Start, welche Methoden die Umgebung unterstützt, und wählt die erste funktionierende aus.

Die erste Replik: Bootstrapping aus dem Speicher

Wenn noch kein Peer existiert, muss die erste Instanz ihre Gewichte irgendwoher bekommen. ModelExpress kann das auf zwei Arten tun: direkt aus einem Object Store (wie S3 oder Hugging Face) oder von einer lokalen Festplatte. Es vermeidet unnötige Zwischenschritte. Beim Streamen aus Object Storage nutzt es ModelStreamer, der die Safetensor-Dateien parallel über mehrere Threads liest und die Tensoren direkt in den GPU-Speicher legt. Die Daten landen nie auf der SSD, es gibt keinen zwischengelagerten Download. Das spart I/O und Zeit.

Alternativ kann MX auch von einer lokalen Festplatte laden – entweder über GPUDirect Storage, das die GPU direkt die Platte lesen lässt, oder über einen gepipelineten Lesevorgang mit ModelStreamer, der Hintergrund-I/O mit GPU-Platzierung überlappt. In tensor-parallelen Deployments teilen sich die Ranks die Arbeit: Sie laden nur einen Teil der Daten und tauschen sie über NCCL aus, statt jeder einzeln alles zu holen.

Jede weitere Replik: GPU-zu-GPU über RDMA

Sobald die erste Replik läuft, ändert sich die Strategie. Ihre Gewichte liegen bereits fertig prozessiert im GPU-Speicher – genau die Daten, die jede neue Replik braucht. Statt sie erneut aus dem Storage zu holen, fragt MX bei der Control Plane nach einem Peer. Wenn ein passender gefunden wird – eine Replik mit demselben Modell und derselben Tensor-Layout-Konfiguration – startet der Transfer direkt von GPU zu GPU über RDMA. Der Autor beschreibt, dass MX dabei NIXL als Standard-Engine nutzt, die hinter den Kulissen verschiedene Netzwerke wie InfiniBand, RoCE, NVLink oder EFA unterstützt.

Die Metadaten – welche GPU, welcher Speicherbereich – werden über die Control Plane ausgetauscht, die Gewichte selbst wandern nie durch die CPU. Das ist der entscheidende Vorteil: keine Kopie in den Host-Speicher, keine unnötigen Latenzen. So kann ein neues Replica in weniger als zehn Sekunden die 800 Gigabyte Gewichte von einem Serving-Peer beziehen. Der gesamte Startup (inklusive JIT-Kernel-Kompilierung) sinkt von acht Minuten auf eine Minute und 44 Sekunden.

Optimierung der Speicherregistrierung

Damit RDMA funktioniert, muss der GPU-Speicher vorher registriert werden – der Treiber teilt dem Netzwerkkarten-Stack mit, welche Speicherbereiche für Remote Access freigegeben sind. Bei einem Modell mit zehntausenden Tensoren summiert sich das Registrieren jedes einzelnen Tensors schnell. ModelExpress bietet zwei Optimierungen: Pool-Registrierung (Zusammenfassen der cudaMalloc-Allokationen) und VMM-Arena-Registrierung (alles in einen großen virtuellen Adressraum legen und nur einmal registrieren). Die VMM-Variante reduziert die Anzahl der ibv_reg_mr-Aufrufe von mehreren Tausend auf einen einzigen. Die Messungen im Blog zeigen, dass die Zeit dafür von über 600 Millisekunden auf etwa 20 Millisekunden sinkt – ein winziger Teil der Startup-Zeit, aber dennoch beachtlich.

Fallback und Fehlersicherheit

Nicht jede Umgebung unterstützt GPUDirect RDMA. Wenn ein Pfad nicht verfügbar ist oder fehlschlägt, fällt MX automatisch auf den nächsten zurück – aber nur, solange noch keine Gewichte geschrieben wurden. Falls nach dem Start des Schreibens ein Fehler auftritt, initialisiert MX das Modell neu, um inkonsistente Zustände zu vermeiden. Das System kann auch mehrere Peers ausprobieren, aber nur bei Metadaten-Fehlern vor dem eigentlichen Transfer. So bleibt die Startup-Logik robust, ohne das Anwendungsmodell zu gefährden.

Mehr als nur Gewichte: Auch kompilierte Kernel profitieren

Ein Modell ist nicht startklar, sobald die Gewichte im GPU-Speicher liegen. Die Inference-Engine muss JIT-kompilierte und autotuned Kernel für die spezifische Modellkonfiguration generieren – etwa für Flash Attention oder DeepGEMM. Normalerweise passiert das bei den ersten Forward-Passes und kann Minuten dauern. ModelExpress überträgt auch den fertigen JIT-Kernel-Cache inklusive aller Optimierungen zusammen mit den Gewichten. Die neue Replik muss nicht noch einmal die gesamte Kompilierung durchlaufen, sondern kann sofort loslegen. Im Benchmark mit DeepSeek-V4-Pro sank die Startzeit dadurch noch einmal deutlich.

Ergebnisse und Einordnung

Die mitgelieferten Messungen zeigen: P2P RDMA über NIXL ist um ein Vielfaches schneller als der Standard-Weg über Object Store und host-staged I/O. Für DeepSeek-V4-Pro auf einem 8x-B200-Node mit ConnectX-7-NICs verkürzt sich die reine Ladezeit von über sieben Minuten auf unter fünf Sekunden. Der gesamte Startup inklusive Modell-Laden, Kernel-Cache-Transfer und Initialisierung fällt von acht Minuten auf unter zwei Minuten. Das verändert, wie wir über horizontale Skalierung und Rolling Updates denken.

Praktisch bedeutet das: KI-Systeme können agiler auf Lastspitzen reagieren. Eine neue Replik ist in weniger als zwei Minuten betriebsbereit statt in zehn Minuten. Bei großen Clustern mit hunderten Repliken summiert sich die gesparte Bandbreite: Statt tausendfach die gleichen 800 Gigabyte aus dem Object Store zu ziehen, reicht ein einmaliger Download. Weitere Repliken beziehen ihre Gewichte über schnelle GPU-to-GPU-Verbindungen. Das reduziert nicht nur die Netzlast, sondern auch die Kosten für den Object Store.

Der Autor beschreibt ModelExpress als einen Schritt hin zu einem „distributed artifact cache“ für KI-Workloads. Die Idee, vor dem Laden zu fragen, wo die Daten bereits in optimaler Form vorliegen, mag naheliegend klingen. Aber sie konsequent umzusetzen – mit automatischer Pfadwahl, RDMA-Integration und Kernel-Caching – erfordert einiges an Engineering. NVIDIA hat das für die eigene Plattform realisiert. Ähnliche Ansätze werden bald Standard in der KI-Infrastruktur sein.

Zeit ist kostbar, besonders wenn GPUs darauf warten, Rechenarbeit zu verrichten. ModelExpress zeigt, dass das Bewegen von Modellgewichten nicht der Flaschenhals sein muss, der den Betrieb ausbremst. Statt bei jedem Start die Welt neu zu laden, fragen wir einfach unseren Nachbarn – und schon geht es weiter.

Quelle: developer.nvidia.com

Warum wird ein Programm trotz neuer CPU und schnellem RAM nicht schneller? Die Antwort liegt oft im Memory-Level Parallelism (MLP). Daniel Lemire hat das mit seinem testingmlp-Benchmark an aktuellen Serverprozessoren getestet. AMD führt mit deutlichem Abstand.

Was ist MLP? Fordert ein Programm Daten an, die nicht im Cache liegen, greift der Prozessor auf den Hauptspeicher zu. Das dauert rund 100 Nanosekunden – etwa 300 Taktzyklen bei 3 GHz. Die RAM-Latenz hat sich in zehn Jahren kaum verbessert. Ein Broadwell von 2016 brauchte 100 ns für einen zufälligen Zugriff. Ein aktueller AMD Turin (Zen 5) mit DDR5-6400 benötigt 140 ns. Ein Kern kann aber mehrere Anfragen gleichzeitig stellen. Die Anzahl gleichzeitig ausstehender Speicheranfragen heißt Memory-Level Parallelism. In keinem Datenblatt findet sich diese Kennzahl.

Lemire maß MLP per Pointer Chase. Ein 1 GiB großer Bereich wird mit einer zufälligen Kette befüllt – jedes Element zeigt auf den nächsten Index. Folgt man der Kette, ist jeder Zugriff vom vorherigen abhängig. Ein einzelner Pointer Chase misst die reine Speicherlatenz. Mehrere Ketten (Lanes) liefen gleichzeitig, jede startet an einem anderen Punkt. So beobachtete Lemire den Durchsatz. Sobald eine weitere Lane keine Steigerung bringt, ist das Limit erreicht. Die geschätzte Gesamtbandbreite diente als Metrik.

Die Experimente fanden auf AWS statt. Die Bandbreitenkurve zeigt einen steilen Anstieg mit jeder Lane, dann einen Knick und ein Plateau. Die Höhe dieses Plateaus variiert stark. Intel verbesserte sich von 10 (Broadwell, 2015) auf 30 (Granite Rapids, 2025). AMD startete 2018 mit 15 (Naples), erreichte 22 (Milan) und nun 58 (Turin, Zen 5). AWS Graviton blieb zurück: Graviton 1 bot 6, Graviton 5 kommt auf 19.

Ein Lichtblick: Graviton 5 hat mit 96 ns die niedrigste Latenz, Intel liegt bei 133 ns, AMD bei 142 ns. Aber Latenz allein ist nicht entscheidend. Bei der Gesamtbandbreite erreicht AMD 24,5 GiB/s, Intel 13,3 GiB/s und Graviton 12,0 GiB/s – trotz AMD-Nutzung von DDR5-6400 gegenüber DDR5-7200 (Intel) und DDR5-8800 (Graviton). Höhere Speichertaktraten gleichen die schwächere Parallelität nicht aus.

MLP ist entscheidend für rechenintensive Anwendungen wie Datenbanken, ML-Inferenz und Simulationen. Sie scheitern oft an der Speicherbandbreite, nicht an der Rechenleistung. Ein Prozessor mit mehr parallelen Anfragen holt mehr Daten aus dem RAM. Apple Silicon schneidet in dieser Hinsicht möglicherweise noch besser ab – das liegt an integrierten Speichercontrollern und enger CPU-RAM-Kopplung in den M‑Chips.

Für Rechenzentren und Cloud-Anbieter ist die CPU-Wahl nicht nur eine Frage von Taktrate und Kernzahl. Der Memory-Level Parallelism bestimmt, wie effizient ein Kern bei Cache-Misses arbeitet. AMD hat mit Zen 5 einen Sprung gemacht, der Intel und ARM deutlich übertrifft. Ob sich das in standardisierten Benchmarks oder realen Anwendungen zeigt, bleibt abzuwarten. Lemires Messung spricht für sich: Wer speicherintensive Workloads betreibt, sollte sich AMDs Turin genauer ansehen.

Quelle: lemire.me