Muse Glimmer 30B lokal für KI-Coding ausführen

Wie wir in unserem Blogbeitrag Muse Glimmer erkundet haben, ist Muse Glimmer 30B ein neues offenes Modell für agentische Aufgaben und Coding-Workloads. 

Besonders spannend: Du kannst das komplette Setup lokal auf einer einzelnen NVIDIA RTX 5090 mit 32 GB VRAM mit llama.cpp ausführen.

Das Modell liegt im GGUF-Format vor; in dieser Anleitung nutze ich die höherwertige dynamische Quantisierung. 

Das vollständige Setup besteht aus:

• muse-glimmer-30B-kquant-dynamic.gguf: 19,7 GB Hauptmodell
• dflash-kquant.gguf: 1,63 GB Draft-Modell für Speculative Decoding
• mmproj-kquant.gguf: 1,4 GB Vision- und Perception-Encoder

Laut Model Card hat das 19,7-GB-Dynamic-Quant nur etwa 0,2 % Leistungsverlust in Benchmarks gegenüber Vollpräzision. 

In meinen Tests nutzte ein 64K-Kontextfenster rund 24 GB VRAM – genug Luft nach oben auf der RTX 5090.

In dieser Anleitung lernst du:

1. llama.cpp mit CUDA-Unterstützung zu bauen
2. Muse Glimmer 30B lokal herunterzuladen und auszuführen
3. DFlash Speculative Decoding und Vision-Input zu aktivieren
4. Das Modell über die API und die integrierte Weboberfläche zu testen
5. Das lokale Modell mit OpenCode zu verbinden
6. Mit Muse Glimmer eine komplette Anwendung zu bauen und zu debuggen

Am Ende hast du ein gutes Gefühl dafür, wo Muse Glimmer als lokales Coding-Modell glänzt und wo es noch hakt. Lies dir außerdem unseren Guide zu Muse Spark 1.3 durch, um die neuesten Features kennenzulernen.

1. llama.cpp für GPU-Inferenz einrichten

Bevor wir Muse Glimmer lokal starten, müssen wir llama.cpp mit CUDA-Unterstützung bauen, damit das Modell die RTX 5090 GPU nutzt.

Installiere zunächst die benötigten Systempakete:

apt-get update

apt-get install -y \
    build-essential \
    cmake \
    curl \
    git \
    libcurl4-openssl-dev

Klonen wir als Nächstes das llama.cpp-Repository und wechseln in das Projektverzeichnis:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

Konfiguriere den Build mit aktivierter CUDA-Unterstützung:

cmake -B build \
    -DBUILD_SHARED_LIBS=OFF \
    -DGGML_CUDA=ON

Kompiliere nun die Kommandozeilentools, das Multimodal-CLI und den Server:

cmake --build build --config Release -j \
    --target llama-cli llama-mtmd-cli llama-server

Sobald der Build fertig ist, mache llama-server global verfügbar, damit du ihn aus jedem Verzeichnis starten kannst:

ln -sf "$(pwd)/build/bin/llama-server" /usr/local/bin/llama-server

Prüfe abschließend, ob die Installation funktioniert:

llama-server --version

Du solltest eine Ausgabe ähnlich der folgenden sehen:

version: 10373 (38406d597)
built with GNU 13.3.0 for Linux x86_64

An diesem Punkt ist llama.cpp mit CUDA-Unterstützung kompiliert und llama-server bereit, Muse Glimmer auf der GPU auszuführen.

2. Muse Glimmer herunterladen

Lade nun das Hauptmodell von Muse Glimmer sowie die zusätzlichen GGUF-Dateien für Speculative Decoding und Vision-Input herunter.

Installiere zuerst die Hugging Face CLI:

pip install -U huggingface_hub

Melde dich dann bei deinem Hugging-Face-Konto an:

hf auth login

Wähle den Browser-Login, öffne die Autorisierungsseite und bestätige die Verbindung im Browser.

Lade jetzt die drei erforderlichen Dateien herunter:

hf download meta-models/Muse-Glimmer-30B-GGUF \
    --local-dir Muse-Glimmer-30B-GGUF \
    --include "muse-glimmer-30B-kquant-dynamic.gguf" \
    --include "dflash-kquant.gguf" \
    --include "mmproj-kquant.gguf"

