Der KV-Cache verlässt die GPU: Scality holt Speicher in den Inferenzpfad

Was geschah

Am 8. Oktober 2026 kündigte das Dateninfrastruktur-Unternehmen Scality in San Francisco die sofortige Verfügbarkeit von AI Inference Factory an. Es ist ein Open-Code-Softwarestack, mit dem Unternehmen, Behörden und Neo-Cloud-Anbieter KI-Inferenz auf eigener Infrastruktur deployen und betreiben; laut Mitteilung eine unterstützte Alternative zu Cloud-KI-Diensten, ohne den gesamten Stack selbst zusammenzubauen.

Der Stack besteht aus vier Teilen: validierte offene Gewichtsmodelle, gepflegt als Teil des Stacks; eine disaggregierte Inferenz-Serving-Schicht mit unabhängig skalierendem Prefill und Decode; eine Control Plane mit Authentifizierung, Metering, Routing an GPUs mit dem relevanten Kontext und SLA-Scheduling; sowie Scality ADI, eine richtliniengesteuerte autonome Datenmanagement-Infrastruktur in der Rolle der gemeinsamen Speicherschicht.

Angeboten als Softwarelizenz oder als vollständig gemanagter Service, wurde die Lösung am 8. Oktober auf dem Scality Day in Paris demonstriert. Scality sagt, den integrierten Stack zu validieren, auszuliefern und zu pflegen, damit Organisationen mit sich schnell wandelnden Modellen, Serving-Technologien und Sicherheitsanforderungen Schritt halten.

[1]

Warum jetzt

Die Mitteilung fasst die Motivation in drei Rechnungen. Erstens: Bei Cloud-Abrechnung pro Token wird die Rechnung umso unvorhersehbarer, je nützlicher der Workflow, und deckeln lässt sie sich nicht. Zweitens: Modellversionen und Quantisierung können nach Ermessen des Anbieters wechseln und erschüttern darauf aufgebaute Workflows. Drittens: Wo Prompts, Dokumente und proprietärer Code verarbeitet werden, unter welcher Jurisdiktion und wer den Zugang kappen kann; die drei Souveränitätsfragen für sensible und regulierte Daten. Scalitys Wette: Die meisten landen hybrid, mit den kritischsten KI-Prozessen on-premises.

Die Mitteilung zitiert IDC-Analystin Nataliya Yezhkova: Wo Infrastruktur Modellzustand effizient halten und servieren kann, ist lokale Inferenz eine glaubwürdige Option für immer mehr Unternehmens- und Public-Sector-Workloads. Hinweis: Dies ist ein Stütz-Zitat innerhalb der Herstellermitteilung, kein unabhängiger IDC-Report.

[1]

Die technische Substanz

Der substanziellste Teil ist das Design von Scality ADI als gemeinsame KV-Cache-Schicht. Bei der Inferenz wächst der KV-Cache mit der Kontextlänge und sprengt schnell den HBM der GPU; konventionell bleibt er auf dem GPU-Server, auf dem er geboren wurde. Scalitys Ansatz: ADI liefert einen gemeinsam genutzten Multipetabyte-Cache, den GPUs mit Latenz in der Größenordnung des GPU-Speichers lesen und Kontext aus dem Speicher wiederherstellen statt neu zu berechnen — mit besserer GPU-Auslastung und geringeren Kosten.

Dazu die Prefill/Decode-Disaggregation: Ein GPU-Pool macht nur Prefill und schreibt den KV-Cache nach ADI; ein anderer nur Decode und liest ihn zurück zur Token-Generierung. Jede Decode-GPU kann jeden Kontext übernehmen, Prefill unterbricht Decode nicht mehr, beide Pools laufen voll.

Die Worte von CTO Giorgio Regni verdienen festgehalten zu werden: Der KV-Cache auf ADI ist schnell genug, um im Serving-Pfad zu sitzen; einen Kontext aus ADI wiederherzustellen ist in der Größenordnung des GPU-Speichers und 14-mal schneller als Neuberechnung, bei durchgehend ausgelasteten GPUs; Speicher ist kein Grund mehr, den KV-Cache im GPU-Server zu behalten. CEO Jérôme Lecat rahmt das Souveränitätsnarrativ: Organisationen brauchen mehr Kontrolle darüber, wo Inferenz läuft, wie Modelle verwaltet werden und was mit ihren Daten geschieht.

[1]

Die Zahlen gelesen

