Kategorie: Erklärer

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

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

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

Arbeitest du mit einem KI-Agenten an einem komplexen Programmierprojekt, gibst du eine Anweisung, der Agent antwortet. Dann die nächste Anweisung – der Agent muss dieselbe riesige Menge Kontext neu verarbeiten. Als müsstest du jedes Mal ein ganzes Buch neu lesen, um einen Satz zu schreiben. Prompt Caching speichert den berechneten Verarbeitungszustand, sodass der Agent nur den neuen Teil einer Anfrage berechnen muss. Dieser Mechanismus ist fragil und hat weitreichende Auswirkungen auf Latenz, Kosten und das Design von Tools und Sitzungen.

Earendil hat die Funktionsweise und Tücken von Prompt Caching für Coding-Agenten analysiert. Large Language Models werden oft als reine Funktionen betrachtet: Text rein, Text raus. Diese Abstraktion ignoriert einen wesentlichen Fakt: Bei einem Coding-Agenten ist der Großteil der Eingabe von Durchlauf zu Durchlauf identisch. Der Agent sendet System-Prompt, Tool-Definitionen, Projektanweisungen, Konversationsverlauf, Tool-Aufrufe und Ergebnisse. Im nächsten Schritt sendet er fast alles noch einmal, plus ein kleines bisschen Neues. Wächst eine Sitzung auf Zehntausende oder Hunderttausende Tokens an, wird es langsam und teuer, den gesamten Prompt für jeden Schritt neu zu berechnen. Prompt Caching macht es wirtschaftlicher, bleibt aber fragil.

Was ein KV-Cache enthält

Ein Transformer arbeitet in zwei Phasen. Während des Prefills liest er die Eingabe-Tokens und berechnet den Aufmerksamkeitszustand. Während des Decodings erzeugt er neue Tokens einzeln. In jeder Attention-Schicht produziert jeder verarbeitete Token einen Key und einen Value. Das sind Arrays von Zahlen, meist Gleitkommazahlen oder quantisierte Werte. Verarbeitet das Modell einen neuen Token, vergleicht es dessen Query mit den früheren Keys, um die Relevanz jedes früheren Tokens zu bestimmen. Daraus entsteht eine gewichtete Mischung der entsprechenden Values. Ein Key ist das, wonach gesucht wird, ein Value die Information, die abgerufen wird – allerdings unscharf, nicht wie ein exakter Lookup. Diese Keys und Values werden aufbewahrt, damit der nächste generierte Token auf alles Vorherige achten kann, ohne die früheren Tokens neu berechnen zu müssen. Dieser gespeicherte Zustand ist der KV-Cache.

Der Cache entspricht einer bestimmten Token-Präfixfolge. Zwei Prompts mit gleicher Bedeutung, aber unterschiedlicher Tokenisierung, teilen sich keinen KV-Cache. Ändert sich ein Token in der Mitte, ist alles danach eine andere Fortsetzung. Prompt Caching verlängert die Lebensdauer dieses Zustands über eine einzelne Generierung hinaus. Beginnt die nächste API-Anfrage des Coding-Agenten mit denselben Tokens, kann das Inferenzsystem die gespeicherte Arbeit für das passende Präfix wiederverwenden und nur das neue Suffix vorausberechnen.

Wo der Cache lebt

Ein Cache muss gespeichert und adressierbar sein. Es gibt zwei grundlegende Ansätze, wie Inferenzsysteme KV-Caches für spätere Anfragen verfügbar machen. Der einfachere ist die Session Affinity. Der Cache bleibt auf oder nahe der GPU, die ihn berechnet hat. Die nächste Anfrage wird an denselben Worker geroutet. Eine Session-ID oder ein Prompt-Cache-Key dient als einfacher Routing-Hinweis. Das vermeidet, einen sehr großen Cache über das Netzwerk zu bewegen. Es ist schnell, wenn es funktioniert, schränkt aber die Planung ein. Der Worker kann überlastet sein, neu starten oder den Eintrag verdrängen. Ein Router kann auch entscheiden, das Balancieren der Flotte sei wichtiger als die Erhaltung eines Session-Caches. Dennoch ist es attraktiv, weil es mit wenig zusätzlicher Infrastruktur auskommt.

