GLM-5.3-Hardwareanforderungen (2026): GPUs, VRAM, RAM

Wer prüfen möchte, ob GLM-5.3 auf einer Desktop-GPU läuft, bekommt eine klare Antwort: Das aktuelle Flaggschiff-Checkpoint braucht serverklassigen Speicher. GLM-5.3-Flash senkt die Einstiegshürde, bleibt aber ein großes Multi-GPU-Modell. Ein quantisiertes Checkpoint zu laden ist außerdem nicht dasselbe, wie einen reaktionsschnellen Coding-Agent bereitzustellen.

Die Hardware-Antwort auf einen Blick

Für das vollständige GLM-5.3 ist eine dokumentierte 8-GPU-FP8-Topologie vorgesehen. Das vollständige Kontextziel mit 1 Million Tokens ist dagegen für 8× B200 dokumentiert. Eine Maschine mit 24 GB, 64 GB, 128 GB oder 192 GB ist kein praxisnahes Ziel für das vollständige Modell – auch dann nicht, wenn beim sparsamen MoE-Routing pro Token nur ein Teil der Parameter aktiviert wird.

Die aktuelle Hugging-Face-Modellkarte nennt 753.329.940.480 Gesamtparameter, 751.226.191.872 FP8-Parameter und eine gesamte Safetensors-Dateigröße von 755.643.409.571 Bytes. Das vLLM-Rezept rundet das Modell auf etwa 743B Gesamtparameter und 39B aktive Parameter. Die gerundeten Werte weichen geringfügig voneinander ab, ändern aber nichts an der Hardware-Einschätzung.

Die reine Speicherrechnung für die Gewichte

Diese Werte sind rechnerische Näherungen vor KV-Cache, Aktivierungen, Laufzeitpuffern und Allocator-Overhead. FP8 und BF16 beziehen sich auf die Größenordnung des aktuellen Flaggschiffs mit rund 753B Parametern; NVFP4 und 2-Bit stammen aus konkreten Implementierungen.

Was sich gegenüber den Hardware-Empfehlungen vor dem Release geändert hat

Das GLM-5.3-Repository ist inzwischen mit nativen FP8-Dateien live. Für Checkpoint-Metadaten ist die aktuelle Modellkarte die maßgebliche Quelle, für Topologie und Startparameter das offizielle vLLM-Rezept und für Messwerte aus dem praktischen Betrieb die Community-Berichte. Das aktuelle Rezept nennt ein Kontextfenster von 1.048.576 Tokens.

Entscheidend ist der Speicher, nicht die Parameterzahl

Bei GLM-5.3 ist zunächst der Gewichtsspeicher der Engpass, danach folgt der Kontextspeicher. Aktive Parameter senken zwar den Rechenaufwand, beseitigen aber nicht den Bedarf, geroutete Experten und Laufzeitpuffer im Speicher zu halten.

24–64 GB: Kein vollständiger lokaler GLM-5.3-Betrieb

Eine einzelne RTX 4090, RTX 5090 oder andere Karte der 24-GB-Klasse kann das native FP8-Checkpoint des Flaggschiffs nicht aufnehmen. Im aktuellen Hugging-Face-Repository belegen die Safetensors-Dateien etwa 756 GB. Auch eine 64-GB-Workstation-Karte bleibt damit weit unter dem erforderlichen Gewichtsspeicher.

CPU-Offload kann ein quantisiertes Experiment zwar zum Laden bringen, ist für einen interaktiven Coding-Service aber eher ein Weg zum Debuggen als eine Standardlösung. Ein Agent muss schließlich wiederholt Tool-Aufrufe in vertretbarer Geschwindigkeit abarbeiten.

128–192 GB: Für das Flaggschiff nein, Flash nur in einer konkreten Konfiguration

Auch eine Maschine mit 128 GB oder 192 GB Unified Memory bleibt unter dem Bedarf des nativen FP8-Flaggschiffs. Für Flash gibt es dagegen einen konkreten Weg: Ein öffentliches validiertes Profil betreibt ein festgelegtes EXL3/TR3-Checkpoint mit 4 bpw auf 2× RTX PRO 6000 Blackwell 96GB.