Scality veröffentlichte Zahlen aus eigenen Tests, ohne unabhängige Verifizierung: Gemma-3 27B lädt in 1,9 Sekunden via RDMA parallel über den Cluster, etwa 10-mal lokales NVMe; 166 ms Warm-Time-to-First-Token bei Wiederherstellung eines 14K-Token-Kontexts aus ADI, nur 83 ms hinter HBM; 14-mal schnellerer KV-Cache-Abruf als Neuberechnung bei 14K, 72-mal bei 439K; Cache über 80-mal dem Speicher einer einzelnen GPU, mit 1.000 nebenläufigen Sessions wiederaufnehmbar ohne Neuberechnung; 97 % der Netzwerk-Linerate zwischen GPUs und Speicher; Kontext vor dem ersten Token wiederhergestellt, ohne messbaren Einfluss auf die Generierung.

Für die Disaggregation selbst zitiert die Mitteilung zwei öffentliche Drittstudien: DistServe (OSDI 2024) mit bis zu 7,4-mal mehr Requests unter gleichen Latenzzielen; Mooncake mit 75 % mehr Requests auf Kimi-Produktionstraffic. Das sind Zahlen öffentlicher Forschung, keine Scality-Tests; sie sind von den Herstellerzahlen zu trennen.

Die Sweet-Spot-Bedingungen sind explizit: 14K und 439K sind die in der Mitteilung gewählten Kontextlängen; kein messbarer Einfluss hängt an der Wiederherstellung vor dem ersten Token, ohne offengelegte Tail-Latenz-Verteilung. Bis zur Dritt-Reproduktion sollte Kapazitätsplanung Herstellerzahlen diskontieren und Messungen auf der eigenen Kontextverteilung verlangen.

[1]

Souveränität und Offenheit

Die Kompatibilitätsliste ist breit: OpenCode-, Hermes-, Goose-, LangGraph- und Pydantic-AI-Harnesses und Agent-Frameworks; validierte offene Gewichtsmodelle darunter Mistral, Gemma, gpt-oss, Qwen, Kimi, GLM und DeepSeek; Standardserver von Dell, HPE, Lenovo und Supermicro. Alles wird als Open Code geliefert: Kunden können inspizieren, wie Inferenzzustand gespeichert und bewegt wird, und Contributions einreichen, aber Scality reviewt sie; die Offenheit ist real, und der Gatekeeper auch.

Zwei Rechnungen sind zu begleichen. Erstens: Open Code mit Scality-Review ist nicht dasselbe wie reines Community-Open-Source; es ist näher an kommerziellem Open Source mit herstellerkontrolliertem Trunk. Zu klären sind Review-Kriterien, Security-Patch-SLAs und Supportgrenzen nach einem Fork. Zweitens: Sobald der KV-Cache ein persistentes, auditierbares, GPU-übergreifend portables Asset wird, liegen Prompts und Dokumente als Cache im gemeinsamen Speicher; Residenz-Policies, Verschlüsselung, Zugriffs-Audit und Löschsemantik müssen neu gebaut werden; die Mitteilung verspricht Policy-Governance und human-approved Lifecycle-Policies für ADI, bleibt aber vage bei den Mechanismen — genau das Detail, das regulierte Käufer vor der Unterschrift festzurren müssen.

[1]

Implikationen und Maßnahmen

Drei Implikationen für Teams, die lokale oder souveräne Inferenz erwägen. Erstens: Die Kostenoptimierungsvariablen ändern sich; KV-Cache-Hitraten, Kontext-Restore-Latenz und Prefill/Decode-Verhältnisse werden so wichtig wie die Zahl gekaufter GPUs; verlangen Sie vom Hersteller Messungen auf Ihrer Kontextverteilung, nicht die Sweet-Spot-Zahlen der Mitteilung.

Zweitens: Die Control Plane entscheidet über den Stack; Authentifizierung, Metering, Routing und SLA-Scheduling bestimmen, ob lokale Inferenz ein betreibbarer Service oder ein Haufen nackter GPUs ist; dass Scality sie unter die vier Teile stellt, zeigt Verständnis für Enterprise-Beschaffungslogik, und Käufer sollten nach derselben Checkliste abnehmen.

Drittens: Drei Dinge lassen sich noch nicht behaupten; ohne unabhängige Reproduktion diskontieren Sie die Zahlen in Ihrer Planung; null offengelegte Kunden, also Produktionsstabilität und Upgrade-Pfade unbekannt; und der lokale Stack tauscht die Token-Rechnung gegen fixe Hardware-Abschreibung, Strom- und Ops-Kosten: vorhersehbarer ist nicht billiger, und TCO braucht Ihre eigenen Workload-Daten. Das Souveränitätsnarrativ muss auf Datenebene landen: Offene Gewichte sind nur Schritt eins; Residenz und Jurisdiktion von KV-Cache, Prompts und Audit-Logs sind der wahre Test.

[1]