AIREITER

Muse Glimmer MLX auf dem Mac einrichten: Anleitung für das SGLang-Backend

Zuletzt aktualisiert: 2026-08-11 00:55:54

Seit Meta Muse Glimmer 30B am 10. August 2026 als multimodales Dense-Modell mit offenen Gewichten veröffentlicht hat, stoßen Mac-Nutzer schnell auf ein Problem: Viele MLX-Laufzeiten kennen die neue Architektur noch nicht und quittieren den Start mit model type muse_glimmer not supported.

Mit dem MLX-Backend von SGLang gibt es einen funktionierenden Weg. Dafür müssen Sie SGLang aus dem Quellcode bauen, konsequent Python 3.11 verwenden und eine Umgebungsvariable setzen. Danach stellt der Server eine OpenAI-kompatible API bereit, die sich direkt mit Coding-Agenten und Chat-Oberflächen nutzen lässt. Diese Anleitung bündelt die Schritte und bekannten Lösungen aus dem Roadmap-Issue #19137 von SGLang.

Voraussetzungen: Das braucht Ihr Mac

Muse Glimmer 30B ist ein dichtes multimodales Modell mit 30 Milliarden Parametern. Die Gewichte benötigen in einer 4-Bit-MLX-Quantisierung bereits rund 16–18 GB. Mit KV-Cache für ein Kontextfenster von 32K Tokens liegt der Arbeitsspeicherbedarf bei etwa 18–20 GB. SGLang begrenzt den Speicher zudem anhand von Metals empfohlener maximaler Working-Set-Größe (PR #21539). In der Praxis steht also weniger zur Verfügung als der gesamte Unified Memory Ihres Macs.

Mac-KonfigurationMuse Glimmer Q4 nutzbar?Empfohlener maximaler Kontext
16 GB (M1/M2/M3 Basis)Nein – OOM vor dem Laden des Modells-
32 GB (M2/M3/M4 Pro)Ja, aber knapp8K–16K Tokens
48 GB (M3/M4 Pro)Komfortabel32K Tokens
64 GB+ (M3/M4 Max)Komfortabel64K+ Tokens
128 GB+ (M3/M4 Ultra)Reserven für Q8128K+ Tokens

Ein Reddit-Nutzer fasste es bei der Veröffentlichung der Gewichte in r/opencodeCLI so zusammen:

"Macs mit 32 GB oder mehr Unified Memory sollten für höhere Quantisierungen geeignet sein."

Zusätzlich benötigen Sie macOS 13.5 oder neuer für Metal-Support, die Xcode Command Line Tools und Homebrew. Das MLX-Backend von SGLang ist ausschließlich mit Python 3.11 verifiziert. Andere Versionen können Probleme verursachen, wie die Roadmap ausdrücklich festhält.

Schritt 1: Python 3.11, uv und MLX installieren

Die Mac-Installation von SGLang beginnt mit zwei Homebrew-Paketen sowie einer von uv verwalteten virtuellen Umgebung mit Python 3.11.

  1. Homebrew-Abhängigkeiten installieren:
brew install ffmpeg uv

ffmpeg übernimmt die Audio- und multimodalen Verarbeitungspipelines. uv ist der schnelle Python-Paketmanager, den die SGLang-Roadmap für das Anlegen der virtuellen Umgebung empfiehlt.

  1. SGLang-Repository klonen:
git clone https://github.com/sgl-project/sglang.git
cd sglang
  1. Python-3.11-Umgebung erstellen und aktivieren:
uv venv -p 3.11 my-venv
source my-venv/bin/activate
python -m pip install --upgrade pip

Verwenden Sie weder Python 3.12 noch 3.13. Laut Roadmap brechen Triton-Stub-Importe ab Python 3.12+ (in PR #21551 korrigiert, aber noch nicht vollständig verifiziert). Auch die MLX-Kompilierungskette ist nur mit 3.11 getestet.

  1. MLX-Laufzeitpakete in der aktuellen Version installieren:
pip install mlx mlx-lm mlx-vlm --upgrade

Die Roadmap warnt ausdrücklich davor, veraltete Versionen von mlx oder mlx-lm einzusetzen: Sie können umfangreiche Profiling-Ausgaben und Fehler bei der Architekturerkennung verursachen. PR #22162 hat diese Pakete als explizite SGLang-Abhängigkeiten ergänzt. Für multimodale Modelle wie Muse Glimmer ist mlx-vlm erforderlich; fehlt es, erscheint beim Start der Fehler model type muse_glimmer not supported.

Schritt 2: SGLang mit MLX-Backend aus dem Quellcode bauen

Das reguläre Paket pip install sglang enthält keine MLX-Unterstützung. Auf dem Mac müssen Sie SGLang daher aus dem Quellcode mit den Apple-MPS-Extras installieren.

  1. pyproject.toml austauschen:
cp python/pyproject.toml python/pyproject.toml.bak
cp python/pyproject_other.toml python/pyproject.toml

Die Datei pyproject_other.toml entfernt reine CUDA-Abhängigkeiten, die sich unter macOS nicht bauen lassen, und ersetzt sie durch MPS-kompatible Alternativen.

  1. SGLang im Editable-Modus mit MPS-Extras installieren:
uv pip install -e "python[all_mps]"

Dadurch werden die Metal-Kernel-Stub-Dateien kompiliert und der Laufzeitpfad für Apple Silicon installiert. Je nach Mac dauert der Build mehrere Minuten; die Metal-Builds von sgl-kernel (PR #23449) beanspruchen dabei am meisten Zeit.

  1. Installation prüfen:
python -c "import sglang; print(sglang.__version__)"

Wenn dieser Import ohne Triton-Fehler durchläuft, ist der MPS-Pfad korrekt eingerichtet.

Schritt 3: Muse Glimmer im MLX-Format herunterladen

Die MLX Community stellt auf Hugging Face einen 4-Bit-quantisierten Build von Muse Glimmer bereit:

huggingface-cli download mlx-community/Muse-Glimmer-30B-4bit

Falls huggingface-cli noch nicht installiert ist, installieren Sie zunächst das passende Paket:

pip install huggingface-hub

Der Download ist ungefähr 16–17 GB groß. Standardmäßig legt huggingface-cli download das Modell unter ~/.cache/huggingface/hub/ ab. SGLang kann die Hugging-Face-Repository-ID direkt über --model-path auflösen; alternativ geben Sie den lokalen Cache-Pfad an.

Speicherbedarf im Überblick:

KomponenteUngefährer Speicherbedarf (Q4)
Modellgewichte (4-Bit)~16–17 GB
KV-Cache (32K Kontext, F16)~1,5–2 GB
Laufzeit + Overhead~1–2 GB
Gesamtes Working Set~18–21 GB

Auf einem Mac mit 32 GB lässt sich das Modell somit laden, doch für große Kontextfenster bleibt wenig Reserve. Startet der Server, stürzt aber beim ersten langen Prompt ab, reduzieren Sie --context-length auf 8192 oder 16384.

Schritt 4: Den SGLang-Server starten

Sobald Abhängigkeiten und Modell bereitstehen, reicht ein einzelner Startbefehl. Entscheidend ist dabei die Umgebungsvariable:

SGLANG_USE_MLX=1 python -m sglang.launch_server \
  --model-path mlx-community/Muse-Glimmer-30B-4bit \
  --port 30000 \
  --context-length 32768

Die wichtigsten Parameter:

  • SGLANG_USE_MLX=1 aktiviert das native MLX-Backend, statt auf PyTorch MPS oder die CPU zurückzufallen. Ohne diese Variable startet der Server zwar, arbeitet aber nur mit einem Bruchteil der Geschwindigkeit.
  • --model-path verweist auf das 4-Bit-Modell im MLX-Format. SGLang erkennt dank PR #25191 die MLX-quantization_config automatisch; zusätzliche Flags sollten nicht nötig sein.
  • --context-length begrenzt das maximale Kontextfenster. Bei Speicherproblemen reduzieren Sie den Wert. Muse Glimmer unterstützt laut Community-Tests und Metas Release Notes theoretisch bis zu 262K Tokens, auf einem Mac mit Unified Memory liegen die praktikablen Grenzen aber deutlich darunter.

Für Fortgeschrittene: SGLang kann BF16-Gewichte bei Bedarf auch direkt mit --quantization mlx_q4 oder mlx_q8 quantisieren (PR #24907). Das Starten dauert länger als beim Laden eines vorbereiteten 4-Bit-Modells. Nutzen Sie diese Option daher nur, wenn Sie den Quantisierungsprozess selbst steuern müssen.

Schritt 5: Die OpenAI-kompatible API testen

Sobald der Server Server is ready ausgibt, testen Sie den OpenAI-kompatiblen Endpunkt mit einer curl-Anfrage:

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "muse-glimmer",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Explain how GQA reduces KV cache size in one sentence."}
    ],
    "max_tokens": 200
  }'

Bei Erfolg erhalten Sie ein JSON-Objekt mit der Antwort. Benchmark-Daten aus der SGLang-Roadmap zufolge sind auf einem M5 Pro mit dem 4-Bit-Modell bei Einzelbenutzer-Decoding etwa 17,6 Tokens pro Sekunde zu erwarten.

Wichtig: Wählen Sie max_tokens großzügig, also 200 oder mehr. Muse Glimmer verfolgt einen Reasoning-First-Ansatz, bei dem Chain-of-Thought-Tokens einen großen Teil des Ausgabe-Budgets verbrauchen können. Scheinen Antworten leer oder abgeschnitten, ist max_tokens meist zu niedrig: Das interne Reasoning verbraucht dann das gesamte Budget, bevor eine sichtbare Antwort erscheint.

MLX-Tuning: Diese Umgebungsvariablen gibt es

SGLang bietet drei MLX-spezifische Umgebungsvariablen, die in der offiziellen Referenz der Umgebungsvariablen dokumentiert sind. Standardmäßig sind sie deaktiviert oder konservativ eingestellt.

VariableStandardFunktion
SGLANG_MLX_USE_CUSTOM_ROPEfalseVerwendet einen eigenen Metal-RoPE-Kernel mit zusammengeführter KV-Cache-Speicherung (PR #22868). Kann bei langen Kontexten das Prefill beschleunigen.
SGLANG_MLX_FUSE_SWIGLUfalseFührt die SwiGLU-Aktivierung in einem einzelnen Metal-Kernel zusammen. Muse Glimmer nutzt SwiGLU in allen 52 Layern, weshalb sich der Overhead von Kernel-Starts beim Decoding reduzieren kann.
SGLANG_MLX_CLEAR_CACHE_STEPS256Leert den internen MLX-Cache alle N Decoding-Schritte, um Speicherfragmentierung vorzubeugen. Mit 0 wird das Leeren vollständig deaktiviert; das empfiehlt sich nur bei reichlich verfügbarem Speicher.

Beispiel mit aktivierten Optimierungen:

SGLANG_USE_MLX=1 \
SGLANG_MLX_USE_CUSTOM_ROPE=true \
SGLANG_MLX_FUSE_SWIGLU=true \
SGLANG_MLX_CLEAR_CACHE_STEPS=128 \
python -m sglang.launch_server \
  --model-path mlx-community/Muse-Glimmer-30B-4bit \
  --port 30000 \
  --context-length 32768

Diese Funktionen gelten laut Roadmap als experimentell. Führt eines der Kernel-Fusion-Flags zu einem Absturz, deaktivieren Sie es und melden Sie den Fehler. Das MLX-Backend wird weiterhin aktiv weiterentwickelt.

Typische Fehler und ihre Lösungen

"Model type muse_glimmer not supported"

Das ist zum Start einer neuen Architektur der häufigste Fehler. Er bedeutet, dass Ihre MLX-Laufzeit – mlx-lm oder mlx-vlm – den Architekturtyp muse_glimmer nicht erkennt. Die Lösung:

pip install mlx-lm mlx-vlm --upgrade

Bleibt der Fehler bestehen, prüfen Sie, ob Ihr SGLang-Checkout den PR für Qwen3 Dense MLX Support enthält (#25754). Dieser ergänzt Architekturumschreibungen für dichte Transformer-Modelle. Möglicherweise müssen Sie mit git pull zunächst den aktuellen main-Branch holen.

Triton-Stub-Absturz mit Python 3.12

Das Setup von SGLang importiert Triton-Stubs, die mit Python 3.12+ nicht kompatibel sind. Erstellen Sie die virtuelle Umgebung deshalb mit Python 3.11 neu:

deactivate
rm -rf my-venv
uv venv -p 3.11 my-venv
source my-venv/bin/activate
uv pip install -e "python[all_mps]"

PR #21551 hat den Triton-Importpfad korrigiert, doch Python 3.11 bleibt die einzige vollständig verifizierte Version.

Server läuft, nutzt aber die CPU

Ist die Token-Generierung extrem langsam, also unter 2 Tokens pro Sekunde, ist SGLang vermutlich auf die CPU zurückgefallen, weil SGLANG_USE_MLX=1 nicht gesetzt war. Prüfen Sie das mit:

echo $SGLANG_USE_MLX

Bleibt die Ausgabe leer, exportieren Sie die Variable vor dem Serverstart oder stellen Sie sie dem Startbefehl direkt voran.

MLX-Speicherabsturz oder Neustart des Systems

Wird die von Metal empfohlene Working-Set-Größe überschritten, kann der Server abstürzen oder sich macOS in schweren Fällen vollständig neu starten. Die Roadmap begrenzt das Working Set seit PR #21539, große Kontextfenster können das Limit aber weiterhin übersteigen. Das hilft:

  • --context-length auf 8192 oder weniger reduzieren
  • SGLANG_MLX_CLEAR_CACHE_STEPS=64 setzen, damit der Cache häufiger geleert wird
  • Das 4-Bit-Modell statt einer On-the-fly-Quantisierung aus BF16-Gewichten verwenden
  • Andere GPU-intensive Anwendungen schließen, insbesondere Safari mit Hardwarebeschleunigung

Tool-Calling-Schleifen oder leere Ergebnisse

In Community-Threads auf r/LocalLLaMA wird berichtet, dass Muse Glimmer Tool Calling je nach Quantisierung uneinheitlich handhabt. Nutzer, die sowohl MLX- als auch GGUF-Varianten testen, melden Tool-Calling-Schleifen. Das Problem ist nicht auf MLX beschränkt, sondern tritt in mehreren Laufzeiten auf. Setzen Sie bei Function Calling max_tokens auf 500 oder mehr, testen Sie zunächst Workflows mit einem einzelnen Aufruf und ziehen Sie Qwen 3.6 27B in Betracht, falls zuverlässiges Tool Calling für Sie oberste Priorität hat.

FAQ

Unterstützt das MLX-Backend von SGLang Speculative Decoding für Muse Glimmer?

Noch nicht. Die SGLang-Roadmap führt EAGLE Speculative Decoding für das MLX-Backend als geplant, aber noch nicht implementiert. Auf dem Mac bleibt es damit beim normalen autoregressiven Decoding mit laut Benchmark-Daten ungefähr 17,6 Tokens pro Sekunde auf einem M5 Pro mit Q4, wie in der Roadmap-Diskussion angegeben.

Für Muse Glimmer auf dem Mac: MLX oder GGUF?

MLX ist der native Weg für Apple Silicon: Es nutzt Metal direkt und profitiert vom Unified Memory ohne explizite CPU-zu-GPU-Kopien. GGUF über llama.cpp ist die Ausweichlösung, wenn Ihre MLX-Laufzeit noch keine Architekturunterstützung für muse_glimmer bietet. Die beiden wichtigsten Optionen sind der 4-Bit-Build der MLX Community und der Unsloth-GGUF-Build auf Hugging Face. Sobald es läuft, liefert MLX in der Regel höhere Decoding-Geschwindigkeiten; GGUF bietet eine breitere Tool-Kompatibilität, etwa mit LM Studio und Ollama.

Wie schlägt sich SGLang MLX beim Serving gegen mlx-lm oder Ollama?

SGLang bietet einen OpenAI-kompatiblen API-Server mit Radix-Caching und den oben beschriebenen Tuning-Variablen. mlx-lm ist einfacher gehalten: Es lädt Modelle und erzeugt Text mit weniger Konfigurationsoptionen, aber ohne Server-Abstraktion. Ein Reddit-Nutzer berichtete in r/LocalLLM von einem Ollama-Tag muse-glimmer:30b-mlx mit eigener API-Schicht. Für eine direkt einsetzbare API für Coding-Agenten wie OpenCode CLI sind SGLang oder Ollama die praktischen Optionen; für schnelle Einzelgenerierungen genügt mlx-lm.