Meta lanza Muse Glimmer, un modelo multimodal de aproximadamente 30 mil millones de parámetros que admite contexto de hasta 128K y puede ejecutarse en dispositivos con 24 GB de memoria VRAM. El modelo está disponible bajo licencia Apache 2.0, utiliza GQA para reducir el uso de KV Cache, combina una arquitectura híbrida de atención local y global para disminuir el costo computacional de contextos largos, y ofrece dos versiones cuantizadas para adaptarse a distintos dispositivos con memoria VRAM. El módulo visual incluye un encoder de percepción ViT independiente para procesar capturas de pantalla e información de pantalla; durante el entrenamiento, se introduce On Policy Distillation para abordar desviaciones en tareas largas. El componente de aceleración de inferencia DFlash emplea Block Diffusion para predecir tokens en paralelo, logrando un aumento de aproximadamente 3 veces en la velocidad de decodificación en RTX 5090. El modelo obtiene excelentes resultados en benchmarks de agentes como MCP Atlas y DeepSearch QA, pero aún tiene margen de mejora en escenarios puramente GUI como OSWorld Verified.

Autor y fuente del artículo: Leifeng.com

Ayer, Meta lanzó Muse Glimmer. Se trata un modelo de agente multimodal de aproximadamente 30 mil millones de parámetros, que admite contexto de hasta 128K, puede invocar herramientas, ejecutar código y procesar imágenes e información de pantalla.

Este modelo está disponible bajo la licencia Apache 2.0, junto con dos versiones cuantizadas de 4-bit, un codificador visual independiente y componentes de aceleración de inferencia DFlash, y ofrece formas de implementación local como llama.cpp, MLX y ExecuTorch.

Aunque el tamaño de parámetros de 30B y el contexto de 128K no parecen excepcionales hoy en día, el problema radica en que Meta quiere que realice algo más que una conversación común: quiere establecer un modelo completo de ejecución de Agentes locales.

El agente local de larga duración de Muse Glimmer enfrenta restricciones de ingeniería exigentes: debe procesar capturas de pantalla generadas continuamente mientras mantiene lógicas de tareas que duran decenas de pasos, todo dentro de una memoria gráfica limitada de 24 GB. Después de ejecutar una tarea durante decenas de pasos, los resultados de las herramientas anteriores, los registros de código, el estado de la página y los procesos de razonamiento se acumulan constantemente en el contexto.

En este momento, muchos problemas que no eran evidentes en escenarios de chat se amplifican rápidamente. ¿Cómo se introduce un contexto de 128K en memoria gráfica limitada? ¿Cómo se gestionan los estados históricos cuando hay cada vez más capturas de pantalla? ¿Cómo continúa el modelo tras un fallo en la llamada a una herramienta? ¿A qué velocidad se ralentiza el Decode debido a la gran cantidad de tokens de razonamiento?

El diseño técnico de Muse Glimmer se centra básicamente en estas preguntas. No resuelve todos los problemas mediante una nueva arquitectura particularmente llamativa, sino que realiza compromisos agresivos en Attention, KV Cache, forma de entrenamiento, cuantización y Decode.

Si antes los modelos locales eran "capaces de funcionar", el objetivo de Muse Glimmer es "funcionar tan bien y de manera continua como en la nube".

Ver estas partes juntas ayuda a entender mejor por qué Meta lo diseñó de esta manera, en comparación con mirar solo el 30B o el 128K por separado.

¿Cómo caben 128K de contexto en 24 GB de memoria GPU?

Muse Glimmer utiliza 52 capas Dense Transformer, un tamaño oculto de 6656, 32 cabezas de consulta y solo 2 cabezas de KV.

Attention no procesa el contexto completo en cada capa, sino que utiliza un ciclo de tres Attention locales seguidos de un Attention global.

Local Attention solo procesa los 2048 tokens cercanos; Global Attention se encarga del intercambio de información a distancias mayores.

Ambos diseños realmente aumentan simultáneamente el costo del contexto largo. Cuando el modelo genera nuevos tokens, almacena en caché las claves y valores de los tokens anteriores, conocidos como KV Cache. Cuanto más largo sea el contexto, mayor será el espacio que ocupa esta parte.

