Cursus
Zoals we in onze blogpost verkenden, is Muse Glimmer 30B een nieuw open model, gebouwd voor agentische en code-workloads.
Wat het extra interessant maakt, is dat je de volledige setup lokaal kunt draaien op een enkele NVIDIA RTX 5090 met 32 GB VRAM met behulp van llama.cpp.
Het model is beschikbaar in GGUF-formaat, en voor deze gids gebruik ik de kwalitatief betere dynamische kwantisatie.
De complete setup bestaat uit:
muse-glimmer-30B-kquant-dynamic.gguf: 19,7 GB hoofdmodeldflash-kquant.gguf: 1,63 GB conceptmodel voor speculative decodingmmproj-kquant.gguf: 1,4 GB vision- en perceptie-encoder
Volgens de modelkaart heeft de dynamische kwantisatie van 19,7 GB slechts ongeveer 0,2% benchmark-degradatie vergeleken met volledige precisie.
In mijn tests gebruikte het model met een 64K contextvenster ongeveer 24 GB VRAM, waardoor er bruikbare marge overblijft op de RTX 5090.
In deze gids leer je hoe je:
llama.cppbouwt met CUDA-ondersteuning- Muse Glimmer 30B lokaal downloadt en draait
- DFlash speculative decoding en vision-input inschakelt
- Het model test via de API en ingebouwde web-UI
- Het lokale model koppelt aan OpenCode
- Muse Glimmer gebruikt om een complete applicatie te bouwen en te debuggen
Aan het einde krijgen we ook een praktisch beeld van waar Muse Glimmer goed presteert als lokaal codeermodel en waar het nog moeite heeft. Bekijk ook zeker onze gids voor Muse Spark 1.3 om de nieuwste features te ontdekken.
1. Stel llama.cpp in voor GPU-inferentie
Voordat we Muse Glimmer lokaal draaien, moeten we eerst llama.cpp bouwen met CUDA-ondersteuning zodat het model de RTX 5090-GPU kan gebruiken.
Begin met het installeren van de vereiste systeempakketten:
apt-get update
apt-get install -y \
build-essential \
cmake \
curl \
git \
libcurl4-openssl-dev
Kloon vervolgens de llama.cpp-repository en ga naar de projectmap:
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
Configureer de build met CUDA ingeschakeld:
cmake -B build \
-DBUILD_SHARED_LIBS=OFF \
-DGGML_CUDA=ON
Compileer nu de commandoregeltools, de multimodale CLI en de server:
cmake --build build --config Release -j \
--target llama-cli llama-mtmd-cli llama-server
Maak na het bouwen llama-server globaal beschikbaar, zodat je het vanuit elke map kunt draaien:
ln -sf "$(pwd)/build/bin/llama-server" /usr/local/bin/llama-server
Controleer tot slot of de installatie werkt:
llama-server --version
Je zou uitvoer moeten zien zoals:
version: 10373 (38406d597)
built with GNU 13.3.0 for Linux x86_64
Op dit punt is llama.cpp gecompileerd met CUDA-ondersteuning en is llama-server klaar om Muse Glimmer op de GPU te draaien.
2. Download Muse Glimmer
Download vervolgens het hoofdmodel van Muse Glimmer samen met de extra GGUF-bestanden die nodig zijn voor speculative decoding en vision-input.
Installeer eerst de Hugging Face CLI:
pip install -U huggingface_hub
Log daarna in op je Hugging Face-account:
hf auth login
![]()
Kies de browserlogin, open de autorisatiepagina en keur de verbinding goed in je browser.
Download nu de drie vereiste bestanden:
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"
Dit downloadt:
muse-glimmer-30B-kquant-dynamic.gguf: het 19,7 GB hoofdmodeldflash-kquant.gguf: het conceptmodel dat wordt gebruikt voor speculative decodingmmproj-kquant.gguf: de perceptie-encoder die nodig is voor beeldinvoer
De bestanden zijn vrij groot, dus het downloaden kan even duren, afhankelijk van je internetverbinding.
![]()
Zodra alle drie de bestanden zijn gedownload, heb je alles om Muse Glimmer te draaien met tekstgeneratie, vision-ondersteuning en DFlash speculative decoding.
3. Serve Muse Glimmer met Vision en Speculative Decoding
Met alle drie de GGUF-bestanden gedownload, kunnen we Muse Glimmer nu starten met llama-server.
Het onderstaande commando laadt het hoofdmodel, schakelt het DFlash-conceptmodel in voor speculative decoding, en voegt de perceptie-encoder toe voor vision-input:
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

