GLM-5.2 lokal: Ollama + LM Studio, der Riese MIT

#Warum GLM-5.2 lokal?

Die meisten „Frontier“-Modelle (die größten und leistungsfähigsten) bleiben hinter einer API verschlossen: GPT, Gemini oder die Versionen von Qwen und DeepSeek mit 100 Milliarden oder mehr Parametern. GLM-5.2 durchbricht diese Logik. Zhipu AI hat die vollständigen Gewichte unter der MIT-Lizenz veröffentlicht – der permissivsten überhaupt, ohne Klausel zur Namensnennung oder zur Weitergabe unter gleichen Bedingungen – und die Community hat schon zur Veröffentlichung funktionsfähige GGUF-Quantisierungen erstellt. Das Ergebnis: Sie können ein Modell der Frontier-Klasse zu Hause hosten, ohne Konto, ohne Kontingentbegrenzung und ohne dass Daten nach außen gelangen.

Der Vorteil liegt nicht in der Geschwindigkeit – um es klar zu sagen: Ein lokal ausgeführtes 753B-Modell wird bei der Reaktionsgeschwindigkeit niemals mit einem Cloud-Endpunkt mithalten können. Der Vorteil liegt in der vollständigen Souveränität über ein Modell, das in puncto reiner Qualität in derselben Liga wie die besten proprietären Dienste spielt: ausführliches Schlussfolgern, Arbeit mit Code in großen Codebasen, ein Kontext von 1 Million Tokens. Für einen Code-Agenten, der stundenlang mit proprietärem Code unter NDA arbeitet, ist die Geschwindigkeit der Vertraulichkeit nachgeordnet.

#Was sich seit GLM-5.1 verändert

Wenn Sie ein GLM-Modell mit überschaubaren Anforderungen auf einer GPU mit 12 bis 24 GB installieren möchten, ist dieser Leitfaden nicht der richtige: GLM-5.1 (dichte Modelle mit 9B und 32B) ist dafür gedacht, und unser eigener Leitfaden dazu behandelt es ausführlich. GLM-5.2 richtet sich an eine andere Zielgruppe. Die Verwechslung kommt häufig vor, weil die Namen aufeinander folgen, aber die beiden Modelle gehören nicht in dieselbe Hardware-Kategorie.

Architektur

GLM-5.1 hat eine dichte Architektur (9B, 32B). GLM-5.2 ist ein MoE mit insgesamt 753B Parametern, bei dem pro Token nur ein Teil der Experten aktiviert wird. Es lässt sich nicht auf einer einzelnen Consumer-GPU betreiben.

Lizenz

GLM-5.1 steht unter der GLM License (einer Apache-Variante mit Namensnennung). GLM-5.2 wechselt zur reinen MIT-Lizenz – kommerzielle Nutzung ohne Einschränkungen, keine virale Klausel.

Kontext

128k bei GLM-5.1 (1M über YaRN mit Qualitätseinbußen). GLM-5.2 unterstützt nativ 1M Tokens, ein echter Vorteil für die Analyse großer Repositories.

Zielhardware

GLM-5.1: eine GPU mit 8–24 GB. GLM-5.2: ein Mac mit 256 GB Unified Memory, eine Multi-GPU-Box oder ein Server mit viel RAM und Offloading.

Anwendungsfälle

GLM-5.1 für einen lokalen Assistenten mit kurzen Reaktionszeiten. GLM-5.2 als Frontier-Referenzmodell, wenn Qualität wichtiger ist als Geschwindigkeit.

#753B MoE: Das Modell verstehen

GLM-5.2 ist ein Mixture-of-Experts-Modell: Von seinen 753 Milliarden Parametern wird bei jedem generierten Token nur ein Bruchteil aktiviert. Dadurch kommt lokale Inferenz überhaupt infrage – der Rechenaufwand pro Token bleibt überschaubar –, doch der Haken liegt woanders: Sämtliche Gewichte müssen in den Speicher passen, auch die Experten, die zu einem bestimmten Zeitpunkt nicht genutzt werden. Der begrenzende Faktor ist der Speicher, nicht die Rechenleistung.

Gesamtparameter

753B, verteilt auf einen gemeinsamen Backbone und einen Pool dynamisch gerouteter Experten.

Aktive Parameter

Ein Bruchteil pro Token (Top-k-Routing). Das ermöglicht trotz der Gesamtgröße einen ordentlichen Durchsatz.

Kontext

