GLM-Hardware-Anforderungen: GLM-5.3, GLM-5.3-Flash und GLM-4.x auf H200 NVL und RTX PRO 6000

GLM-Hardware-Anforderungen: die kurze Antwort

GLM-5.3, das Open-Weight-Modell von Z.ai mit 753B Parametern, braucht für seinen FP8-Checkpoint mit 756 GB acht H200 NVL in einem Server. Als zwei Pipeline-Stufen zu je vier Karten betrieben, fasst dieser Server nach unserer Schätzung etwa 23 gleichzeitige Gespräche mit 32.768 Token bei einem Cache in 16 Bit oder 37 mit dem FP8-Cache aus dem vLLM-Rezept. Mit dem Tensor-Parallelismus des Rezepts über alle acht Karten liegen die Werte bei etwa 11 und 18. Die FP8-Gewichte passen weder auf acht RTX PRO 6000 noch auf einen DGX Spark. Das kleinere GLM-5.3-Flash läuft auf vier H200 NVL oder, für einen einzelnen Nutzer, auf vier RTX PRO 6000, und GLM-4.7-Flash, ein 30B-Modell, läuft auf einer RTX PRO 6000, einer H200 NVL oder einem DGX Spark.

Die Konfigurationen sind unsere Schätzungen für 1, 20 und 100 gleichzeitige Gespräche mit je 32.768 Token auf vLLM 0.28.0, der Mindestversion des GLM-5.3-Rezepts von vLLM, gerechnet mit derselben Speicherregel wie unsere Übersicht LLM-Hardware-Anforderungen je Modell.

Varianten von GLM-5.3, GLM-5.3-Flash und GLM-4.x im Oktober 2026

Model Cards, Dateilisten und config.json-Dateien von zai-org sowie docs.z.ai, abgerufen am 9. Oktober 2026. Cache je 32K ist unsere Schätzung für ein Gespräch, in 16 Bit, sofern nicht FP8 angegeben ist.

GLM-5.3 ist ein Mixture-of-Experts-Modell, dessen config.json die Architektur GlmMoeDsaForCausalLM nennt: 78 Layer, 256 geroutete Experten, von denen 8 je Token aktiv sind, ein Shared Expert und ein Layer für Multi-Token-Prediction (MTP). Der FP8-Checkpoint nutzt Block-Skalierungen von 128 × 128. Die Dokumentation von Z.ai nennt reine Texteingabe, ein Kontextfenster von 1M Token und eine maximale Ausgabe von 128K Token, doch keine der beiden Quellen gibt die aktiven Parameter an.

Für GLM-5.3-Flash nennt die Dokumentation von Z.ai, übersetzt, „320B Parameter insgesamt, davon 18B aktiviert“ sowie native Eingabe von Bildern, Video und Dateien, und seine config.json hat 45 Layer, 34 mit linearer Attention und 11 mit Sparse Attention. GLM-4.7 und GLM-4.5 haben 92 Layer mit Grouped-Query Attention und 8 KV-Heads, GLM-4.5-Air dieselbe Attention in 46 Layern. GLM-4.7-Flash, das die Card von Z.ai „ein 30B-A3B-MoE-Modell“ nennt, hat auf seiner Card nur BF16-Gewichte.

KV-Cache je Gespräch aus der config.json

Unser Leitfaden dazu, wie viel VRAM ein LLM braucht beschreibt die allgemeine Methode: Gewichte und Cache teilen sich 90 Prozent des vom Treiber gemeldeten Speichers, abzüglich 3 GiB je Karte, das sind 83,04 GiB je RTX PRO 6000 und 123,36 GiB je H200 NVL. Für einen DGX Spark (128 GB) setzen wir 102 GB an.

GLM-4.7, GLM-4.5 und GLM-4.5-Air speichern Keys und Values je KV-Head: 2 × 92 Layer × 8 Heads × 128 Werte × 2 Byte ergeben 368 KiB je Token oder 11,5 GiB für ein Gespräch mit 32K in 16 Bit. GLM-5.3 und GLM-4.7-Flash speichern stattdessen je Layer einen komprimierten latenten Vektor aus 512 Werten plus einem Positionsanteil aus 64 Werten, den kv_lora_rank und qk_rope_head_dim ihrer Konfigurationsdateien. Bei GLM-5.3 sind das 1.152 Byte je Layer in 16 Bit, plus 132 Byte für den Key des Sparse-Attention-Indexers, den wir als Obergrenze auf allen 78 Layern zählen. Das ergibt 97,8 KiB je Token und 3,06 GiB je Gespräch mit 32K.

