Wie Zadara die KI-Leistung für eine optimal dimensionierte Infrastruktur optimiert und warum Zadara die ideale KI-Fabrikplattform für Training und Inferenz ist.

KI-Infrastrukturprojekte scheitern seltener an falschen Technologieentscheidungen, sondern häufiger an einer falschen Dimensionierung. Ist die Infrastruktur zu klein dimensioniert, gerät Ihr LLM unter realer Nutzerlast ins Stocken. Ist sie zu groß, investieren Sie in teure GPU-Hardware, die 80 % der Zeit ungenutzt bleibt.

Dieser Artikel führt Sie Schritt für Schritt durch ein praktisches Framework zur Dimensionierung von GPU- und Recheninfrastruktur für KI-Workloads – von der ersten Anforderungserhebung bis hin zu einer Empfehlung für eine implementierbare Architektur. Er erläutert außerdem, wie die Verwendung von Zadara als Grundlage die Gesamtleistung der KI optimiert, sobald die richtigen Dimensionierungsentscheidungen getroffen wurden. Darüber hinaus wird verdeutlicht, wie die Flexibilität von Zadara Inferenz, souveräne KI und umfangreiches Batch-Training mit überlegener Leistung für eine optimal dimensionierte Bereitstellung ermöglicht.

Ob Sie eine private KI-Implementierung für datensouveräne Workloads, eine GPU-beschleunigte Analyse-Pipeline oder eine mandantenfähige Inferenzplattform planen – die Methodik ist dieselbe. Die von Zadara angebotenen oder unterstützten Hardwareoptionen, von spezialisierten Inferenzknoten auf Basis von NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs (96 GB VRAM pro GPU, 4 GPUs pro Knoten) bis hin zu großflächigen HGX-Clustern mit NVIDIA Spectrum-X-Netzwerk oder InfiniBand, decken das gesamte Spektrum der hier besprochenen Anwendungsfälle ab.

Zadaras Position im KI-Bereich und seine KI-optimierte Lösung wurden auf der NVIDIA GTC 2026 hervorgehoben. Dort gab Zadara die Angleichung an NVIDIAs Software Reference Guide für mandantenfähige KI-Cloud-Infrastruktur bekannt und präsentierte seine Architektur der „Neutral AI Factory“. Der NVIDIA-Blog zur GTC stellte Zadara zudem im Kontext einer strategischen Partnerschaft mit DDN vor, die darauf abzielt, leistungsstarke KI-Infrastruktur für Sovereign Clouds und mandantenfähige KI-Fabriken auf Basis von NVIDIA-Referenzarchitekturen bereitzustellen.

Warum die Größe wichtiger ist als die Wahl der Hardware

Das GPU-Portfolio von NVIDIA ist beeindruckend und entwickelt sich rasant weiter – von professionellen GPUs für spezifische Workloads bis hin zu den neuesten Beschleunigern für Rechenzentren wie der NVIDIA H200 und der NVIDIA B300. Größere Cluster-Konfigurationen mit NVIDIA Spectrum-X Ethernet oder InfiniBand-Netzwerken lassen sich auf Tausende von GPUs skalieren. Bevor Sie sich jedoch für eine bestimmte GPU entscheiden, müssen Sie eine grundlegendere Frage beantworten: Welche Art von Workload führen Sie aus?

KI-Workloads auf GPUs lassen sich in zwei grundlegend verschiedene Kategorien einteilen und verfolgen unterschiedliche Optimierungsziele:

Diese Unterscheidung ist der erste Schritt bei jeder Dimensionierungsdiskussion. Außerdem ist mehr nicht immer besser oder kostengünstiger. Erfahrungsgemäß fordern viele Kunden die schnellste verfügbare GPU an, obwohl ihre eigentliche Arbeitslast batchorientiert ist. Eine von Zadara betriebene, passgenaue GPU-Konfiguration, die auf den Arbeitslasttyp abgestimmt ist, ist in diesem Fall kostengünstiger und betriebsfreundlicher.

Die drei Säulen der GPU-Dimensionierung

Sobald Sie Ihre Arbeitslastart kennen, bestimmen drei technische Dimensionen Ihre Hardwareanforderungen. Stellen Sie sich diese als übereinanderliegende Schichten vor.