Nativ 1 Million Tokens Kontext. Achtung: Der KV-Cache für 1 Million Tokens verbraucht enorm viel Speicher; nutzen Sie diese Kontextlänge nur in Fällen, die sie rechtfertigen.

Lizenz

MIT. Sie können das Modell feinabstimmen, verteilen und in kommerzielle Produkte integrieren, ohne Verpflichtungen.

Format

Originalgewichte in BF16 (~1,5 TB). In dieser Form lokal unbrauchbar: Hier kommen die quantisierten GGUF-Versionen ins Spiel.

#Die GGUF-Quants (unsloth)

Die Community hat die Quantisierungen erstellt, die GLM-5.2 nutzbar machen. Die dynamischen Quantisierungen von Unsloth sind die Referenz: Sie verwenden je nach Bedeutung der Schichten eine unterschiedliche Präzision und erhalten dadurch die Qualität besser als eine einheitliche Quantisierung bei gleicher Modellgröße. Das ist bei sehr niedriger Präzision entscheidend, denn jedes Bit zählt.

Q2_K_XL (unsloth)

~200 GB. Der realistische Einstieg. Die Qualität ist schlechter, aber noch brauchbar; diese Version passt auf einen Mac mit 256 GB oder ein System mit mehreren RTX 4090.

Q4_K_M

~380–400 GB. Der optimale Bereich für die Qualität, aber nur für Server mit sehr großem Speicher oder leistungsstarke Multi-GPU-Systeme geeignet.

Q5_K_M

~480 GB. Bei dieser Art von Modell kaum ein wahrnehmbarer Gewinn gegenüber Q4; für den lokalen Einsatz selten gerechtfertigt.

Q8_0 / BF16

800 GB bis 1,5 TB. Das ist der Bereich professioneller GPU-Server und liegt außerhalb der Möglichkeiten eines handelsüblichen Rechners.

# huggingface-cli doit être installé : pip install -U huggingface_hub
# Q2_K_XL est réparti en plusieurs shards GGUF
huggingface-cli download unsloth/GLM-5.2-GGUF \
  --include "*Q2_K_XL*" \
  --local-dir ./glm-5.2-gguf

#Realistische Hardwarevoraussetzungen

Es gibt keine „leichte“ Konfiguration für GLM-5.2. Hier sind die beiden Konfigurationsprofile, die tatsächlich funktionieren, ohne die Zahlen zu schönen.

Mac Apple Silicon 256 GB

Ein Mac Studio der M-Serie mit 256 GB Unified Memory bietet Platz für Q2_K_XL und lässt noch Spielraum für den Kontext. Unified Memory ist hier ein entscheidender Vorteil: keine Trennung zwischen CPU- und GPU-Speicher.

Mac 192 GB

Machbar, aber knapp: Q2_K_XL passt in den Speicher, aber verkleinern Sie das Kontextfenster und schließen Sie alles andere. 128 GB liegen unter der praktisch nutzbaren Mindestkapazität.

Multi-GPU-Box

Mehrere RTX 4090 (jeweils 24 GB) plus viel System-RAM für das CPU-Offloading. 200 GB passen nicht allein in den VRAM; sie werden auf GPU-Speicher und RAM verteilt.

Speicher

Mindestens 200 GB freier Speicherplatz für Q2, eine schnelle NVMe-SSD (beim ersten Laden werden Hunderte GB gelesen).

System-RAM (Rechner)

Mindestens 128 GB RAM, wenn Sie Experten auf die CPU auslagern, 256 GB für ausreichend Spielraum.

#1. Installation mit LM Studio

LM Studio ist für ein Modell dieser Größe oft die einfachste Lösung, besonders auf dem Mac: Die MLX-Engine und die Speicherverwaltung sind ausgereift, und die Benutzeroberfläche zeigt in Echtzeit, wie viel Speicher das Modell benötigt, bevor es geladen wird. Das ist wertvoll, wenn man sich der Speichergrenze nähert.

1. 01
   1. LM Studio installieren

   Laden Sie LM Studio von der offiziellen Website (lmstudio.ai) herunter und installieren Sie es. Wählen Sie auf dem Mac die native Version für Apple Silicon.
2. 02
   2. Das Modell suchen

   Geben Sie im Suchtab „GLM-5.2“ ein und suchen Sie das GGUF-Repository von unsloth. LM Studio zeigt für jede Quantisierung an, ob sie mit Ihrem verfügbaren RAM kompatibel ist (grüne/orange/rote Kennzeichnung).