Damit lädst du Folgendes herunter:

• muse-glimmer-30B-kquant-dynamic.gguf: das 19,7 GB große Hauptmodell
• dflash-kquant.gguf: das Draft-Modell für Speculative Decoding
• mmproj-kquant.gguf: der Perception-Encoder für Bild-Input

Die Dateien sind recht groß, der Download kann je nach Internetverbindung etwas dauern.

Sobald alle drei Dateien vorliegen, kannst du Muse Glimmer mit Textgenerierung, Vision-Unterstützung und DFlash Speculative Decoding ausführen.

3. Muse Glimmer mit Vision und Speculative Decoding bereitstellen

Mit allen drei GGUF-Dateien können wir Muse Glimmer jetzt mit llama-server starten.

Der folgende Befehl lädt das Hauptmodell, aktiviert das DFlash-Draft-Modell für Speculative Decoding und bindet den Perception-Encoder für Vision-Input ein:

llama-server \
    -m /workspace/Muse-Glimmer-30B-GGUF/muse-glimmer-30B-kquant-dynamic.gguf \
    -md /workspace/Muse-Glimmer-30B-GGUF/dflash-kquant.gguf \
    --mmproj /workspace/Muse-Glimmer-30B-GGUF/mmproj-kquant.gguf \
    --spec-type draft-dflash \
    --spec-draft-n-max 15 \
    -ngl 99 \
    --spec-draft-ngl all \
    -fa on \
    --temp 1.0 \
    --top-p 0.95 \
    --top-k 64 \
    --ctx-size 64000 \
    --alias muse-glimmer-30B \
    --host 0.0.0.0 \
    --port 8910 \
    --jinja

Diese Konfiguration nutzt ein 64K-Kontextfenster, lagert das Modell auf die GPU aus, aktiviert Flash Attention und startet den Server auf Port 8910.

Sobald das Modell geladen ist, ist es hier erreichbar:

http://127.0.0.1:8910

Du kannst prüfen, ob alles korrekt läuft, indem du eine einfache Anfrage an die OpenAI-kompatible API sendest:

curl -s http://127.0.0.1:8910/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "muse-glimmer-30B",
        "messages": [
            {
                "role": "user",
                "content": "Explain speculative decoding in three simple sentences."
            }
        ]
    }'

In diesem Test generierte Muse Glimmer 364 Completion-Tokens mit 83,94 Tokens/Sekunde, während der Prompt mit 147,48 Tokens/Sekunde verarbeitet wurde. 

Mit aktiviertem DFlash Speculative Decoding schlug das Draft-Modell 1.665 Tokens vor, von denen 253 akzeptiert wurden – eine Akzeptanzrate von etwa 15,2 %. 

Der 64-Token-Prompt wurde in etwa 434 ms verarbeitet, die Generierung dauerte ungefähr 4,34 Sekunden. 

Die Antwort bestätigt, dass das Modell korrekt über die lokale API läuft.

Du kannst außerdem prüfen, wie viel GPU-Speicher das Setup nutzt:

nvidia-smi

Mit dem 30B dynamisch quantisierten Modell, DFlash-Draft, Vision-Encoder und 64K-Kontextfenster belegte mein Setup ungefähr 23,8 GB VRAM auf der RTX 5090.

Damit bleiben rund 8 GB VRAM frei – genug Spielraum, um später größere Kontextfenster zu testen.

4. Muse Glimmer in der Weboberfläche mit Vision- und Coding-Prompts testen

llama-server bringt eine integrierte Weboberfläche mit, mit der du das Modell ohne manuelle API-Calls schnell ausprobieren kannst.

Öffne:

http://127.0.0.1:8910

Über die Oberfläche kannst du normale Textprompts, Bildverständnis und schnelle Coding-Experimente testen.

Weil wir den Vision-Encoder mit

--mmproj /workspace/Muse-Glimmer-30B-GGUF/mmproj-kquant.gguf

geladen haben, akzeptiert Muse Glimmer auch Bild-Input.