Muse Glimmer tiene solo 2 cabezas KV por capa, con una dimensión de cabeza de 128. Según un cálculo aproximado en BF16, un token ocupa aproximadamente 1024 bytes en KV por capa.

Si las 52 capas guardaran completamente el contexto de 128K, la caché KV requeriría aproximadamente 6,5 GiB. Sin embargo, Muse Glimmer tiene realmente 39 capas locales y 13 capas globales. Las capas locales solo necesitan mantener una ventana deslizante de aproximadamente 2048 tokens; solo las capas globales necesitan guardar el contexto largo completo.

Siguiendo el mismo cálculo, la caché KV podría reducirse a aproximadamente 1.7 GiB. Esto no es el uso de memoria GPU publicado oficialmente, sino solo una estimación teórica basada en los parámetros de arquitectura públicos, pero ya permite entender por qué se diseñó esta estructura así.

Si en lugar de usar 2 KV Heads, guardara KV independientes para los 32 Heads como en la MHA tradicional, bajo las mismas condiciones, la caché KV teóricamente aumentaría aproximadamente 16 veces, llegando directamente a más de 20 GiB.

El caché KV por sí solo ya supera una tarjeta gráfica de 24 GB. Aquí se utilizan en realidad dos métodos. GQA reduce la cantidad de KV que se debe guardar por token, y la atención local reduce el número de capas que necesitan guardar KV completos a largo plazo.

Después de completar este paso, la cuantificación ponderada tiene sentido. El peso de Muse Glimmer con K Quant de 17 GB es aproximadamente 16.8 GB, el módulo visual alrededor de 1.4 GB, DFlash aproximadamente 1.6 GB; sumados, estas partes ya alcanzan casi 20 GB. Esta versión está diseñada para dispositivos con 24 GB de memoria VRAM, mientras que otra versión de aproximadamente 20 GB de Dynamic K Quant está orientada a dispositivos de 32 GB.

Las dos cuantizaciones no difieren solo en tamaño de archivo. Entre las 15 métricas de benchmark proporcionadas por Meta, la pérdida promedio de precisión para Dynamic K Quant es aproximadamente del 0,2%, mientras que para K Quant 17 GB es del 1,0%.

Es decir, la versión de 24 GB reduce aún más la memoria de video y ocupa menos espacio, pero requiere aceptar una pérdida de rendimiento ligeramente más notable. La versión de 32 GB intenta conservar el rendimiento original del modelo.

El contexto de 128K de Muse Glimmer se logra con esta combinación. Primero, la atención reduce el cálculo; luego, GQA reduce el KV Cache; finalmente, se comprimen los pesos del modelo mediante cuantización.

Este enfoque también tiene un costo. Las 39 capas Locales solo pueden acceder directamente a 2048 tokens cercanos; la información a larga distancia debe propagarse a través de la capa Global. Por lo tanto, poder ingresar 128K no es lo mismo que poder utilizar de manera estable todo el 128K.

Los resultados de Beam128K de Meta indican que esta estructura híbrida local y global aún posee una buena capacidad para aprovechar información a larga distancia, pero aborda el contexto largo, no la memoria a largo plazo. Qué información debe guardarse, qué ya está obsoleta y cuándo actualizar el estado aún requiere el procesamiento del Agent Runtime.

Este problema se vuelve más evidente con el agente visual.

128K tampoco es espacio ilimitado

Muse Glimmer también incluye un ViT G 14 Perception Encoder con aproximadamente 1.8 mil millones de parámetros, diseñado para procesar capturas de pantalla, páginas web, gráficos y documentos. Una imagen puede convertirse en un máximo de 4096 tokens visuales.

Actualmente es entrada de texto e imágenes, salida de texto, y no se introducen todos los modalidades en el mismo modelo de generación.