Deze configuratie gebruikt een 64K contextvenster, offloadt het model naar de GPU, schakelt Flash Attention in en draait de server op poort 8910.
Zodra het model is geladen, is het beschikbaar op:
http://127.0.0.1:8910
Je kunt bevestigen dat alles goed draait door een eenvoudige aanvraag te sturen naar de OpenAI-compatibele API:
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."
}
]
}'
Voor deze test genereerde Muse Glimmer 364 completion-tokens met 83,94 tokens/seconde, terwijl de prompt werd verwerkt met 147,48 tokens/seconde.
Met DFlash speculative decoding ingeschakeld stelde het conceptmodel 1.665 tokens voor, waarvan er 253 werden geaccepteerd, wat een acceptatiegraad van ongeveer 15,2% geeft.
De prompt van 64 tokens werd verwerkt in ongeveer 434 ms, terwijl de generatie ongeveer 4,34 seconden duurde.
De respons bevestigt dat het model correct draait via de lokale API.
Je kunt ook controleren hoeveel GPU-geheugen de complete setup gebruikt:
nvidia-smi
Met het 30B dynamisch gekwantiseerde model, DFlash-conceptmodel, vision-encoder en 64K contextvenster samen geladen, gebruikte mijn setup ongeveer 23,8 GB VRAM op de RTX 5090.

Dat laat grofweg 8 GB VRAM over, wat ons ruimte geeft om later te experimenteren met grotere contextvensters.
4. Test Muse Glimmer in de web-UI met vision- en codeprompts
llama-server wordt geleverd met een ingebouwde web-UI, wat het makkelijk maakt om het model te testen zonder handmatig API-verzoeken te sturen.
Open:
http://127.0.0.1:8910
Je kunt de interface gebruiken voor reguliere tekstprompts, beeldbegrip en snelle code-experimenten.
Omdat we de vision-encoder hebben geladen met:
--mmproj /workspace/Muse-Glimmer-30B-GGUF/mmproj-kquant.gguf
kan Muse Glimmer ook beeldinvoer accepteren.
Om de vision-capaciteiten te testen, uploadde ik de cover van een van mijn boeken en gebruikte ik de volgende prompt:
Describe what you see in this image and point out the most important details.

Het model gaf een gedetailleerde beschrijving van de cover en pikte ook diverse kleinere visuele elementen op.
Dit was een nuttige eerste test om te bevestigen dat de vision-encoder correct werkte.
Vervolgens testte ik zijn codeervermogen met een eenvoudige websitegeneratie-opdracht:
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.
Tijdens deze codeertaak lag de gemiddelde generatie rond de 121 tokens per seconde, wat merkbaar sneller was dan de eerdere algemene teksttest.
DFlash speculative decoding leek bijzonder goed te werken bij dit soort sequentiële codegeneratieworkloads.

Het model genereerde een bruikbare luxe-horlogesite.
Er zaten nog een paar issues in de eindoutput, wat niet heel verrassend is voor een 30B-model, maar het wist wel heel snel een compleet project te produceren.

Muse Glimmer is gepositioneerd als een agentisch codeermodel, dus de belangrijkere test is hoe goed het presteert wanneer het bestanden moet maken, commando’s moet uitvoeren, eigen werk moet testen en problemen moet oplossen. Dat testen we hierna door het te koppelen aan OpenCode.
5. Koppel Muse Glimmer aan OpenCode en test agentische coding
Nu Muse Glimmer lokaal draait, is de volgende stap het koppelen aan OpenCode en kijken hoe het presteert als agentisch codeermodel.
Installeer eerst OpenCode:
curl -fsSL https://opencode.ai/install | bash