Dieses Profil verwendet 175,6 GB Checkpoint-Daten, ungefähr 220 GB freien Speicherplatz, PCIe-Peer-to-Peer-Kommunikation und eine festgelegte Laufzeitumgebung. Es nennt eine Obergrenze von 262.144 Tokens pro Anfrage, handelt sich aber um ein diskretes Zwei-GPU-Deployment und nicht um 192 GB gewöhnlichen System-RAM. Für genau diese Flash-Konfiguration werden außerdem 171,7 Tokens pro Sekunde beim Decoding und eine mediane Zeit bis zum ersten Token von 0,059 Sekunden angegeben.

2–4 GPUs mit viel Speicher: Flash prüfen, nicht das Flaggschiff

Zwei oder vier Karten mit viel VRAM sind der erste Bereich, in dem sich Flash ernsthaft untersuchen lässt. Präzision, Laufzeit, Kontextlänge, Batching und Bildeingaben verändern den Speicherbedarf allerdings jeweils. Das validierte Zwei-GPU-Profil unterstützt Text, strukturierte Tools und semantische Bildeingaben. Video ist deaktiviert, der Endpunkt besitzt keine integrierte Authentifizierung und das mitgelieferte Vision-Template benötigt vor der multimodalen Verifizierung eine reversible Reparatur. Diese Details gelten für das festgelegte Rezept, nicht automatisch für jedes Flash-Build und auch nicht für das Flaggschiff.

8× H200 oder H20: Dokumentierte FP8-Topologie des Flaggschiffs

Das offizielle vLLM-Rezept nennt acht H200- oder H20-GPUs als Standardtopologie für natives FP8. Zum Einsatz kommen achtfaches Tensor-Parallelism, ein FP8-KV-Cache, Multi-Token-Prediction mit fünf Tokens, automatische Tool-Auswahl sowie GLM-spezifische Parser für Reasoning und Tool-Aufrufe.

Das ist die dokumentierte Topologie, aber keine Zusage für eine bestimmte Tokens-pro-Sekunde-Leistung. Der tatsächliche Durchsatz hängt unter anderem von Interconnect, Kontextlänge, Batch-Größe, parallelen Sequenzen und dem verwendeten Serving-Build ab. Die vLLM-Seite liefert die Konfiguration, aber keine gemessenen Produktionswerte.

8× B200: Wenn das 1-Million-Token-Ziel zählt

Das offizielle Rezept sieht acht B200-GPUs für die vollständige Kontextkonfiguration mit 1.048.576 Tokens vor. Der zusätzliche Kontext ist vor allem eine VRAM-Frage: Der KV-Cache wächst mit aktiven Sequenzen und Kontextlänge. Ein Deployment, das mit 32K oder 128K Tokens funktioniert, unterstützt deshalb nicht automatisch eine Million Tokens bei gleicher Parallelität.

Beginne mit einem kleineren Wert für --max-model-len und erhöhe ihn erst, nachdem du die KV-Cache-Nutzung gemessen hast. Ein großes beworbenes Kontextfenster ist für umfangreiche Repositories und Dokumente nützlich, macht aber nicht jede Anfrage günstig oder latenzarm.

Host-Anforderungen, die das offizielle Rezept offenlässt

Das vLLM-Rezept nennt GPU-Topologie und Startparameter, veröffentlicht aber keine allgemeingültigen Anforderungen an System-RAM, Stromversorgung, Kühlung, Speicherreserve oder Netzwerk. Diese Werte hängen von Checkpoint, Laufzeit, Kontextziel und Provider-Plattform ab.

Der minimale offizielle Serving-Weg

Der dokumentierte Deployment-Weg verwendet vLLM 0.28.0 und einen OpenAI-kompatiblen Endpunkt. Er ist für einen Multi-GPU-Node ausgelegt. Den Befehl auf eine kleinere Maschine zu kopieren, beseitigt den Speicherbedarf des Modells nicht.

Die dokumentierte Laufzeit installieren

uv venv
source .venv/bin/activate
uv pip install "vllm==0.28.0" --torch-backend=auto
uv pip install "transformers>=5.15.0"

Das vLLM-Rezept weist außerdem darauf hin, dass DeepGEMM für FP8-Leistung erforderlich ist. Prüfe das aktuelle Rezept mit dem GPU-Image der Zielplattform, bevor du einen kostenpflichtigen Node bereitstellst.

Natives FP8-GLM-5.3 starten