Säule 1: Modellgewichte, Ihre VRAM-Basislinie

Jedes KI-Modell verfügt über Parameter. Jeder Parameter benötigt Speicherplatz auf der GPU. Die Anzahl der Bytes, die jeder Parameter belegt, beeinflusst die Gesamtgenauigkeit des Modells. Daher hängt die benötigte Speichermenge von der gewählten numerischen Genauigkeit (dem Format) ab.

VRAM für Modellgewichte = Parameteranzahl x Bytes pro Parameter

Tabelle 1 – Präzisionsformate und die Gesamtgröße des KI-Modells.

Eine praktische Faustregel, die häufig angewendet wird, besagt Folgendes:

 Modellgröße in Milliarden x 2 = minimaler VRAM in GB bei FP16.

Zadaras GPU-Cloud unterstützt eine Vielzahl von NVIDIA-GPU-Konfigurationen in Hunderten von Edge-Clouds weltweit. Inferenzoptimierte Knoten nutzen die NVIDIA RTX PRO 6000 Blackwell Server Edition (96 GB GDDR7 VRAM pro GPU, 4 GPUs pro Knoten, insgesamt 384 GB), die sich für fokussierte Workloads und souveräne Edge-Bereitstellungen eignet. Für größere Modelle und hohe Parallelitätsanforderungen unterstützt Zadara HGX-Klasse-AI-Factory-Rechenzentrumsbeschleuniger, darunter die NVIDIA H200 GPU (141 GB HBM3e, 8 GPUs pro Knoten, insgesamt 1,128 GB) und die NVIDIA B300 GPU (288 GB HBM3e, 8 GPUs pro Knoten, insgesamt 2,304 GB). Für Modelle, die den VRAM eines einzelnen Knotens überschreiten, erweitern Multi-Node-Konfigurationen mit NVIDIA Spectrum-X- oder InfiniBand-Clustern diese Kapazität auf jede gewünschte Größe.

Hinweis zur Dimensionierung: Für Produktionsworkloads in regulierten Branchen (Finanzwesen, Gesundheitswesen, Behörden) empfehlen wir FP16 oder INT8 anstelle von INT4. Der Qualitätsunterschied ist messbar, und bei sicherheitskritischen KI-Implementierungen ist Zuverlässigkeit wichtiger als die maximale Ausnutzung der vorhandenen GPU-Leistung.

Säule 2: Speicherbandbreite – der eigentliche Leistungstreiber

Hier ist eine kontraintuitive Wahrheit über LLM-Inferenz: Engpässe liegen selten in den Rechenressourcen (FLOPS). Meistens ist es die Speicherbandbreite – die Geschwindigkeit, mit der Modellgewichte während der Token-Generierung aus dem VRAM gelesen werden können –, die die Leistung beeinflusst.

Während der Dekodierungsphase (Generierung jedes Ausgabetokens) muss das Modell für jedes erzeugte Token seinen vollständigen Gewichtssatz einlesen. Dies ist eine speicher- und bandbreitenintensive, keine rechenintensive Operation.

Ungefähre Token pro Sekunde = GPU-Speicherbandbreite (GB/s) / Modellgröße (GB)

Für ein 70B FP16-Modell (140 GB) auf einer einzelnen NVIDIA H200 SXM GPU mit 4,800 GB/s Bandbreite:

4,800 GB/s / 140 GB = ~34 Token/s pro Benutzer (einzelne GPU, keine Stapelverarbeitung)

Mit Tensorparallelität über vier NVIDIA H200 GPUs (zusammen ca. 19,200 GB/s) und optimierter Bereitstellung über vLLM:

19,200 GB/s / 140 GB = ~137 Token/s Gesamtdurchsatz vor Batching-Overhead

Auf inferenzoptimierten Knoten mit NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs (jeweils mit ca. 1,792 GB/s GDDR7-Bandbreite und 96 GB VRAM) passt ein 70B INT8-Modell (70 GB) auf eine einzelne GPU. Die Bandbreitenberechnung für eine Karte ergibt somit 1,792 / 70, was etwa 25 Token pro Sekunde entspricht. Durch die Nutzung aller vier GPUs im Tensor-Parallelbetrieb des Knotens erreicht die Gesamtbandbreite ca. 7,168 GB/s, wodurch mit Batching ein deutlich höherer Durchsatz erzielt wird.

