Am 10. August 2026 hat Meta Superintelligence Labs Muse Glimmer veröffentlicht: ein multimodales 30B-Modell unter Apache-2.0-Lizenz und das open-weight-Pendant zum geschlossenen Muse Spark. Es ist auf agentenbasierte Aufgaben ausgelegt: mehrstufiges Reasoning, Tool-Use und Code-Generierung. In der 4-Bit-Variante belegt es 18 GB VRAM und läuft damit auf Consumer-GPUs wie einer RTX 4090 oder einem Mac mit M4-Chip.
Dieser Beitrag zeigt den kürzesten Weg von einer leeren Maschine zu einem laufenden Muse-Glimmer-Dienst mit REST-Schnittstelle. Basis ist eine Ollama-Installation per Docker unter Linux; auf einem Mac mit Apple Silicon nutzen Sie stattdessen die native Ollama-App. Wer Ollama bereits kennt, kann direkt ab „Modell ziehen" einsteigen.
Aktualisiert am 7. Oktober 2026: Die Anleitung für Apple Silicon korrigiert: Die MLX-Variante läuft mit der nativen Ollama-App, nicht im Docker-Container, weil Docker Desktop unter macOS die GPU nicht an Linux-Container durchreicht. Außerdem nutzt das Compose-File jetzt den Docker-Tag 0.32.9, weil es kein Image mit dem Tag 0.32.8 gibt, und der Hinweis zu AMD-GPUs ist präzisiert.
Was Muse Glimmer von anderen Open-Weight-Modellen unterscheidet
Der auffälligste Unterschied zu Modellen wie Llama 3.x oder Mistral ist der eingebettete Vision-Encoder: Das Modell besteht aus einem Sprachkern mit etwa 27,8 Mrd. Parametern und einem separaten 1,8-Mrd.-Parameter-Wahrnehmungsmodul, das Bilder, Screenshots und Diagramme verarbeitet. Ein 128K-Token-Kontextfenster erlaubt lange Dokumente und mehrstufige Agentenschritte innerhalb einer einzigen Konversation.
Muse Glimmer lohnt sich dort, wo Datenschutz einen Cloud-Dienst ausschließt, wo multimodale Eingaben (etwa Screenshots von Benutzeroberflächen oder Fotos von Formularen) verarbeitet werden sollen, oder wo ein Coding-Agent auf eigener Hardware laufen soll. Für hohen parallelen Durchsatz in der Produktion bleibt ein dedizierter Serving-Stack wie vLLM die robustere Wahl; wie das aufgesetzt wird, erklärt der Abschnitt zu Hermes und vLLM im Beitrag Ollama: ein LLM lokal self-hosten.
Voraussetzungen
- Ollama ≥ 0.32.8: obligatorisch; Version 0.32.7 enthält das Modell im Manifest, hat aber noch keine NVIDIA/AMD-Unterstützung und bricht den Download mit HTTP 412 ab
- 18 GB VRAM (NVIDIA/AMD) für die Standard-Variante (Q4_K_M) oder 21 GB Unified Memory für Apple Silicon mit dem MLX-Variant
- Unter Linux mit NVIDIA- oder AMD-GPU: Docker und Docker Compose (empfohlen) oder eine native Ollama-Installation; auf einem Mac mit Apple Silicon: die native Ollama-App
Ollama per Docker starten
Der folgende Stack ist für Linux gedacht, mit NVIDIA-GPU oder nur mit CPU. Für eine AMD-GPU nehmen Sie laut Ollama-Docker-Doku das Image mit dem Tag-Suffix -rocm und reichen zusätzlich die Geräte /dev/kfd und /dev/dri an den Container durch. Auf einem Mac mit Apple Silicon installieren Sie stattdessen die native Ollama-App: Docker Desktop reicht die GPU unter macOS nicht an Linux-Container durch, im Container liefe Ollama dort also ohne GPU-Beschleunigung.
services:
ollama:
image: ollama/ollama:0.32.9 # erster Docker-Tag ab der Mindestversion 0.32.8 (Stolperfalle 1)
ports:
- "127.0.0.1:11434:11434"
volumes:
- ollama_models:/root/.ollama
restart: unless-stopped
# NVIDIA-GPU (NVIDIA Container Toolkit vorausgesetzt):
# deploy:
# resources:
# reservations:
# devices:
# - driver: nvidia
# count: all
# capabilities: [gpu]
volumes:
ollama_models:
docker compose up -d
curl -s http://localhost:11434/api/version
Das Volume ollama_models verhindert, dass mehrere Gigabyte große Modellgewichte nach jedem Container-Neustart erneut heruntergeladen werden. Die Bindung an 127.0.0.1 schließt externe Zugriffe aus; Ollama hat keine eingebaute Authentifizierung. Wer Ollama nativ installieren möchte oder mehr über die Konfigurationsoptionen wissen will, findet den Einstieg im Beitrag Ollama: ein LLM lokal self-hosten.
Modell ziehen und testen
# Linux (Docker), NVIDIA oder CPU, Q4_K_M, ca. 18 GB Download:
docker compose exec ollama ollama pull muse-glimmer
# Apple Silicon, native Ollama-App (nicht im Container) - MLX-Engine, ca. 19 GB:
ollama pull muse-glimmer:30b-mlx
# Geladene Modelle pruefen (auf dem Mac: ollama list):
docker compose exec ollama ollama list
# Interaktiver Schnelltest im Terminal (auf dem Mac: ollama run muse-glimmer:30b-mlx):
docker compose exec -it ollama ollama run muse-glimmer
REST-API aufrufen
Muse Glimmer nutzt dieselbe HTTP-Schnittstelle wie jedes andere Ollama-Modell: kein zusätzliches SDK, kein neuer Port. Auch die native App auf dem Mac lauscht auf Port 11434; dort tragen Sie in den folgenden Beispielen muse-glimmer:30b-mlx als Modell ein. Standardmäßig streamt Ollama die Antwort als eine Folge von JSON-Objekten (eines pro Zeile); "stream": false fasst alles zu einer einzigen Antwort zusammen, was für Skripte und Batch-Verarbeitung praktischer ist.
Für eine reine Text-Anfrage:
curl -s http://localhost:11434/api/chat -d '{
"model": "muse-glimmer",
"messages": [
{ "role": "user", "content": "Schreibe eine Python-Funktion, die ISO-8601-Datumsstrings parst." }
],
"stream": false
}'
Der Antworttext steht in message.content. Für multimodale Prompts hängen Sie das Bild als Base64-String im images-Array an die Nachricht:
# Linux: -w 0 unterdrueckt Zeilenumbrueche; macOS: base64 ohne -w
IMG=$(base64 -w 0 screenshot.png)
curl -s http://localhost:11434/api/chat -d '{
"model": "muse-glimmer",
"messages": [
{
"role": "user",
"content": "Beschreibe, was in diesem Screenshot zu sehen ist.",
"images": ["'"$IMG"'"]
}
],
"stream": false
}'
Anfragen und Antworten auf einen Blick:
+--------------------+
Text -------> | | ---> JSON
| ollama serve | message.content
Bild -------> | Port 11434 | eval_count
+--------------------+
Bestehende Anwendungen, die das OpenAI-Python-SDK verwenden, können Sie ohne Umbau auf Muse Glimmer umlenken, indem Sie base_url="http://localhost:11434/v1/" setzen, denn der Endpunkt /v1/chat/completions ist vollständig kompatibel.
Drei Stolperfallen
1. Mindestversion 0.32.8 ignorieren. Version 0.32.7 enthält Muse Glimmer im Manifest, hat aber noch keine NVIDIA/AMD-Unterstützung; der Pull bricht mit HTTP 412 ab. Prüfen Sie vorab mit ollama --version. Ein Docker-Image mit dem Tag 0.32.8 gibt es auf Docker Hub nicht (nur 0.32.8-rocm); der erste passende Tag ist 0.32.9, wie im Compose-File oben.
2. Falscher Tag auf Apple Silicon. Der Standard-Tag muse-glimmer ist GGUF-basiert. Für die MLX-Engine nennt die Ollama-Bibliothek auf Apple Silicon ausdrücklich muse-glimmer:30b-mlx; ziehen Sie für deutlich höhere Token-Raten auf M4- und M5-Chips diesen Tag, und zwar mit der nativen Ollama-App, nicht im Docker-Container. Laut Release Notes führt Ollama seit Version 0.40.0 auf Apple Silicon Modellarchitekturen, die die MLX-Laufzeit unterstützt, automatisch mit MLX aus; die Bibliothek empfiehlt für Muse Glimmer aber weiterhin den expliziten MLX-Tag. Die beiden Tags belegen unterschiedliche Speicherbereiche im Ollama-Verzeichnis; wer sie verwechselt, lädt Daten doppelt herunter.
3. VRAM-Budget zu knapp angesetzt. Die 18 GB für den Q4_K_M-Variant setzen sich aus rund 17 GB Modellgewichten und rund 1 GB Vision-Encoder zusammen. Hinzu kommen 1 bis 2 GB für den KV-Cache während des Inference-Laufs. Auf einer Karte mit exakt 18 GB VRAM läuft das Setup an seiner Grenze, während 24 GB deutlich komfortableren Betrieb ermöglichen.
Wie es weitergeht
Damit läuft Muse Glimmer lokal und ist per REST erreichbar. Ein naheliegender nächster Schritt ist eine RAG-Pipeline: Dokumente über POST /api/embed mit einem Embedding-Modell wie nomic-embed-text vektorisieren und in einer lokalen Vektordatenbank ablegen. Wie das mit Qdrant funktioniert, erklärt der Beitrag Qdrant self-hosten für RAG.
Weiterführende Quellen: Ollama-Blog zu Muse Glimmer, Meta-Forschungsblog, Ollama-API-Referenz, Ollama-Bibliothek: muse-glimmer.
Hinweis: Die Beiträge dieses Blogs werden unter Einsatz von KI erstellt und vor der Veröffentlichung redaktionell geprüft. Die redaktionelle Verantwortung trägt Emre Yurtbay (siehe Impressum).