vllm serve zai-org/GLM-5.3 \
  --kv-cache-dtype fp8 \
  --tensor-parallel-size 8 \
  --speculative-config.method mtp \
  --speculative-config.num_speculative_tokens 5 \
  --tool-call-parser glm47 \
  --reasoning-parser glm45 \
  --enable-auto-tool-choice \
  --served-model-name glm-5.3

Die Parameter haben jeweils eine konkrete Aufgabe:

• --tensor-parallel-size 8 verteilt das Checkpoint auf acht GPUs.
• --kv-cache-dtype fp8 reduziert den Cache-Druck gegenüber einem Cache mit höherer Präzision.
• Die MTP-Einstellung mit fünf Tokens aktiviert spekulatives Decoding entsprechend dem dokumentierten Rezept.
• --tool-call-parser glm47 und --reasoning-parser glm45 formatieren die Modellausgabe für Tool-Nutzung und Reasoning.
• --enable-auto-tool-choice erlaubt dem Server, bei entsprechenden Client-Vorgaben automatisch Tools auszuwählen.

Den Endpunkt prüfen, bevor der Agent verbunden wird

curl -X POST "http://localhost:8000/v1/chat/completions" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "glm-5.3",
    "messages": [
      {"role": "user", "content": "Write a Python function that reverses a linked list."}
    ],
    "max_tokens": 256
  }'

Eine erfolgreiche Antwort bestätigt, dass das Modell geladen wurde – nicht, dass Tool-Nutzung oder Long-Context-Verhalten funktionieren. Die offizielle Modellkarte nennt SGLang als weiteren OpenAI-kompatiblen Weg. Dieser Leitfaden verwendet jedoch vLLM, weil GPU-Topologie und Startparameter in einem eigenen Rezept dokumentiert sind.

Das unterschätzte Speicherbudget: KV-Cache und dauerhaft aktiviertes Reasoning

Die GLM-5.3-Modellkarte und das vLLM-Rezept behandeln Thinking als dauerhaft aktiviert. Unterstützte Werte für den Reasoning-Aufwand sind low, high und max. Wenn keine unterstützte niedrigere Einstellung angegeben wird, ist max der Standard.

Längeres Reasoning verbraucht mehr Output-Tokens. Ein Coding-Agent kann außerdem große Repository-Präfixe über wiederholte Tool-Aufrufe hinweg im KV-Cache behalten. Mehr parallele Sequenzen vervielfachen den Cache-Bedarf, auch wenn die Modellgewichte unverändert bleiben.

Nutze die Einstellungen als Steuerung für das Deployment:

• Low: Der beste Startpunkt für interaktives Coding, kurze Anfragen und latenzempfindliche Tools.
• High: Für Aufgaben, die mehr Planung benötigen, aber weiterhin ein interaktives Antwortbudget haben.
• Max: Für schwierige Aufgaben mit langem Planungshorizont, bei denen zusätzliche Reasoning-Tokens gerechtfertigt sind.

Für die vollständige Kontextkonfiguration auf B200 empfiehlt das offizielle Rezept --max-num-seqs 32 und verwendet FP8-Einstellungen für den Cache. Betrachte diesen Wert als Ausgangspunkt: Reduziere die Parallelität, wenn dem Server der Speicher ausgeht, und behaupte erst dann Unterstützung für eine Million Tokens, wenn eine echte Anfrage diesen Bereich ohne Kürzung des Caches erreicht.

Wann die API die vernünftigere Hardware-Entscheidung ist

Beim Self-Hosting bleibt GPU-Kapazität reserviert, auch wenn gerade kein Entwickler Anfragen stellt. Bei sporadischem Traffic, geringer Parallelität oder während ein Team GLM-5.3 noch evaluiert, vermeidet die API den Kauf oder die dauerhafte Miete eines Acht-GPU-Nodes. Dafür müssen Datenverarbeitung beim Anbieter und die Abhängigkeit vom Provider akzeptiert werden.

Die aktuelle Preisseite von Z.ai führt GLM-5.3 mit 1,40 $ pro 1 Mio. Input-Tokens, 0,26 $ pro 1 Mio. gecach­te Input-Tokens und 4,40 $ pro 1 Mio. Output-Tokens. Für GLM-5.3-Flash nennt sie zum Listenpreis 0,15 $ / 0,03 $ / 0,50 $; außerdem wird eine Aktion mit 50 % Rabatt bis zum 9. September 2026 angezeigt. Vor der Budgetplanung sollte die aktuelle Abrechnungsseite geprüft werden.

