Bietet unseren Wiederverkäufern, Integratoren, Resellern und anderen Channel-Partnern Zugriff auf Produktschulungen, Vertriebs- und Marketingressourcen, Deal-Registrierung und mehr.
Überlegen Sie, inwieweit die Ineffizienz Ihres Inferenzsystems darauf zurückzuführen ist, dass es bereits verarbeitete Kontexte erneut berechnet. Viele Entwickler von KI-Infrastrukturen wissen, dass in Testumgebungen die Kosten für die Neuberechnung des Kontextes relativ unbedeutend sind. Die Prompts sind kurz, die Sitzungen überschaubar und die Leistung vorhersehbar.
In der Produktion ist es jedoch anders. Im großen Maßstab summieren sich Ineffizienzen schnell zu Kosten-, Latenz- und Nutzungsproblemen. Genau dieser Frage wollten wir in unserer jüngsten Forschungskooperation mit SK hynix nachgehen.
Die Studie vereint die Expertise von Seagate im Bereich Festplatten und die führende Position von SK hynix im Bereich Speicher und NAND-Flash-SSDs. Sie untersucht die systemweiten Kompromisse bei der Skalierung von Inferenz-Workloads und zeigt auf, dass mehrstufige SSD- und Festplattenarchitekturen die Grundlage für den Erfolg bilden.
Der Übergang zu agentischen Systemen verändert die Kalkulation.
Die Standardinferenz ist transaktional. Eine Anfrage geht ein, eine Antwort geht raus, und die Aufgabe ist erledigt. Agentische Workloads funktionieren anders. Sie übernehmen den aktuellen Zustand in den nächsten Schritt. Im Laufe der Interaktion akkumuliert sich Kontext, und jede neue Anfrage baut auf dem vorherigen Kontext auf
Gegenüber herkömmlichen Chatbots generiert agentische KI bis zu 15-mal mehr Tokens1, was die Systemfunktion grundlegend verändert. Es geht nicht mehr darum, neue Tokens zu generieren. Das System muss entscheiden, wie viel von den bisherigen Berechnungen beibehalten und wie viel von Grund auf neu aufgebaut werden soll.
Wo der KV-Cache zur Einschränkung wird
Der Key-Value-Cache (KV-Cache) speichert Zwischenrepräsentationen vorheriger Token, sodass das Modell diese nicht bei jeder Anfrage neu berechnen muss. Anfangs funktioniert es gut. Der Engpass ist die Kapazität.
Eine NVIDIA H100 GPU verfügt über High-Bandwidth-Speicher von 80 GB, was ausreicht, um etwa 1,2 Minuten KV-Cache zu speichern. Ein Server mit 1 TB CPU-Speicher verlängert diese Zeit auf etwa 16 Minuten. Keine der beiden Lösungen ist auch nur annähernd für einen mehrstufigen agentischen Workflow geeignet, bei dem Sitzungen Stunden, Tage oder Wochen dauern.
Wenn dieser Speicher voll ist, muss das System ältere Kontexte entfernen. Wenn dieser Kontext wieder relevant wird (und bei agentischen Workloads ist das in der Regel der Fall), berechnet das System ihn neu. Dies verlängert die Zeit bis zum ersten Token immer mehr, erhöht die GPU-Auslastung ohne jegliche Steigerung des nutzbaren Outputs und führt zu Kostenschwankungen, selbst wenn die Nachfrage gleich bleibt.
Mehr DRAM zu investieren verschafft zwar Zeit, löst aber nicht das eigentliche Problem. Das System ist nach wie vor durch den Speicher begrenzt, und der Druck steigt mit zunehmendem Workload.
Kontext als persistenten Zustand behandeln
Hier ändert sich der Ansatz langsam. Statt den KV-Cache als speichergebundene Optimierung zu behandeln, kann er auch als persistenter Zustand betrachtet werden, der über Inferenzzyklen hinweg erhalten, abgerufen und wiederverwendet wird.
In der Praxis bedeutet das mehrstufige Speicherung. Der Hot Context bleibt im Speicher, in der Nähe der GPU. SSDs dienen als Pufferschicht für schnellen Datenzugriff und Datenplatzierung, während Festplattenarrays Objektspeichersysteme unterstützen und die dauerhafte Kapazität bieten, die erforderlich ist, um Kontextdaten über Tage oder Wochen hinweg zu einem Bruchteil der Kosten von All-Flash-Speichern zu speichern.
Die eigentliche Veränderung besteht darin, dass der KV-Cache nicht mehr auf den Arbeitsspeicher beschränkt ist. Stattdessen kann er nun über ein mehrstufiges System von Speicherressourcen verwaltet werden, das die Kapazität skaliert, sodass Inferenzsysteme mehr frühere Arbeiten vorhalten und die Neuberechnung an der Quelle reduzieren können.
In enger Zusammenarbeit mit SK hynix haben wir Benchmark-Tests mit NVIDIA Dynamo und einer Hybridkonfiguration aus SSD- und Festplatte durchgeführt. Wir stellten fest, dass die Auswirkungen bei allen Kennzahlen messbar waren, die für Infrastrukturteams wichtig sind: die Zeit bis zum ersten Token (TTFT), Durchsatz, GPU-Auslastung und Kosten.
Während die Testumgebung kontrollierte Bedingungen vorgibt, ist der Effekt in realen Einsatzumgebungen noch ausgeprägter, da längere Sitzungen und größere Datensätze die Neuberechnung verstärken. Die vollständigen Ergebnisse unserer gemeinsamen Arbeit – Kostenmodellierung über Speicherebenen und Architekturspezifikationen hinweg – werden im Whitepaper detailliert beschrieben.
Hybridspeicher erreichen eine 95%ige Verbesserung der TTFT im Vergleich zur erneuten Generierung.
Diese Lösung funktioniert nur, wenn der Speicher direkt in den Inferenz-Stack integriert ist. Dazu ist eine speziell entwickelte Infrastruktur erforderlich, keine nachgerüstete Standardhardware, um KV-Cache-Daten zwischen Speicher und GPU-Arbeitsspeicher zu verschieben, ohne CPU-Engpässe im Großbetrieb oder neue Latenzen zu verursachen.
Objektspeicher als Aufzeichnungssystem für KI
Ich glaube, unsere Zusammenarbeit mit SK hynix belegt einen umfassenderen architektonischen Wandel, der bereits im Gange ist. Da Inference-Engines immer mehr Zustandsinformationen verwalten, verschwimmt die Grenze zwischen Arbeitsspeicher und Massenspeicher.
Was einst ein flüchtiger Kontext war, wird zunehmend zu einem dauerhaften Zustand – der über mehrere Ebenen hinweg verwaltet und über längere Zeit beibehalten wird. In diesem Modell dient der Speicher nicht nur der Unterstützung der Inferenz. Er bestimmt vielmehr, wie Kontext vorgehalten und abgerufen wird. Das entspricht dem Wandel zum Objektspeicher als maßgeblicher Datenbasis moderner KI-Infrastrukturen.
Wenn Ihr Team Entscheidungen zur Architektur für Inferenz im großen Maßstab trifft, empfehle ich, vorher das Whitepaper zu lesen, in dem die Benchmarks, der Stufenansatz und das Kostenmodell erläutert werden, die bei der Definition Ihres Systems zur Bewertung dieser Kompromisse erforderlich sind.
