Tensormesh startet Plattform, um Inferenzkosten für LLMs durch Wiederverwendung des KV-Caches zu senken

Jedes Mal, wenn ein KI-Assistent ein umfangreiches Dokument erhält, muss er dessen Inhalt verarbeiten, bevor er mit der Beantwortung beginnen kann. Tauchen dieselben Dokumente, Anweisungen oder Gesprächsverläufe erneut auf, muss ein Großteil dieser Verarbeitung möglicherweise wiederholt werden. Im Unternehmensmaßstab kann diese Wiederholung teure GPU-Kapazitäten beanspruchen, ohne zusätzliche nutzbringende Arbeit zu leisten.

Tensormesh geht dieses Problem mit der Tensormesh Platform an, die am 14. Oktober 2026 angekündigt wurde. Das Unternehmen, dessen Team das Open-Source-Projekt LMCache entwickelt hat, führt eine Verwaltungsebene für Unternehmen ein, die das Schlüssel-Wert-Caching (KV-Caching) in Organisationen unterstützt, die große Sprachmodelle auf ihrer eigenen Infrastruktur betreiben.

Die Plattform verwaltet wiederverwendbare Inferenzzustände im GPU-Speicher, im CPU-Speicher und auf Speichermedien. Der angestrebte Nutzen ist klar: Der Umfang der Prompt-Verarbeitung, die eine GPU-Flotte wiederholen muss, soll sinken. Gleichzeitig erhalten Betreiber Kontrollmöglichkeiten darüber, wie dieser zwischengespeicherte Zustand aufbewahrt, gemeinsam genutzt und überwacht wird.

Warum der KV-Cache wichtig ist

Die Inferenz von LLMs umfasst zwei wichtige Phasen. Beim Vorverarbeiten verarbeitet das Modell den Eingabe-Prompt. Beim Dekodieren erzeugt es die Antwort Token für Token. Der KV-Cache speichert Zwischenzustände im Zusammenhang mit der Attention, auf die das Modell zurückgreifen kann, um bereits verarbeitete Tokens erneut zu berücksichtigen, ohne alles von Grund auf neu berechnen zu müssen.

Die Wiederverwendung dieses Zustands über mehrere Anfragen hinweg kann den Aufwand für die Vorverarbeitung verringern, wenn sich der Eingabekontext wiederholt. Ein Support-Assistent kann beispielsweise bei Hunderten unterschiedlicher Fragen dasselbe Produkthandbuch heranziehen. Ein Agent kann bei wechselnden Aufgaben immer wieder dieselben Anweisungen oder Werkzeuge einbeziehen.

Das unterscheidet sich vom Zwischenspeichern einer fertigen Antwort. Das System kann die mit dem gemeinsamen Kontext verbundene Berechnung wiederverwenden und trotzdem auf eine neue Frage eine neue Antwort erzeugen.

Die Dokumentation zum automatischen Prefix-Caching von vLLM beschreibt diesen Vorteil bei wiederholten Dokumentabfragen und mehrteiligen Gesprächen. Sie macht zugleich eine wichtige Einschränkung deutlich: Prefix-Caching beschleunigt die Verarbeitung des Prompts, nicht die Erzeugung neuer Ausgabe-Tokens. Bei Workloads, die von langen Antworten oder weitgehend einzigartigen Eingaben geprägt sind, kann der Nutzen geringer ausfallen.

Für Unternehmenskunden lautet die entscheidende Frage, welcher Anteil ihrer tatsächlichen Workloads wiederverwendbaren Kontext enthält – und ob sich dieser Kontext schneller und kostengünstiger abrufen lässt, als ihn neu zu berechnen.

Vom Cache zur verwalteten Infrastruktur

In der Ankündigung nennt Tensormesh fünf betriebliche Schwerpunkte: Sicherheit, Beobachtbarkeit, Ausfallsicherheit, Richtlinienverwaltung und Mandantenfähigkeit. Sie betreffen die praktischen Aufgaben, zwischengespeicherte Daten zu schützen, die Leistung zu verfolgen, Ausfälle zu beheben, Aufbewahrung und Verdrängung zu steuern sowie Teams oder Kunden auf einer gemeinsam genutzten Infrastruktur voneinander zu trennen.

Das Unternehmen beschreibt außerdem Controller-APIs, mit denen sich Cache-Einträge fixieren, lokalisieren, verschieben, komprimieren und löschen lassen. Damit wird die Verwaltung des Cache-Lebenszyklus ausdrücklich zu einer betrieblichen Aufgabe, statt sie vollständig den einzelnen Inferenzprozessen zu überlassen.