Herlaad de shell en bevestig de installatie:
exec bash
opencode --version
Voor deze test gebruikte ik:
1.18.16
Maak de configuratiemap voor OpenCode aan:
mkdir -p ~/.config/opencode
In plaats van een teksteditor te openen, maak je het configuratiebestand direct vanuit de terminal aan:
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
Dit vertelt OpenCode dat het de OpenAI-compatibele API moet gebruiken die door onze lokale llama-server wordt aangeboden.
Maak vervolgens een nieuw project aan:
mkdir muse-app
cd muse-app
git init
opencode

OpenCode start de terminal-UI met Muse Glimmer 30B al geconfigureerd als het hoofdmodel.
Bouw een complete applicatie
Om het model op iets realistischers te testen, vroeg ik het een medische onderzoeksapplicatie te bouwen:
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.

Het eerste resultaat was indrukwekkend. Het kostte slechts ongeveer één minuut om het volledige project te genereren.
Het maakte razendsnel de backend, frontend, dependencies en de algehele applicatiestructuur.
Daarna vroeg ik om zowel de backend als de UI te testen.
Daar begon ik de zwaktes van het model te merken.
Snel in bouwen, zwakker in debuggen
Op kunstmatige code-benchmarks scoort Muse Glimmer vergelijkbaar met het Qwen3.6 27B -model, maar op basis van mijn eigen tests vind ik het merkbaar minder wanneer je echt een codeertaak moet doorwerken.
Het grootste probleem was debuggen.
Muse Glimmer was heel snel in het vanaf nul creëren van een compleet project, maar zodra er iets misging, had het moeite om zelfstandig door het probleem heen te werken. Het kon lang verschillende dingen proberen zonder veel vooruitgang te boeken.
Uiteindelijk moest ik precies zeggen wat het moest doen.
Zo instrueerde ik het expliciet om:
- De backendserver op de achtergrond te starten.
- Te wachten tot de server beschikbaar is.
- Een verzoek naar de draaiende applicatie te sturen.
- De respons te controleren.
- Eventuele fouten te verhelpen.
- De applicatie opnieuw te testen.
Zodra ik die concrete stappen gaf, begreep het de taak en volgde het ze succesvol op.

Dat was waarschijnlijk mijn grootste inzicht bij het gebruik van Muse Glimmer met OpenCode.
Je moet heel expliciet zijn over wat je wilt dat het doet.
In plaats van te zeggen "test de applicatie" of "los het probleem op", werkt het veel beter als je de exacte reeks acties beschrijft die het moet nemen.
Prompt-engineering is daarom bij dit model bijzonder belangrijk.
De uiteindelijke applicatie
Na het doorlopen van de debug-issues werkte de resulterende MedSearch AI-applicatie erg goed.