Aus diesem Grund ermöglichen Multi-GPU-Konfigurationen mit der AI Cloud von Zadara, insbesondere solche, die NVIDIA Spectrum-X High-Bandwidth Networking oder InfiniBand zwischen den Knoten nutzen, überproportionale Leistungssteigerungen bei der Inferenz großer Modelle.

Die Spectrum-X-Implementierung von Zadara basiert auf NVIDIA Spectrum-4 Ethernet-Switches mit einer aggregierten Schaltkapazität von bis zu 51.2 Tb/s, gepaart mit BlueField-3 SuperNICs, die eine RoCE-Konnektivität von bis zu 400 GbE zwischen GPU-Servern ermöglichen.

Die operative Einzigartigkeit dieser Lösung liegt in Zadaras GPU-Net-Technologie. Diese Orchestrierungsschicht stellt automatisch dedizierte, skalierbare GPU-Kommunikationspfade in Ost-West-Richtung zwischen virtuellen Maschinen bereit, richtet Konfigurationen an der schienenoptimierten Topologie von Spectrum-X gemäß NVIDIAs Referenzarchitektur aus und gewährleistet die Mandantenisolation durch automatisierte VRF-Zuweisung. Kunden profitieren so von erstklassiger GPU-Verbindungsleistung über Ethernet, ohne den Aufwand einer manuellen Verwaltung.

Säule 3: KV-Cache, der versteckte VRAM-Verbraucher

Wenn ein Sprachmodell Token generiert, geschieht dies einzeln. Dabei behält es den gesamten Kontext der bis dahin generierten Token im Blick. Dieser Token-Korpus wächst mit fortschreitender Inferenz. Um die wiederholte Generierung derselben Token zu vermeiden, berechnet und speichert das Sprachmodell intern Schlüssel-Wert-Vektoren für jedes bisher gesehene Token. Dies ist der KV-Cache. Ohne ihn müsste das Modell bei jedem Generierungsschritt den gesamten Kontext neu berechnen, was die Inferenz unpraktikabel verlangsamen würde.

Der KV-Cache ist unerlässlich. Er bleibt bei einer reinen Dimensionierungsberechnung anhand von Modellgewichten unbemerkt und kann unter realen Arbeitslasten den gesamten VRAM-Bedarf leicht verdoppeln oder verdreifachen.

Der Cache wächst mit drei Faktoren: der Modellarchitektur (Anzahl der Schichten, Aufmerksamkeitsköpfe, verborgene Dimension), der Kontextlänge und der Anzahl gleichzeitiger Benutzer. Moderne große Sprachmodelle wie LLaMA-3 70B verwenden Grouped Query Attention (GQA) mit 8 KV-Köpfen anstelle der üblichen 64. Dies reduziert die Größe des KV-Caches pro Benutzer im Vergleich zu älteren Architekturen mit mehreren Aufmerksamkeitsköpfen erheblich. Eine realistische Schätzung für LLaMA-3 70B mit GQA bei 4K Kontext liegt bei etwa 0.5 bis 1 GB KV-Cache pro gleichzeitigem Benutzer.

Tabelle 2 – KV-Cache-Größen

Hinweis: Bei älteren Architekturen ohne GQA (z. B. der ursprünglichen GPT-Architektur mit vollständiger Multi-Head-Attention) kann der KV-Cache pro Benutzer 3- bis 4-mal höher sein. Überprüfen Sie bei der Dimensionierung stets die Attention-Konfiguration des jeweiligen Modells.

Hier wird vLLM mit Paged Attention zu einer entscheidenden Architekturentscheidung und nicht nur zu einer optionalen Optimierung. Indem der KV-Cache als dynamische Speicherseite verwaltet wird, analog zur Funktionsweise des virtuellen Speichers in einem Betriebssystem, reduziert vLLM die VRAM-Verschwendung durch vorab zugewiesene, aber ungenutzte Cache-Blöcke. In der Praxis erhöht dies die Anzahl der gleichzeitig von einer Hardwarekonfiguration bedienten Benutzer um das Drei- bis Vierfache.