3. 03
   3. Die Quantisierung Q2_K_XL wählen

   Wählen Sie die Variante Q2_K_XL. LM Studio lädt alle Shards automatisch herunter — planen Sie je nach Ihrer Verbindung viel Zeit ein (200 GB).
4. 04
   4. Den Kontext einstellen

   Reduzieren Sie vor dem Laden die Kontextlänge auf einen sinnvollen Wert (8k–16k zum Testen). Stellen Sie nicht gleich zu Beginn 1M ein: Der KV-Cache würde den Speicherbedarf explodieren lassen.
5. 05
   5. Laden und testen

   Klicken Sie auf « Load ». Beobachten Sie die Speicheranzeige. Sobald das Modell geladen ist, senden Sie einen ersten Prompt und messen Sie den angezeigten Durchsatz in tok/s.

#2. Installation mit Ollama

Ollama kann GLM-5.2 auch aus einer GGUF-Datei bereitstellen, über ein Modelfile, das auf die heruntergeladenen Dateien verweist. Dies ist die bevorzugte Methode, wenn Sie das Modell anderen Tools (Agenten, IDEs, Open WebUI) über eine OpenAI-kompatible API zur Verfügung stellen möchten.

# Fichier : Modelfile
FROM ./glm-5.2-gguf/GLM-5.2-Q2_K_XL-00001-of-00005.gguf

PARAMETER num_ctx 16384
PARAMETER temperature 0.6

# Créer l'entrée Ollama à partir du Modelfile
ollama create glm-5.2 -f Modelfile

# Lancer
ollama run glm-5.2

Nach der Erstellung wird GLM-5.2 wie jedes andere Ollama-Modell über den Standard-Endpunkt http://localhost:11434 bereitgestellt. Jeder OpenAI-kompatible Client kann das Modell dann abfragen, indem er auf diese Adresse verweist.

# Dans un autre terminal, après le premier prompt
ollama ps

#3. Mac-Konfiguration mit 256 GB

Das ist die eleganteste Konfiguration für GLM-5.2. Der vereinheitlichte Speicher von Apple Silicon bedeutet, dass GPU und CPU denselben Speicherpool nutzen: keine aufwendigen Datenübertragungen, keine manuelle Aufteilung. Ein Mac Studio mit 256 GB lädt die Q2_K_XL-Variante und lässt noch Platz für ein komfortables Kontextfenster.

Geladenes Modell

Q2_K_XL (~200 GB) passt in den Speicher; für den KV-Cache und das System bleiben etwa 40–50 GB übrig.

Erwarteter Durchsatz

Etwa 5 bis 12 Tok/s bei der Generierung je nach Kontextlänge. Angemessen für asynchrone Aufgaben, frustrierend für schnelle interaktive Chats.

Praktikable Kontextlänge

32k bis 64k ohne Probleme. Eine Erweiterung auf 128k und mehr ist möglich, beansprucht durch den KV-Cache aber schnell viel Speicher.

Empfohlenes Tool

LM Studio für eine einfache Bedienung oder Ollama, wenn Sie Agenten daran anbinden.

#4. Box RTX 4090 im 2-Bit-Format

Auf PCs müssen Sie die Trennung zwischen VRAM und RAM berücksichtigen. Eine einzelne RTX 4090 (24 GB) kann natürlich keine 200 GB aufnehmen: Die Strategie besteht darin, möglichst viele Experten in den VRAM zu laden und den Rest mit llama.cpp in den System-RAM auszulagern. Der Durchsatz hängt dann direkt vom GPU/CPU-Verhältnis und der Geschwindigkeit Ihres RAM ab.

./llama-server \
  -m glm-5.2-gguf/GLM-5.2-Q2_K_XL-00001-of-00005.gguf \
  -c 16384 \
  -ngl 99 \
  --n-cpu-moe 40 \
  -fa \
  --host 0.0.0.0 --port 8080

-ngl 99

Versucht, möglichst viele Schichten auf der GPU unterzubringen. llama.cpp füllt den verfügbaren VRAM und verlagert den Rest auf die CPU.

--n-cpu-moe 40

Belässt die angegebenen MoE-Schichten auf der CPU. Das ist der entscheidende Hebel bei einem MoE: Der dichte Backbone wird im VRAM gehalten, die Experten werden in den RAM ausgelagert. Passen Sie die Anzahl an Ihren verfügbaren VRAM an.

-fa

Flash Attention reduziert den Speicherbedarf des KV-Caches. Aktiviert lassen.

Multi-GPU

Mit 2 bis 4 RTX 4090 verteilt llama.cpp automatisch (--split-mode). Mehr VRAM bedeutet weniger CPU-Offload und damit besseren Durchsatz.