Zum Testen der Vision-Fähigkeit habe ich das Cover eines meiner Bücher hochgeladen und folgenden Prompt verwendet:

Describe what you see in this image and point out the most important details.

Das Modell lieferte eine detaillierte Beschreibung des Covers und erkannte auch mehrere kleinere visuelle Elemente. 

Ein guter erster Check, dass der Vision-Encoder korrekt arbeitet.

Als Nächstes habe ich die Coding-Fähigkeit mit einer einfachen Website-Generierung getestet:

Build a modern luxury watch website for VELORÉ, 
with a minimalist V logo, black/ivory/deep-green palette, 
cinematic hero, premium watches, smooth animations, 
and elegant Swiss-inspired styling.

Bei dieser Aufgabe lag die Generierung im Schnitt bei 121 Tokens pro Sekunde – spürbar schneller als beim allgemeinen Texttest. 

DFlash Speculative Decoding scheint sich besonders gut für sequentielle Codegenerierung zu eignen.

Das Modell erzeugte eine brauchbare Luxusuhren-Website. 

Im Endergebnis gab es noch ein paar kleinere Punkte – für ein 30B-Modell nicht überraschend –, aber das Projekt stand sehr schnell komplett.

Muse Glimmer ist als agentisches Coding-Modell positioniert. Entscheidend ist daher, wie gut es Dateien anlegt, Befehle ausführt, die eigene Arbeit testet und Probleme behebt. Das prüfen wir als Nächstes, indem wir es mit OpenCode verbinden.

5. Muse Glimmer mit OpenCode verbinden und agentisches Coding testen

Da Muse Glimmer nun lokal läuft, verbinden wir es mit OpenCode und schauen, wie es sich als agentisches Coding-Modell schlägt.

Installiere zuerst OpenCode:

curl -fsSL https://opencode.ai/install | bash

Lade die Shell neu und prüfe die Installation:

exec bash
opencode --version

Für diesen Test verwendete ich:

1.18.16

Lege das OpenCode-Konfigurationsverzeichnis an:

mkdir -p ~/.config/opencode

Erstelle die Konfigurationsdatei direkt im Terminal:

cat > ~/.config/opencode/opencode.json <<'EOF'
{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "llama.cpp": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Muse Glimmer Local",
      "options": {
        "baseURL": "http://127.0.0.1:8910/v1"
      },
      "models": {
        "muse-glimmer-30B": {
          "name": "Muse Glimmer 30B"
        }
      }
    }
  },
  "model": "llama.cpp/muse-glimmer-30B"
}
EOF

Damit nutzt OpenCode die OpenAI-kompatible API unseres lokalen llama-server.

Erstelle als Nächstes ein neues Projekt:

mkdir muse-app
cd muse-app
git init
opencode

OpenCode startet sein Terminal-UI mit Muse Glimmer 30B bereits als Hauptmodell konfiguriert.

Eine komplette Anwendung bauen

Um das Modell praxisnah zu testen, ließ ich eine medizinische Recherche-Anwendung bauen:

Build a modern medical AI web app called MedSearch AI.
Use Python FastAPI for the backend and HTML, CSS and JavaScript for the frontend.
Create a clean dark interface where users can ask medical research questions. 
Send prompts to my local Muse Glimmer server at:http://127.0.0.1:8910/v1/chat/completions
Add web search for the latest reliable medical information, show sources clearly, 
support streaming responses and Markdown, and include a clear-chat button and server status indicator.

Create all files, install dependencies, test the app, and tell me how to run it.

Das erste Ergebnis war beeindruckend. Die Generierung des gesamten Projekts dauerte nur rund eine Minute. 

Backend, Frontend, Abhängigkeiten und Struktur der Anwendung waren sehr schnell erstellt.

Danach bat ich es, Backend und UI zu testen.

Hier traten die Schwächen des Modells zutage.

Schnell im Aufbau, schwächer im Debugging

In künstlichen Coding-Benchmarks liegt Muse Glimmer ähnlich wie Qwen3.6 27B – in meinen praktischen Tests war es jedoch spürbar schwächer, wenn es eine Coding-Aufgabe wirklich Schritt für Schritt durcharbeiten musste.