Der andere Ansatz ist die Verteilung des Caches. KV-Blöcke können in einer anderen Speicherebene abgelegt oder über mehrere Worker verfügbar gemacht werden. Eine Anfrage ist dann nicht so stark an eine einzelne GPU gebunden. Das verbessert Scheduling-Flexibilität und Wiederherstellbarkeit. Das Verschieben, Indizieren und Behalten von KV-Blöcken ist selbst ein Systemproblem. Implementierungen mischen GPU-Speicher, Host-Speicher, lokalen Speicher, entfernten Speicher, präfixbewusstes Routing und Verdrängungsstrategien auf unterschiedliche Weise.

Cache und Präfixe: Sitzungen sind Bäume, keine Listen

Ein interessanter Punkt: Viele Coding-Agenten – darunter auch Pi, an dem Earendil arbeitet – modellieren Sitzungen als Bäume. Ein Befehl wie /tree kann die aktive Konversation auf einen früheren Punkt zurücksetzen und entlang eines anderen Zweigs fortsetzen. Ein Zurückspulen kann das aktive Suffix verwerfen, ohne es aus der Sitzungsdatei zu löschen. Ein neuer Zweig kann den größten Teil des alten Kontexts teilen, einen kleinen Teil oder praktisch keinen. Alle drei Zweige können dieselbe Pi-Session-ID haben. Aus Sicht des Routers sind sie eine Sitzung. Aus Sicht des Prompt-Caches sind es drei Token-Sequenzen mit nur teilweisem Präfix-Overlap.

Wenn der Cache wiederverwendbare Präfix-Blöcke behält, kann ein Sprung von D nach F möglicherweise root -> C wiederverwenden. Wenn er nur die heißeste Fortsetzung behält, die gemeinsamen Blöcke verdrängt wurden oder die Anfrage anderswo hin geroutet wird, kann der Treffer viel kleiner ausfallen. Ein Sprung zu Z bewahrt möglicherweise nur den System-Prompt und die anfänglichen Tool-Definitionen, obwohl er von A startet. Das genaue Cache-Management hängt stark vom Anbieter ab. Auch der umgekehrte Fall kann eintreten: Ein Fork oder eine neue Sitzung erzeugt eine neue Session-ID, während ein großer Teil identischen Kontexts übernommen wird. Ein Routingsystem, das Caches nach Session-Key isoliert, übersieht möglicherweise diesen nützlichen Overlap.

Explizites vs. automatisches Präfix-Caching

Anbieter-APIs bieten zwei Hauptstile. Anthropics traditionelles Interface nutzt explizite cache_control-Punkte. Der Client markiert Grenzen nach stabilen Teilen der Anfrage, wie dem System-Prompt, Tool-Definitionen oder dem letztmöglichen cachebaren Konversationsinhalt. Der Server kann den Präfix, der an diesen Punkten endet, schreiben oder nachschlagen. Die Grenze ist explizit, aber die Wiederverwendung erfordert, dass der Inhalt davor übereinstimmt. Auch die Preise sind explizit: Man zahlt für Cache-Schreibvorgänge und kann wählen, wie lange der Cache gehalten wird – zu unterschiedlichen Preisen. Andere APIs verwenden automatisches Präfix-Caching: Der Client sendet die Anfrage normal, der Anbieter findet ein wiederverwendbares Präfix ohne clientseitige Haltepunkte. Ein Prompt-Cache-Key oder Session-Header kann das Routing verbessern, macht aber unterschiedliche Präfixe nicht gleich.

Warum Tool-Loadouts Caches zerstören