Das sind Beispiele für Tokenkosten, keine Break-even-Rechnung zwischen API und Self-Hosting. Für einen belastbaren lokalen Vergleich müssen der Stundenpreis des Nodes, die dauerhaft erzielte Tokens-pro-Sekunde-Leistung, die Auslastung, Strom, Speicher, Engineering-Zeit sowie fehlgeschlagene oder wiederholte Agent-Läufe berücksichtigt werden. Eine Erklärung der einzelnen Tarife gibt es im API-Preisleitfaden zu GLM-5.3-Flash von AIReiter.

Die Entscheidung lautet:

• Wähle die gehostete GLM-5.3-API, wenn du das Flaggschiff brauchst, aber unregelmäßige oder moderate Nachfrage hast.
• Wähle GLM-5.3-Flash, wenn niedrigere Tokenkosten, multimodale Eingaben oder ein kleineres Self-Hosting-Ziel wichtiger sind als die Kapazität des Flaggschiffs.
• Wähle das selbst gehostete GLM-5.3-Flaggschiff, wenn Datenschutz, Kontrolle oder dauerhaft hohe Auslastung ein Deployment mit acht GPUs rechtfertigen.

FAQ zu den GLM-5.3-Hardwareanforderungen

Läuft GLM-5.3 auf einer einzelnen RTX 4090, RTX 5090 oder 24-GB-GPU?

Nein, jedenfalls nicht als vollständiges Modell. Das Repository des nativen FP8-Modells enthält etwa 756 GB an Safetensors-Dateien. Eine 24-GB-Karte kann daher höchstens an einem extremen Offload- oder Quantisierungsexperiment beteiligt sein, nicht aber das Modell für normales Serving aufnehmen.

Reichen 128 GB oder 192 GB RAM aus?

Für das native FP8-Deployment des Flaggschiffs reicht das nicht. Das validierte Flash-Profil verwendet zwei diskrete GPUs mit jeweils 96 GB, ein festgelegtes 4-bpw-Checkpoint und zusätzlichen Speicherplatz. Das ist nicht mit einem Laptop oder einer Unified-Memory-Workstation mit 192 GB gleichzusetzen.

Was ist der Unterschied zwischen GLM-5.3 und GLM-5.3-Flash?

Es handelt sich um zwei eigenständige Modelle: Die Modellkarte des Flaggschiffs nennt rund 753B Gesamtparameter, während Z.ai Flash als Modell mit 320B Gesamtparametern und 18B aktiven Parametern sowie nativer multimodaler Ausrichtung beschreibt. Flash ist kleiner und günstiger, bleibt aber ein serverklassiges Modell und kein 18B-Desktop-Modell.

Welche Präzision sollte ich wählen?

Nutze natives FP8, wenn die dokumentierte Topologie mit acht GPUs verfügbar ist. BF16 eignet sich für Referenzqualität oder spezielle Evaluierungen, sofern der Speicher mehrerer Nodes akzeptabel ist. NVFP4 kommt nur auf unterstützter Blackwell-Hardware infrage. Außerdem sollte beachtet werden, dass das aufgeführte NVFP4-Checkpoint eine Community-Neuquantisierung und nicht das ursprüngliche Standardpaket ist.

Kann ich GLM-5.3 mit einem Coding-Agent verbinden?

Ja. Das offizielle vLLM-Rezept aktiviert einen OpenAI-kompatiblen Endpunkt sowie Parser für Tool-Aufrufe und Reasoning. Clients mit Unterstützung für diese Schnittstelle können sich nach der Serverprüfung verbinden. Teste dennoch den konkreten Agent-Harness, das Tool-Schema und das Verhalten langer Sitzungen. Eine erfolgreiche Chat-Completion allein beweist noch keine Agent-Kompatibilität.

Was du als Nächstes tun solltest

Für einen Desktop oder einen Host mit weniger als 192 GB solltest du zuerst die gehostete API testen. Miete die dokumentierte Acht-GPU-Topologie für einen repräsentativen Workload oder evaluiere Flash auf einer Multi-GPU-Maschine mit viel Speicher. Self-Hosting lohnt sich erst, wenn die gemessene Auslastung zeigt, dass Kontrolle und Datenschutz die Infrastrukturkosten rechtfertigen.