9 Von Giorgio Regni, Chief Technology Officer, Scality. 8. Oktober 2026. Die meisten Unternehmen sind über eine Cloud-API in die KI eingestiegen, und für Pilotprojekte war das die richtige Entscheidung. Im Produktivbetrieb sieht es anders aus. Sobald Agenten in die tägliche Arbeit einziehen, vervielfachen sich die Token-Mengen, jede Anfrage enthält proprietären Code und Dokumente, und das Modell hinter einem validierten Workflow kann sich nach dem Zeitplan eines anderen ändern. In der IDC-Umfrage vom Juni 2026 unter 1.015 Infrastruktur-Entscheidern (auf Englisch) stimmten 85 % zu, dass ihre KI-Workloads eine hybride Infrastruktur aus On-Premises und Public Cloud benötigen. Das Interesse an schlüsselfertigen Systemen wächst dabei aufgrund von Bedenken zur Datensouveränität. Die praktische Frage lautet dann, welche Workloads zuerst On-Premises gehören. Die Antwort sind meist die volumenstarken, ständig laufenden Arbeiten mit sensiblen Daten – Coding-Agenten stehen dabei weit oben auf der Liste. Es sind zugleich die Workloads, die sich am schwersten selbst betreiben lassen. Was braucht es, um KI-Inferenz unternehmensweit auf der eigenen Infrastruktur zu betreiben? Jede Agentensitzung bringt Kontext mit, den das Modell lesen muss, bevor es antworten kann: das Repository, den System-Prompt, die Tool-Definitionen, den bisherigen Gesprächsverlauf. Das Modell behält nichts davon zwischen zwei Anfragen. Jedes Mal, wenn ein Entwickler zurückkehrt, berechnet eine GPU diesen Kontext entweder komplett neu oder liest ihn von dort zurück, wo er gespeichert wurde. Im großen Maßstab entscheidet diese Wahl über die Kosten der Inferenz – und deshalb liefert ein Speicherunternehmen heute einen Inferenz-Stack. Denn der schwierigste Teil beim Betrieb eines Modells hat sich als Speicherfrage erwiesen. Scality AI Inference Factory, am 8. Oktober 2026 vorgestellt, ist ein Open-Code-Stack auf Basis von Scality ADI (AI Data Infrastructure) für den Betrieb von Open-Weight-Modellen auf der eigenen Infrastruktur. Er ist als Softwarelizenz oder als vollständig verwalteter Service erhältlich. Ihre Coding-Agenten lesen den ganzen Tag dieselbe Codebasis Jede wiederkehrende Sitzung ist eine Wahl zwischen Neuberechnen und Zurücklesen des Kontexts. Stellen Sie sich zehntausend Entwickler vor, die am Montagmorgen ihre Coding-Agenten öffnen. Jede Sitzung lädt dasselbe Repository, denselben System-Prompt und dieselben Tool-Definitionen. Bis zum Mittag hat jeder Agent diesen Kontext Dutzende Male erneut gelesen, und ein Entwickler, der für ein Meeting weggeht, erwartet bei seiner Rückkehr, dass die Sitzung dort weitermacht, wo sie aufgehört hat. Veröffentlichte Messungen zeigen, wie weit das geht. In einer Studie zu agentischen Workloads (auf Englisch) aus diesem Jahr wurden 84,6 bis 99,5 % der Eingabe-Token von einem Durchgang zum nächsten aus dem Cache wiederverwendet. Dieselbe Studie stellte fest, dass die Trefferquote von etwa 98 % auf 16 bis 26 % sank, sobald zu viele gleichzeitige Agenten den Cache überfüllten. Das Modell vergisst zwischen den Anfragen alles. Etwas anderes muss diesen Kontext halten, und jedes Mal, wenn er fehlt, muss eine GPU bereits erledigte Arbeit erneut berechnen. Gecachte Token: ein Zehntel des Preises – aus gutem Grund Die meisten großen Anbieter berechnen für ein gecachtes Eingabe-Token etwa ein Zehntel eines nicht gecachten. Das zeigt: Kontext neu zu berechnen ist ein Kostenfaktor, den man vermeiden sollte. Die veröffentlichte Preisliste (auf Englisch) von Anthropic berechnet einen Cache-Treffer beispielsweise mit dem 0,1-Fachen des Eingabepreises, bei den neuesten Modellen noch weniger. Caching erspart dem Anbieter die Neuberechnung. Mit dem Rabatt gibt er Ihnen einen Teil dieser Ersparnis weiter und behält seine Marge. Wenn die meisten Token Ihrer Entwickler Wiederholungen sind, zahlen Sie Runde um Runde für denselben Kontext. Anbieter haben diesen Cache gebaut, weil das Neuberechnen von Kontext teuer ist. Auf Ihren eigenen Servern ist dieser Cache bereits bereitgestellte Hardware und kostet Sie nichts zusätzlich. Der Cache ist groß, und wir haben ihn in unserem eigenen Kundenlabor gemessen. Eine einzige GLM-5.2-Sitzung mit einem Kontext von 438.764 Token erzeugte 189 GB KV-Cache, etwa 430 KB pro Token. Mit dem auf alle acht GPUs unseres Servers geladenen Modell passte diese eine Sitzung nicht in den HBM und musste in externen Speicher ausgelagert werden. Zehntausend solcher Sitzungen bräuchten etwa 1,9 PB. Der Cache passt weder in den GPU-Speicher noch in den DRAM eines einzelnen Servers. In GPU-Architekturen mit disaggregiertem Speicher muss jede GPU jedes gecachte Token erreichen können. Speicher in dieser Größenordnung ist ein Storage-Problem – und Storage betreibt Scality seit 2009 ununterbrochen im Produktivbetrieb. Lange galt die Annahme, Storage sei zu langsam für den Serving-Pfad, in dem jede Millisekunde vor dem ersten Token zählt. Wir haben im vergangenen Jahr getestet, ob das noch stimmt. Wir haben GPUs mit Objektspeicher verbunden und alles gemessen Mit dem aus Scality ADI bereitgestellten Cache haben wir eine Time to First Token (TTFT) von 166 ms bei einem Kontext von 14.000 Token gemessen – nur 83 ms hinter dem GPU-Speicher. Und anders als beim GPU-Speicher wächst die Kapazität mit dem hinzugefügten Storage. Wir haben GPUs über RDMA direkt mit Scality ADI verbunden, die CPU aus dem Datenpfad genommen und gemessen, was zurückkam. Das Labor war bewusst bescheiden: ein Server mit acht GPUs, fünf Speicherserver, die einige Generationen alt sind, und vier RDMA-Verbindungen mit 100 Gbit/s. Im Labor war das Netzwerk die Grenze; das Produkt lief auf einem 400-Gbit/s-Fabric. vLLM zerlegt den KV-Cache in Blöcke fester Größe und gibt jedem einen Namen, sodass Scality ADI jeden Block als Objekt speichern kann. Selbst mit S3 über RDMA durchläuft jeder Objektlesezugriff noch die S3-Control-Plane, die für das offene Internet gebaut wurde – mit Signierung der Anfrage, Richtlinienprüfung, Metadatensuche, Prüfsummen und XML-Framing bei jeder Anfrage. Der Scality AI Connector ersetzt sie durch unsere eigene schlanke Control-Plane mit Authentifizierung in einem Durchgang und ohne XML- oder Multipart-Framing. So läuft der Steuerpfad in Mikrosekunden, und das Objektmodell bleibt gleich. Für einen Lesezugriff reserviert die GPU Platz in ihrem Speicher und teilt Scality ADI mit, welches Objekt dort abgelegt werden soll. Die GPU steuert die Übertragung nie selbst; das übernimmt Scality ADI. Das TLC-NVMe-Laufwerk legt das Objekt über PCIe im RAM des Speicherservers ab, und die Netzwerkkarte sendet es über RDMA direkt in den GPU-Speicher. Die Daten umgehen CPU, Kernel und Software-Stack – so erreicht der Connector 97 % der Netzwerk-Leitungsrate zwischen GPUs und Storage. Die Neuberechnung des Kontexts mit 14.000 Token dauerte 2,3 Sekunden – 14-mal länger als das Zurücklesen. Bei einem größeren Modell ist der Abstand größer. Bei GLM-5.2 mit einem Kontext von 438.764 Token dauerte die Neuberechnung 529 Sekunden und das Zurücklesen 7,3 Sekunden – 72-mal schneller. In einem zweiten Durchlauf mit 8 vLLM-Instanzen (1 pro GPU) hielt Scality ADI 8 TB KV-Cache – mehr als das 80-Fache des Speichers einer GPU und etwa das Zehnfache des gesamten Servers. Das erste Token blieb bei jeder Größe von 69 GB bis 8 TB zwischen 355 und 373 ms. Die Latenz zwischen den Token änderte sich nicht: Der Abruf ist vor dem ersten Token abgeschlossen, und jedes weitere Token läuft aus dem GPU-Speicher. Da der Cache in Scality ADI liegt und nicht in einem einzelnen Server, kann jede GPU darauf zugreifen – und genau das ermöglicht getrenntes Serving: die beiden Phasen der Inferenz auf separaten GPU-Pools auszuführen. Prefill berechnet den KV-Cache für einen neuen Prompt, Decode erzeugt die Antwort Token für Token. Laufen beide auf denselben GPUs, unterbricht jedes neue Prefill die bereits laufenden Decodes. Nach der Trennung erledigt jeder Pool ganztags eine Aufgabe und skaliert eigenständig, wobei beide mit demselben gemeinsamen KV-Cache arbeiten. Die zugrunde liegende Forschung ist öffentlich. DistServe (OSDI 2024) (auf Englisch) maß bis zu 7,4-mal mehr Anfragen pro GPU bei gleichen Latenzzielen, wobei der Cache direkt zwischen den GPUs übertragen wurde. In unserem Design schreibt Prefill den KV-Cache stattdessen in Scality ADI, und Decode liest ihn zurück. So kann jede Decode-GPU jeden wiederkehrenden Kontext übernehmen, und die Speicherebene setzt der Größe dieses Caches praktisch keine Grenze. Über denselben Pfad werden auch Modelle geladen. Die 54,86 GB Gewichte des Modells Gemma-3 27B wurden in 1,9 Sekunden aus Scality ADI in eine GPU geladen – fast zehnmal schneller als von den lokalen Laufwerken des GPU-Servers, weil gleichzeitig von vielen Laufwerken der Speicherebene gelesen wird. Je nach Last kann eine GPU bis zu tausendmal am Tag das Modell wechseln. Jede Schicht oberhalb des Speichers musste korrigiert werden Wir haben jede Korrektur upstream eingereicht. Die Serving-Engine, die Weight Loader, die Data Mover und das Fabric waren alle für langsamen und kleinen Speicher geschrieben. Keine dieser Komponenten rechnete mit einer entfernten Ebene, die mit der Geschwindigkeit der Hardware antwortet. Mehrere versagten auf eine Weise, die erst sichtbar wird, wenn man die Speicherseite der Inferenz misst. Der deutlichste Fall war der KV-Offload-Connector von vLLM, der für jede Wiederherstellung etwa fünfmal so viele Cache-Blöcke abrief wie nötig. Wer diesen Connector zum Auslagern in einen Objektspeicher nutzte, zahlte diesen Aufschlag. Wir haben den Connector korrigiert, den vLLM-Kern unverändert gelassen und die Korrektur upstream eingereicht, sodass jeder Objektspeicher hinter diesem Pfad davon profitiert. Außerdem haben wir ModelExpress, den Open-Source-Model-Loader, so erweitert, dass er Gewichte direkt aus dem Objektspeicher lädt. Es gibt keinen Scality-Fork irgendeiner Komponente des Stacks. Wir paketieren den Stack, halten jede Schicht aktuell, während sich Modelle und Serving-Engines ändern, und können ihn für Sie betreiben. Sie kontrollieren Modell, Daten und Kosten Sie behalten Ihr Harness, wählen aus validierten Open-Weight-Modellen und entscheiden, wann sich etwas ändert. Ihre Entwickler behalten die Tools, die sie bereits nutzen, und ändern eine einzige Einstellung: Der Inferenz-Endpunkt wechselt von der Cloud-API zu Ihrem eigenen. Claude Code, Codex, OpenCode und die anderen Tools Ihrer Entwickler funktionieren weiter wie bisher. Das Modell, das Sie wählen, bleibt das Modell, das Sie betreiben. Version, Quantisierung und Ausmusterung ändern sich, wenn Sie es entscheiden (und nicht, wenn ein Anbieter seine Flotte umverteilt), sodass ein im März validiertes Ergebnis im September reproduzierbar ist. Wenn Sie KI in Ihrem eigenen Produkt verkaufen, ist diese Reproduzierbarkeit Teil dessen, was Sie Ihren Kunden versprechen. Auch der Kontext bleibt, wo er ist. Eine externe API erhält nie nur eine Frage: Sie erhält die Codebasis, die abgerufenen Dokumente und die Ausgabe jedes Tools, das der Agent aufgerufen hat. Auf Ihrer eigenen Infrastruktur verlässt nichts davon Ihren Perimeter. Es bleibt unter Ihrer Rechtshoheit, und niemand außerhalb Ihres Unternehmens kann es abschalten. Der gesamte Stack lässt sich sicher betreiben. Auch die Kosten funktionieren anders. Eine nutzungsbasierte API-Rechnung wächst mit jedem Token – also am schnellsten, wenn die Einführung erfolgreich ist. Auf Ihren eigenen Servern ist das Budget fest, und je mehr Ihre Teams sie nutzen, desto günstiger wird jedes Token. Was Sie bereitstellen Scality AI Inference Factory bündelt den gesamten Serving-Stack hinter einem Endpunkt. Er umfasst vLLM, Dynamo, den Scality AI Connector, Scality ADI und mehr. Zu den validierten Open-Weight-Modellfamilien gehören Mistral, Gemma, gpt-oss, Qwen, Kimi, GLM und DeepSeek. Der Stack läuft auf Standardservern von Dell, HPE, Lenovo und Supermicro. Sie erhalten den Quellcode, können prüfen, wie der Inferenzzustand gespeichert und bewegt wird, und können Änderungen zur Prüfung durch unsere Ingenieure einreichen. Die darunterliegende Speicherebene betreibt bereits mehr als 12 EB im Produktivbetrieb in über 70 Ländern. Sprechen Sie mit einem KI-Architekten von Scality über Ihren Workload. Bringen Sie Ihren Traffic und ein Repository mit, und wir dimensionieren ihn gemeinsam mit Ihnen. Hören Sie auf, für den Neuaufbau von Kontext zu bezahlen, den Sie bereits haben. Entdecken Sie On-Premises-KI-Inferenz mit Scality und helfen Sie Ihrem Team, KI zu den eigenen Bedingungen zu betreiben.