De applicatie was snel, rijk aan features en verrassend eenvoudig.
Het gebruikte een lichte FastAPI-backend met pure HTML, CSS en JavaScript in plaats van te leunen op een groot frontend-framework.
Die eenvoud was eigenlijk een van de dingen die ik prettig vond aan het resultaat.
Muse Glimmer creëerde een functionele AI-applicatie zonder onnodige complexiteit te introduceren.
Mijn ervaring tot nu toe is dat Muse Glimmer uitstekend is in het snel genereren van veel werkende code, maar veel minder betrouwbaar is wanneer het zelf problemen moet diagnosticeren, meerstapsdebugging moet plannen en zelfstandig van fouten moet herstellen.
Voor lokaal coderen is dat onderscheid belangrijk.
Als je het duidelijke en gedetailleerde instructies geeft, kan het heel capabel zijn.
Als je verwacht dat het zelfstandig elke stap uitvogelt, vooral tijdens het debuggen, worden de beperkingen veel duidelijker.
Laatste gedachten
Muse Glimmer 30B is nog steeds een heel nieuw model, en dat bleek uit mijn tests.
Het was erg snel in het genereren van code, maar had meer moeite met debuggen en taken met meerdere stappen. Ik moest het vaak precies vertellen wat het moest doen voordat het verder kon.
Zelfs met die issues denk ik dat het model veel potentieel heeft.
Met betere prompting en toekomstige verbeteringen zie ik het uitgroeien tot een zeer bruikbaar lokaal codeermodel, vergelijkbaar met mijn ervaring met Qwen3.6 27B.
Ik vind dit ook een mooie richting voor Meta AI.
Er is duidelijke interesse in lokale code-agents omdat ze kunnen bieden:
- Lagere kosten, zonder API-kosten
- Betere privacy voor je code en data
- Meer controle over output
- De mogelijkheid om lokaal te werken zonder afhankelijk te zijn van een externe model-API
In mijn setup gebruikte het model ongeveer 24 GB GPU-geheugen, wat het praktisch maakt voor high-end lokale hardware.
Je kunt dit soort modellen ook draaien met systeem- of unified memory, al is de performance dan trager.
In deze gids hebben we llama.cpp gebouwd, de Muse Glimmer-GGUF-bestanden gedownload, vision en speculative decoding ingeschakeld, de API en web-UI getest en het model gekoppeld aan OpenCode.
We hebben het ook gebruikt om een complete applicatie te bouwen en te testen.
Mijn belangrijkste conclusie is dat Muse Glimmer heel snel is in het creëren van code, maar nog duidelijke instructies nodig heeft bij het debuggen of het afhandelen van complexere agentische taken.
FAQs
Wat is DFlash speculative decoding in llama.cpp, en waarom heb ik een apart GGUF-bestand nodig?
DFlash (draft-dflash) is een block-diffusion speculative decoding-techniek die in één forward pass een hele blok concepttokens vóór het hoofdmodel voorspelt. Door stukjes tekst in één keer te raden en het grotere model ze snel te laten verifiëren, versnelt het de tekstgeneratie aanzienlijk. Het aparte dflash-kquant.gguf-bestand is het lichte conceptmodel dat expliciet is getraind om de output van Muse Glimmer te anticiperen.
Kan ik Muse Glimmer 30B draaien op AMD-GPU’s of Apple Silicon Macs, of is NVIDIA vereist?
Omdat het model draait op llama.cpp, heb je niet per se een NVIDIA-GPU nodig. Meta heeft sterke out-of-the-box lokale performance bevestigd op AMD Ryzen AI Max+-processors en Radeon PRO R9700-videokaarten. Apple Silicon-gebruikers (M2/M3/M4 Max of Ultra) kunnen het model ook efficiënt draaien door gebruik te maken van Unified Memory in macOS, al moeten ze llama.cpp met Apple Metal-ondersteuning (-DGGML_METAL=ON) compileren in plaats van CUDA.
Wat is het maximale contextvenster voor Muse Glimmer 30B?
Het model ondersteunt een native contextvenster tot 131.072 (128K) tokens. Het volledig benutten van de 128K-context vereist echter aanzienlijk meer VRAM om de KV-cache op te slaan. Om het maximale contextvenster lokaal op een 32 GB videokaart te draaien, moet je waarschijnlijk KV-cache-kwantisatie inschakelen (zoals 8-bit- of 4-bit-cachetypes) in llama.cpp of een deel van de lagen van het model naar je systeems RAM offloaden.
Muse Glimmer 30B vs. Qwen3.6 27B: welke is beter voor lokaal coderen?
Hoewel beide zeer capabele modellen zijn in een vergelijkbare gewichtsklasse, blinken ze uit op verschillende gebieden. Muse Glimmer 30B is uitzonderlijk snel in zero-shot codegeneratie en het razendsnel opzetten van complete applicatiestructuren vanaf nul. Qwen3.6 27B is momenteel echter betrouwbaarder voor zelfstandig, meerstaps debuggen en agentische probleemoplossing. Als je Muse Glimmer gebruikt voor debuggen, krijg je de beste resultaten door het zeer expliciete, stap-voor-stap troubleshooting-instructies te geven.
