7 Min. Lesezeit

Die durchschnittliche GPU-Auslastung im Unternehmen liegt bei rund fünf Prozent. Der Rest steht still, weil Daten erst kopiert, gestaged und in Position gebracht werden, bevor ein Workload überhaupt startet. Qumulo und Cisco haben am 26. Mai eine Architektur vorgestellt, die genau diese Lücke schließen soll: vorhandene Beschleuniger schneller arbeiten lassen, statt neue zu kaufen.

Das Wichtigste in Kürze

• Liquidity statt Kauf: Der Cloud AI Accelerator stellt verteilte Unternehmensdaten in Echtzeit an GPUs bereit, ohne Replikation oder wochenlanges Staging.
• Connect statt Copy: On-Premises- und Cloud-Systeme binden ohne Datenkopie an AWS Bedrock, Azure AI Foundry und Google Vertex AI an.
• Cisco als Hybrid-Anker: Netzwerk, Security und UCS-Compute tragen die Architektur über AWS, Azure, Google Cloud und OCI hinweg.

Verwandt:AWS und Nvidia: GPU-Million zwingt Platform-Teams  /  FinOps sieht alles, darf aber nichts

Was Qumulo und Cisco angekündigt haben

Was ist GPU-Liquidity? GPU-Liquidity bezeichnet den Ansatz, vorhandene Grafikprozessoren schneller produktiv zu machen, statt neue zu beschaffen. Daten stehen ohne langes Staging bereit, sodass ein Beschleuniger früher mit der eigentlichen Arbeit beginnt. Der Engpass verschiebt sich damit vom Hardware-Einkauf zur Frage, wie zügig bestehende Kapazität tatsächlich rechnet.

Am 26. Mai stellte Qumulo den Cloud AI Accelerator vor, kurz darauf folgte mit der CloudBridge-Architektur ein zweiter Baustein, terminiert vor der Cisco Live 2026. Der Kern beider Ankündigungen ist derselbe Gedanke: GPU-Kapazität ist teuer und knapp, aber sie liegt überwiegend brach. Nicht weil zu wenig Rechenleistung da wäre, sondern weil die Daten nicht rechtzeitig dort sind, wo der Beschleuniger sie braucht.

Technisch bündelt die Architektur drei vorhandene Qumulo-Komponenten: Cloud Native Qumulo, die Cloud Data Fabric und einen Cache-Layer namens NeuralCache. Zusammen sollen sie verteilte Daten über On-Premises, Edge und mehrere Clouds hinweg als eine logische Quelle an die GPUs reichen. Cisco liefert dazu Netzwerk, Security und mit UCS die On-Premises-Compute-Basis. Verfügbar ist das Angebot nach Herstellerangaben über AWS, Azure, Google Cloud und Oracle Cloud Infrastructure. Das Timing ist kein Zufall: Vor einer Hausmesse präsentiert man die Bausteine, die das Portfolio für das Jahr definieren sollen.

1. Die 95-Prozent-Lücke ist ein Datenproblem

Die zentrale Zahl aus der Ankündigung ist unbequem. Wenn GPUs im Schnitt nur zu fünf Prozent ausgelastet sind, dann ist der teuerste Posten im KI-Budget die Zeit, in der nichts passiert. In den meisten Fällen liegt das nicht an der Modellarchitektur und auch nicht an zu kleinen Clustern. Es liegt an der Pipeline davor: Daten werden aus dem Quellsystem exportiert, in ein Format gebracht, in eine GPU-nahe Flash-Schicht geladen und erst dann verarbeitet.

Diese Beobachtung deckt sich mit dem, was Plattform-Teams aus dem Betrieb kennen. Ein Cluster, der drei Tage auf seine Trainingsdaten wartet, ist betriebswirtschaftlich kein Cluster, sondern eine Rückstellung. Die Diskussion über GPU-Knappheit verschiebt sich damit weg vom Einkauf und hin zur Frage, wie schnell vorhandene Kapazität tatsächlich arbeiten kann. Wer im vergangenen Jahr Budget für zusätzliche Beschleuniger durchgesetzt hat, sollte zuerst prüfen, ob die alten überhaupt ausgelastet waren.

2. Connect statt Copy ist der eigentliche Hebel

Der technische Anspruch lautet: keine Kopie. Statt Daten in eine GPU-nahe Umgebung zu replizieren, soll der Accelerator die bestehenden Qumulo-Systeme direkt an die Inferenz- und Trainingsdienste der Hyperscaler anbinden. Konkret nennt Qumulo AWS Bedrock, Azure AI Foundry und Google Vertex AI als Ziele, die ohne vorheriges Umkopieren erreichbar werden.

Der Unterschied ist nicht kosmetisch. Jede Kopie bedeutet Speicherkosten, Konsistenzrisiko und Zeit. Wer die Kopie streicht, streicht auch die Wochen, in denen das teure Silizium auf seine Nahrung wartet. Für DACH-Teams mit verteilten Standorten ist ein zweiter Punkt fast wichtiger: Daten, die nicht kopiert werden, verlassen ihren kontrollierten Ort seltener. Das berührt direkt die Vorgaben zur Datenresidenz, die in regulierten Branchen ohnehin jede Architekturentscheidung mitbestimmen.

