Wie ein gemeinsamer KV Cache die LLM-Inferenzlatenz um das 14-fache senkte, ganz ohne neue GPUs

Die Kurzfassung: Eine quelloffene KV-Cache-Schicht namens LMCache senkte die mittlere Time-to-first-token auf einem großen Mixture-of-Experts-Modell um rund das 14-fache, und zwar ohne eine schnellere GPU, ein kleineres Modell oder mehr Speicher. Das Einzige, was sich änderte, war der Ort, an dem der Cache lag. Aus acht Serving-Prozessen, die jeweils einen privaten Cache hüteten, wurden acht Prozesse, die sich einen teilen.

Das ist die ganze Lektion, und sie ist größer als eine einzelne Bibliothek. Die meiste Inferenzoptimierung wird als Kauf schnellerer Hardware verkauft. Ein großer Teil der Latenz, für die du zahlst, ist dein eigenes System, das eine Antwort neu berechnet, die es schon hat, in einem Cache, der zum falschen Prozess gehört. Dieser Artikel erklärt, was sich geändert hat, was die Zahlen belegen und was nicht, und wie du erkennst, ob dieselbe Architektur deinem eigenen LLM-Serving helfen würde.

Der teure Standard: Jeder Rank hortet seinen eigenen Cache

Wenn ein Modell eine Konversation bedient, liest es nicht bei jedem Zug die gesamte Historie neu ein. Es speichert den Zwischenstand der Attention für die Tokens, die es schon gesehen hat. Dieser Speicher ist der KV Cache (Key-Value-Cache), und seine Wiederverwendung ist der Grund, warum der zweite Zug eines Chats viel schneller ist als der erste. Ihn neu zu berechnen nennt man Prefill, und Prefill ist der teure Teil bei der Beantwortung eines langen Prompts.

Hier ist die Falle. Um ein großes Modell schnell zu bedienen, betreibst du mehrere Kopien davon parallel auf einem Server, eine pro GPU, jede in ihrem eigenen Prozess. Im herkömmlichen Aufbau hält jeder dieser datenparallelen Ranks seinen eigenen privaten KV Cache. Die Caches reden nie miteinander.

LMCaches eigener Benchmark macht die Kosten greifbar. Qwen3-235B-A22B lief über acht H100-GPUs. Jeder Rank bekam 50 GB CPU-Speicher für das KV-Cache-Offloading, sodass der Server insgesamt 400 GB vorhielt. Auf dem Papier ist das ein großer Cache. In der Praxis waren es acht isolierte 50-GB-Caches, nicht ein gemeinsamer 400-GB-Cache.

Stell dir nun eine echte Multi-Turn-Konversation vor. Zug eins wird an Rank 3 geroutet, der den Kontext berechnet und cached. Zug zwei derselben Konversation wird an Rank 6 geroutet. Rank 6 kann nicht sehen, was Rank 3 gecached hat. Der genaue Zustand, den er braucht, liegt im Host-Speicher auf demselben physischen Server, gehört aber einem anderen Prozess, also tut das Modell das Einzige, was es kann: Es prefillt die ganze Konversation erneut von Grund auf. Für diese Berechnung hast du schon einmal bezahlt. Du zahlst erneut dafür, bei jedem Zug, der auf einem anderen Rank landet.

Was LMCache änderte: ein Cache statt acht

LMCache ist eine quelloffene, Apache-2.0-lizenzierte KV-Cache-Schicht für Inferenz-Engines wie vLLM und SGLang. Ihre Aufgabe ist es, den KV Cache aus dem knappen GPU-Speicher in eine gestufte Hierarchie aus CPU-Speicher, lokaler Disk und Remote-Stores zu verlagern und den Cache über Requests, Sessions und Engine-Instanzen hinweg wiederverwendbar zu machen.

Die Änderung, die die 14-fache Zahl hervorbrachte, ist architektonisch, nicht algorithmisch. Im herkömmlichen In-Process-Aufbau ist in jeden Serving-Prozess eine eigene Cache-Bibliothek eingebettet, weshalb die Caches isoliert sind. LMCaches Multi-Process-Modus zieht den Cache aus den einzelnen Prozessen heraus und betreibt ihn als einen eigenständigen Dienst. Jeder Serving-Prozess auf dem Knoten registriert sich bei ihm und liest aus demselben host-seitigen Pool.

