GLM-5.2 bietet Open-Weight-Coding-Modellen ein echtes 1M-Token-Context-Fenster. Das Schwierige ist, dieses vollständige Fenster auf der Hardware bereitzustellen, die viele Teams bereits in Produktion einsetzen: Hopper.

Wir haben GLM-5.2-FP8 in W4AFP8 quantisiert und es mit SGLang auf einem einzelnen 8×H200-Knoten validiert. Das Checkpoint reduziert den Speicherbedarf der Gewichte von 755 GB auf 368 GB und schafft so 387 GB HBM frei für den 1M-Token-KV-Cache und zusätzlichen Laufzeitspeicher.

Warum das wichtig ist

GLM-5.2 hat bereits die Modellseite von langem Kontext gelöst: Sparse Attention, IndexShare, MTP spekulatives Decoding, Tool-Nutzung, Reasoning und ein 1.048.576-Token-Fenster. Beim Deployment gibt es jedoch noch ein zweites Problem. Ein 1M-Token-Fenster braucht Platz für Modellgewichte, KV-Cache, CUDA-Graphs, Runtime-Buffer und den Serving-Overhead.

Das offizielle FP8-Checkpoint ist der richtige allgemeine Serving-Benchmark. Auf Hopper lässt dieser Benchmark deutlich weniger Speicherfreiraum, sobald man sich dem vollständigen Context-Fenster nähert. W4AFP8 verändert das Speicherbudget, ohne die Modellfamilie, den Tokenizer, die API-Form oder das Verhalten von GLM-5.2 zu ändern.