Ein häufiges und überraschendes Problem: Tool-Definitionen beeinflussen Caches. Sie erscheinen meist vor der Konversation und werden intern in den System-Prompt eingefügt. Ihre Namen, Beschreibungen und JSON-Schemata sind genauso Modelleingabe wie jeder andere Text. Ein Tool hinzufügen, entfernen, sein Schema ändern oder auch nur die Tools in einer anderen Reihenfolge serialisieren – all das kann den ersten Unterschied weit vorne im Prompt platzieren. Dies ist eine häufige Überraschung bei Plugin-Systemen und MCP-ähnlichen Tool-Katalogen.

Tools nur dann zu laden, wenn sie relevant werden, klingt effizient, weil zunächst weniger Schemata gesendet werden. Bei den meisten Modellen invalidiert das neu erweiterte Loadout jedoch die gecachte Konversation, die darauf folgt. Das Sparen weniger Tool-Schema-Tokens kann dazu führen, dass Zehntausende von Konversations-Tokens erneut verarbeitet werden müssen. Einige neuere Modell-APIs unterstützen additives Tool-Laden. Ein Tool kann zu einem bestimmten Tool-Ergebnis innerhalb des Transkripts verfügbar werden, anstatt in die ursprüngliche Tool-Liste eingefügt zu werden. Das alte Präfix bleibt unverändert. Pi unterstützt dies heute für Modelle mit nativen Deferred-Tool-Mechanismen. Wenn eine Erweiterung eine rein additive Änderung mit setActiveTools() vornimmt, zeichnet Pi die hinzugefügten Namen auf dem Tool-Ergebnis auf. Für unterstützte Anthropic-Modelle verwendet es deferred definitions und tool_reference, für unterstützte OpenAI-Modelle entsprechende Tool-Suche-Einträge. Andere Modelle bekommen einen sicheren Fallback: Pi sendet die komplette aktive Tool-Liste bei der nächsten Anfrage, was funktional korrekt ist, aber den Prompt-Cache löschen kann.

Das Wort „additiv“ ist wichtig. Das Entfernen von Tools, das Ersetzen eines Loadouts durch ein anderes oder das Ändern von Prompt-Schnipseln verändert immer noch die frühere Eingabe. Eine Erweiterung, die den System-Prompt neu aufbaut, die Tool-Reihenfolge mischt, Zeitstempel einfügt oder bei jedem Schritt die aktiven Tools ändert, kann unbeabsichtigt das Caching für die gesamte Sitzung zunichtemachen. Erweiterbarkeit bedeutet, dass Pi die Cache-Stabilität nicht für jede Erweiterung garantieren kann. Es kann cache-freundliche Mechanismen bereitstellen; Erweiterungen müssen sie nutzen. Cache-Effizienz ist für viele Erweiterungen nur ein nachträglicher Gedanke – teilweise, weil bei einem Festpreis-Abo die Kosten von Cache-Fehlern nicht so offensichtlich sind.

Unterbrechungen und TTLs

Standard-Lebensdauern einiger wichtiger Prompt-Caches sind kurz. Anthropics fünf Minuten sind kürzer als viele normale Programmieraktivitäten. Wenn man bei der Nutzung von Fable einen Kaffee trinken geht und zehn Minuten später zurückkommt, kostet eine einzelne „sag hallo“-Nachricht mehr Geld als erwartet. Der Benutzer betrachtet eine Programmier-Sitzung als kontinuierlich aktiv, der Inferenz-Anbieter sieht eine Abfolge isolierter Anfragen. Ein langer Build, eine Testsuite, Mittagessen, ein Meeting oder einfach das Anhalten, um einen Diff zu überprüfen – all das kann die Cache-Lebensdauer überschreiten. Die nächste Anfrage enthält denselben Prompt, aber der gespeicherte KV-Zustand ist weg, und das Präfix wird erneut als Input berechnet.

