Meta presentó Muse Glimmer, un modelo de pesos abiertos de 30 mil millones de parámetros destilado desde Muse Spark y orientado a flujos de trabajo agénticos que corren en el propio dispositivo. En paralelo, ExecuTorch sumó soporte de extremo a extremo para ejecutarlo sobre GPU NVIDIA y en Mac con silicio de Apple.
¿Por qué ExecuTorch y no otro runtime local?
La mayoría de los frameworks de IA local reescriben los modelos en lenguajes distintos de Python. Según el equipo de PyTorch, ese enfoque escalaba bien cuando los modelos eran transformers de texto estándar, pero hoy las arquitecturas se volvieron más complejas: entradas y salidas multimodales, diseños nuevos y algoritmos de decodificación avanzados como DFlash, una decodificación especulativa basada en difusión paralela pensada para baja latencia. Reimplementar todo eso en cada backend no escala.
ExecuTorch toma otro camino. El ingeniero implementa el modelo, y su estrategia de decodificación, en PyTorch. Al momento de desplegar exporta a ExecuTorch y el framework se encarga del descenso específico por backend: Triton sobre CUDA, y MLX nativo o Metal personalizado en silicio de Apple. La compilación anticipada optimiza el camino de ejecución completo, no operación por operación.
Así se habilitaron las entradas de texto e imagen de Muse Glimmer, la exportación directa desde GGUF, la ejecución nativa de K-quants, el contexto de más de 128 mil tokens y la decodificación especulativa DFlash. El equipo publicó paquetes de artefactos PTE precompilados, listos para descargar y correr con el runtime de ExecuTorch.
¿Cómo se pone en marcha?
Un PTE es el artefacto serializado que la pila de Python de ExecuTorch produce de forma anticipada a partir del grafo PyTorch del modelo, ya optimizado para un backend específico.
Hay PTE verificados publicados en Hugging Face para CUDA de NVIDIA y para Metal en Apple Silicon, en versiones de solo texto y de texto más imagen, con y sin DFlash. Están disponibles en este repositorio.
Quien prefiera construirlos por su cuenta puede seguir el README de Muse Glimmer en ExecuTorch y elegir backend, modalidad, largo de contexto y uso de DFlash. La exportación parte directo desde los checkpoints GGUF liberados. En CUDA, la exportación compila y autoajusta kernels de Triton para la arquitectura de GPU detectada, por lo que conviene exportar en la misma arquitectura donde se va a ejecutar.
ExecuTorch trae presets de CMake para los backends CUDA y MLX. Tras seguir las instrucciones de instalación, la construcción del runtime es directa:
# Construir los runners para tu backend:
$ cd examples/models/muse-glimmer
$ cmake --workflow --preset muse-glimmer-cuda # usar muse-glimmer-mlx en macOS
# Esto compila solo_runner, dflash_runner y el worker de servicio.Una vez construidos, el modelo se puede invocar directamente desde la línea de comandos:
$ PROMPT='<|start|>user<|message|>Describe this image: <img><|eot|><|start|>assistant'
$ cmake-out/examples/models/muse-glimmer/dflash_runner \
--model_path artifacts/dflash-vision/model.pte \
--data_path artifacts/dflash-vision/aoti_cuda_blob.ptd \
--tokenizer_path assets/hf/tokenizer.json \
--image_path image.jpg --prompt "$PROMPT" \
--block_length 4 --n_draft 3 --temperature 0 --max_new_tokens 256También puede levantarse como servidor local compatible con API, para que un agente de código lo consuma como si fuera un proveedor remoto.
Rendimiento medido
En el experimento de entrada de texto e imagen sobre un Mac M5 Pro de 64 GiB, la ejecución simple alcanzó 21,6 tokens por segundo, mientras que la configuración con DFlash llegó a 33,0 tokens por segundo, una mejora de 52,8% sin regresión de calidad, según las mediciones publicadas.
| Configuración en M5 Pro (64 GiB) | Velocidad | Diferencia |
|---|---|---|
| Ejecución simple (solo runner) | 21,6 tok/s | referencia |
| Con DFlash (decodificación especulativa) | 33,0 tok/s | +52,8% |
Las curvas de prefill y decodificación se midieron con contexto variable sobre una NVIDIA A100, usada como aproximación a las tarjetas RTX, y sobre un Mac con M5 Max.
Qué se construyó por dentro
Para habilitar DFlash, el equipo optimizó la interoperabilidad entre el modelo objetivo y el borrador compartiendo pesos y exportando ambos en un único PTE. La dimensión del bloque de DFlash se exporta de forma dinámica, así un mismo PTE admite largos de bloque seleccionables en tiempo de ejecución. El runtime soporta tanto decodificación voraz como muestreo por rechazo.
En cuanto a cuantización, la exportación sale directo del GGUF liberado con el modelo. Los formatos Q4_K, Q5_K y Q6_K se mapean a INT4, INT5 e INT6 empaquetados con kernels GEMV dp4a en CUDA, y a kernels Metal reempaquetados o fusionados en MLX. En MLX, al reempaquetar se fusionan subbloques adyacentes cuya escala y mínimo son idénticos hasta un tamaño de grupo de 128, siempre que la fusión sea sin pérdida.
Del lado del servicio, una sola carga del modelo atiende múltiples conversaciones aisladas mediante reasignación de estado mutable por sesión en ambos backends. Se sumó además plantillado de conversación Harmony con enrutamiento de razonamiento y un analizador para el formato XML de llamadas a herramientas del modelo, incluidas varias llamadas en un mismo turno.
Entre las optimizaciones por backend, la decodificación se captura en un grafo CUDA, lo que reduce la sobrecarga de lanzamiento de kernels a un solo envío. Los kernels de K-quant empaquetados aceleran la decodificación con lotes pequeños, y las rutas de FlashDecoding++ con división K sensible al largo optimizan la decodificación de un token y los bloques cortos de verificación de DFlash. RMSNorm, RoPE, SDPA, las actualizaciones de caché KV y las operaciones lineales cuantizadas bajan a implementaciones nativas de MLX o a Metal personalizado.
¿Por qué el contexto largo no revienta la memoria?
Muse Glimmer admite más de 128 mil tokens de contexto y es eficiente en el crecimiento de su caché KV: solo 13 de sus 52 capas son globales, las otras 39 usan ventana deslizante. Esa proporción, cercana al 25%, es la que vuelve práctico el contexto largo en dispositivos de borde, donde la memoria disponible es el límite duro.
Un dato que el anuncio no entrega y conviene tener a mano al planificar hardware: a 4 bits por parámetro, 30 mil millones de parámetros ocupan alrededor de 15 GB solo en pesos, antes de la caché KV. Es decir, una tarjeta de 24 GB de memoria de video deja margen razonable para contexto extendido, mientras que una de 16 GB obliga a bajar la cuantización o a recortar el contexto. Para integradores en Chile y la región, donde el equipamiento con más de 24 GB de memoria de video sigue siendo caro y de importación lenta, esa aritmética define si el proyecto corre en una estación local o termina en la nube.
Qué falta todavía
Esta primera versión soporta entradas de texto e imagen; el video aún no está disponible y sigue en desarrollo. Tampoco hay compartición de prefijos entre sesiones, checkpointing ni batching continuo, tres funciones en las que el equipo está trabajando para hacer ExecuTorch más apto para cargas agénticas.
Referencias: Muse Glimmer en ExecuTorch, Muse Glimmer en Hugging Face y la documentación de ExecuTorch.