Mit einem FP8-Cache speichert vLLM den latenten Vektor jedes Tokens in 656 Byte je Layer, wie sein Blogbeitrag vom 29. September 2025 für DeepSeek-V3.2 beschreibt, dessen latenter Vektor dieselben 512 plus 64 Werte hat. Das ergibt 60 KiB je Token und 1,88 GiB je Gespräch mit 32K. Für GLM-5.3-Flash wenden wir die Angabe von Z.ai selbst, einen KV-Cache, der, übersetzt, „um das 4,44-Fache gegenüber GLM-5.3“ reduziert ist, auf unseren Wert für GLM-5.3 an; das ergibt etwa 0,69 GiB.

Der vLLM-Blog zu Decode Context Parallelism vom 7. August 2026 hält für MLA-Modelle fest, dass unter Tensor-Parallelismus, übersetzt, „der latente KV-Cache vollständig auf jedem TP-Rank repliziert wird“. GLM-5.3 hat denselben latenten Vektor aus 512 plus 64 Werten, deshalb halten acht Karten, über die das Modell per Tensor-Parallelismus verteilt ist, acht Kopien des Caches jedes Gesprächs. Pipeline-Parallelismus halbiert den Cache je Karte, weil jede Stufe nur den Cache ihrer eigenen Layer hält, und vLLM führt Pipeline-Parallelismus für die GLM-5-Architektur als unterstützt. Der Data-Parallel-Leitfaden von vLLM nennt für MoE-Modelle mit MLA eine dritte Aufteilung, Data-Parallel-Attention, bei der, übersetzt, „jede DP-Engine einen unabhängigen KV-Cache hat“, aber jede Karte die Gewichte außerhalb der Experten wiederholt; diese Aufteilung haben wir für GLM-5.3 nicht dimensioniert. Der Blog stellt Decode Context Parallelism (DCP) als Abhilfe vor, die jeden Cache nach Token auf die Karten aufteilt, und vLLM 0.30.0 führt in den Release Notes „PCP+DCP on sparse-MLA models“, also für den Attention-Typ von GLM-5.3. Nach unserer Schätzung ergäbe -dcp 8 etwa 92 Gespräche mit 32K in 16 Bit, doch kein Rezept, das wir gefunden haben, betreibt GLM-5.3 so, deshalb rechnet die Tabelle nicht damit.

GPUs für 1, 20 und 100 Nutzer

Unsere Schätzungen für vLLM 0.28.0, keine Messungen: Karten für 1, 20 und 100 gleichzeitige Gespräche mit je 32.768 Token, in Konfigurationen mit 1, 2, 4 oder 8 Karten, mit einem Cache in 16 Bit. Latente Caches (GLM-5.3, GLM-5.3-Flash, GLM-4.7-Flash) sind vollständig auf jeder Karte gezählt, über die das Modell per Tensor-Parallelismus verteilt ist; die Werte mit acht Karten bei GLM-5.3 und GLM-5.3-Flash setzen zwei Pipeline-Stufen zu je vier voraus. Beim DGX Spark zeigt die Tabelle nur, ob der Speicher reicht.

GLM-5.3 lässt auf acht H200 NVL nach den Gewichten 35,35 GiB je Karte. In zwei Pipeline-Stufen zu je vier Karten aufgeteilt, hält jede Karte den Cache von 39 Layern, Platz für etwa 23 Gespräche mit 32K in 16 Bit oder 37 mit dem FP8-Cache, den das vLLM-Rezept setzt. Mit dem Tensor-Parallelismus des Rezepts über alle acht Karten hält jede Karte alle 78 Layer jedes Caches, und die Werte sinken auf etwa 11 und 18. Hundert Nutzer mit 32K brauchen in der Aufteilung mit zwei Stufen deshalb etwa drei Server, während ein solcher Server 100 Gespräche mit 8K bei einem FP8-Cache fasst.

GLM-5.3-Flash passt mit seinen 305 GiB Gewichten auf vier Karten beider Typen. Auf vier RTX PRO 6000 bleiben 6,7 GiB je Karte, etwa neun Gespräche mit 32K, deshalb brauchen 20 Nutzer acht Karten in zwei Stufen. Vier H200 NVL lassen 47 GiB je Karte, etwa 68 Gespräche, und 100 Nutzer brauchen acht.