So sind dieselben 400 GB nicht länger acht abgeschottete Eimer, sondern werden zu einer gemeinsamen Schicht. Wenn Zug zwei auf Rank 6 landet, fragt Rank 6 den gemeinsamen Cache, findet den Zustand, den Rank 3 bereits berechnet hat, und überspringt den Prefill. Das Modell, die Hardware und die gesamte Cache-Kapazität sind alle identisch. Die Berechnung wird einfach nicht mehr weggeworfen.

Die Benchmark-Zahlen

Diese Zahlen stammen aus LMCaches veröffentlichtem Multi-Turn-Konversations-Benchmark auf Qwen3-235B-A22B-Instruct-2507-FP8, ausgeführt auf acht NVIDIA H100 80GB GPUs mit vLLM 0.18.1 und LMCache 0.4.3-dev. Sie vergleichen das herkömmliche In-Process-Offload mit dem Multi-Process-Modus. Es sind vom Autor berichtete Ergebnisse auf einer Hardware und einem Workload; behandle sie als starkes Richtungssignal, nicht als Garantie für deinen Traffic.

Lies die Form, nicht nur die Schlagzeile. Der Gewinn ist dort am größten, wo die isolierten Caches am meisten wehtun: kalte Züge, die sonst eine lange Historie neu prefillen müssten. Dass die mittlere TTFT von etwa vier Sekunden auf unter eine Drittelsekunde fällt, ist der Unterschied zwischen einem Chat, der sich träge anfühlt, und einem, der sich sofort anfühlt. Die P99-Verbesserung zählt für ein Produkt sogar noch mehr, denn der Tail ist das, was deine langsamsten Nutzer tatsächlich erleben.

Warum das wichtig ist, selbst wenn du LMCache nie anfasst

Der Punkt ist nicht, dass du eine bestimmte Bibliothek installieren sollst. Der Punkt ist, wo die Verschwendung versteckt war. Der Server hatte die Arbeit bereits erledigt. Er hatte den Speicher, um das Ergebnis zu behalten. Er warf das Ergebnis weg, weil der Cache pro Prozess partitioniert war statt pro Knoten geteilt.

Dieses Muster taucht überall in selbst gehosteter Inferenz auf: Berechnungen, für die schon bezahlt wurde, verworfen wegen der Art, wie das System zusammengebaut wurde, und nicht wegen dessen, wie viel Hardware es hat. Bevor jemand eine größere GPU-Bestellung genehmigt, ist die günstigere Frage, ob die aktuellen Maschinen Antworten neu berechnen, die sie schon halten. Kapazität zu kaufen ist der teure Weg, ein Problem zu lösen, das Wiederverwendung oft gratis löst. Dasselbe Argument über Ausgaben machen wir in unserem Guide zum Senken von LLM-Token-Kosten, und über Hardware in der Break-even-Analyse lokale Modelle gegenüber APIs.

Wo ein gemeinsamer KV Cache hilft und wo nicht

Cache-Wiederverwendung zahlt sich in direktem Verhältnis dazu aus, wie stark sich deine Requests überschneiden. Es ist ein Hebel, kein Gesetz, also sei ehrlich über deinen eigenen Traffic, bevor du ein 14x erwartest.

Einen Cache zu teilen ist auch nicht gratis. Ein eigenständiger Cache-Dienst fügt einen Netzwerk-Hop hinzu, ein bewegliches Teil, das betrieben und überwacht werden muss, und ein Lookup, das bei einem Miss etwas Latenz kostet. Wenn sich Requests kaum überschneiden, kann dieser Overhead den eingesparten Prefill überwiegen. Die Architektur ist ein starker Standard für konversationelles und Long-Context-Serving, kein universelles Upgrade.

Senkt das wirklich deine Inferenzrechnung?

Schneller ist nicht dasselbe wie günstiger. Ein Latenzgewinn wird nur dann zum Kostengewinn, wenn er etwas von der Rechnung entfernt oder dir erlaubt, mehr aus derselben Maschine zu bedienen. Bepreise die Änderung gegen das, was du tatsächlich betreibst:

