Meta dice 3.1x pero no dice de cuánto: corriendo Muse Glimmer 30B local con llama.cpp
Meta Superintelligence Labs liberó Muse Glimmer el 10 de agosto: un modelo denso de 30 mil millones de parámetros, Apache-2.0, destilado por logits desde Muse Spark, multimodal y entrenado con datos de más de 100 idiomas. El encuadre del propio blog es inusualmente estrecho para el lanzamiento de un modelo — esto no se presenta como un 30B de propósito general, se presenta para un solo trabajo: “Muse Glimmer is a 30-billion-parameter model optimized for always-on local agent workflows.”
El argumento técnico detrás de ese pitch es un envelope de memoria. En precisión completa el modelo necesita más de 55 GB. Cuantizado a 4 bits con K-quants, el language model baja de 20 GB, lo que lo mete dentro de máquinas de 24 y 32 GB. Y para que un agente always-on sea tolerable a ese tamaño, Meta incluye un drafter de speculative decoding, DFlash, con tres speedups publicados: 3.1x en una RTX 5090, 1.8x en una M5 Max, 1.5x en una M4 Max.
Esos son los números del anuncio. Hay dos cosas que conviene saber de ellos antes de planificar una máquina alrededor.
Primero: los speedups no tienen denominador. Meta publica multiplicadores y ningún throughput absoluto en ninguna parte — ni en el blog, ni en la model card. Un 3.1x sobre un tok/s que no se declara te dice que el drafter funciona; no te dice si el agente es usable en tu máquina. Ese número lo tienes que medir tú, y la última sección de este artículo es cómo.
Segundo: los “menos de 20 GB” son solo el modelo de texto. El vision encoder y el drafter son archivos aparte, y cada uno es memoria que también tienes que sostener. La cifra real viene más abajo.
Qué salió de verdad, y qué no
El blog dice que las optimizaciones de llama.cpp, MLX y ExecuTorch “will land in the coming days”. Eso fue cierto durante alrededor de un día, y ya quedó viejo justo para la que más importa.
El soporte de llama.cpp está mergeado y funcionando hoy — build b10353 o posterior, aterrizó el 10 de agosto. Meta publicó GGUFs oficiales en meta-models/Muse-Glimmer-30B-GGUF, y la comunidad tenía conversiones arriba el mismo día (bartowski, unsloth). MLX y ExecuTorch sí siguen pendientes de verdad. Así que si estás en Apple silicon y esperabas MLX, sigues esperando; si quieres correr esto hoy en cualquier cosa, llama.cpp es el camino, Metal incluido.
Esa es la diferencia entre una integración anunciada y una mergeada, y en este lanzamiento corta para los dos lados.
Cuánta máquina hace falta de verdad
El repo oficial de GGUFs de Meta trae cuatro archivos. Esta es la tabla que el titular de “menos de 20 GB” comprime:
| Archivo | Tamaño | Qué es |
|---|---|---|
muse-glimmer-30B-kquant-17gb.gguf |
16.8 GB | Modelo de texto, apuntado a 24 GB de VRAM |
muse-glimmer-30B-kquant-dynamic.gguf |
19.7 GB | Variante de mayor calidad, apuntada a 32 GB |
mmproj-kquant.gguf |
1.4 GB | Vision encoder — necesario para imágenes |
dflash-kquant.gguf |
1.6 GB | Drafter de speculative decoding DFlash |
Lo que da tres configuraciones reales, según los propios requisitos declarados por Meta:
- Solo texto — ~17–20 GB
- Texto + visión — ~19–22 GB
- Texto + visión + drafter — ~20–23 GB
Y eso es antes del KV cache. Fíjate en lo que significa para la placa de 24 GB a la que apunta el quant de 17 GB: con visión y drafter cargados estás en ~20–23 GB de pesos, y el context window que puedes pagar es lo que sobre. Muse Glimmer soporta 131.072 tokens de contexto y hasta 262.144 — no vas a servir el techo de ese rango en una placa de 24 GB con el vision encoder residente. El envelope de 32 GB es donde la configuración completa deja de ser una negociación.
Este es un número de factibilidad, no de velocidad. Te dice si el modelo entra, y no dice nada de qué tan rápido corre una vez que entró.
Si quieres más aire, los dynamic quants de Unsloth bajan más: UD-Q2_K_XL en 12–14 GB, UD-Q3_K_XL en 14–15 GB, UD-Q4_K_XL en 17 GB (su punto de partida recomendado), UD-Q6_K_XL en 20–22 GB, UD-Q8_K_XL en 34 GB. Una advertencia de su documentación: NVFP4 está marcado como work-in-progress y por ahora no funciona. No planifiques alrededor de eso.
Empieza por el quant de 17 GB incluso si tienes 32 GB. Se descarga más rápido, te deja espacio para sumar el vision encoder y el drafter de a uno, y vas a aprender dónde está tu propio techo caminando hacia él en vez de arrancar por encima.
Cómo correrlo
El camino mínimo es un comando, una vez que tengas un llama.cpp actual:
# se requiere build b10353 o posterior
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON # Metal viene activado por defecto en macOS; quita la flag para CPU-only
cmake --build build --config Release -j
Después, el modelo:
llama serve -hf meta-models/Muse-Glimmer-30B-GGUF
Eso baja el quant por defecto y te deja un endpoint compatible con OpenAI. Los settings de sampling recomendados por Meta son temperature 1.0, top-p 0.95, top-k 64 — conviene ponerlos de forma explícita, porque correr un 30B con defaults ajustados para otro modelo es una forma habitual de concluir que un modelo es peor de lo que es.
Para sumar visión, carga el multimodal projector junto a los pesos de texto:
llama-server \
-m muse-glimmer-30B-kquant-17gb.gguf \
--mmproj mmproj-kquant.gguf \
-c 32768
Mantén el contexto moderado al principio. -c 32768 en una placa de 24 GB es un punto de partida realista con visión cargada; súbelo hasta que choques con un fallo de asignación de memoria y después baja un escalón. Ten en cuenta que el video se procesa solo como frames individuales — acá no hay modelado temporal.
Para sumar el drafter, DFlash entra como draft model:
llama-server \
-m muse-glimmer-30B-kquant-17gb.gguf \
--model-draft dflash-kquant.gguf \
-c 32768
Vale la pena entender el mecanismo, porque explica de dónde sale el speedup y cuándo se evapora. DFlash es un drafter de 5 capas con sliding-window attention que predice bloques enteros de 16 tokens en un solo forward pass; después el 30B verifica el bloque de una sola vez. Cuando el drafter adivina bien, obtienes muchos tokens por cada forward pass caro. Cuando adivina mal, pagas el pass del drafter y recibes poco a cambio. El speculative decoding es una apuesta a la predictibilidad — que es exactamente por lo que rinde bien en cargas agénticas llenas de tool calls estructurados y JSON, y peor en prosa abierta.
Eso también explica la diferencia entre hardware: 3.1x en una RTX 5090 contra 1.8x en una M5 Max no es el drafter comportándose distinto, es cuánto estaba limitado por ancho de banda de memoria el paso de decode de base.
Midiendo el número que Meta no publicó
Como no hay ningún tok/s de referencia en todo el lanzamiento, así consigues el tuyo. llama-bench te da prefill y decode por separado:
llama-bench -m muse-glimmer-30B-kquant-17gb.gguf -p 512 -n 128
pp512 es prefill (procesamiento del prompt), tg128 es decode (generación de tokens). Son números distintos con cuellos de botella distintos y quieres los dos — un agente que lee un contexto grande antes de cada acción vive o muere por el prefill, no por el decode.
Después corre lo mismo con el drafter conectado y compara. Tu multiplicador no va a ser 3.1x salvo que estés en una RTX 5090 corriendo una carga tan predecible como la de Meta, y ese es justamente el punto: el multiplicador es una propiedad de tu carga de trabajo, no del modelo.
Haz la medición con los prompts reales que manda tu agente. Un loop de tool-calling y una sesión de chat te van a dar tasas de aceptación bastante distintas.
¿Es realmente mejor que lo que ya estás corriendo?
La tabla de benchmarks de Meta compara Muse Glimmer contra Gemma4-31B y Qwen3.6-27B. Todas las cifras son auto-reportadas por Meta:
| Benchmark | Muse Glimmer | Gemma4-31B | Qwen3.6-27B | |
|---|---|---|---|---|
| Agentic | MCP Atlas | 75.5 | 54.2 | 62.5 |
| DeepSearch QA | 74.6 | 61.7 | 71.1 | |
| Coding | SWE-Bench Pro | 51.2 | 36.9 | 50.2 |
| SWE-Bench Verified | 76.0 | 66.6 | 77.2 | |
| Multimodal | Charxiv Reasoning | 78.8 | 77.7 | 78.4 |
| MMMU Pro | 74 | 73 | 75 | |
| Reasoning | AIME 2026 | 94.7 | 89.2 | 94.1 |
| GPQA Diamond | 83.5 | 85.7 | 84.2 |
Lee esa tabla con honestidad y dice algo más útil que “Meta gana”. En coding, multimodal y reasoning, Muse Glimmer y Qwen3.6-27B se intercambian posiciones dentro de un punto o dos, y Qwen se lleva SWE-Bench Verified y MMMU Pro. Gemma4-31B se lleva GPQA Diamond. Esas columnas describen tres modelos de la misma clase.
El único lugar donde la brecha no es marginal es lo agéntico: MCP Atlas 75.5 contra 62.5 de Qwen — trece puntos — y DeepSearch QA en 74.6 contra 71.1. Ahí es donde aparecen el mid-training con datos de contexto largo cargados de agentes y el RL del post-training, y es la única columna que justifica el encuadre del lanzamiento.
El hilo de HN (1.123 puntos, 609 comentarios) llegó a la misma lectura desde el otro lado: los usuarios describen a Glimmer apenas por encima de Qwen3.6-27B en casi todo excepto en tool-calling. No aparecen autores de Meta en el hilo. Otros reportes que vale la pena pesar: los tamaños cuantizados quedan cerca (un Q4_K_XL en ~15.9 GB contra los 17.6 GB de Qwen3.6-27B), el KV cache limita la inferencia paralela práctica a unas 4 requests concurrentes en hardware de consumo, y las trazas de razonamiento de Glimmer se describen de forma consistente como escuetas.
Así que la decisión es más estrecha de lo que sugiere el anuncio. Si corres un modelo local para chat, autocompletado de código o escritura, el caso para cambiar es delgado — un par de puntos de benchmark, para cualquiera de los dos lados. Si corres un modelo local como agente — servidores MCP, loops de herramientas, workflows multi-paso — esa brecha de trece puntos en MCP Atlas es la razón entera por la que este modelo existe, y vale la pena medirla contra tu propio setup.
Qué revisar antes de comprometerte
Tres cosas que este lanzamiento no te dice, en orden de cuánto te van a costar:
- El throughput absoluto. Mídelo. Un 3.1x en una máquina que decodifica a 4 tok/s es un producto distinto de un 3.1x en una que decodifica a 40.
- Tu prefill. Los loops de agente releen contexto todo el tiempo. Nadie publicó una cifra de prefill y
llama-bench -pte da la tuya en un minuto. - Si necesitas el vision encoder o no. Son 1.4 GB de memoria residente más su parte del envelope. Si tu agente nunca ve una imagen, dejar
mmprojsin cargar te devuelve contexto.
Y si estás en Apple silicon: llama.cpp con Metal funciona hoy, MLX todavía no. Conviene saber cuál estás esperando antes de planificar alrededor de un número.
Si ya corres un modelo local como agente — ¿cuánto de tu setup está limitado por tokens por segundo, y cuánto por el modelo simplemente eligiendo la herramienta equivocada? Cuéntanos qué estás corriendo y sobre qué.