Auf der zCompute Cloud von Zadara stellen wir vLLM als containerisierte Workload auf Kubernetes bereit und nutzen den NVIDIA GPU Operator für die Geräte-Plugin-Verwaltung. Dies bietet Ihnen die Flexibilität, die Dimensionierung zur Laufzeit und nicht nur zum Beschaffungszeitpunkt anzupassen.

Ein praktisches Dimensionierungsmodell

Nachdem die drei Säulen verstanden wurden, folgt hier das Fünf-Schritte-Framework, das wir bei der Dimensionierung der GPU-Infrastruktur für Kunden auf Zadara verwenden:

Schritt 1: Arbeitslastanforderungen klären

Bevor Sie einen Hardwarekatalog öffnen, beantworten Sie folgende Fragen: Welches Modell (Name und Anzahl der Parameter)? Online-Inferenz oder Stapelverarbeitung? Maximale Anzahl gleichzeitiger Benutzer (bei Online-Verarbeitung) bzw. Stapelverarbeitungsvolumen pro Stunde (bei Stapelverarbeitung)? Maximale Kontextlänge (2K / 4K / 8K / 128K Tokens)? Qualitätsanforderungen (FP16-Produktionsqualität oder INT8/INT4 akzeptabel)? Anforderungen an die Datensouveränität (lokal, spezifische geografische Lage, Air-Gap)?

Der letzte Punkt gewinnt für Unternehmenskunden zunehmend an Bedeutung. Zadaras Sovereign AI Edge Cloud, die weltweit an Hunderten von Edge-Standorten (On-Premises oder in Partner-Rechenzentren) eingesetzt wird, ist speziell für Organisationen konzipiert, bei denen Daten eine bestimmte Region oder Einrichtung nicht verlassen dürfen.

Schritt 2: Gesamt-VRAM berechnen

Gesamt-VRAM = Modellgewichte + KV-Cache + Framework-Overhead

Modellgewichte: Parameter (B) x Formatmultiplikator (GB). KV-Cache: Abhängig von der Modellarchitektur (siehe GQA-Head-Count), der Kontextlänge und der Anzahl gleichzeitiger Benutzer. Skaliert proportional für längere Kontexte. Framework-Overhead: 2 bis 4 GB (CUDA-Laufzeit, vLLM, Kubernetes-Overhead).

Schritt 3: GPU-Konfiguration auswählen

Ordnen Sie Ihren gesamten VRAM-Bedarf einer GPU-Klasse und -Konfiguration zu. Zadara unterstützt verschiedene NVIDIA-GPU-Leistungsklassen. Die passende GPU hängt von Ihrer Modellgröße, den Anforderungen an die Parallelverarbeitung und die Leistung ab.

Kontaktieren Sie das Zadara-Team, um die aktuell verfügbaren GPU-Konfigurationen zu bestätigen. Das Portfolio wird im Einklang mit der NVIDIA-Roadmap kontinuierlich weiterentwickelt.

Schritt 4: Leistung validieren

Überprüfen Sie, ob Ihre Konfiguration die Anforderungen an Latenz und Durchsatz erfüllt:

Geschätzte Token/s = (Kombinierte Bandbreite GB/s) / (Modellgröße GB)

Für Online-Inferenzziele gilt: Die Zeit bis zum ersten Token (TTFT) sollte unter 2 Sekunden liegen. Die wahrgenommene Generierungsgeschwindigkeit sollte 30 Token/s pro Benutzer überschreiten.

Falls die Schätzung zu niedrig ausfällt, sollten entweder GPUs hinzugefügt oder eine Quantisierung in Betracht gezogen werden. Der damit verbundene Qualitätsverlust muss jedoch für den Kunden dokumentiert werden.

Schritt 5: Redundanz hinzufügen und skalieren

Eine GPU-Bereitstellung auf einem einzelnen Knoten ist nicht produktionsreif. Für jede kundenorientierte Anwendung gilt:

Hohe Verfügbarkeit: Mindestens zwei unabhängige GPU-Knoten hinter einem Load Balancer. Kubernetes-Scheduling: Der NVIDIA GPU Operator auf zCompute Kubernetes ermöglicht GPU-Scheduling und Zustandsüberwachung auf Knotenebene. Horizontale Skalierung: Die Autoscaling-Gruppen von Zadara passen die Anzahl der GPU-Knoten flexibel an den Bedarf an.

Speicher für Modellgewichte und Datensätze: Die Architektur von Zadara bietet zwei komplementäre Speicherebenen. Elastische Blockvolumes werden standardmäßig von Zadara (zStorage VPSA) bereitgestellt und liefern konsistenten Blockspeicher mit geringer Latenz für GPU-Knoten über iSCSI zu persistenten Kubernetes-Volumes. Dies ist die Standardeinstellung für die Speicherung von Modellgewichten und verhindert Leistungseinbußen beim Kaltstart. Für Workloads, die einen gemeinsam genutzten Dateispeicher mit hohem Durchsatz erfordern (z. B. große Trainingsdatensätze, Checkpoint-Management über mehrere Knoten hinweg oder mandantenfähige Modellregistrierungen), integriert Zadara je nach Anwendungsanforderungen entweder DDN EXAScaler oder das eigene Dateisystem. Die Auswahl zwischen diesen gemeinsam genutzten Speicheroptionen richtet sich nach dem spezifischen Leistungsprofil, dem Umfang und den Datenzugriffsmustern des Workloads.

Beispielaufgabe: Sovereign AI-Plattform für einen Finanzdienstleistungskunden

Um dies zu verdeutlichen, folgt hier eine Dimensionierungsübung, die repräsentativ für Implementierungen ist, die wir für Kunden aus regulierten Branchen konzipiert haben.

Kundenprofil: Regionales Finanzdienstleistungsinstitut. Benötigt einen privaten LLM für die interne Analyse von Compliance-Dokumenten und strukturierte Frage-Antwort-Runden. Die Daten müssen innerhalb des Zuständigkeitsbereichs des Instituts verbleiben. Maximal 40 Analysten gleichzeitig. Kontextlänge bis zu 8,192 Tokens (umfangreiche regulatorische Dokumente). Reaktionszeit: Zeit bis zum ersten Token unter 2 Sekunden.

Modellauswahl: LLaMA-3 70B in INT8 (Qualität ausreichend für strukturierte Dokumenten-Fragen und -Antworten, souveräner Einsatz vor Ort).

Schritt 2: VRAM-Berechnung

Modellgewichte (INT8): 70 GB. KV-Cache (40 Benutzer, 8K Kontext, GQA mit 8 KV-Köpfen): ca. 25 GB. Bei 8K Kontext ist der Cache pro Benutzer etwa doppelt so groß wie die Schätzung von 4K, sodass 40 Benutzer mit jeweils ca. 0.6 GB einen Cache von ca. 25 GB ergeben. Framework-Overhead: 4 GB.

Benötigter VRAM insgesamt: ~99 GB

Schritt 3: GPU-Auswahl

Erforderlich: ~99 GB VRAM.

Option A: NVIDIA RTX PRO 6000 Blackwell Server Edition-Knoten (4 x 96 GB = 384 GB gesamt). Das 70 GB große INT8-Modell passt auf eine einzelne GPU, wobei auf dieser Karte noch 26 GB für den KV-Cache zur Verfügung stehen. Durch die Parallelisierung der Tensoren auf zwei GPUs wird das Modell in jeweils 35 GB aufgeteilt, sodass pro GPU ca. 61 GB für den KV-Cache und den Framework-Overhead verbleiben. Dies ist mehr als ausreichend für 40 gleichzeitige Benutzer mit 8K-Kontext.

Option B: HGX-Serverknoten mit NVIDIA H200 GPU (8 x 141 GB = 1,128 GB gesamt). Empfohlen für zukünftiges Wachstum, höhere Parallelitätsreserven und wenn der Kunde plant, auf größere Modelle oder längere Kontextfenster zu erweitern. Mit Tensorparallelität (tp=2) ist jeder GPU-Shard 35 GB groß, mit über 100 GB Reserve pro GPU.

Schritt 4: Leistungsvalidierung (NVIDIA RTX PRO 6000 Blackwell, tp=2)