3. Was Cisco im Hybrid-Setup beiträgt

Die Partnerschaft mit Cisco ist mehr als ein Logo auf der Folie. Cisco bringt die Netzwerk- und Security-Schicht ein, die nötig ist, damit Daten über Cloud- und Standortgrenzen hinweg überhaupt schnell und kontrolliert fließen. Mit UCS kommt eine On-Premises-Compute-Basis dazu, die das Modell aus der reinen Cloud-Welt holt und für Häuser interessant macht, die nicht alles in einen Hyperscaler legen wollen oder dürfen.

Die zweite Ankündigung, CloudBridge, zielt auf einen verwandten Schmerzpunkt: die sogenannte Flash-Tax. Gemeint ist der Aufpreis für GPU-nahen Flash-Speicher, den Qumulo mit bis zu 400 Prozent beziffert. Wer Trainingsdaten nicht mehr vollständig in diese teure Schicht laden muss, umgeht einen Teil der Hardware-Knappheit, ohne neue Kapazität zu kaufen. Das ist der betriebswirtschaftliche Kern der ganzen Geschichte: nicht mehr Leistung, sondern weniger Verschwendung.

4. Wo die Architektur an Grenzen stößt

So sauber das Versprechen klingt, es verschiebt Probleme, statt sie aufzulösen. Wer die Kopie streicht, macht das Netzwerk zum kritischen Pfad. Latenz und Bandbreite zwischen Datenquelle und GPU entscheiden dann darüber, ob aus Theorie Durchsatz wird. Das ist beherrschbar, aber es ist Arbeit, und sie fällt im Betrieb an, nicht im Pitch.

Hinzu kommt die Abhängigkeit. Eine Datenfabric, die alles zusammenhält, wird selbst zum Fundament, das man nicht mehr ohne Weiteres austauscht. Das ist kein Argument gegen die Architektur, aber ein Punkt für die Vertragsverhandlung und die Exit-Planung. Wer die Fabric einführt, sollte von Anfang an dokumentieren, wie ein Ausstieg aussähe, solange die Frage noch theoretisch ist.

Was DACH-Teams jetzt konkret prüfen sollten

Der ehrlichste Test ist nicht das Datenblatt, sondern die eigene Pipeline. Wer wissen will, ob GPU-Liquidity etwas bringt, misst zuerst die eigene Time-to-GPU: Wie lange dauert es vom Anstoß eines Workloads bis zum ersten verarbeiteten Batch? Liegt diese Spanne im Bereich von Tagen, ist der Hebel real. Liegt sie bei Minuten, löst der Accelerator ein Problem, das man nicht hat.

Der zweite Schritt ist die Kostenfrage ohne Marketing. Idle-GPU-Kosten lassen sich beziffern, sobald man Auslastung und Stundensatz nebeneinander legt. Erst diese Zahl entscheidet, ob die neue Fabric eine Investition oder eine weitere Schicht ist. Ein sauberer Pilot mit einem realen Workload, einer gemessenen Vorher-Auslastung und einer klaren Abbruchbedingung sagt mehr als jede Referenzarchitektur. Wer beides misst, führt die Diskussion mit dem Anbieter auf Augenhöhe statt auf Folienhöhe.

Häufige Fragen

Was bedeutet GPU-Liquidity?

Gemeint ist, vorhandene GPU-Kapazität schneller produktiv zu machen, indem Daten ohne langes Staging bereitstehen. Der Engpass verschiebt sich vom Kauf neuer Hardware zur Frage, wie früh bestehende Beschleuniger arbeiten können.

Muss ich meine Daten in die Cloud kopieren?

Nach Herstellerangaben nicht. Der Cloud AI Accelerator bindet bestehende Qumulo-Systeme direkt an AWS Bedrock, Azure AI Foundry und Google Vertex AI an, ohne die Daten vorher umzukopieren.

Welche Clouds werden unterstützt?

Qumulo nennt AWS, Azure, Google Cloud und Oracle Cloud Infrastructure. Über Cisco UCS kommt eine On-Premises-Variante für hybride Aufstellungen dazu.

Welche Rolle spielt Cisco?

Cisco liefert Netzwerk, Security und mit UCS die On-Premises-Compute-Basis. Diese Schicht entscheidet, ob Daten über Cloud- und Standortgrenzen schnell genug an die GPUs gelangen.

Für wen lohnt sich der Ansatz?

Vor allem für Häuser mit verteilten Daten und messbar langer Time-to-GPU. Wer seine Workloads heute schon in Minuten startet, hat den Engpass anderswo und profitiert kaum.

Bildquelle: KI-generiert (Juni 2026), C2PA-Zertifikat im Bild hinterlegt