GLM-4.7 und GLM-4.5 belegen in FP8 etwa 337 GiB, mehr als die 332 GiB von vier RTX PRO 6000, deshalb brauchen sie acht. Vier H200 NVL fassen sie mit 13 Gesprächen mit 32K, und 20 Nutzer brauchen acht. Das deckt sich mit der Card von Z.ai zu GLM-4.5, die vier H200 bei FP8 als Minimum nennt und acht für den vollen Kontext von 128K. Ein FP8-Cache halbiert die Cache-Werte und lässt acht H200 NVL 100 Nutzer von GLM-4.7 bedienen.

GLM-4.7-Flash lässt auf einer RTX PRO 6000 Platz für etwa 15 Gespräche mit 32K und auf einer H200 NVL für 39. Ein DGX Spark fasst es mit etwa 22. Für 100 Nutzer braucht eine Kopie je Karte auf acht RTX PRO 6000 oder vier H200 NVL keinen Datenverkehr zwischen den Karten.

Für die RTX PRO 6000 führt die Support-Matrix von TensorRT-LLM (Version 1.3.0rc29) nur FP8 mit Skalierung je Tensor, während diese Checkpoints Block- oder Kanal-Skalierungen nutzen; prüfen Sie also, ob Ihre Engine sie auf dieser Karte ausführt.

Wir bauen KI-Server mit vier oder acht H200 NVL und ihren NVLink-Brücken oder mit Karten der RTX PRO 6000 Server Edition. Nennen Sie uns die GLM-Variante, Ihre Kontextlänge und die Spitzenzahl der Gespräche, und wir antworten innerhalb eines Werktages.

Warum GLM-5.3 acht H200 NVL und nicht acht RTX PRO 6000 braucht

Die FP8-Gewichte von GLM-5.3 belegen 704 GiB. Acht RTX PRO 6000 stellen nach unserer Regel 664 GiB bereit, sodass schon die Gewichte nicht passen. Acht H200 NVL stellen 987 GiB bereit, und das GLM-5.3-Rezept von vLLM, aktualisiert am 3. Oktober 2026, hält fest, übersetzt: „Der FP8-Checkpoint passt auf einen einzelnen 8xH200- / 8xH20-Knoten“. Das BF16-Repository übersteigt mit 1,51 TB die 1.128 GB von acht H200 NVL, und laut Rezept „brauchen diese Gewichte ein Multi-Node-Deployment“.

Stand 9. Oktober 2026 veröffentlichen weder zai-org noch NVIDIA einen 4-Bit-Checkpoint von GLM-5.3 auf Hugging Face. Das vLLM-Rezept verweist auf einen NVFP4-Checkpoint für Blackwell, den Inferact veröffentlicht hat, und weitere NVFP4-Konvertierungen stammen von Dritten; mit ihnen rechnen wir hier nicht. NVFP4 läuft nativ auf Blackwell-Karten wie der RTX PRO 6000, während die H200 NVL keine FP4-Arithmetik hat, wie unser Leitfaden dazu, wie viele H200 NVL große Modelle brauchen erklärt.

vLLM-Einstellungen für GLM-5.3 auf acht H200 NVL

Das GLM-5.3-Rezept von vLLM stellt den FP8-Checkpoint auf acht H200 mit --tensor-parallel-size 8 und --kv-cache-dtype fp8 bereit. Dazu kommt spekulatives Decoding mit MTP über --speculative-config.method mtp und fünf spekulative Token. Laut Rezept ist DeepGEMM erforderlich.

In einem Server mit acht H200 NVL verbinden die Brücken höchstens vier Karten, deshalb schickt Tensor-Parallelismus über acht Karten das All-Reduce jedes Layers über PCIe zwischen den beiden Domänen. Unser Artikel zur Aufteilung eines Modells über PCIe und NVLink beschreibt Tensor-Parallelismus innerhalb jeder Domäne und Pipeline-Parallelismus zwischen ihnen, in vLLM --tensor-parallel-size 4 mit --pipeline-parallel-size 2. Diese Aufteilung halbiert auch den latenten Cache je Karte. Das Rezept testet sie nicht, weder mit noch ohne MTP, vergleichen Sie also beide Aufteilungen auf dem gelieferten Server.