Kombinierte Bandbreite: 2 x 1,792 GB/s = 3,584 GB/s
Aufteilung des Modells: 70 GB / 2 = 35 GB pro Karte
Geschätzter Token-Durchsatz: 3,584 / 70 = ~51 Token/s
Pro Benutzer (40 gleichzeitig mit Batchverarbeitung): ~40-50 Token/s
TTFT bei dieser Last: ~1.2s (innerhalb des Zielbereichs)

Schritt 5: Vollständige Architektur

Rechenleistung: Zwei identische NVIDIA RTX PRO 6000 Blackwell Server Edition-Knoten auf Zadara zCompute, aktiv/aktiv für hohe Verfügbarkeit. Orchestrierung: Kubernetes auf Zadara zCompute mit NVIDIA GPU Operator. Bereitstellung: vLLM mit Paged Attention und Tensorparallelität. Blockspeicher: Zadara zStorage VPSA für die Speicherung von Modellgewichten (NVMe-basiert, bereitgestellt über iSCSI an persistente Kubernetes-Volumes). Gemeinsamer Speicher: DDN EXAScaler oder Zadara-Dateisystem, ausgewählt basierend auf den Zugriffsmustern der Datensätze und den Durchsatzanforderungen. Netzwerk: Isolierte Zadara VPC mit privatem Endpunkt, kein ausgehender Internetverkehr. Überwachung: Prometheus + Grafana für GPU-Auslastung, TTFT, Token/s und VRAM-Verbrauch.

Ergebnis: 40 gleichzeitige Benutzer, TTFT konstant unter 1.5 Sekunden, volle Datensouveränität innerhalb der Gerichtsbarkeit des Kunden gewahrt, keine Abhängigkeit von öffentlichen Cloud-APIs.

Wann sollte man mit Spectrum-X Networking auf Clusterkonfigurationen skalieren?

Einzelknoten-GPU-Bereitstellungen bewältigen den Großteil der Inferenz-Workloads in Unternehmen problemlos. Es gibt jedoch Szenarien, in denen Multi-Node-GPU-Cluster mit NVIDIA Spectrum-X-Netzwerk die richtige Lösung darstellen:

Feinabstimmung des Basismodells: Das Training oder die Feinabstimmung von Modellen mit über 70 Milliarden Parametern erfordert kontinuierliche, rechenintensive Operationen auf vielen GPUs gleichzeitig. Die Netzwerkbandbreite zwischen den GPU-Knoten wird dabei zum entscheidenden Faktor. Die Schaltkapazität von 51.2 Tb/s des Spectrum-X und die 400-GbE-RoCE-Konnektivität von BlueField-3 beseitigen diesen Engpass.

Sehr große Modelle (400B+): Modelle wie LLaMA 405B oder proprietäre Architekturen im großen Maßstab benötigen Hunderte von Gigabyte VRAM und eine intensive GPU-zu-GPU-Kommunikation für die Tensorparallelität. Die zweistufige Leaf/Spine-Architektur von Spectrum-X unterstützt bis zu 8,000 GPUs, sodass die Clustergröße des Netzwerks nicht begrenzt ist.

Hochkonkurrenzfähige Inferenz im großen Maßstab: Bei der Bedienung einer großen Anzahl gleichzeitiger Nutzer mit auf mehrere Knoten verteilten Modellen erzeugt das Zugriffsmuster des KV-Caches einen erheblichen Ost-West-Datenverkehr zwischen den GPUs. Jeder Token-Generierungsschritt erfordert das Lesen und Aktualisieren zwischengespeicherter Schlüssel-Wert-Paare. Sind diese Caches auf mehrere Knoten verteilt, beeinflussen Netzwerklatenz und Bandbreite direkt die Zeit bis zum ersten Token (Time to First Token, TTF) und den Durchsatz pro Nutzer. Das adaptive Routing und die RoCE-Staukontrolle von Spectrum-X sorgen für einen vorhersehbaren Datenfluss zwischen den Knoten, selbst unter hoher Mehrbenutzerlast. Dadurch werden Latenzspitzen vermieden, die die Nutzererfahrung im großen Maßstab beeinträchtigen.

