OpenLake: Rust-Speicher-Engine für KV-Cache-Offload und Checkpointing

Welches Problem OpenLake adressiert

Bei LLM-Inference mit langen Kontextfenstern dominiert der Prefill-Schritt die Latenz. Jede neue Anfrage mit demselben Systemprompt oder demselben Konversationsverlauf berechnet dieselben Key-Value-Tensoren erneut. OpenLake setzt genau dort an: Der Inference-Engine schreibt den KV-Cache einmal, OpenLake legt ihn auf Host-RAM und Disk ab und liefert ihn in Millisekunden zurück. Das README nennt als Beispiel einen 66-fachen Geschwindigkeitsvorteil bei der Time to First Token, wenn ein Cache-Treffer vorliegt, gemessen bei einem Kontextfenster von 128K. Diese Zahl stammt aus der Projektkommunikation und ist nicht unabhängig überprüft. Die Zielgruppe sind Betreiber von GPU-Clustern mit wiederkehrenden Prefixen, nicht Anwender mit kurzen, einmaligen Prompts. Daneben nennt das README drei weitere Einsatzfelder: Checkpointing für RL- und ML-Workloads, Vektorindex-Aufbau und -Serving sowie Kontextspeicher für agentische Abrufe.

Wie der KV-Offload technisch an den vLLM-Connector andockt

OpenLake ist kein Speicher, den die Anwendung direkt anspricht. Der Einstieg läuft über einen vLLM-KV-Transfer-Connector namens OpenLakeConnector, der im Python-Paket openlake_client.openlake_connector liegt. In der vLLM-Konfiguration wird er über kv_connector und kv_connector_module_path registriert, kv_role steht auf kv_both, das heißt Lesen und Schreiben laufen über denselben Connector. Die eigentliche Adressierung erfolgt über kv_connector_extra_config mit den Feldern openlake_nodes (Liste von host:port-Einträgen) und openlake_device. Der Daemon openlaked lauscht standardmäßig auf Port 9400. Im Einzelknotenbetrieb steht openlake_device auf local, im Mehrknotenbetrieb auf einem RDMA-Gerätenamen wie mlx5_ib0. Damit ist der Datenfluss klar: vLLM erzeugt die KV-Tensoren, der Connector schreibt sie in den lokalen oder entfernten openlaked, und ein späterer Prefill derselben Sequenz liest sie zurück, statt sie neu zu berechnen. Ein Prefix, der auf einem GPU-Host berechnet wurde, lässt sich laut README von jedem anderen Host aus dem gemeinsamen Pool bedienen.

Zwei Betriebsarten: lokaler KV-Pool und S3-kompatibler Objektspeicher

Das Repository beschreibt zwei Nutzungswege, die unterschiedliche Anforderungen stellen. Der erste installiert nur den Connector über pip install openlake-vllm und startet openlaked ohne Argumente. In diesem Modus bleibt der Cache auf demselben Host. Für den clusterweiten Betrieb wird openlaked mit einer TOML-Datei gestartet, im Beispiel kv_rdma.toml aus crates/openlake_server/configs/, wobei jeder Knoten eine eigene self_id erhält, etwa 0, 1, 2. Der zweite Weg baut OpenLake aus dem Quelltext und betreibt es als S3-kompatiblen Objektspeicher. Nach cargo build --release --bin openlaked wird der Daemon mit crates/openlake_server/configs/storage-tcp-local.toml gestartet, nachdem die Verzeichnisse data/d0 bis data/d3 angelegt wurden. Der Zugriff erfolgt dann über einen gewöhnlichen S3-Client mit den Zugangsdaten openlakeadmin und der Endpunkt-URL http://127.0.0.1:90. Das sind zwei Produkte in einem Repository, und wer nur den KV-Offload braucht, muss die S3-Seite nicht konfigurieren.

Was der Connector voraussetzt und wo er nicht passt

Die Installation über pip install openlake-vllm setzt eine vLLM-Version voraus, die das Feld kv_connector_module_path auswertet. Das ist ein verhältnismäßig neues Konfigurationsfeld. Wer eine ältere vLLM-Version betreibt oder eine eigene Inferenz-Engine verwendet, kann den Connector nicht ohne Anpassung nutzen. OpenLake ist damit kein engine-neutraler Speicher, sondern ein Anhängsel an vLLM. Ein zweiter Punkt ist der Daemon pro Knoten: openlaked läuft auf jedem GPU-Host, und die Kubernetes-Anleitung im Helm-Chart-Verzeichnis platziert laut README eine Instanz auf jedem ausgewählten Knoten. Das erzeugt Betriebsaufwand, den ein zentraler Objektspeicher nicht hat. Drittens ist der Nutzen an die Arbeitslast gebunden. Bei kurzen, einmaligen Prompts ohne gemeinsamen Prefix gibt es nichts wiederzuverwenden, und der Schreibaufwand für den KV-Cache fällt trotzdem an. Die Beispiele im README arbeiten mit 128K- und 256K-Kontextfenstern; das ist der Bereich, für den das Design gedacht ist.

Der Vergleich mit einem klassischen Objektspeicher