Das größte Problem war das Debugging.

Muse Glimmer erstellt sehr schnell ein komplettes Projekt. Sobald jedoch etwas schiefläuft, tut es sich schwer, das Problem eigenständig systematisch zu lösen. Es probiert vieles aus, ohne dabei unbedingt voranzukommen.

Am Ende musste ich sehr genau vorgeben, was zu tun ist. 

Zum Beispiel wies ich es explizit an, Folgendes zu tun:

1. Backend-Server im Hintergrund starten.
2. Warten, bis der Server erreichbar ist.
3. Eine Anfrage an die laufende Anwendung senden.
4. Die Antwort prüfen.
5. Aufgetretene Fehler beheben.
6. Die Anwendung erneut testen.

Mit diesen konkreten Schritten verstand es die Aufgabe und folgte ihr erfolgreich.

Das war wohl meine wichtigste Erkenntnis mit Muse Glimmer und OpenCode. 

Du musst sehr klar sagen, was genau passieren soll. 

Statt „Teste die Anwendung“ oder „Behebe den Fehler“ funktioniert es deutlich besser, wenn du die genaue Abfolge der Schritte beschreibst.

Prompt-Engineering ist bei diesem Modell daher besonders wichtig.

Die finale Anwendung

Nach dem Debugging lief die Anwendung MedSearch AI sehr gut.

Die App war schnell, umfangreich ausgestattet und angenehm schlank. 

Sie setzte auf ein leichtgewichtiges FastAPI-Backend mit purem HTML, CSS und JavaScript statt auf ein großes Frontend-Framework.

Diese Einfachheit war tatsächlich einer der Pluspunkte am Ergebnis. 

Muse Glimmer baute eine funktionale KI-Anwendung, ohne unnötige Komplexität einzuführen.

Meine Zwischenbilanz: Muse Glimmer ist exzellent darin, schnell viel lauffähigen Code zu erzeugen, aber deutlich weniger verlässlich, wenn es Probleme diagnostizieren, mehrstufig debuggen und sich eigenständig von Fehlersituationen erholen soll.

Für lokales Coding ist dieser Unterschied entscheidend. 

Gibst du klare, detaillierte Anweisungen, ist es sehr fähig. 

Erwartest du, dass es jeden Schritt eigenständig herausfindet – gerade beim Debugging –, werden die Grenzen deutlich.

Fazit

Muse Glimmer 30B ist noch sehr neu, und das zeigte sich in meinen Tests. 

Es war sehr schnell in der Codegenerierung, tat sich aber beim Debugging und bei mehrstufigen Aufgaben schwerer. Oft musste ich sehr genau vorgeben, wie es weitergehen soll.

Trotzdem sehe ich viel Potenzial im Modell. 

Mit besserem Prompting und zukünftigen Verbesserungen kann es ein sehr brauchbares lokales Coding-Modell werden – ähnlich wie meine Erfahrungen mit Qwen3.6 27B.

Ich finde auch, dass das eine sehr gute Richtung für Meta AI ist. 

Das Interesse an lokalen Coding-Agenten ist groß, denn sie bieten:

• Geringere Kosten, keine API-Gebühren
• Besseren Datenschutz für Code und Daten
• Mehr Kontrolle über Ausgaben
• Lokales Arbeiten ohne Abhängigkeit von externen Modell-APIs

In meinem Setup nutzte das Modell rund 24 GB GPU-Speicher – damit ist es auf High-End-Hardware lokal gut einsetzbar. 

Du kannst solche Modelle auch mit System- oder Unified Memory laufen lassen, dann allerdings mit geringerer Performance.

In diesem Guide haben wir llama.cpp gebaut, die Muse-Glimmer-GGUF-Dateien heruntergeladen, Vision und Speculative Decoding aktiviert, API und Web-UI getestet und das Modell mit OpenCode verbunden. 

Außerdem haben wir damit eine komplette Anwendung gebaut und getestet. 

Meine Hauptlektion: Muse Glimmer ist sehr schnell in der Codeerzeugung, braucht aber beim Debugging und bei komplexeren agentischen Aufgaben weiterhin klare Anweisungen.