RUSTFS GPUCACHE · G3.5 In Entwicklung
Gemeinsamer KV-Cache auf G3.5.
GPUCache bildet die gemeinsame KV-Hot-Tier G3.5. Die implementierte Datenstrecke nutzt Hostspeicher und TCP. RustFS ist die kältere G4-Objektschicht außerhalb des heißen Anfragepfads.
Rust · Apache 2.0 · CPU/TCP-Quellcode verfügbar
Problem
Wird Kontext verdrängt, muss die GPU neu rechnen.
Langer Kontext, mehrzügige Gespräche und Agents lassen den KV Cache wachsen, bis der GPU-Speicher ihn nicht mehr hält. Wird verdrängter KV wieder gebraucht, muss das Prefill erneut laufen: Die GPU rechnet Arbeit, die sie schon getan hat, und das erste Token wartet länger.
Jede vorhandene Schicht hat eine Grenze. Host-Speicher ist endlich. Eine lokale SSD des Knotens bedient eine Maschine und lässt sich kaum über Knoten hinweg teilen. Gemeinsamer Speicher ist für Dauerhaftigkeit und Kapazität gebaut und liegt nicht auf dem heißen Inferenzpfad.
Ansatz
Passende Blöcke wiederverwenden, bei Miss neu berechnen.
BlueField-3, GDS und echtes RDMA sind Entwicklungsziele: NOT_RUN_HARDWARE. Der aktuelle Pfad kopiert im Hostspeicher und beansprucht weder Zero-Copy noch eine Umgehung der CPU.
- 01
Der heute ausführbare Pfad
CPU/TCP sowie Speicher- und Dateibackends sind im Quellcode verfügbar. GPU oder DPU sind nicht erforderlich.
- 02
Ein Knoten oder mehrere Shards
Begrenzte Routen, Verbindungen und Epoch-Fencing unterstützen betreiberverwaltete Shards.
- 03
Bei Verlust neu berechnen
G3.5 fügt weder Erasure Coding noch Replikate zur dauerhaften Speicherung hinzu. Unbekannter Transferabschluss bleibt bis zum expliziten Drain oder einem neueren Fence in Quarantäne. RustFS übernimmt die Dauerhaftigkeit kalter Daten. Dies ist ein Cache-Vertrag, keine Disaster-Recovery-Lösung oder Flottenqualifikation.
Nicht passend
- Daten, die dauerhaft bleiben müssen. G3.5 ist ein Cache. Dauerhafte Daten gehören auf RustFS in G4.
- Checkpoint-Speicher für das Training. Das ist Arbeit für G4.
- Der Produktionseinsatz ist noch nicht qualifiziert.
Architektur
Heute CPU/TCP. Hardwareziele separat prüfen.
GPUCache bildet die gemeinsame KV-Hot-Tier G3.5. Die implementierte Datenstrecke nutzt Hostspeicher und TCP. RustFS ist die kältere G4-Objektschicht außerhalb des heißen Anfragepfads.
- Host-Client
- TCP
- G3.5-ShardRust
- CPU
- Hostspeicher / Dateien
CPU-Vertrag verfügbar
- 01
Der heute ausführbare Pfad
CPU/TCP sowie Speicher- und Dateibackends sind im Quellcode verfügbar. GPU oder DPU sind nicht erforderlich.
- 02
Identität vor Wiederverwendung
Nur bestätigte Blöcke mit vollständiger passender Identität können treffen. Bei Miss wird neu berechnet.
- 03
Ein Knoten oder mehrere Shards
Begrenzte Routen, Verbindungen und Epoch-Fencing unterstützen betreiberverwaltete Shards.
- 04
Die Cold-Tier bleibt separat
RustFS liegt auf G4 außerhalb des heißen Pfads. Cold-Mock-Verträge sind getestet; Live-RustFS bleibt NOT_RUN_HARDWARE.
- 05
Das DPU-Ziel
DPU/GDS/RDMA bleiben NOT_RUN_HARDWARE. engine-spike nutzt künstliche Blöcke; aarch64 liefert nur CPU-Nachweise.
BlueField-3, GDS und echtes RDMA sind Entwicklungsziele: NOT_RUN_HARDWARE. Der aktuelle Pfad kopiert im Hostspeicher und beansprucht weder Zero-Copy noch eine Umgehung der CPU. Der heute ausführbare Pfad
Roadmap
Wo die Arbeit steht.
Der Status unterscheidet verfügbaren Quellcode und reproduzierbare CPU-Verträge von Hardwarequalifikation. Er verspricht weder einen Veröffentlichungstermin noch gemessene Flottenkapazität.
| Status | Funktion | Grenze |
|---|---|---|
| CPU/TCP verfügbar | Identität, Lebenszyklus, MemoryStore/FileStore, TCP-ACL und Lesezulassung | Synthetische Tests; vertrauenswürdige Netzwerkgrenze, kein mTLS. |
| CPU/TCP verfügbar | Begrenzte Shard-Clients, Mitgliedschaft und Epoch-Fencing | Betreiberverwaltete Routen; kein verteilter Konsens und keine Größenqualifikation. |
| Mock-Vertrag verfügbar | G4-Manifest v3, begrenzte Queue, Refill und Aufbewahrung | Live-RustFS: NOT_RUN_HARDWARE. Verwaiste Objekte werden nicht automatisch gesammelt. |
| CPU-Simulation verfügbar | DPU-Nachrichten, Fehlerinjektion und funktionaler TCP-Vergleich | Kein Beleg für Geräte-Offload, Zero-Copy, Durchsatz oder TCO. |
| Versuch mit künstlichen Blöcken | EngineBlockContract und engine-spike | Echter vLLM-Export/Import: NOT_RUN_HARDWARE; GPU-/Modelllauf: NOT_RUN_BUDGET. |
| In Entwicklung | Echtes RDMA, GDS, BlueField-3 / DOCA und SPDK | NOT_RUN_HARDWARE. Optionale Features bleiben ohne Geräteanbindung und verweigern das Öffnen. |
GPUCache wird vom RustFS-Team gebaut. Die beiden haben in der Speicherhierarchie eine klare Trennung. GPUCache ist die heiße Schicht G3.5, nah an der GPU und für die Wiederverwendung. RustFS ist die Kapazitätsschicht G4, ein in Rust geschriebener S3-kompatibler verteilter Objektspeicher, und bewahrt Modelle, Datensätze, Sitzungsverläufe und Inferenzergebnisse.
Eine verlorene heiße Schicht lässt sich neu berechnen. Daten in der Kapazitätsschicht dürfen nicht verloren gehen. Getrennte Aufgaben bleiben jeweils einfacher.
Schnellstart In Entwicklung
Den CPU-Vertrag bauen, testen und prüfen.
Der main-Branch enthält ausführbaren Rust-Code für einen gemeinsamen KV-Cache auf G3.5 mit CPU/TCP. Beginnen Sie mit den Vertragstests; GPU und DPU sind nicht erforderlich.
Der Quellcode ist verfügbar. Es gibt noch keine installierbare Veröffentlichung oder Qualifikation für den Produktionseinsatz.
- Stabiles Rust mit Cargo, Git und Python 3 installieren.
- Quellcode klonen und Workspace-Tests ausführen.
- Demos und CPU-Regression nach der vollständigen Anleitung starten.
git clone https://github.com/rustfs/GPUCache.git
cd GPUCache
cargo test --workspace --all-targets
cargo run -p gpucache-transport --bin share-demoDie vollständige Anleitung enthält die CPU-Regression und klare Hardwaregrenzen. Aus dem Quellcode bauen und testen
Dokumentation
Implementierung und Grenzen verstehen.
Architektur, Schichten, Status, Quellcodebefehle und Skalierung trennen CPU-Verträge von unqualifizierten Hardwarezielen.
Mitmachen
Die Schicht G3.5 gemeinsam bauen.
GPUCache sucht Leute, die Rust-Systemprogrammierung, RDMA/RoCEv2, NVIDIA DOCA und BlueField, ARM64-Cross-Kompilierung und die KV-Cache-Mechanismen von vLLM und TensorRT-LLM kennen.