Muse Glimmer 30B: el regreso de Meta al open-weight, en local con Ollama

#¿Por qué Muse Glimmer 30B?

Muse Glimmer 30B marca el regreso de Meta al terreno de los modelos de pesos abiertos. Tres aspectos lo convierten en un modelo interesante para alojarlo por tu cuenta: la licencia Apache 2.0 (uso comercial sin cláusula de umbral de usuarios, a diferencia de las antiguas licencias de Llama), la multimodalidad nativa de texto + imagen y una arquitectura pensada para los bucles de agentes: llamadas fiables a herramientas, salidas estructuradas y un presupuesto de razonamiento ajustable.

El verdadero argumento sigue siendo el tamaño. Con 30 mil millones de parámetros y el GGUF Q4_K_M publicado por Meta, el modelo funciona en una sola GPU de consumo de 24 a 32 GB. No hacen falta varias GPU ni descargar parte del modelo al disco: estamos en la misma categoría de accesibilidad que un Qwen 32B, pero con visión además.

Licencia

Apache 2.0 — uso comercial libre, redistribución y fine-tuning autorizados sin restricción de volumen.

Modalidades

Texto e imagen de entrada, texto de salida. Diseñado para la lectura de capturas de pantalla, esquemas y documentos.

Objetivo

Agentes y herramientas: llamadas a funciones, JSON estricto y contexto largo para las trazas de ejecución.

Formato oficial

GGUF Q4_K_M empujado day-0 en la biblioteca Ollama, más un portaje MLX para Apple Silicon.

#Requisitos y VRAM (24-32 GB)

Los pesos de un 30B en Q4_K_M ocupan alrededor de 18-19 GB. Pero con Muse Glimmer, el proyector de imagen y la caché de contexto aumentan el consumo real de memoria: calcula entre 24 y 32 GB de VRAM para un uso multimodal cómodo con un contexto de trabajo adecuado. Para texto únicamente y con un contexto pequeño, una GPU de 24 GB es más que suficiente.

Configuración ideal

RTX 4090 de 24 GB o RTX 5090 de 32 GB entre las opciones de NVIDIA: todo en VRAM, sin recurrir a la CPU.

Apple Silicon

Mac M4 Pro/Max con 32 GB de memoria unificada o más. La memoria compartida aloja el modelo y la caché de imágenes sin problemas.

Gama de entrada

Una RTX 4080 de 16 GB ejecuta el modelo, pero este no cabe por completo en la VRAM: parte de las capas pasa a la RAM y la inferencia se ralentiza considerablemente.

Software

Ollama ≥ 0.6 (soporte day-0 de la arquitectura), controladores GPU actualizados (CUDA lado NVIDIA), 30 GB de espacio en disco libre.

#Instalación de Ollama paso a paso

Si Ollama no está ya instalado, el procedimiento dura dos minutos. El daemon escucha por defecto en http://localhost:11434, y es él quien descarga y sirve el modelo.

1. 01
   Instalar Ollama

   En Linux, un solo comando. En macOS y Windows, descarga la aplicación desde ollama.com. Comprueba después que el daemon esté funcionando con `ollama --version`.
2. 02
   Descargar Muse Glimmer 30B

   La etiqueta oficial apunta al GGUF Q4_K_M. La descarga ocupa aproximadamente 18-19 GB: ten en cuenta el ancho de banda y el espacio en disco necesarios.
3. 03
   Primer intercambio

   Inicia el modelo en modo interactivo. En el primer arranque, Ollama carga los pesos en la VRAM (unos segundos según la GPU) y luego aparece un indicador de entrada.
4. 04
   Exponer la API

   Una vez descargado el modelo, el endpoint compatible con OpenAI ya está disponible en el puerto 11434. No hace falta ninguna configuración adicional para conectar una app o Open WebUI a ese endpoint.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version

# Télécharge le GGUF Q4_K_M officiel (~18-19 Go)
ollama pull muse-glimmer:30b

# Chat interactif
ollama run muse-glimmer:30b

Para un uso programático, la API REST responde en JSON. Aquí tienes una llamada mínima que utiliza solo texto:

curl http://localhost:11434/api/chat -d '{
  "model": "muse-glimmer:30b",
  "messages": [
    { "role": "user", "content": "Résume en trois points ce que change la licence Apache 2.0 pour un projet commercial." }
  ],
  "stream": false
}'

#Usar las funciones multimodales

El interés de Muse Glimmer está en razonar sobre imágenes: leer una captura de pantalla de un error, extraer una tabla de un documento escaneado, describir un esquema de arquitectura. En la CLI, basta con arrastrar la ruta de la imagen al prompt.

ollama run muse-glimmer:30b
>>> Décris cette capture et liste les erreurs visibles: ./capture-console.png

A través de la API, se envía la imagen codificada en base64 en el campo `images` del mensaje. Es el formato estándar de los modelos de visión de Ollama, por lo que todos los clientes existentes funcionan sin adaptación.

import base64, requests

with open("schema.png", "rb") as f:
    img = base64.b64encode(f.read()).decode()