Dentro del flujo de trabajo del agente, esta capacidad visual se encarga principalmente de leer el estado del entorno. El agente de uso de computadora primero observa la pantalla actual, identifica la ubicación de las páginas, botones y textos, y luego realiza una operación. Después de que la página cambie, vuelve a leer la nueva captura de pantalla para decidir el siguiente paso.

Por lo tanto, las entradas visuales continúan ingresando al contexto. Si se conservan completamente todas las capturas de pantalla de una tarea de decenas de pasos, incluso con 128K, el contexto se llenará rápidamente con tokens visuales. Las capturas de pantalla antiguas también podrían entrar en conflicto con el estado actual. La página ya ha cambiado, pero los botones y ventanas anteriores siguen presentes en el contexto, lo que obliga al modelo a realizar una evaluación adicional para determinar cuál es el estado más reciente.

Meta tampoco conserva ilimitadamente el historial de capturas de pantalla en la evaluación de OSWorld Verified, sino que solo mantiene las capturas más recientes. Esto demuestra que el Perception Encoder y la Gestión del Contexto son dos problemas distintos.

El primero se encarga de convertir la pantalla actual en información que el modelo pueda entender, mientras que el segundo debe determinar qué estados históricos aún tienen valor y cuáles deben eliminarse. Por lo tanto, 128K parece más bien proporcionar al agente un espacio de trabajo más amplio, en lugar de eliminar la gestión de estado.

Y cuando el agente interactúa constantemente con el entorno, la pregunta también pasa de lo que el modelo vio a lo que el modelo acaba de hacer.

Ahora entra en la parte de entrenamiento de Muse Glimmer.

¿Cómo continuar después de que el agente se desvíe?

Muse Glimmer se destila a partir de Muse Spark.

Meta divide el entrenamiento en Pre Training, Mid Training y Post Training. Pre Training utiliza Logit Distillation, Mid Training incorpora más datos de contexto largo, Reasoning Trace y Agent, y Post Training añade SFT, On Policy Distillation y RL.

La destilación Logit tiene una ligera diferencia con el enfoque tradicional de entrenar un modelo pequeño con las respuestas de un modelo grande. Cuando el docente predice el siguiente token, genera una distribución de probabilidad sobre todo el vocabulario. El estudiante no solo aprende el token final seleccionado, sino también el juicio relativo del docente sobre los demás candidatos.

Esto es útil para el agente, ya que muchos escenarios no tienen una única acción posible. Frente a una página web, el modelo puede continuar buscando, abrir un resultado determinado o cambiar de herramienta. La distribución de probabilidad del profesor incluirá sus preferencias sobre estas acciones, no solo el texto final producido.

En Mid Training, el entrenamiento comienza a pasar de respuestas individuales a trayectorias de tareas completas. Después de ejecutar una herramienta, el entorno cambia: la búsqueda devuelve nuevos resultados, la ejecución de código fallida genera errores y hacer clic incorrectamente en la GUI también cambia la página. Es decir, la salida del agente modifica directamente la entrada del siguiente paso.

Supongamos que la trayectoria correcta del Teacher es de A a B, luego a C y finalmente a D. Si el Student solo aprende de los datos del Teacher, verá repetidamente A a B y B a C. Pero en la ejecución real, el Student podría llegar al primer paso a otro estado B.

A partir de este momento, el entorno ha cambiado, y el camino de B a C en el conjunto de entrenamiento no puede decirle directamente cómo actuar ahora. La distilación On Policy es lo que actúa aquí. El estudiante primero realiza un Rollout por sí mismo, entrando en los estados que realmente producirá, y luego recibe supervisión de un modelo más fuerte en esos estados.

Por lo tanto, los datos de entrenamiento ya no solo incluyen la ruta ideal del profesor, sino que también cubren los estados de error generados por el estudiante. Esto está conectado con la recuperación de fallos enfatizada por Muse Glimmer.

Después de ingresar parámetros incorrectos, si el modelo puede comprender el error y realizar una nueva llamada a la herramienta, la tarea aún puede continuar. Si se toma un camino incorrecto en la web, siempre que se identifique que el estado actual es incorrecto, se puede retroceder o cambiar de ruta. Lo realmente problemático es cuando el modelo no se da cuenta del error y continúa ejecutándose sobre el estado erróneo, permitiendo que el desvío se acumule.