Pi folgt den fünf Minuten Standard, die Anthropic für API-Benutzer empfiehlt. Ein Blick in Claude Codes Codebasis zeigt, dass Anthropic für seine eigenen Abonnement-Benutzer das Cache-Timeout auf eine Stunde erhöht. Die erhöhten Kosten sind für API-Kunden oft nicht gerechtfertigt. Man kann sich aber dafür entscheiden. Einige Anbieter wie Anthropic bieten längere Aufbewahrungskontrollen an. Für unterstützte Direct-APIs können Pi-Benutzer PI_CACHE_RETENTION=long setzen, um diese anzufordern. Das bleibt aber eine Anfrage: Pi kann ein Gateway nicht zwingen, einen Eintrag zu behalten, eine Verdrängung unter Speicherdruck zu verhindern oder einen Cache am Leben zu erhalten, während keine Modellanfrage gestellt wird.

Die Kosten eines Fehlschlags

Preise für ungecachten Input, Cache-Schreibvorgänge und Cache-Lesevorgänge unterscheiden sich. Cache-Lesevorgänge sind meist vergünstigt, weil die teure Prefill-Arbeit bereits erledigt ist. Cache-Schreibvorgänge können einen Aufschlag verlangen, weil der Anbieter verspricht, den Zustand für die spätere Nutzung aufzubewahren. Betrachten Sie eine Coding-Sitzung mit 100.000 Token Historie, gefolgt von einer kurzen neuen Anfrage. Wenn der Cache funktioniert, wird fast die gesamte Historie zum niedrigeren Cache-Lesepreis abgerechnet. Nur das kleine neue Material wird zum regulären Input-Preis verarbeitet und möglicherweise in den Cache geschrieben. Bei einem Cache-Fehler muss der Anbieter die gesamten 100.000 Token Historie erneut zum regulären Input-Preis verarbeiten. Möglicherweise berechnet er auch das Zurückschreiben dieser Historie in den Cache. Deshalb kann eine kurze Anfrage wie „weiter“ nach einem Cache-Ablauf überraschend teuer sein. In einer langen Coding-Sitzung kann das erneute Lesen des alten Inputs mehr kosten als das Generieren der nächsten Antwort.

Prompt Caching schafft nicht offensichtliche Anreize. Der Benutzer möchte hohe Trefferquoten, weil sie Latenz und Kosten senken. Ein Inferenz-Betreiber, der die GPUs besitzt, sollte sie ebenfalls wollen: Weniger Prefill-Arbeit bedeutet mehr Anfragen mit derselben Hardware. Ein gut entworfener Rabatt auf gecachte Tokens kann beide Seiten in Einklang bringen, während gleichzeitig der Anreiz bleibt, Caching-Mechanismen zu optimieren.

Für Coding-Agenten ist Prompt Caching mehr als ein Implementierungsdetail. Es beeinflusst Latenz, Kosten, Tool-Design, Sitzungsdesign und sogar welche Produktfunktionen überhaupt sinnvoll angeboten werden können. Die Fragilität des Caches – durch Tool-Änderungen, Session-Neustarts, Routing-Entscheidungen oder schlichte Zeitüberschreitungen – macht es zu einer zentralen architektonischen Überlegung. Wer einen KI-Agenten entwickelt oder intensiv nutzt, sollte verstehen, wie der Cache auf den jeweiligen Providern und in der eigenen Anwendung funktioniert. Denn diese unscheinbare Optimierung entscheidet über Geschwindigkeit und Kosten jeder Interaktion.

Quelle: earendil.com

Dein Postfach quillt über. Drei Meetings am Nachmittag, ein Projekt stockt, irgendwo zwischen den Terminen wartet eine Präsentation. Bisher hilft dir eine KI mit Antworten, Zusammenfassungen oder E-Mail-Texten. Nützlich, aber sie nimmt dir die Arbeit nicht ab. Du musst sie immer wieder anschieben. Genau hier setzt ein neues Konzept an: der Agentic PC.

Ein Agentic PC ist ein normaler Arbeitsrechner, ausgelegt darauf, dass KI-Agenten selbstständig für dich arbeiten. Statt auf Befehle zu warten, verstehen sie Kontexte, planen Projekte, sortieren deinen Posteingang, erstellen Entwürfe und führen mehrschrittige Arbeitsabläufe aus. Du delegierst Routineaufgaben an einen lokalen KI-Agenten und behältst die Kontrolle über wichtige Entscheidungen. Für viele Unternehmen wird das 2025 bis 2026 Realität.