Hochleistungsfähige Multi-Tenant-Inferenzplattformen: Die Bedienung hunderter gleichzeitiger Nutzer in vollständig isolierten Tenants erfordert sowohl GPU-Skalierbarkeit als auch strikte Leistungsisolation. Die GPU-Net-Technologie von Zadara übernimmt die Tenant-Isolation automatisch. Die GPU-Kommunikationspfade jedes Tenants werden ohne manuelle Netzwerkkonfiguration bereitgestellt, und die Leistung bleibt unabhängig von der Aktivität benachbarter Tenants garantiert konstant.

Für diese Anwendungsfälle bietet die zCompute-Plattform dieselbe Verwaltungsschnittstelle, dasselbe VPC- und Netzwerkmodell sowie dieselben Kubernetes-nativen Operationen sowohl in Einzelknoten- als auch in Clusterumgebungen. Sie skalieren die Hardware, ohne die betriebliche Komplexität zu erhöhen.

Zadara als KI-Fabrikplattform

Über die Entscheidungsfindung bei der Dimensionierung einzelner GPUs hinaus besteht der größere Nutzen von Zadara darin, dass es das ermöglicht, was NVIDIA als KI-Fabrik bezeichnet: eine skalierbare, automatisierte Infrastruktur für die Entwicklung, das Training, die Bereitstellung und die Wartung von KI-Modellen auf wiederholbare und produktionsreife Weise.

Zadara stellt die Softwareplattform und Orchestrierungsschicht bereit, die dies ermöglicht: zCompute für elastische GPU-Rechenleistung, eine mehrstufige Speicherarchitektur, die Zadara zStorage VPSA für elastische Block-Volumes mit DDN EXAScaler oder dem Zadara-Dateisystem für gemeinsam genutzten Speicher mit hohem Durchsatz kombiniert (ausgewählt je nach Anwendungsanforderungen), GPU-Net für automatisierte Spectrum-X-Netzwerke und Sovereign AI Edge Cloud für Bereitstellungen, bei denen Daten innerhalb eines bestimmten geografischen Gebiets oder einer bestimmten Einrichtung verbleiben müssen. Diese Komponenten sind von Anfang an integriert und nicht aus Produkten verschiedener Anbieter zusammengesetzt.

Das richtige Gespräch über die Größe

Die Dimensionierung der GPU-Infrastruktur ist ebenso ein Erkenntnisprozess wie eine technische Übung. Die richtigen Fragen (Workload-Typ, Modellgröße, Parallelität, Kontextlänge, Qualitätsanforderungen, Souveränitätsbeschränkungen) entscheiden darüber, ob eine optimale Bereitstellung leistungsschwach oder überdimensioniert ist.

Zadaras zCompute Cloud bietet die Flexibilität, mit der optimalen Größe zu starten und horizontal mit den sich ändernden Workloads zu skalieren. Mit GPU-Konfigurationen, die von inferenzoptimierten NVIDIA RTX PRO 6000 Blackwell GPU-Knoten bis hin zu Spectrum-X-vernetzten HGX-Clustern (NVIDIA H200 GPU und NVIDIA B300 GPU) reichen, eng integriertem, mehrstufigem Enterprise-Speicher und souveränen Bereitstellungsoptionen an Hunderten von Edge-Standorten passt sich die Infrastruktur den Workloads an – und nicht umgekehrt.

Wenn Sie die Bereitstellung einer GPU-Infrastruktur planen und dieses Dimensionierungsframework mit Ihren spezifischen Workload-Parametern durchspielen möchten, wenden Sie sich an das Zadara-Team. Wir helfen Ihnen gerne bei der Berechnung.

© 2026 Zadara. Alle Rechte vorbehalten. Dieses Dokument dient ausschließlich Informationszwecken und stellt keine Rechts-, Finanz- oder sonstige professionelle Beratung dar. Ohne vorherige schriftliche Genehmigung von Zadara darf kein Teil dieser Publikation vervielfältigt oder verbreitet werden. Alle Produktnamen, Logos und Marken sind Eigentum ihrer jeweiligen Inhaber. Die Verwendung dieser Marken dient ausschließlich der Identifizierung und stellt keine Empfehlung dar.