Por lo tanto, la capacidad de un agente no debe evaluarse solo por si una llamada a herramienta es correcta en un solo intento, sino también por si puede completar la tarea final y recuperarse después de errores intermedios. Esto explica por qué Muse Glimmer tiene un mejor rendimiento en algunos benchmarks de agentes de larga duración.

Sin embargo, que la tarea se pueda completar no significa que no haya problemas con la ejecución local. Si una tarea compleja genera una gran cantidad de tokens de razonamiento, el nuevo cuello de botella rápidamente se convertirá en el decode.

Dos preguntas una tras otra

Muse Glimmer admite cuatro niveles de fuerza de razonamiento: low, medium, high y xhigh. Esta configuración puede entenderse como el presupuesto de razonamiento en tiempo de ejecución.

Los niveles más altos suelen hacer que el modelo genere más tokens de razonamiento, lo que puede aumentar la tasa de éxito en tareas complejas de codificación y agentes, pero el costo es directo: el contexto crece más rápido y el tiempo de decodificación es más largo.

Meta utiliza high Reasoning Strength en su Benchmark público. Esto da lugar a DFlash.

La decodificación de Transformer es autoregresiva. El segundo token debe esperar al primero, y el tercero depende del segundo. Para respuestas de cientos de tokens, esto es aceptable, pero una tarea de un agente puede generar acumulativamente miles o incluso decenas de miles de tokens.

La técnica de Speculative Decoding consiste en agregar un Drafter más pequeño. El Drafter primero predice un segmento futuro de tokens, y luego el modelo principal los verifica de forma simultánea. Si múltiples candidatos pueden aceptarse consecutivamente, se reduce la cantidad de pasos de Decode ejecutados por el modelo principal de 30B.

El problema con los enfoques tradicionales es que el propio Drafter suele ser un modelo autoregresivo. Si debe generar 16 tokens, aún así necesita generarlos uno por uno.

DFlash reemplazó este fragmento por Block Diffusion.

El tamaño del bloque DFlash de Muse Glimmer es 16, lo que permite predecir en paralelo un conjunto de tokens candidatos. Pero solo ser más rápido no es suficiente para Drafter. Si las predicciones son inexactas, el modelo principal rechazará muchos candidatos, y la ventaja de velocidad inicial se perderá rápidamente.

Por lo tanto, DFlash también lee directamente las Funciones Ocultas de las capas 1, 13, 25, 37 y 49 de Muse Glimmer y envía estas representaciones intermedias al Drafter, que solo tiene 5 capas. Así, Drafter no necesita comprender por sí mismo el contexto completo, sino que aprovecha directamente las representaciones internas ya formadas por el modelo principal de 30B.

Estas características no se utilizan solo una vez en la entrada, sino que se inyectan continuamente en las claves y valores de cada capa del Drafter para evitar que se debiliten progresivamente a medida que la red se profundiza.

Hay un detalle adicional durante el entrenamiento. En un bloque de 16 tokens, los tokens iniciales son más importantes que los finales. Si el primer token es incorrecto, incluso si los posteriores se adivinan correctamente, la longitud de aceptación continua será muy corta.

Por lo tanto, DFlash asigna un mayor Loss Weight a los tokens antes del bloque, reduciéndolos progresivamente después. Optimiza el prefijo aceptable más largo posible, en lugar de perseguir simplemente la precisión promedio en 16 posiciones. En los datos K Quant de 17 GB proporcionados por Meta, la velocidad de Decode en RTX 5090 aumentó de aproximadamente 74,9 tokens/s a 233,4 tokens/s.

Si una tarea de Agent genera acumuladamente 10.000 tokens, solo considerando el Decode, la primera requiere aproximadamente 134 segundos, mientras que la segunda, unos 43 segundos. Las tareas reales también incluyen Prefill, ejecución de herramientas y espera de red, pero para Agents con alta Reasoning Strength, esta diferencia ya afecta notablemente la experiencia completa de la tarea.