Der Unterschied: Assistent vs. Agent

Bisherige KI-Assistenten sind reaktiv. Du stellst eine Frage, sie geben eine Antwort. Sie fassen Texte zusammen, verbessern E-Mails oder durchsuchen Dateien. Dafür reichen zehn bis 30 TOPS. Ein Agentic PC geht weiter. Er versteht Zusammenhänge, plant selbstständig und führt Aufgaben aus deinen Apps heraus aus. Dafür braucht es einen Multi‑Thread‑CPU, großen lokalen Arbeitsspeicher und eine leistungsfähige lokale KI.

Ein gutes Bild: Ein Assistent reicht dir Karteikarten mit Notizen. Du machst die Arbeit selbst. Ein Agent liest die Karteikarten, setzt Prioritäten, erledigt die Recherche und legt dir nur noch die Entscheidung vor. Der Assistent hilft dir, schneller zu arbeiten. Der Agent arbeitet für dich.

Warum das für Unternehmen wichtig wird

Der Reiz für Unternehmen liegt auf der Hand: Zeitersparnis und Effizienz. Wenn ein KI-Agent Meetings vorbereitet, E-Mails kategorisiert und Berichte erstellt, bleiben Mitarbeitern mehr Stunden für strategische Aufgaben. Ein zweiter, oft übersehener Vorteil: Kosten. Viele KI‑Dienste laufen in der Cloud. Jeder Aufruf kostet Geld – Token‑Verbrauch oder Rechenzeit. Ein Agentic PC verlagert einen Großteil dieser Arbeit auf den lokalen Rechner. Die KI läuft direkt auf der Hardware des Mitarbeiters. Das senkt wiederkehrende Cloud‑Kosten und macht die Kostenstruktur kalkulierbarer. AMD spricht von einer „Optimierung des Token‑Verbrauchs“ und einer „vorhersehbareren Kostenbasis“ für Enterprise‑KI.

Hinzu kommt der Datenschutz. Sensible Geschäftsdaten müssen nicht mehr ständig in die Cloud übertragen werden, sondern können lokal verarbeitet werden. Das erleichtert Compliance‑Anforderungen, besonders in regulierten Branchen wie Finanzen, Gesundheitswesen oder Recht.

Die Hardware dahinter: AMD Ryzen AI Max PRO

Für solche Agentic PCs braucht es entsprechende Hardware. AMD hat mit der Ryzen‑AI‑Max‑PRO‑Serie eine Plattform vorgestellt, die speziell für diese Arbeitslasten entwickelt wurde. AMD zufolge ist es der erste x86‑Client‑Prozessor, der große Sprachmodelle mit über 300 Milliarden Parametern lokal ausführen kann. Möglich wird das durch eine Kombination aus leistungsstarken CPU‑Kernen, einer integrierten KI‑Engine und einem großen, einheitlichen Arbeitsspeicher von bis zu 192 GB.

Warum ist so viel Speicher wichtig? KI‑Modelle – vor allem große – brauchen enorm viel Platz im Arbeitsspeicher. Wenn mehrere KI‑Agenten gleichzeitig laufen sollen, wird der Speicher schnell zum Flaschenhals. Mit 192 GB Unified Memory können Unternehmen mehrere Agenten parallel betreiben und mit besonders umfangreichen Modellen arbeiten. AMD nennt konkrete Benchmarks: Ein System mit Ryzen AI Max+ PRO erledigt bestimmte Entwickleraufgaben bis zu sechsmal schneller als ein vier Jahre alter Laptop.

Anwendungsfälle: Vom Helpdesk bis zur Finanzanalyse

Die Praxisbeispiele von AMD für Agentic PCs sind vielfältig. In der IT‑Abteilung könnte ein Agent Server überwachen, Störungen erkennen und automatisch erste Maßnahmen einleiten, während er die Schritte dokumentiert. In der Softwareentwicklung durchforstet der Agent Code, schreibt Tests und erstellt einen Pull‑Request. Für Führungskräfte koordiniert der Agent Kalender, bereitet Briefings vor und plant Reiserouten. Im Kundenservice greift der Agent auf die Account‑Historie zu, beantwortet Anfragen und aktualisiert das CRM.