resp = requests.post("http://localhost:11434/api/chat", json={
    "model": "muse-glimmer:30b",
    "messages": [{
        "role": "user",
        "content": "Quels composants communiquent avec la base de données ?",
        "images": [img],
    }],
    "stream": False,
})
print(resp.json()["message"]["content"])

Para su uso con agentes, Muse Glimmer acepta definiciones de herramientas en formato OpenAI. Describes tus funciones en el campo `tools` y el modelo devuelve una llamada estructurada que tu código ejecuta antes de devolver el resultado. Este es el aspecto en el que más se ha trabajado el modelo: pocas alucinaciones en los argumentos y JSON válido de forma fiable.

#Decodificación especulativa DFlash

Meta lanza Muse Glimmer con DFlash, su método de decodificación especulativa: un pequeño modelo «borrador» propone varios tokens por adelantado, que el modelo principal valida en una sola pasada. Cuando las propuestas son buenas —lo cual es frecuente en código y texto estructurado— se generan varios tokens por paso en lugar de uno, lo que aumenta la tasa de generación sin pérdida de calidad, y la salida sigue siendo idéntica a la de una decodificación clásica.

El principio

Un modelo ligero de borrador predice la continuación; el modelo de 30B verifica los tokens en bloque y acepta los correctos.

La mejora

La velocidad de generación aumenta con contenidos previsibles (código, JSON, trazas de agente); la mejora es nula o negativa con texto muy creativo, donde fallan las predicciones.

El costo

El modelo borrador ocupa un poco más de VRAM: una razón para optar por 32 GB si quieres tener DFlash activo en modo multimodal.

Activación

Según la versión de Ollama, DFlash se configura a través de un parámetro del Modelfile o una opción de servicio. Revisa la nota de versión oficial del tag.

#En Mac: la adaptación a MLX

Meta también publicó una versión MLX, el framework de Apple optimizado para la memoria unificada de los chips M. En un Mac reciente, MLX aprovecha mejor la GPU integrada que el backend Metal de llama.cpp para este modelo, con un consumo de memoria más previsible.

En concreto: si usas Apple Silicon y quieres la máxima velocidad, prueba la versión adaptada a MLX en paralelo con Ollama. Ollama sigue siendo la opción más sencilla para la integración y la API compatible con OpenAI; MLX busca maximizar la velocidad de procesamiento en Mac. La elección depende de si priorizas la comodidad o el rendimiento puro.

#Las puntuaciones anunciadas, con perspectiva crítica

Meta anuncia una puntuación de 51,2 en SWE-Bench Pro, el benchmark de resolución de tickets reales de software. Sobre el papel, es excelente para un modelo de 30B: suficiente para competir con modelos mucho más grandes. Pero una cifra promocional no permite juzgar cómo funciona en la práctica.

El contexto cuenta

Una puntuación en SWE-Bench depende mucho del entorno de ejecución del agente, del prompt y del número de intentos permitidos. Dos configuraciones pueden producir una diferencia de 15 puntos en la puntuación del mismo modelo.

Q4 no es FP16

Las puntuaciones oficiales se miden con precisión completa. El GGUF Q4_K_M que ejecutas pierde un poco de fidelidad: la diferencia es real en las tareas al límite de sus capacidades.

Tus tareas ≠ el benchmark

SWE-Bench se basa en código abierto en Python. Tus propios tickets —otro lenguaje, una base de código propietaria, en francés— no se comportan necesariamente de la misma manera.

El enfoque adecuado: considera 51,2 una señal alentadora, no una promesa. Prepara entre cinco y diez tareas representativas de tu trabajo real, mide la tasa de éxito en Q4_K_M en tu máquina y compárala con la del modelo que ya utilizas. Es el único benchmark que cuenta para tu decisión.

#Solución de problemas

Desbordamiento de VRAM en modo multimodal

Reduce el tamaño de las imágenes enviadas y el contexto (`num_ctx`), o desactiva DFlash para liberar la memoria del modelo borrador.

Etiqueta no encontrada

El soporte es day-0 pero requiere una versión reciente de Ollama. Haz `ollama --version` y actualiza si el pull falla con un error de arquitectura.

Generación muy lenta

Verifica con `ollama ps` que el modelo esté completamente en la GPU (100 %). Si indica un porcentaje de uso de CPU, significa que la capacidad de la VRAM se ha superado: es el caso típico con 16 GB.

JSON de herramienta inválido

Baja la temperatura y proporciona esquemas de herramientas explícitos. Muse Glimmer es fiable al generar salidas estructuradas, pero una temperatura alta rompe la consistencia.

#Para ir más allá

Muse Glimmer se instala como cualquier otro modelo Ollama: las guías a continuación cubren las bases si estás empezando o quieres optimizar.

Instalar Ollama correctamente

La guía «Instalar Ollama en Linux» explica en detalle systemd y la configuración de GPU NVIDIA/AMD si empiezas desde cero.

Elegir la cuantización adecuada

« Elegir la cuantización (Q4, Q5, Q8, FP16) » explica el equilibrio calidad/memoria — útil para decidir si Q4_K_M es suficiente o si se debe buscar Q5.

Dimensionar el GPU

Antes de comprar hardware para un 30B multimodal, «Elegir tu GPU para la IA local» te ayuda a evitar que subestimes la VRAM necesaria.