Der naheliegende Alternativweg ist ein S3-kompatibler Speicher wie MinIO oder Ceph, den man direkt als Checkpoint-Ziel oder KV-Ablage verwendet. Der Unterschied liegt nicht in der Protokollschicht, sondern in der Platzierung. Ein zentraler Objektspeicher liegt typischerweise auf separaten Storage-Knoten hinter einem Netzwerk, jede Leseoperation geht über HTTP und den Objektspeicher-Stack. OpenLake installiert seinen Daemon dagegen auf den GPU-Hosts selbst und nutzt deren Host-RAM und lokale Disk, mit RDMA als Transport im Clusterbetrieb. Das README formuliert das als Speicher, der neben den GPUs liegt, statt hinter einem Netzwerk. Der Preis dafür ist genau umgekehrt: Ein zentraler Objektspeicher skaliert unabhängig von der GPU-Flotte und überlebt den Ausfall einzelner GPU-Knoten ohne Weiteres, während OpenLake an die Lebensdauer und Erreichbarkeit dieser Knoten gebunden ist. Für Checkpointing, das einen Ausfall überstehen muss, ist das eine relevante Einschränkung, die das README nicht ausräumt.

Kompression als zusätzliche Schicht: ExANS

Seit Version 0.8 enthält OpenLake ExANS, einen verlustfreien Codec für BF16-KV-Cache. Das README nennt 1,51-fache Kosteneinsparung. Ob dieser Wert aus einem internen Benchmark stammt oder aus einem reproduzierbaren Testaufbau, geht aus dem Material nicht hervor. Technisch ist der Ansatz nachvollziehbar: KV-Cache ist der größte Einzelposten im Speicherbedarf langer Kontexte, und eine verlustfreie Kompression reduziert sowohl die Menge der zu übertragenden Bytes als auch den belegten Platz. Wer den Codec aktivieren will, findet die Konfiguration nach eigener Aussage des Projekts in den Blogbeiträgen, nicht im hier vorliegenden README-Ausschnitt. Das ist eine Lücke: Die zentrale Funktion der Version 0.8 wird im Repository-Text nur als Update-Zeile erwähnt, ohne Konfigurationsschlüssel oder Beispiel.

Lizenz, Wartung und Upgrade-Aufwand

OpenLake steht unter Apache-2.0, was kommerzielle Nutzung, Modifikation und Weitergabe erlaubt, sofern Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen kenntlich gemacht werden. Das Repository ist nicht archiviert, der letzte Push datiert auf den 6. September 2026. Die Release-Historie zeigt v0.8.0 am 12. August 2026, v0.8.1 zwei Tage später und v0.9.0 am 5. September 2026. Dieser Rhythmus deutet auf aktive Entwicklung, bedeutet aber auch, dass sich Konfigurationsformate zwischen Minor-Versionen bewegen können. Die Toolchain-Anforderung liegt bei Rust 1.91 oder neuer, was bei selbst gebauten Binaries einen aktuellen Compiler auf den Build-Rechnern voraussetzt. Für den Connector-Pfad ist die Kopplung an vLLM der eigentliche Wartungstreiber: Ändert vLLM die KV-Transfer-Schnittstelle, muss openlake-vllm nachziehen. Wer den S3-Pfad nutzt, ist davon nicht betroffen, trägt aber den Aufwand für den eigenen Build und die Verzeichnisstruktur unter data/.

MLPerf-Platzierung und was sie aussagt

Das README verweist auf eine Platzierung in MLPerf Storage v3.0 im Bereich Object Checkpointing, vor NVIDIA und Nebius. Solche Ergebnisse sind an einen konkreten Aufbau gebunden: Hardware, Client-Anzahl, Datensatz und Konfiguration sind Teil des Benchmarks. Die Platzierung belegt, dass das Projekt in einem standardisierten Prüfverfahren mithalten kann. Sie belegt nicht, dass dieselbe Leistung auf einer anderen Hardware-Kombination oder mit einem anderen Zugriffsmuster entsteht. Wer den Objektspeicher-Pfad evaluieren will, sollte deshalb den eigenen Testaufbau nachbauen, statt die veröffentlichte Zahl zu übernehmen. Die Konfigurationsdateien dafür liegen im Repository unter crates/openlake_server/configs/, und der Quickstart beschreibt den vollständigen Ablauf vom Klonen bis zum ersten aws-Befehl gegen den lokalen Endpunkt.

Redaktionelles Fazit

Sinnvoll ist OpenLake für Teams, die bereits vLLM mit langen Kontextfenstern und wiederkehrenden Prefixen betreiben und über ein RDMA-Fabric oder lokale NVMe-Ressourcen auf den GPU-Hosts verfügen. Wer keinen vLLM-Connector einsetzen will, keinen Daemon pro Knoten betreiben möchte oder dessen Arbeitslast keine wiederverwendeten Prefixe erzeugt, sollte bei einem klassischen Objektspeicher bleiben. Vor dem Rollout ist zu prüfen, ob die installierte vLLM-Version das Feld kv_connector_module_path akzeptiert, ob openlaked mit der eigenen kv_rdma.toml-Konfiguration startet und ob der Connector nach einem Neustart des Daemons tatsächlich wieder auf denselben Pool zeigt.

Offizielle Quellen

1. License: Apache-2.0
2. openlake-project/openlake on GitHub
3. Project website
4. README
5. Releases