Das zugrunde liegende LMCache-Projekt trennt die Cache-Verwaltung von der Serving-Engine und unterstützt das Auslagern und Abrufen über mehrere Speicherstufen hinweg. Die Dokumentation beschreibt die Wiederverwendung über Anfragen, Sitzungen und Engine-Instanzen hinweg sowie austauschbare Speicher- und Transport-Backends.

Die Unternehmensplattform baut auf dieser Grundlage auf. Laut ihrem Installationsleitfaden verwaltet ein Kubernetes-Operator die Komponenten der Cache-Engine: Cache-Server laufen auf GPU-Knoten, während ein Koordinator die Koordination auf Flottenebene übernimmt. Helm dient der Bereitstellung; eine Weboberfläche und Kommandozeilenwerkzeuge unterstützen den Betrieb.

Diese Architektur ist wichtig, weil GPU-Speicher eine begrenzte Ressource ist. Würde jeder möglicherweise wiederverwendbare Prompt dort aufbewahrt, stünde er in Konkurrenz zu anderen Inferenzanforderungen. Werden weniger unmittelbar benötigte Zustände in den Hauptspeicher des Hosts oder auf Speichermedien ausgelagert, lässt sich eine größere Menge davon aufbewahren – allerdings verursacht der Abruf zusätzliche Bandbreiten- und Latenzkosten.

Über identische Prompt-Präfixe hinaus

Prefix-Caching funktioniert gut, wenn zwei Prompts mit denselben Tokens beginnen. Bei der Retrieval-Augmented Generation (RAG) kann es schwieriger sein: Eine Anwendung ruft relevante Dokumente ab, doch diese können in unterschiedlicher Reihenfolge oder nach jeweils anderem vorangestelltem Text erscheinen.

Betrachten wir zwei hypothetische Anfragen, die dieselben Dokumente verwenden. Die eine enthält Dokument A, gefolgt von B; die andere enthält B, gefolgt von A. Beide umfassen wiederverwendbares Material, doch ihr gemeinsamer Anfang kann kurz sein.

Tensormesh nutzt CacheBlend, um die Wiederverwendung über den Anfang eines Prompts hinaus auszuweiten. Die LMCache-Dokumentation erläutert, dass dabei ein Teil der Tokens gezielt neu berechnet und zugleich auf zwischengespeicherte Blöcke zurückgegriffen wird. Die Neuberechnung ist wichtig, weil der umgebende Kontext eines Blocks den internen Zustand des Modells beeinflussen kann.

Das auf der EuroSys 2025 vorgestellte Forschungspapier zu CacheBlend berichtet für die untersuchten Workloads von einer um den Faktor 2,2 bis 3,3 kürzeren Zeit bis zum ersten Token und einem 2,8- bis 5-mal höheren Durchsatz gegenüber einer vollständigen Neuberechnung des KV-Caches. Die Autoren untersuchten drei Open-Source-Modelle und vier Benchmark-Datensätze.

Das sind Forschungsergebnisse unter bestimmten Bedingungen, keine garantierte Einsparung bei jeder Tensormesh-Bereitstellung. Sie zeigen jedoch, warum die Wiederverwendung über ein gemeinsam genutztes Präfix hinaus technisch interessant ist: So lässt sich nützliche Rechenarbeit einsparen, die beim herkömmlichen Präfixabgleich unberücksichtigt bliebe.

Knotenübergreifende Wiederverwendung und die Bedeutung versionsspezifischer Unterstützung

Die Einführungsankündigung beschreibt Peer-to-Peer-Übertragungen von KV-Zuständen, bei denen ein Knoten zwischengespeicherte Zustände von einem anderen abrufen kann. In den Produktmaterialien des Unternehmens wird außerdem die Entkopplung von Prefill und Decode beschrieben. Dabei wird die Verarbeitung der Eingabeaufforderung von der Generierung der Ausgabe getrennt, sodass die beiden Phasen auf unterschiedlichen Workern laufen können.

Das sind sich ergänzende Möglichkeiten, die Inferenz zu organisieren. Durch das Teilen kompatibler Zustände lässt sich vermeiden, sie auf einem anderen Knoten erneut zu berechnen. Durch die Trennung der Phasen können Infrastrukturteams die Ressourcen je nach deren Verarbeitungsanforderungen unterschiedlich zuweisen.

Allerdings stimmen die öffentlichen Materialien hinsichtlich des Veröffentlichungsstatus nicht vollständig überein. Die Einführungsübersicht beschreibt das Teilen von Zuständen über mehrere Knoten hinweg und die Entkopplung, während die versionsspezifische Kompatibilitätsmatrix vom 17. September Peer-to-Peer-Übertragungen und die Entkopplung auf ihrer Roadmap aufführt. Die Feature-Dokumentation enthält außerdem Vorschauseiten.

