Curso
Programación asistida por IA para desarrolladores
1 h 30 min
10.5K
Como explicamos en nuestro artículo del blog, Muse Glimmer 30B es un nuevo modelo abierto diseñado para tareas agentivas y de programación.
Lo más interesante es que puedes ejecutar todo el montaje en local con una sola NVIDIA RTX 5090 con 32 GB de VRAM usando llama.cpp.
El modelo está disponible en formato GGUF y, para esta guía, utilizaré la cuantización dinámica de mayor calidad.
La configuración completa consta de:
muse-glimmer-30B-kquant-dynamic.gguf: 19,7 GB del modelo principaldflash-kquant.gguf: 1,63 GB modelo de borrador para decodificación especulativammproj-kquant.gguf: 1,4 GB codificador de visión y percepción
Según la model card, la cuantización dinámica de 19,7 GB solo tiene alrededor de un 0,2% de degradación en benchmarks frente a la precisión completa.
En mis pruebas, ejecutar el modelo con una ventana de contexto de 64K consumió unos 24 GB de VRAM, dejando margen útil en la RTX 5090.
En esta guía, aprenderás a:
- Compilar
llama.cppcon soporte CUDA - Descargar y ejecutar Muse Glimmer 30B en local
- Activar la decodificación especulativa DFlash y la entrada de visión
- Probar el modelo vía API y con la Web UI integrada
- Conectar el modelo local a OpenCode
- Usar Muse Glimmer para crear y depurar una aplicación completa
Al final, también tendremos una idea práctica de dónde destaca Muse Glimmer como modelo local de programación y dónde aún se atasca. También te recomiendo nuestro tutorial de Muse Spark 1.3 para conocer sus últimas novedades.
1. Configura llama.cpp para inferencia en GPU
Antes de ejecutar Muse Glimmer en local, primero necesitamos compilar llama.cpp con soporte CUDA para que el modelo use la GPU RTX 5090.
Empieza instalando los paquetes del sistema necesarios:
apt-get update
apt-get install -y \
build-essential \
cmake \
curl \
git \
libcurl4-openssl-devDespués, clona el repositorio de llama.cpp y entra en el directorio del proyecto:
git clone https://github.com/ggml-org/llama.cpp
cd llama.cppConfigura la compilación con CUDA activado:
cmake -B build \
-DBUILD_SHARED_LIBS=OFF \
-DGGML_CUDA=ONAhora compila las herramientas de línea de comandos, la CLI multimodal y el servidor:
cmake --build build --config Release -j \
--target llama-cli llama-mtmd-cli llama-serverCuando termine, haz que llama-server esté disponible globalmente para poder ejecutarlo desde cualquier ruta:
ln -sf "$(pwd)/build/bin/llama-server" /usr/local/bin/llama-serverPor último, confirma que la instalación funciona:
llama-server --versionDeberías ver algo similar a:
version: 10373 (38406d597)
built with GNU 13.3.0 for Linux x86_64En este punto, llama.cpp está compilado con soporte CUDA y llama-server está listo para ejecutar Muse Glimmer en la GPU.
2. Descarga Muse Glimmer
A continuación, descarga el modelo principal de Muse Glimmer junto con los archivos GGUF adicionales necesarios para la decodificación especulativa y la entrada de visión.
Primero, instala la CLI de Hugging Face:
pip install -U huggingface_hubLuego inicia sesión en tu cuenta de Hugging Face:
hf auth login
Elige el inicio de sesión vía navegador, abre la página de autorización y aprueba la conexión en tu navegador.
Ahora descarga los tres archivos necesarios:
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"Esto descarga:
muse-glimmer-30B-kquant-dynamic.gguf: el modelo principal de 19,7 GBdflash-kquant.gguf: el modelo de borrador usado para decodificación especulativammproj-kquant.gguf: el codificador de percepción necesario para entrada de imágenes
Los archivos son bastante grandes, así que la descarga puede tardar según tu conexión.
Cuando tengas los tres archivos, ya dispones de todo lo necesario para ejecutar Muse Glimmer con generación de texto, soporte de visión y decodificación especulativa DFlash.
3. Sirve Muse Glimmer con visión y decodificación especulativa
Con los tres archivos GGUF descargados, ya podemos iniciar Muse Glimmer con llama-server.
El siguiente comando carga el modelo principal, activa el modelo de borrador DFlash para decodificación especulativa y añade el codificador de percepción para la entrada de visión:
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
Esta configuración usa una ventana de contexto de 64K, descarga el modelo a la GPU, activa Flash Attention y ejecuta el servidor en el puerto 8910.
Una vez cargado el modelo, estará disponible en:
http://127.0.0.1:8910Puedes confirmar que todo funciona enviando una petición sencilla a la API compatible con OpenAI:
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."
}
]
}'En esta prueba, Muse Glimmer generó 364 tokens de completado a 83,94 tokens/segundo, mientras que el prompt se procesó a 147,48 tokens/segundo.
Con la decodificación especulativa DFlash activada, el modelo de borrador propuso 1.665 tokens, de los cuales se aceptaron 253, con una tasa de aceptación de aproximadamente 15,2%.
El prompt de 64 tokens se procesó en unos 434 ms, y la generación tardó aproximadamente 4,34 segundos.
La respuesta confirma que el modelo se ejecuta correctamente a través de la API local.
También puedes comprobar cuánta memoria de GPU está usando toda la configuración:
nvidia-smiCon el modelo de 30B cuantizado dinámicamente, el borrador DFlash, el codificador de visión y la ventana de 64K cargados juntos, mi equipo usó aproximadamente 23,8 GB de VRAM en la RTX 5090.
Eso deja unos 8 GB de VRAM libres, dándonos margen para probar ventanas de contexto mayores más adelante.
4. Prueba Muse Glimmer en la Web UI con prompts de visión y de código
llama-server incluye una Web UI integrada, lo que facilita probar el modelo sin tener que enviar peticiones a la API manualmente.
Abre:
http://127.0.0.1:8910Puedes usar la interfaz para prompts de texto, comprensión de imágenes y experimentos rápidos de programación.
Como cargamos el codificador de visión con:
--mmproj /workspace/Muse-Glimmer-30B-GGUF/mmproj-kquant.ggufMuse Glimmer también puede aceptar entrada de imágenes.
Para probar su capacidad de visión, subí la portada de uno de mis libros y usé este prompt:
Describe what you see in this image and point out the most important details.
El modelo produjo una descripción detallada de la portada y también captó varios elementos visuales pequeños.
Fue una primera prueba útil para confirmar que el codificador de visión funcionaba correctamente.
Después, probé su capacidad de programación con una tarea simple de generación de sitio web:
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.Durante esta tarea, la generación promedió alrededor de 121 tokens por segundo, notablemente más rápido que en la prueba de texto general.
La decodificación especulativa DFlash pareció funcionar especialmente bien en este tipo de generación secuencial de código.
El modelo generó un sitio web de relojes de lujo utilizable.
Aun así había algunos fallos en el resultado final, algo esperable para un modelo de 30B, pero fue capaz de producir un proyecto completo muy rápido.
Muse Glimmer está posicionado como un modelo agentivo de programación, así que la prueba más importante es cómo rinde cuando tiene que crear archivos, ejecutar comandos, probar su propio trabajo y corregir problemas. Eso lo probaremos ahora conectándolo a OpenCode.
5. Conecta Muse Glimmer a OpenCode y prueba la programación agentiva
Ahora que Muse Glimmer se ejecuta en local, el siguiente paso es conectarlo a OpenCode y ver cómo se comporta como modelo agentivo de programación.
Primero, instala OpenCode:
curl -fsSL https://opencode.ai/install | bash
Recarga la shell y confirma la instalación:
exec bash
opencode --versionPara esta prueba, yo estaba usando:
1.18.16Crea el directorio de configuración de OpenCode:
mkdir -p ~/.config/opencodeEn lugar de abrir un editor, crea el archivo de configuración directamente desde la 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"
}
EOFEsto indica a OpenCode que use la API compatible con OpenAI expuesta por nuestro llama-server local.
Ahora, crea un proyecto nuevo:
mkdir muse-app
cd muse-app
git init
opencode
OpenCode iniciará su interfaz en terminal con Muse Glimmer 30B ya configurado como modelo principal.
Crea una aplicación completa
Para probar el modelo en algo más realista, le pedí que construyera una aplicación de investigación médica:
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.
El resultado inicial fue muy bueno. Apenas tardó un minuto en generar el proyecto completo.
Creó el backend, el frontend, las dependencias y la estructura general de la aplicación muy rápido.
Luego le pedí que probara tanto el backend como la interfaz.
Aquí fue donde empecé a notar las debilidades del modelo.
Rápido creando, más flojo depurando
En benchmarks artificiales de programación, Muse Glimmer queda en posiciones similares al modelo Qwen3.6 27B , pero por mi experiencia es claramente peor cuando se pone a resolver una tarea de código real.
El mayor problema fue la depuración.
Muse Glimmer fue muy rápido creando un proyecto completo desde cero, pero cuando algo fallaba, le costaba avanzar por sí solo. Podía pasar mucho tiempo probando cosas sin progreso real.
Al final tuve que decirle exactamente qué hacer.
Por ejemplo, le indiqué explícitamente que:
- Arrancara el servidor backend en segundo plano.
- Esperara a que el servidor estuviera disponible.
- Enviara una petición a la aplicación en ejecución.
- Comprobara la respuesta.
- Corrigiera cualquier error encontrado.
- Volviera a probar la aplicación.
Una vez le di esos pasos concretos, entendió la tarea y los siguió con éxito.
Probablemente esa fue mi mayor conclusión al usar Muse Glimmer con OpenCode.
Hay que ser muy explícito con lo que quieres que haga.
En vez de decir "prueba la aplicación" o "corrige el problema", funciona mucho mejor si describes la secuencia exacta de acciones que debe seguir.
Por eso, el prompt engineering es especialmente importante con este modelo.
La aplicación final
Tras resolver los problemas de depuración, la aplicación MedSearch AI resultante funcionó muy bien.
La aplicación era rápida, con muchas funciones y sorprendentemente sencilla.
Usó un backend ligero con FastAPI y HTML, CSS y JavaScript sin depender de un gran framework de frontend.
Esa simplicidad fue, de hecho, una de las cosas que más me gustó del resultado.
Muse Glimmer creó una aplicación de IA funcional sin añadir complejidad innecesaria.
Mi experiencia hasta ahora es que Muse Glimmer es excelente generando mucho código funcional muy rápido, pero es bastante menos fiable cuando tiene que diagnosticar problemas, planificar una depuración en varios pasos y recuperarse solo de fallos.
Para programación en local, esa distinción importa.
Si le das instrucciones claras y detalladas, puede ser muy capaz.
Si esperas que averigüe cada paso de forma autónoma, sobre todo durante la depuración, sus limitaciones se notan mucho más.
Conclusiones
Muse Glimmer 30B sigue siendo un modelo muy nuevo, y eso se notó en mis pruebas.
Fue muy rápido generando código, pero tuvo más dificultades con la depuración y las tareas de varios pasos. A menudo tuve que decirle exactamente qué hacer para que avanzara.
Aun con esos problemas, creo que el modelo tiene mucho potencial.
Con mejores prompts y futuras mejoras, puede convertirse en un modelo local de programación muy usable, similar a mi experiencia con Qwen3.6 27B.
También creo que es una gran dirección para Meta AI.
Hay un claro interés en agentes de programación en local porque ofrecen:
- Menor coste, sin cargos por API
- Más privacidad para tu código y tus datos
- Mayor control sobre el output
- Capacidad de trabajar en local sin depender de una API externa
En mi equipo, el modelo usó alrededor de 24 GB de memoria de GPU, lo que lo hace práctico para hardware local de gama alta.
También puedes ejecutar modelos así con memoria del sistema o unificada, aunque el rendimiento será menor.
En esta guía, compilamos llama.cpp, descargamos los archivos GGUF de Muse Glimmer, activamos la visión y la decodificación especulativa, probamos la API y la Web UI, y conectamos el modelo a OpenCode.
También lo usamos para crear y probar una aplicación completa.
Mi principal conclusión es que Muse Glimmer es muy rápido creando código, pero aún necesita instrucciones claras al depurar o manejar tareas agentivas más complejas.
