Optimierung von GLM-4.7-Flash auf dem M4 Mac Mini mit 24 GB RAM

✍️ OpenClawRadar📅 Veröffentlicht: 24. Februar 2026🔗 Source
Optimierung von GLM-4.7-Flash auf dem M4 Mac Mini mit 24 GB RAM
Ad

Praktische Konfiguration für GLM-4.7-Flash auf M4-Hardware

Ein Entwickler, der OpenClaw und Ollama auf einem M4 Mac Mini mit 24 GB RAM testet, hat spezifische Optimierungsdetails für den Betrieb des GLM-4.7-Flash-Modells geteilt. Die Quelle liefert konkrete Realitäten der Speicherzuweisung und Konfigurationsparameter, die innerhalb der Hardwaregrenzen funktionieren.

Speicherrealität und Modellauswahl

Die Tests zeigen, dass das effektive GPU-Speicherbudget auf dem M4 Mini etwa 17,8 GB Metal (GPU-wired) beträgt, nicht die vollen 24 GB. Der Rest wird von macOS, Anwendungen und CPU-Berechnungen belegt. Diese Einschränkung beeinflusst die Modellauswahl und Kontextgröße.

  • Q4_K_XL-Quantisierung (17,5 GB GGUF) kann 32k Kontext nicht verarbeiten: Modell (14,4 GB) + KV (2,8 GB) + Berechnung (1,4 GB) = 18,6 GB → Speichermangel
  • Q3_K_XL-Quantisierung (13,8 GB GGUF) funktioniert bei 32k Kontext: Modell (12,7 GB) + KV (3,2 GB) + Berechnung (1,4 GB) = 16,1 GB mit 1,7 GB Puffer
  • Die Kontextobergrenze liegt bei etwa 34k, bevor Speichermangel auftritt

Konfigurationsdetails

Die erfolgreiche Einrichtung verwendet:

  • Modell: unsloth/GLM-4.7-Flash-GGUF von Hugging Face
  • Quantisierung: Q3_K_XL
  • Kontextgröße: 32k mit MLA (Multi-Head Latent Attention)
  • KV-Cache-Implementierung: llama.cpp's v-less KV-Cache (PR #19067, Jan 2026) ausgelöst durch GGUF-Metadaten (key_length_mla, kv_lora_rank)
  • Build-Anforderung: llama.cpp b7860+

Die MLA-Implementierung reduziert den KV-Speicherverbrauch erheblich - der 32k-Kontext-KV-Cache beträgt nur 3,2 GB statt 13 GB.

Ad

Framework-spezifische Überlegungen

Agenten-Frameworks wie OpenClaw haben interne Kontextschwellenwerte, die die Leistung beeinflussen:

  • OpenClaw löst unter 32k Kontext aggressive Komprimierung aus
  • Erhöhung des Kontexts von 20k auf 32k reduzierte die Startzeit von 5 Minuten auf 2 Minuten 17 Sekunden
  • Komprimierungsdurchläufe sanken von 2 auf 1 bei Anpassung von num_ctx an Framework-Schwellenwerte
  • num_ctx muss in die Ollama Modelfile integriert werden - OpenClaw und andere Orchestratoren, die Ollamas OpenAI-kompatible API verwenden, ignorieren es auf Anfrageebene

Leistungstestdaten

Der Entwickler lieferte spezifische Zeitdaten für verschiedene Aufgaben:

Aufgabe                     Zeit   Eingabe-Tokens  Komprimierungen  Ergebnis
Persönlichkeitseinführung   119s   ~13.900        2                ✅
Profilabruf                 60s    13.247         2                ✅ mit Einschränkung
Aufgabenerstellung          61s    13.375         2                ✅
Speicherschreiben           165s   14.448         2                ✅
Speicherabruf               89s    14.085         2                ✅
Websuche + Synthese         273s   18.668         2                ✅

MLX-Überlegungen

Der Entwickler weist darauf hin, dass MLX und GGUF unterschiedliche Formate sind - Unsloth/bartowski GGUF-Dateien können nicht mit mlx-lm ausgeführt werden. Derzeit existiert kein 3-Bit-Flash-Modell im mlx-community-Repository, nur 4-Bit-Modelle sind verfügbar.

📖 Read the full source: r/openclaw

Ad

👀 Siehe auch