monatlicher Nutzen = eingesparte GPU-Stunden für erneutes Prefilling + höherer Durchsatz pro vorhandener GPU + aufgeschobener Hardwarekauf - Overhead des Cache-Dienstes und Betriebszeit

Wiederverwendeter Prefill gibt GPU-Zeit frei, und freigewordene GPU-Zeit ist entweder ein kleinerer Cluster oder mehr Traffic, der auf dem aktuellen bedient wird. Der klare Gewinn ist das Überschreiten einer Schwelle: ein Latenzziel, das du nun ohne zusätzlichen Knoten erreichen kannst, ein Nebenläufigkeitsniveau, das dieselben GPUs nun aushalten, oder ein geplantes Hardware-Upgrade, das du aufschieben kannst. Wenn sich deine Requests selten überschneiden, ist die ehrliche Antwort, dass die Einsparung klein ist und dein Aufwand anderswo besser aufgehoben ist. Für das vollständige Kaufen-gegen-Mieten-Bild, in das dies einfließt, arbeite dich durch was das Selbst-Hosten von LLMs in der EU wirklich kostet.

Eine kurze Bewertung, bevor du dein Serving umverdrahtest

1. Miss deine Wiederverwendung. Bevor du die Architektur anfasst, protokolliere, wie oft Requests ein Präfix teilen oder eine Konversation fortsetzen. Die Überschneidung ist die gesamte Größe des Preises; wenn sie gering ist, hör hier auf.
2. Bilde eine Baseline für den Tail, nicht nur den Mittelwert. Erfasse P50 und P99 TTFT und Decoding-Geschwindigkeit auf deinem echten Traffic. Die größten Gewinne des Benchmarks lagen im Tail, und der Tail ist das, was Nutzer spüren.
3. Bestätige, dass die Topologie passt. Das 14x kam vom Vereinen mehrerer datenparalleler Ranks auf einem Knoten. Wenn du heute einen Prozess pro GPU betreibst, hast du die Fragmentierung, die das behebt; wenn du einen einzelnen Prozess betreibst, nicht.
4. Pilotiere auf einem Shadow oder einem Ausschnitt. Route eine Kopie oder einen Bruchteil des Traffics durch den Shared-Cache-Aufbau und vergleiche mit der Baseline auf derselben Hardware und demselben Workload.
5. Bepreise es, miss nicht nur die Zeit. Wandle die gemessene Latenz- und Durchsatzänderung in GPU-Stunden, Knotenzahlen oder aufgeschobene Käufe um, abzüglich der Kosten für den Betrieb des Cache-Dienstes.

Fragen, die du dir stellen solltest, bevor du es einführst

• Welcher Anteil unserer Requests teilt tatsächlich ein Präfix oder setzt eine bestehende Konversation fort?
• Betreiben wir mehrere datenparallele Ranks pro Knoten, sodass isolierte Caches für uns überhaupt ein Problem sind?
• Wie sehen unsere aktuellen P50- und P99-TTFT- und Decoding-Zahlen auf Produktions-Traffic aus, nicht auf einem Benchmark?
• Was kostet uns der eigenständige Cache-Dienst an Latenz bei einem Miss, an operativer Angriffsfläche und an Failure-Modi?
• Wandelt sich der Latenzgewinn in weniger GPUs, mehr Durchsatz oder einen aufgeschobenen Kauf um, und um wie viel?
• Wie ist der Reifegrad, die Lizenz und der Wartungszustand der Cache-Schicht, und können wir sie bei Bedarf betreiben oder forken?

Quellen und Grenzen der Aussagen

Die Architektur, das 400-GB-Fragmentierungsbeispiel und alle Benchmark-Zahlen stammen aus LMCaches Beitrag "LMCache's New Architecture Boosts MoE Inference Performance by 10x" sowie dem GitHub-Repository und der Dokumentation des Projekts. Die berichteten Latenz- und Durchsatzzahlen gehören ihren Autoren und ihrem Testsystem, einem 8x-H100-Server mit vLLM 0.18.1 und LMCache 0.4.3-dev auf Qwen3-235B-A22B; Wavect hat sie nicht reproduziert. Die Fakten wurden am 23. Juli 2026 geprüft.