Dieselbe Matrix unterscheidet zwischen Funktionen, die in den Tests von Tensormesh verifiziert wurden, und solchen, die zwar vorgelagert unterstützt werden, vor einem Einsatz in der Produktion aber weitere Tests erfordern. Sie führt vLLM und NVIDIA Dynamo als verifizierte Inferenz-Engines auf; SGLang und TensorRT-LLM stehen auf der Roadmap.

Die weit gefassten Kompatibilitätsaussagen zur Veröffentlichung beschreiben somit eine Designrichtung und belegen nicht, dass jede Kombination aus Modell und Infrastruktur validiert wurde. Teams sollten die konkrete Version, Inferenz-Engine, das Modell und den Cache-Modus überprüfen, die sie einsetzen möchten.

In der Einführungsübersicht wird ausdrücklich vLLM auf Kubernetes mit NVIDIA- oder unterstützten AMD-Instinct-GPUs über ROCm sowie dateisystemgestützter Speicher beschrieben. Nicht präfixbasiertes Caching für dichte Modelle und die Unterstützung von SGLang werden als geplant bezeichnet. Außerdem wird klargestellt, dass der Cache parallel zu selbst gehosteten Modellen läuft und kein Zusatzmodul ist, das sich an eine beliebige API für gehostete Modelle anbinden lässt.

Wo sich der Einsatz wirtschaftlich lohnen könnte

Am ehesten eignen sich Anwendungen, die wiederholt umfangreichen gemeinsamen Kontext verarbeiten: interne Wissensassistenten, Dienste zur Dokumentenanalyse und Agenten, die immer wieder auf einen stabilen Bestand an Anweisungen oder Referenzmaterial zurückgreifen.

Eine aussagekräftige Bewertung würde das Verhalten bei kaltem und warmem Cache anhand repräsentativer Anfragen vergleichen. Betreiber sollten die Zeit bis zum ersten Token, den Durchsatz, die Cache-Abrufzeit, die GPU-Auslastung sowie die Arbeitsspeicher-, Speicherplatz- und Netzwerkkosten für die Aufbewahrung der Zustände messen.

Die Cache-Trefferquote allein reicht nicht aus. Eine hohe Trefferquote ist nur dann hilfreich, wenn die eingesparte Rechenarbeit nach Abzug des Aufwands für Übertragung und Verwaltung einen Nettovorteil bringt. Ebenso bedeutet ein schnelleres erstes Token nicht zwangsläufig, dass die gesamte Antwort proportional schneller fertiggestellt wird.

Auch die Antwortqualität sollte gesondert überprüft werden, insbesondere wenn zwischengespeicherte Abschnitte in veränderten Kontexten zusammengeführt werden. Die selektive Neuberechnung von CacheBlend soll dieses Problem angehen; Tests in der Produktion sollten jedoch die eigenen Dokumente, Eingabeaufforderungsformate und Modellkonfigurationen des Unternehmens berücksichtigen.

Aufbewahrungsdauer und Mandantentrennung gewinnen ebenfalls an Bedeutung, wenn der Cache über einen einzelnen Prozess hinausgeht. Zu den relevanten betrieblichen Fragen gehört, wer einen Eintrag wiederverwenden darf, wie lange er verfügbar bleibt und wie sich Richtlinienänderungen oder Löschanfragen auf gespeicherte Zustände auswirken. Die von Tensormesh angekündigten Verwaltungsfunktionen sollen dafür sorgen, dass sich diese Entscheidungen steuern lassen.

Ein pragmatischer Ansatz, um wiederholte Arbeit zu vermeiden

Laut der Ankündigung des Unternehmens ist Tensormesh Platform seit dem Start verfügbar. Die Bedeutung der Plattform liegt darin, Inferenzzustände als eine über eine ganze Flotte hinweg verwaltbare Ressource zu behandeln und wiederverwendbare Rechenarbeit über die unmittelbare Lebensdauer einer Anfrage hinaus aufzubewahren.

Für Unternehmen, die ihre eigene LLM-Infrastruktur betreiben, bietet dies einen konkreten Hebel zur Effizienzsteigerung: Mehr von der bereits geleisteten Arbeit zur Verarbeitung von Eingabeaufforderungen wiederverwenden. Das Ergebnis hängt davon ab, wie häufig sich Arbeitslasten wiederholen, wie kompatibel der Cache ist und welche Kosten die Datenübertragung verursacht – doch das sind messbare technische Fragen, die Teams anhand ihres eigenen Anfrageaufkommens prüfen können.