TensorCast soll das Management von KI-Tensoren vereinheitlichen

TensorCast ist eine vorgeschlagene „Tensor-as-a-Service“-Schicht (TaaS): ein verteiltes, programmierbares System, das sich um die Identität, Platzierung, Übertragung, Umwandlung, gemeinsame Nutzung und Bereitstellung von Tensorzuständen kümmert – und zwar unabhängig von der Berechnung, die diese Zustände erzeugt oder verwendet. 1

Der architektonische Ansatz soll bislang getrennt entwickelte Systeme für Modellgewichte, KV-Cache, Netzwerkübertragungen und Speicher-Backends unter einer gemeinsamen Steuerebene zusammenführen. Das ist vor allem für dynamische KI-Dienste interessant, bei denen sich Daten laufend zwischen GPUs, Rechnerknoten und Speicherebenen bewegen.

Warum TensorCast entwickelt wurde

Große Sprachmodelle verwalten längst nicht mehr nur statische Modellgewichte. Auch der KV-Cache – ein Zwischenspeicher für bereits verarbeitete Aufmerksamkeitszustände – sowie Aktivierungen und andere Zwischenzustände müssen verteilt gespeichert, verschoben und wieder bereitgestellt werden. In herkömmlichen Systemen liegen diese Aufgaben häufig in verschiedenen Inferenz-Engines, Routern, Scheduler-Komponenten, Netzwerkpfaden und Speicherdiensten. 1

Das führt zu sogenannten vertikalen Einzellösungen: Eine Optimierung für den KV-Cache muss etwa in der Cache-Implementierung, im Request-Routing und in der Inferenz-Engine berücksichtigt werden. Neue, komponentenübergreifende Strategien lassen sich dadurch nur schwer entwickeln und warten.

TensorCast behandelt das Management des Tensor-Lebenszyklus deshalb als eigene fehlende Systemschicht. Eine Anwendung beschreibt, was mit einem Tensor geschehen soll; die Laufzeitumgebung entscheidet anschließend, wo er platziert, wie er übertragen oder transformiert und wann er materialisiert wird. 1

Im Unterschied zu einem klassischen Objektspeicher betrachtet TensorCast Tensoren nicht bloß als undurchsichtige Datenblöcke. Und anders als compute-zentrierte Frameworks plant es nicht primär Aufgaben, sondern den Lebenszyklus des Tensorzustands.

Die wichtigsten Bausteine

• Tensoren als eigenständige Objekte: Jeder Tensor erhält eine eindeutige Identität sowie Angaben zu Besitz, Speicherort und Lebenszyklus. Eine Engine kann so auf Modellgewichte, KV-Cache-Blöcke oder Zwischenzustände verweisen, ohne deren konkreten Aufenthaltsort oder Speicherformat fest einzubauen. 1
• Kombinierbare Lebenszyklus-Operationen: Entwickler können Bausteine für Übertragung, Transformation, Vorabruf, Replikation und Materialisierung zu einer workload-spezifischen Richtlinie kombinieren. Für jede neue Optimierung muss die zugrunde liegende Infrastruktur nicht von Grund auf angepasst werden. 1
• Trennung von Richtlinie und Mechanismus: Die gewünschte Strategie wird über TensorCast-APIs formuliert. Die Laufzeit übernimmt anschließend verteilte Ausführung und Datenbewegung, ohne dass die eigentliche Ausführungs-Engine geändert werden muss. 1
• Getrennte Steuer- und Datenebene: Der Global Store (GS) verwaltet Metadaten wie den Zustand von Knoten und Workern, Tensorstandorte, Besitzverhältnisse und Scheduling-Informationen. Die Worker übertragen die eigentlichen Daten. Der Global Store koordiniert also, statt selbst zum Transportkanal für alle Tensorinhalte und damit zum Flaschenhals zu werden. 1
• Unterschiedliche Strategien für Metadaten: Relativ statische Objekte mit geringer Anzahl, etwa Modellgewichte, können zentral im Global Store erfasst werden. Umfangreiche und dynamische Zustände wie KV-Cache werden dagegen fragmentiert. Ein zuständiger Worker verwaltet dabei Besitz und Konsistenz mithilfe von Leases und Fencing-Tokens. 1
• Effiziente Materialisierung: Replikate auf Workern können GPU-Speicher über CUDA IPC und CPU-Speicher über lokale memfd-Handles bereitstellen. Für entfernte Quellen unterstützt TensorCast direkte RDMA-Schreibvorgänge. So lassen sich unnötige Kopien vermeiden und direkte GPU-zu-GPU- oder lokale Freigabepfade nutzen, sofern die Hardware dies erlaubt. 6