High Reasoning Strength aumenta la generación de tokens, y DFlash se encarga de reducir este tiempo. Un contexto largo aumenta el KV Cache, y GQA y Local Attention se encargan de reducir el uso de memoria. La cuantización mantiene los pesos del modelo dentro del rango que las tarjetas gráficas de consumo pueden soportar.

Además, Muse Glimmer obtuvo buenos resultados en los benchmarks de agentes MCP Atlas, DeepSearch QA y Gaia2. Estas tareas requieren cadenas de ejecución largas.

MCP Atlas requiere que el modelo seleccione y llame herramientas entre varios servidores MCP. DeepSearch QA necesita buscar continuamente, abrir páginas, encontrar información y continuar ejecutando según los nuevos resultados. Gaia2 simula aplicaciones con estado, como correo electrónico, calendario y contactos, y el entorno mismo cambia durante la tarea.

Estas tareas son más coherentes con el entrenamiento de Muse Glimmer. Sin embargo, en OSWorld Verified, TerminalBench y SWE Bench Verified, no mantiene la misma ventaja. Por ejemplo, en OSWorld Verified, Muse Glimmer obtiene una puntuación de 65.9, mientras que Qwen3.6 27B alcanza 75.6. En TerminalBench 2.1, Muse Glimmer obtiene 51.7, mientras que el contrario llega a 60.7.

Por lo tanto, su distribución de capacidades es bastante clara. El Agente de Investigación, la colaboración de herramientas y las tareas de larga duración con estado son más fuertes, mientras que los escenarios de GUI pura, terminal y parte de los Agentes de codificación aún tienen un margen de mejora significativo. Estas puntuaciones no deben interpretarse completamente según las listas tradicionales de modelos.

Los resultados del Agent Benchmark también pueden verse afectados por el System Prompt, la definición de herramientas, el scaffold, el número máximo de pasos de ejecución, los parámetros de muestreo e incluso el modelo de evaluación. El mismo Meta indica que las herramientas de agente y los System Prompt utilizados por modelos de terceros no necesariamente están optimizados para ellos.

Por lo tanto, en la fase de Agent, comparar individualmente los Checkpoints ya resulta cada vez más difícil para reflejar la situación completa. La seguridad plantea un problema similar.

Ejecutar localmente realmente reduce el envío frecuente de archivos, capturas de pantalla y contexto privado a la nube, pero esto soluciona únicamente la ruta de los datos. Las inyecciones de prompt, llamadas incorrectas a herramientas, excesos de permisos y operaciones irreversibles siguen existiendo. Meta también evaluó por separado los riesgos agenciales, la privacidad y las inyecciones de prompt, y recomienda seguir aumentando los guardrails y la intervención humana necesaria en despliegues reales.

A clear path of capability

La ruta técnica completa de Muse Glimmer finalmente puede conectarse en una cadena bastante clara.

El tamaño del modelo se mantiene alrededor de 30B, GQA y Local Attention reducen el costo de memoria en contextos de 128K, la cuantización permite que el modelo se ejecute en dispositivos de 24 GB y 32 GB, el Perception Encoder se encarga de leer el entorno visual, On Policy Distillation aborda los estados desviados en tareas largas, Reasoning Strength permite a los desarrolladores controlar el presupuesto de razonamiento, y DFlash maneja la latencia de decodificación generada por grandes cantidades de tokens de razonamiento.

Muse Glimmer no ha demostrado que un modelo local de 30B pueda reemplazar al modelo frontal en la nube, pero sí ha demostrado que el fin último de un modelo local de 30B no radica en la mera escala, sino en el diseño sistémico que equilibra múltiples restricciones físicas. Ya ha integrado en un mismo diseño del sistema las cuatro restricciones más difíciles de manejar en un agente local: memoria gráfica, contexto, percepción del estado del entorno y velocidad de inferencia.

Muse Glimmer, aunque aún no puede reemplazar por completo los modelos de punta en la nube, ya ha trazado un camino viable para la implementación industrial del objetivo de "cada persona tiene su propio agente privado".