Setzen Sie --max-model-len auf den Kontext, den Sie bereitstellen; der AMD-Befehl des Rezepts nutzt 524.288 Token. Beim vollen Kontext von 1M Token braucht ein Gespräch in der Aufteilung mit zwei Stufen etwa 30 GiB FP8-Cache je Karte, was acht H200 NVL nach unserer Schätzung für einen Nutzer fassen. Unter reinem Tensor-Parallelismus braucht es 60 GiB je Karte, mehr als die verbleibenden 35 GiB. Der vLLM-Blog vom 8. September 2026 berichtet von GLM-5.3 mit vollem Kontext von 1M auf einem Knoten mit acht H200 mit Hybrid HiSparse, das die Cache-Seiten, die der Indexer nicht auswählt, in gepinnten CPU-Speicher verschiebt, wenn der GPU-Speicher knapp wird. HiSparse kam mit Release 0.30.0, 0.31.0 führt „HiSparse hardening“, und laut Beitrag ist es, übersetzt, „derzeit nur für NVIDIA-GPUs implementiert“. Für den vollen Kontext von 1M nennt das Rezept acht B200-GPUs mit je 180 GB, eine Systemklasse, die wir nicht liefern.

Rack, Strom und Host-Speicher für einen Server mit acht H200 NVL

Acht H200 NVL mit bis zu 600 W je Karte ziehen allein für die Karten 4,8 kW, vor Prozessoren, Speicher und Lüftern. Das ist mehr, als ein einphasiger 16-A-Stromkreis mit etwa 3,7 kW trägt, planen Sie also Drehstromabgänge an der Rackposition und C19-Ausgänge an der PDU für die größeren Netzteile. Jede Karte braucht das 600-W-GPU-Stromkabel, denn eine H200 NVL startet an einem 450-W-Kabel nicht. Die Card von Z.ai zu GLM-4.5 verlangt mehr als 1 TB Arbeitsspeicher im Server, und die Konfiguration mit acht H200 NVL auf unserer Seite zu KI-Servern hat 1 bis 2 TB. Der Modellspeicher braucht 756 GB für den FP8-Checkpoint und weitere 1,51 TB, wenn Sie die BF16-Gewichte behalten. Unser Artikel Strom und Kühlung für ein GPU-Rack behandelt Einhausung und Bodenbelastung.

Wir prüfen Rack, Strom und Luftstrom, bevor wir ein Angebot erstellen. Beschreiben Sie die Rackposition, ihre Absicherung in Ampere und Phasen und die PDU-Ausgänge im Formular unten.

GLM-Lizenzbedingungen für die Nutzung im Unternehmen

GLM-5.3 steht unter der GLM-5.3 License, die die Nutzung der Software unter ihren Bedingungen „ohne Einschränkung“ erlaubt. Ihre Klausel 2 definiert Model as a Service, übersetzt, als „Gewährung des Zugangs zu Inferenz oder Fine-Tuning eines Sprachmodells für Dritte (z. B. über eine API)“ mit maßgeblicher Kontrolle über Eingaben, Parameter oder Trainingsdaten. Ausgenommen sind laut Definition „Endnutzerprodukte, deren Modellfähigkeiten ausschließlich in bestimmte Funktionen oder Harnesses eingebettet sind“. Überschreitet ein Lizenznehmer, der ein solches Geschäft betreibt, die in der Klausel festgelegte Umsatzschwelle, muss er nach dem Lizenztext die Sicherheitsprüfung von Z.AI bestehen, bevor er die Software oder ihre abgeleiteten Werke für einen kommerziellen Zweck nutzt. Eine territoriale Beschränkung haben wir im Text nicht gefunden. GLM-5.3-Flash, GLM-4.7, GLM-4.7-Flash und GLM-4.5 tragen laut ihren Model Cards die MIT-Lizenz. Ob Klausel 2 auf ein Deployment zutrifft, ist eine rechtliche Bewertung für Ihre Rechtsabteilung.

Was wir liefern

Wir liefern die H200 NVL mit ihren Zweifach- und Vierfach-NVLink-Brücken, die RTX PRO 6000 als Workstation, Max-Q und Server Edition sowie die DGX Spark Founders Edition, als Karten oder in nach Auftrag gebauten KI-Servern. Alles kommt unter einem EU-Vertrag und auf einer Rechnung, mit Herstellergarantie; unser Sortiment professioneller GPUs führt jede Karte. Modelle, RAG und MLOps auf der Hardware sind unsere Leistung Private AI/ML, mit Engineering von unserem Engineering-Partner Vixen.UNO.

FAQ