Warum der Umzug eines KV-Cache einfacher werden soll

Bei einem mehrstufigen Dialog kann eine Sitzung wegen ungleichmäßiger Auslastung von einer Inferenzinstanz auf eine andere verschoben werden müssen. In einem herkömmlichen Stack betrifft das meist gleichzeitig den Request-Router, die KV-Cache-Logik der Inferenz-Engine sowie das Cache- oder Netzwerk-Backend.

Mit TensorCast kann eine Richtlinie stattdessen die Tensorobjekte identifizieren, die zum KV-Cache der Sitzung gehören, ihre Platzierung beziehungsweise Materialisierung beim Ziel-Worker anfordern und künftige Anfragen dorthin weiterleiten. Die Laufzeit übernimmt Suche, Übertragung und Speicherbindung. 1

Das bedeutet nicht, dass die Migration kostenlos oder ohne Datenübertragung wäre. Der Vorteil liegt vielmehr darin, dass die Strategie einmal auf der Ebene des Tensor-Lebenszyklus formuliert wird, anstatt sie in mehreren eng gekoppelten Komponenten separat nachzubauen. Dadurch werden Richtlinien auf Basis von Cache-Lokalität, wiederverwendeten Gewichten oder der gemeinsamen Platzierung zusammengehöriger Zustände leichter prototypisierbar und einsetzbar. 1

Was die Experimente zeigen

Die Autoren integrierten TensorCast sowohl in vLLM als auch in SGLang. Untersucht wurden unter anderem die Materialisierung und Synchronisierung von Modellgewichten, die Verwaltung des KV-Cache sowie programmierbares Request-Routing. 1

Den Angaben der Studie zufolge erreicht TensorCast beim KV-Cache eine Leistung, die mit Mooncake, einem spezialisierten KV-Cache-System, vergleichbar ist. Gleichzeitig soll TensorCast flexibler bleiben, wenn eine Richtlinie mehrere Komponenten eines KI-Systems gleichzeitig einbeziehen muss. 1

Für den Start einer Instanz von Qwen3-235B-A22B – eines Modells mit insgesamt 235 Milliarden Parametern, von denen 22 Milliarden aktiviert werden – berichten die Autoren von einem bis zu 228,6-mal schnelleren Start als bei gängigen verteilten Dateisystemen. 12

In Szenarien mit hoher Parallelität und mehrstufigen Agenten-Dialogen soll eine programmierbare TensorCast-Richtlinie die mediane Time-to-First-Token (TTFT), also die Zeit bis zum ersten ausgegebenen Token, um bis zu 93,2 Prozent reduziert haben. 1

Einordnung

TensorCast zielt damit auf eine Infrastruktur, in der Modellzustände nicht länger an einzelne Frameworks oder Back-Ends gebunden sind. Schneller Modellstart, cache-bewusstes Routing, die Migration laufender Sitzungen und die Wiederverwendung bereits geladener Tensoren könnten als programmierbare Systemrichtlinien umgesetzt werden – statt jeweils als isolierte Optimierung in einem bestimmten Framework.

Die Zahlen stammen allerdings aus den von den Autoren berichteten Experimenten eines Forschungs-Preprints. Unabhängige Reproduktionen und Tests unter Produktionsbedingungen stehen daher noch aus. TensorCast ist vor allem als architektonischer Vorschlag bedeutsam: Es versucht, das Management von Tensorzuständen zu einer eigenständigen, gemeinsam nutzbaren Infrastrukturaufgabe zu machen. 1