Zhipu AI hat GLM-5.3 am 14. August 2026 veröffentlicht. Für Infrastrukturteams ist vor allem der geplante Release der offenen Gewichte relevant: Sie sollen etwa zwei Wochen später, um den 28. August, in Zhipus Hugging-Face-Organisation erscheinen. Nutzen Sie dieses Zeitfenster, um Hardware zu planen, einen Serving-Stack zu testen und eine Regressions-Baseline gegen die gehostete API zu erstellen, bevor die ersten Safetensors-Shards verfügbar sind.
Apidog noch heute ausprobieren
Zhipus interne Bewertungen attestieren der Codierungsfähigkeit eine 50%ige Verbesserung gegenüber GLM-5.2. Terminal-Bench 3.0 stieg von 4.6 auf 28.3, und laut Startberichten beschreibt das Unternehmen die Agentenleistung als „nahezu Claude Fable 5“. Die vollständige Benchmark-Einordnung finden Sie in unserem GLM-5.3-Erklärer. Dieser Beitrag beantwortet die praktische Frage: Was muss am Veröffentlichungstag bereitstehen, damit Sie GLM-5.3 selbst hosten können?
Hinweis: Die Gewichte sind derzeit noch nicht herunterladbar. Angaben zum Release-Fenster basieren auf Zhipus Ankündigungen; nicht bestätigte Details sind Erwartungen, keine Fakten. Sie können jedoch schon jetzt eine Baseline über die gehostete API erstellen und später dieselbe Testsammlung gegen Ihren lokalen Endpunkt ausführen. Dafür eignet sich Apidog.
TL;DR
- GLM-5.3 wurde am 14. August 2026 ausgeliefert. Die offenen Gewichte werden laut Zhipu etwa zwei Wochen später, um den 28. August, erwartet: huggingface.co/zai-org.
- Die GLM-5-Familie nutzt laut Z.ai-Dokumentation eine Mixture-of-Experts-Architektur mit 744 Milliarden Gesamtparametern, etwa 40 Milliarden aktiven Parametern pro Durchlauf und 200K Kontext.
- Die Gewichte benötigen rechnerisch rund 1,5 TB in BF16 oder rund 744 GB in FP8 — ohne KV-Cache.
- Erwartet werden ein BF16-Repository und ein offizielles FP8-Repository. Community-GGUF-Quants dürften später folgen.
- Für den ersten Tag sind vLLM und SGLang die pragmatischen Serving-Stacks. Beide bieten OpenAI-kompatible APIs.
- Erstellen Sie jetzt in Apidog eine Sammlung mit zwei Umgebungen:
hostedundlocal.
Was Zhipu wann veröffentlicht
Zhipu, international als Z.ai vermarktet, hat den GLM-5.3-API-Launch mit dem Versprechen verbunden, die Gewichte etwa zwei Wochen später offenzulegen. Das erwartete Veröffentlichungsfenster liegt damit um den 28. August 2026 auf Hugging Face.
Zhipu erklärt die Verzögerung mit dem bisher umfangreichsten Risikoprüfungssystem des Unternehmens. Das ist angesichts der 84,5 % auf CyberGym relevant — etwas über Claude Mythos 5 und GPT-5.6 Sol. Seeking Alpha interpretiert den Release als Versuch, Zhipus Position bei offenen Modellen zu stärken.
Für Self-Hosting sind zwei Punkte entscheidend:
Das Basismodell bleibt unverändert.
GLM-5.3 basiert auf GLM-5 mit skaliertem Post-Training. vLLM und SGLang sollten daher dieselbe Architektur behandeln, die bereits für GLM-5 und GLM-5.2 unterstützt wird. Neue Attention-Varianten oder ein neuer Tokenizer werden nicht erwartet.Das Veröffentlichungsmuster ist etabliert.
Zhipus Hugging-Face-Organisation enthält GLM-5, GLM-5.1 und GLM-5.2, jeweils mit einer FP8-Variante. Für GLM-5.3 ist daher eine BF16-Safetensors-Version plus offizielles FP8-Repository plausibel.
Prüfen Sie beim Erscheinen des Repositories unbedingt die Modellkarte und Lizenz, bevor Sie GLM-5.3 kommerziell einsetzen.
Hardware planen: 744B insgesamt, 40B aktiv
Die GLM-5-Familie ist ein Mixture-of-Experts-Modell mit:
- 744 Milliarden Gesamtparametern
- etwa 40 Milliarden aktiven Parametern pro Vorwärtsdurchlauf
- 200K Kontextfenster
Diese Werte stammen aus der Z.ai-Dokumentation. Hugging-Face-Repositories können leicht höhere Gesamtwerte nennen, wenn Embeddings eingerechnet werden.
Für die Infrastrukturplanung ist die MoE-Asymmetrie entscheidend:
Compute verhält sich ungefähr wie bei einem dichten 40B-Modell.
Pro Token werden nur die gerouteten Experten aktiviert.Speicher verhält sich wie bei einem 744B-Modell.
Alle Experten müssen im adressierbaren Speicher liegen.
| Präzision | Gewichtsbedarf, rechnerisch | Realistischer Einsatzort |
|---|---|---|
| BF16 | ~1,5 TB | Multi-Node-Cluster oder größte Single-Server-GPU-Konfigurationen |
| FP8, offiziell | ~745 GB | High-End-Multi-GPU-Server, potenziell Single Node |
| INT4-Klasse, Community-Quants | ~370–400 GB | Kleinere Multi-GPU-Systeme; Qualitätsberichte abwarten |
Diese Zahlen enthalten nicht den KV-Cache. Das 200K-Kontextfenster ist daher keine kostenlose Kapazität: KV-Cache-Speicher steigt mit Kontextlänge und Batch-Größe.
Praktische Entscheidung
Definieren Sie vor dem Release eine maximale Kontextlänge pro Deployment-Tier:
Evaluation: 16K oder 32K Kontext
Standard-Inferenz: 32K oder 64K Kontext
Langkontext-Workloads: nur mit separatem Kapazitätsbudget
Wenn Ihnen nur eine einzelne Consumer-GPU zur Verfügung steht, sind vollständige GLM-5.3-Gewichte nicht das Ziel. Sinnvolle Alternativen:
- GPU-Stunden für Evaluierungen mieten
- auf Community-Quants warten
- GLM-5.3 gehostet nutzen und kleinere Modelle lokal ausführen
Unser Leitfaden zu den besten lokalen LLMs im Jahr 2026 zeigt, welche Modelle in Single-GPU- und Workstation-Budgets passen.
Serving-Stack vor dem Gewichtsrelease auswählen
Installieren und testen Sie Ihren Serving-Stack vor dem Release. Debugging von CUDA-Treibern, NCCL oder Netzwerk-Topologien am Veröffentlichungstag ist vermeidbar.
Option 1: vLLM
vLLM ist für diese Modellklasse die Standardwahl:
- Unterstützung für die GLM-5-Familie
- MoE-Routing
- Tensor- und Expertenparallelität
- OpenAI-kompatibler Server
Ein möglicher Startbefehl könnte nach dem Repository-Release so aussehen:
vllm serve zai-org/GLM-5.3-FP8 \
--tensor-parallel-size 8 \
--max-model-len 65536 \
--served-model-name glm-5.3
Behandeln Sie diesen Befehl als Vorlage:
- Der endgültige Repository-Name muss beim Release geprüft werden.
-
--tensor-parallel-sizehängt von GPU-Anzahl, VRAM und Interconnect ab. -
--max-model-lensollte zu Ihrem KV-Cache-Budget passen.
Option 2: SGLang
SGLang ist eine starke Alternative, besonders für Agenten-Workloads mit wiederkehrenden langen Präfixen:
- MoE-optimierte Ausführung
- Radix-Tree-Prefix-Caching
- OpenAI-kompatibler API-Endpunkt
Wenn Ihre Anwendung wiederholt denselben Systemprompt, Tool-Kontext oder Agentenverlauf sendet, kann Prefix-Caching relevant sein.
Option 3: llama.cpp, Ollama und LM Studio
Die llama.cpp-Familie benötigt GGUF-Konvertierungen. Diese erscheinen typischerweise erst Tage oder Wochen nach einem Safetensors-Release durch die Community.
Dieser Weg ist interessant für kleinere Hardware, aber validieren Sie Quantisierungen immer gegen Ihre eigene Baseline. Übernehmen Sie keine Qualitätsannahmen blind.
Trockenlauf durchführen
Führen Sie diese Woche mindestens einen Test durch:
# Beispiel: Prüfen, ob vLLM grundsätzlich installiert ist
vllm --help
# Danach mit GLM-5.2 oder einem kleineren MoE-Modell testen
Testen Sie dabei insbesondere:
- GPU-Erkennung
- CUDA- und Treiberversionen
- Multi-GPU-Kommunikation
- Modell-Download-Pfad
- API-Erreichbarkeit
- maximale Kontextlänge
- OOM-Verhalten bei parallelen Requests
Die gehostete API als Baseline verwenden
Bevor Sie selbst hosten, dokumentieren Sie das Verhalten der Referenzimplementierung. Die gehostete API liefert Ihnen Vergleichsdaten für die lokale Bereitstellung.
Wenn Ihre lokale Instanz später andere Antworten liefert, können Sie damit unterscheiden zwischen:
- Quantisierungsverlust
- Fehlern in der Serving-Konfiguration
- normaler Stichprobenvarianz
- Abweichungen bei Tool-Calling oder Streaming
Die gehostete API ist OpenAI-kompatibel:
International: https://api.z.ai/api/paas/v4/chat/completions
Festlandchina: https://open.bigmodel.cn/api/paas/v4/chat/completions
Auth: Authorization: Bearer <key>
Die Z.ai-Dokumentation listet derzeit glm-5. Für glm-5.3 sollten Sie die exakte Modell-ID in den offiziellen Dokumenten prüfen. Die Einrichtung für beide Regionen beschreibt unser GLM-5.3 API Quickstart.
Baseline per cURL erfassen
Verwenden Sie feste Prompts und temperature: 0:
curl https://api.z.ai/api/paas/v4/chat/completions \
-H "Authorization: Bearer $GLM_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "glm-5.3",
"temperature": 0,
"messages": [
{
"role": "user",
"content": "Write a Python function that parses RFC 3339 timestamps and returns UTC datetimes. Include error handling for invalid input."
}
]
}' > baseline-rfc3339.json
Erstellen Sie 20 bis 50 Baselines für Ihre realen Workloads:
- Code-Generierung
- Refactoring
- Tool-Call-Entscheidungen
- strukturierte JSON-Ausgaben
- Langkontext-Zusammenfassungen
- Agenten-Schritte
- Sicherheits- oder Validierungsaufgaben
Temperatur 0 macht die Ausgabe nicht zwingend bitgenau reproduzierbar, reduziert aber die Varianz genug, um grobe Qualitätsverluste sichtbar zu machen.
Regressionstests in Apidog aufbauen
cURL-Dateien reichen für einen einzelnen Test. Sobald Sie jedoch mehrere Endpunkte, Quantisierungen und Serving-Konfigurationen vergleichen, benötigen Sie eine strukturierte Testsammlung.
Apidog eignet sich dafür als API-Regressionsframework. Die zugrunde liegende Testdisziplin entspricht klassischen API-Tests, wie in unserem API-Testleitfaden für QA-Ingenieure beschrieben.
Schritt 1: Eine Sammlung pro Baseline-Suite
Erstellen Sie eine Anfrage pro Baseline-Prompt für den Chat-Completions-Pfad:
POST {{base_url}}/chat/completions
Beispiel-Body:
{
"model": "glm-5.3",
"temperature": 0,
"messages": [
{
"role": "user",
"content": "Write a Python function that parses RFC 3339 timestamps and returns UTC datetimes."
}
]
}
Schritt 2: Zwei Umgebungen anlegen
Erstellen Sie mindestens diese beiden Environments.
hosted
base_url=https://api.z.ai/api/paas/v4
GLM_API_KEY=<ihr-api-key>
local
base_url=http://localhost:8000/v1
GLM_API_KEY=local-serving
Verwenden Sie in jeder Anfrage Variablen:
Authorization: Bearer {{GLM_API_KEY}}
POST {{base_url}}/chat/completions
Damit wechseln Sie den Zielendpunkt über ein Dropdown statt durch Änderungen an jeder einzelnen Anfrage.
Schritt 3: Assertions zuerst auf Struktur, dann auf Inhalt
Prüfen Sie zunächst die API-Form:
HTTP-Status ist 200
choices[0].message.content ist nicht leer
usage ist vorhanden
Fügen Sie danach robuste Inhaltsprüfungen hinzu. Für eine Python-Code-Baseline könnten das sein:
Antwort enthält: def
Antwort enthält: datetime
Antwort enthält: try
Vermeiden Sie Assertions auf exakten Wortlaut, wenn mehrere korrekte Implementierungen möglich sind.
Schritt 4: Gehostete Antworten als Beispiele speichern
Speichern Sie erfolgreiche Antworten aus der hosted-Umgebung als Referenz-Fixtures.
Beim lokalen Release-Tag-Run:
- Gewichte herunterladen
- vLLM oder SGLang starten
-
localauswählen - dieselbe Sammlung ausführen
- Ergebnisse gegen die gespeicherten Referenzen prüfen
Schritt 5: Headless über die CLI ausführen
Nutzen Sie den Apidog Runner, um die Sammlung ohne UI auszuführen. So wird der Vergleich skriptfähig und wiederholbar:
# Beispielhaft: Collection per Apidog Runner ausführen
apidog-cli run --environment local --collection glm53-regression
Führen Sie den Test erneut aus, sobald Sie eine dieser Variablen ändern:
- Quantisierungsstufe
- vLLM- oder SGLang-Version
- Tensor-Parallelität
- Expert-Parallelität
- Kontextlimit
- Prefix-Caching
- GPU-Topologie
Das Ziel ist ein reproduzierbarer Bericht: Bestanden/Nicht bestanden pro Prompt, nicht nur ein subjektiver Eindruck.
Client-Code bleibt gleich
Da sowohl die gehostete API als auch vLLM und SGLang OpenAI-kompatible Endpunkte bereitstellen, muss sich Ihr Anwendungs-Code kaum ändern.
Steuern Sie das Ziel über eine Umgebungsvariable:
import os
from openai import OpenAI
# Hosted: GLM_BASE_URL=https://api.z.ai/api/paas/v4
# Local: GLM_BASE_URL=http://localhost:8000/v1
client = OpenAI(
base_url=os.environ["GLM_BASE_URL"],
api_key=os.environ.get("GLM_API_KEY", "local-serving"),
)
response = client.chat.completions.create(
model="glm-5.3",
temperature=0,
messages=[
{
"role": "user",
"content": "Refactor this function to remove the nested loops: ..."
}
],
)
print(response.choices[0].message.content)
Registrieren Sie beim lokalen Server denselben Modellnamen:
--served-model-name glm-5.3
Dann bleibt der Modellstring für gehostete und lokale Requests identisch.
Testen Sie Tool-Calling, Streaming und JSON-Modus explizit. Gerade bei Tool-Aufrufen weichen lokale Serving-Stacks häufiger vom Verhalten gehosteter APIs ab.
Kostenrahmen: gehostete API oder eigene GPUs?
Zum Launch hatte Zhipu keine 5.3-spezifischen API-Preise veröffentlicht. Prüfen Sie vor einer Kostenrechnung die offizielle Preisgestaltungsseite.
Der Vergleich ist daher zunächst strukturell:
| Szenario | Typisch sinnvoller Ansatz |
|---|---|
| Geringe oder unregelmäßige Auslastung | Gehostete API |
| Evaluation und Proof of Concept | GPU-Stunden mieten |
| Hohe, kontinuierliche Token-Auslastung | Selbst-Hosting prüfen |
| Strenge Daten-Governance | Selbst-Hosting prüfen |
| Anforderungen an Netzwerkisolation oder Verfügbarkeit | Selbst-Hosting prüfen |
Ein 744B-MoE selbst zu hosten bedeutet, GPU-Kapazität auch dann zu bezahlen, wenn keine Tokens fließen. Selbst-Hosting wird typischerweise relevant, wenn:
- die dauerhafte Auslastung die API-Kosten übersteigt,
- Prompts und Daten im eigenen Netzwerk bleiben müssen,
- Sie Kontrolle über Latenz, Verfügbarkeit und Deployment benötigen.
Offene Gewichte dienen außerdem als Absicherung gegen Preisänderungen. Unsere Analyse der DeepSeek-API-Preiserhöhung zeigt, warum Teams ihre Unit Economics nicht ausschließlich auf Einführungspreise stützen sollten.
Checkliste für den Veröffentlichungstag
Die Punkte 1 bis 6 können Sie schon heute erledigen.
- Präzision festlegen: BF16, FP8 oder auf Community-Quants warten.
- Serving-Stack installieren: vLLM oder SGLang einrichten.
- Trockenlauf durchführen: Mit GLM-5.2 oder einem anderen MoE-Modell testen.
- API-Zugang einrichten: Z.ai-API-Schlüssel erstellen und die Modell-ID in der Live-Dokumentation prüfen.
- Baselines erfassen: 20 bis 50 Temperatur-0-Antworten von der gehosteten API speichern.
-
Apidog-Sammlung anlegen:
hosted- undlocal-Umgebungen plus Form- und Inhaltsassertions erstellen. - Kontextlimit definieren: Maximale bereitgestellte Kontextlänge je Deployment-Tier festlegen.
-
Repositories beobachten: huggingface.co/zai-org auf
GLM-5.3undGLM-5.3-FP8prüfen. - Lizenz lesen: Modellkarte und kommerzielle Nutzungsbedingungen vor dem Deployment prüfen.
-
Lokalen Server starten: Gewichte laden, Endpoint konfigurieren und
localaktivieren. - Regression ausführen: Lokale Ergebnisse mit gehosteten Fixtures vergleichen.
- Erst danach optimieren: Quantisierung, Parallelität, Prefix-Caching und Kontextlimits tunen.
FAQ
Kann ich GLM-5.3-Gewichte jetzt herunterladen?
Nein. Stand 14. August 2026 ist nur die gehostete API live. Zhipu erwartet die offenen Gewichte etwa zwei Wochen nach dem Release, um den 28. August. Das erwartete Ziel ist die zai-org Hugging-Face-Seite.
Läuft GLM-5.3 auf einer einzelnen Consumer-GPU?
Nicht mit vollständigen Gewichten. Die 744 Milliarden Gesamtparameter benötigen in FP8 rechnerisch etwa 744 GB vor dem KV-Cache. Auch INT4-Klasse-Quants liegen voraussichtlich im Multi-GPU-Bereich.
Für Single-GPU-Budgets sollten Sie kleinere lokale Modelle verwenden und GLM-5.3 über die gehostete API nutzen. Unsere Übersicht zu lokalen LLMs hilft bei der Auswahl.
Welches Serving-Framework sollte ich für GLM-5.3 verwenden?
vLLM ist die sicherste Standardoption: GLM-5-Familienunterstützung, MoE-bewusste Parallelisierung und OpenAI-kompatibler Server.
SGLang ist besonders interessant für Agenten-Workloads mit langen gemeinsamen Präfixen. llama.cpp, Ollama und LM Studio werden erst relevant, wenn Community-GGUF-Konvertierungen verfügbar sind.
Wird mein bestehender OpenAI-SDK-Code mit selbst gehostetem GLM-5.3 funktionieren?
Ja. Ändern Sie die base_url Ihres SDK von:
https://api.z.ai/api/paas/v4
auf Ihren lokalen vLLM- oder SGLang-Endpunkt:
http://localhost:8000/v1
Behalten Sie dabei dieselbe Request-Struktur. Testen Sie Streaming und Tool-Calling separat.
Warum sollte ich die gehostete API nutzen, wenn ich selbst hosten möchte?
Weil sie Ihre Referenzimplementierung ist. Ohne Baselines können Sie bei lokalen Abweichungen nicht erkennen, ob die Ursache Quantisierung, Serving-Konfiguration oder normales Modellverhalten ist.
Erfassen Sie die Baselines jetzt über den gehosteten Endpunkt und verwalten Sie sie mit dem GLM-5.3 API Quickstart und Apidog.
Wo GLM-5.3 in Ihren Stack passt
GLM-5.3 ist eine der stärksten Ankündigungen offener Gewichte für Coding-Workloads in diesem Jahr: hohe Ergebnisse auf Terminal-Bench 3.0 und Agents' Last Exam, ein CyberGym-Score über zwei Frontier-Modellen und ein angekündigter Zeitplan für offene Gewichte.
Der Vorteil in der ersten Woche hängt nicht primär vom größten GPU-Budget ab. Entscheidend ist Vorbereitung:
- Serving-Stack installiert
- Präzisionsstufe gewählt
- Hardware-Kapazität geprüft
- Kontextlimit festgelegt
- gehostete Baselines gespeichert
- Regressionstests automatisiert
Beginnen Sie mit der Checkliste, erfassen Sie diese Woche Ihre Baselines und laden Sie Apidog herunter, um sie zu verwalten: eine Sammlung, zwei Umgebungen (hosted und local) und Assertions, die aus „Funktioniert meine Bereitstellung?“ einen reproduzierbaren Bestanden/Nicht-bestanden-Bericht machen.
Top comments (0)