LMCache meldete mit einem gemeinsamen KV Cache eine 13,7-fach niedrigere mittlere TTFT

Die Kurzfassung: LMCache meldete in einem Multi-Turn-Benchmark auf einem großen Mixture-of-Experts-Modell, dass die mittlere Time-to-first-token (TTFT) von 3,98 Sekunden auf 0,29 Sekunden fiel. Das entspricht einem Verhältnis von 13,7 zu 1. Modell, acht H100-GPUs und die gesamte host-seitige Cache-Kapazität von 400 GB blieben gleich, während acht isolierte Pools pro Rank durch einen gemeinsamen Pool ersetzt wurden.

Das ist ein nützliches Architekturergebnis, kein allgemeines Versprechen einer 13,7-fachen Verbesserung. Workload, Softwareversionen, Request-Routing, Cache-Treffer und Systemkonfiguration stammen vom LMCache-Team; Wavect hat den Test nicht reproduziert. Dieser Artikel erklärt den berichteten Mechanismus, die Grenzen der Aussage und welche Belege du brauchst, um den Nutzen für dein eigenes LLM-Serving zu prüfen.

Das Benchmark-Problem: Jeder Rank hatte einen isolierten Cache

Bei autoregressiver Inferenz speichert ein KV Cache die Zwischenergebnisse der Attention für bereits verarbeitete Tokens. Wenn ein späterer Request ein wiederverwendbares, exaktes Präfix besitzt und der Serving-Stack auf kompatible Cache-Blöcke zugreifen kann, lässt sich ein Teil des Prompt-Prefills vermeiden. Der Nutzen hängt unter anderem von Prompt-Länge, Modell, Hardware, Batching, Trefferrate, Transferpfad und Nebenläufigkeit ab.

Hier ist die Falle. Im Benchmark nutzte vLLM acht datenparallele Ranks mit automatischer Expert Parallelism: Die Attention wurde über die GPUs repliziert, während die Mixture-of-Experts-Layer verteilt waren. Jeder Rank lief in einem eigenen Prozess und hielt einen privaten KV Cache. Die Caches redeten nicht 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.

Betrachte einen späteren Zug, dessen exakt wiederverwendbares Präfix von Rank 3 gecached wurde, der aber an Rank 6 geroutet wird. In der isolierten Benchmark-Konfiguration konnte Rank 6 nicht auf den host-seitigen Cache von Rank 3 zugreifen. Über diesen Pfad ließ sich das Präfix daher nicht wiederverwenden, und die entsprechende Prefill-Arbeit musste erneut erfolgen.

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 hinter dem gemeldeten Verhältnis von 13,7 zu 1 bei der mittleren TTFT ist architektonisch, nicht algorithmisch. Im herkömmlichen In-Process-Aufbau war in jeden Serving-Prozess eine eigene Cache-Bibliothek eingebettet, sodass die host-seitigen Pools isoliert blieben. LMCaches Multi-Process-Modus verlagerte die Cache-Verwaltung in einen eigenständigen Dienst, der die Serving-Prozesse mit einem gemeinsamen host-seitigen Pool verband.

Damit wurden aus acht lokalen 50-GB-Pools bei gleicher Gesamtkapazität von 400 GB eine gemeinsame Schicht. Bei einem kompatiblen Cache-Treffer kann ein anderer registrierter Prozess wiederverwendbare KV-Blöcke abrufen, statt den entsprechenden Prefill zu wiederholen. Modell und GPU-Hardware blieben gleich; geändert wurden die Cache-Architektur und die zugehörige Serving-Konfiguration.

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. Verglichen wurden In-Process-Offload und Multi-Process-Modus bei angegebenen zwei Requests pro Sekunde über 120 Sekunden. Es sind Projektautoren-Ergebnisse für ein System und einen Workload, kein unabhängiger Benchmark und keine Garantie für deinen Traffic.

Lies die Form und die Grenzen, nicht nur die Schlagzeile. Der veröffentlichte Workload war auf Multi-Turn-Präfixwiederverwendung ausgelegt und traf damit genau das Fragmentierungsproblem. Mittlere und P99-TTFT verbesserten sich in diesem Test. Auch die gemeldete Decoding-Geschwindigkeit änderte sich, doch der Beitrag liefert nicht genügend unabhängige Wiederholungen, Unsicherheitsanalyse, Rohdaten oder alternative Workloads, um die Verhältnisse zu verallgemeinern.

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.

Ähnliche Verschwendung kann bei selbst gehosteter Inferenz entstehen, wenn wiederverwendbare Berechnung über Prozess- oder Knotengrenzen nicht erreichbar ist. Miss vor einem Kapazitätskauf wiederholte Präfixe, Cache-Treffer, Prefill-Zeit, GPU-Auslastung und Routing. Wiederverwendung ist nicht kostenlos: Sie verursacht Speicher-, Transfer-, Lookup-, Koordinations-, Isolations-, Korrektheits- und Betriebskosten. Dieselbe Vollkostenlogik verwenden wir in unserem Guide zum Senken von LLM-Token-Kosten und in der Break-even-Analyse lokale Modelle gegenüber APIs.

Wenn du Wiederverwendung bereits ausgereizt hast und ein Modell einen stabilen, latenzkritischen Workload bedient, wird Spezialisierung zur nächsten Frage. Unser Check des fest verdrahteten Taalas-HC1-LLM-ASIC zeigt, was 17.000 Token/s belegen und was du vor dem Tausch von Modellflexibilität gegen Geschwindigkeit prüfen musst.

Wo ein gemeinsamer KV Cache hilft und wo nicht

Überschneidungen zwischen Requests schaffen eine Chance für Cache-Wiederverwendung, bestimmen das Ergebnis aber nicht allein. Kompatible Präfixe, Routing, Eviction, Transferkosten, Cache-Kapazität, Nebenläufigkeit und die Baseline-Implementierung beeinflussen den gemessenen Nutzen.

Ein eigenständiger Cache-Dienst ergänzt einen Pfad zur Koordination zwischen Prozessen, eine weitere abzusichernde und zu überwachende Komponente, Kapazitäts- und Eviction-Entscheidungen sowie Lookup- oder Transferarbeit bei Treffern und Fehlschlägen. Bei wenig kompatibler Wiederverwendung oder teurem Transfer kann der Overhead den eingesparten Prefill überwiegen. Behandle Shared Caching als workloadabhängige Option, nicht als Standard für jeden konversationellen oder Long-Context-Dienst.

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:

geschätzter monatlicher Nutzen = vermiedene Compute- und Kapazitätskosten - Kosten für Cache-Infrastruktur, Transfer, Engineering, Sicherheit und Betrieb

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 Verhältnis von 13,7 zu 1 bei der mittleren TTFT entstand durch das Vereinen von acht datenparallelen Rank-Caches auf einem Knoten. Prüfe vor einer Übertragung, ob Routing und Cache-Architektur dieselbe Fragmentierung erzeugen.
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 die Benchmark-Zahlen stammen aus LMCaches Multi-Process-Benchmark-Beitrag, dem GitHub-Repository und der Dokumentation des Projekts. Die gemeldeten Latenz- und Durchsatzzahlen gehören den Projektautoren 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 2. September 2026 erneut geprüft.