#5. Lang laufende Coding-Agenten

Genau hier ergibt GLM-5.2 im lokalen Betrieb trotz seiner Langsamkeit Sinn. Ein Code-Agent, der eine große Codebasis refaktoriert, Dutzende Dateien liest und über Stunden hinweg Schlussfolgerungen zieht, lässt sich von einer Latenz von einigen Sekunden pro Token nicht stören: Er arbeitet im Hintergrund. Entscheidend sind die Qualität des Schlussfolgerns und das Kontextfenster von 1 Million Tokens, mit dem er das gesamte Repository im Blick behalten kann – ohne dass auch nur eine Zeile proprietären Codes Ihren Rechner verlässt.

Riesiges Kontextfenster

Die Million Tokens ermöglicht es, eine vollständige Codebasis in den Prompt einzufügen, statt sie aufzuteilen. Das verbessert die Konsistenz von Änderungen über mehrere Dateien hinweg.

Tool Calling

GLM-5.2 unterstützt Werkzeugaufrufe im OpenAI-Format – unverzichtbar für einen Agenten, der liest, schreibt und ausführt.

OpenAI-Endpoint

Über Ollama (localhost:11434) oder llama.cpp (localhost:8080) verbinden Sie Aider, Cline oder jeden anderen Agenten, der die OpenAI-API nutzt.

Asynchrones Arbeiten

Starten Sie die Aufgabe und machen Sie etwas anderes. Bei 5–10 Tok/s dauert ein umfangreiches Refactoring eine Weile, läuft aber ohne Aufsicht.

#Realistische Erwartungen und Fehlerbehebung

Kein seriöser Leitfaden wird behaupten, dass ein 753B-Modell lokal flüssig läuft. Hier sind die tatsächlichen Probleme und die entsprechenden Lösungen.

Swap auf der Festplatte = Todesstoß

Wenn das Modell nicht mehr in den Arbeitsspeicher passt und auf die Auslagerungsdatei auf dem Datenträger ausweicht, dauert die Generierung mehrere Sekunden pro Token. Reduzieren Sie den Kontext, wählen Sie eine kleinere quantisierte Variante oder schließen Sie andere Anwendungen mit hohem RAM-Verbrauch.

Sehr langsamer Ladevorgang

Das Laden von 200 GB von einer SSD dauert mehrere Minuten. Das ist normal. Eine schnelle NVMe-SSD macht einen deutlichen Unterschied; ein externes USB-Laufwerk sollten Sie keinesfalls verwenden.

OOM beim Laden

Passen Sie auf einem Mac das GPU-Limit (iogpu.wired_limit_mb) an. Erhöhen Sie auf einem PC --n-cpu-moe, um mehr Experten in den RAM auszulagern.

Qualität nimmt ab

Bei 2-Bit-Quantisierung kann das Modell häufiger halluzinieren. Senken Sie die Temperatur (0,6 oder niedriger) und bevorzugen Sie dynamische Quantisierungen von unsloth statt einer einheitlichen Q2-Quantisierung.

Enttäuschender Durchsatz

Das ist zu erwarten. Ein Modell in der Größenordnung von Frontier-Modellen ist im lokalen Betrieb nicht schnell. Wenn Sie Wert auf Geschwindigkeit legen, reagieren GLM-5.1 32B oder ein Qwen3 deutlich schneller.

#Weiterführende Informationen

GLM-5.2 ist ein Extremfall, bei dem Quantisierung, Hardware und die Bereitstellung von Agenten eine Rolle spielen. Diese Leitfäden behandeln die Grundlagen, die Sie in diesen Bereichen beherrschen sollten.

Der vernünftige kleine Bruder

„GLM 5.1 lokal: die Open-Weight-Alternative, die Sie kennen sollten“ – wenn Ihre Hardware auf 24 GB begrenzt ist, ist das das richtige GLM-Modell für Sie: Es reagiert deutlich schneller.

Die Quantisierung verstehen

„Die Quantisierung wählen (Q4, Q5, Q8, FP16)“ – unerlässlich, um zu verstehen, warum die dynamische 2-Bit-Quantisierung GLM-5.2 zugänglich macht, ohne es zu zerstören.

Programmieren mit einem lokalen Agenten

„Aider + Ollama: im Terminal mit einem 100 % lokalen Agenten programmieren“ – der Ausgangspunkt, um GLM-5.2 in einen echten Entwicklungsworkflow zu integrieren.