Auch Cybersicherheit profitiert: Ein Sicherheitsagent erkennt verdächtige Aktivitäten, analysiert die Bedrohung, führt Reaktionsprotokolle aus und hält alles schriftlich fest. In der Finanzanalyse durchsucht der Agent Unternehmenseinreichungen, baut Bewertungsmodelle, identifiziert Risiken und erstellt Investment‑Memoranden. All das geschieht lokal, in Echtzeit und ohne dass der Mitarbeiter jeden Schritt manuell anstoßen muss.

Der Mensch bleibt immer im Entscheidungsprozess. Der Agent schlägt vor, bereitet vor, dokumentiert – aber die finale Entscheidung trifft weiterhin der Mitarbeiter. Das verhindert Kontrollverlust und schafft Vertrauen in die Technologie.

Technische Einordnung: Was bedeutet das konkret?

Für Unternehmen, die über Agentic PCs nachdenken, gibt es einige technische Aspekte zu bedenken. AMD betont, dass die Rechenleistung in TOPS allein nicht ausreicht. Entscheidend ist die Kombination aus CPU‑Leistung, Arbeitsspeicher und der Fähigkeit, mehrere Agenten gleichzeitig auszuführen. Ein Agentic PC muss Multi‑Threaded sein – viele Aufgaben parallel bearbeiten können – und genügend Speicher für große Modelle bieten.

Die aktuelle Generation der Ryzen‑AI‑Max‑PRO‑Prozessoren erreicht bis zu 32 TOPS (beim Max+ Modell), was für anspruchsvolle lokale KI ausreicht. AMD weist darauf hin, dass die Leistung in der Praxis von vielen Faktoren abhängt, etwa vom KI‑Modell, der Softwareversion und der Systemkonfiguration. Die genannten sechsfachen Geschwindigkeitssteigerungen beziehen sich auf einen spezifischen, von AMD definierten Workflow mit sechs parallelen KI‑Agenten und einem großen Modell (ChatGPT 5.5 High). Im Alltag variiert die Verbesserung, aber die Tendenz ist klar: Die Hardware ist bereit für die Agenten‑Ära.

Die Grafik von AMD zeigt: 2023–2024 reichten zehn bis 30 TOPS für Assistenzaufgaben. 2025–2026 braucht es Multi‑Threading und großen Speicher. 2026 und darüber hinaus geht es um autonome Ausführung komplexer Workflows mit hoher lokaler Leistung. Der Übergang von Assistenz zu echter Delegation findet in den nächsten zwei bis drei Jahren statt.

Fazit: Was bedeutet das für Unternehmen?

Agentic PCs sind keine bloße Neuigkeit, sondern eine logische Weiterentwicklung der Arbeitsplatz‑KI. Statt die KI nur als Wissensquelle oder Schreibhilfe zu nutzen, können Mitarbeiter ihr echte Arbeit übertragen. Für Unternehmen bedeutet das weniger Cloud‑Kosten, mehr Datenschutz, höhere Effizienz. Gleichzeitig müssen sie in leistungsfähige Hardware investieren – die sich aber schnell amortisiert, wenn viele Routineaufgaben automatisiert werden.

AMD hat mit der Ryzen‑AI‑Max‑PRO‑Serie eine Plattform geschaffen, die diese Entwicklung unterstützt. Die Kombination aus hoher CPU‑Leistung, großem Unified Memory und dedizierter KI‑Engine macht sie zu einer der ersten ernst zu nehmenden Optionen für Enterprise‑Agentic‑Computing. Die Frage ist nicht mehr, ob lokale KI‑Agenten kommen, sondern wie schnell Unternehmen sie in ihre Arbeitsabläufe integrieren. Wer jetzt die Weichen stellt und auf leistungsfähige PCs setzt, wird morgen einen Vorsprung haben.

Quelle: amd.com