Presentan Muse Spark 1.1

 (ai.meta.com)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Muse Spark 1.1, presentado por Meta Superintelligence Labs, es un modelo de razonamiento multimodal orientado a tareas de agentes, con mejoras frente a la versión anterior en uso de herramientas y de computadoras, programación y comprensión multimodal
  • Su punto clave es encargarse de la planificación y orquestación en apps y servicios externos, y generalizar en zero-shot a native tools, MCP servers y custom skills
  • Gestiona activamente una ventana de contexto de 1 millón de tokens para recuperar información de trabajos previos y mantener comprimido el contexto clave necesario para pasos posteriores
  • Los desarrolladores pueden acceder al modelo desde la Meta Model API en vista previa pública, y en la app de Meta AI y en meta.ai puede usarse en modo “Thinking”
  • Meta realizó evaluaciones de seguridad antes del despliegue según el Advanced AI Scaling Framework, y concluyó que está dentro de márgenes de seguridad en las categorías Chemical & Biological, Cybersecurity y Loss of Control

Posicionamiento y disponibilidad de Muse Spark 1.1

  • Muse Spark 1.1 es el modelo más reciente de Meta Superintelligence Labs y se presenta como una mejora importante frente a Muse Spark
  • Es un modelo de razonamiento multimodal para tareas de agentes, con énfasis en mejoras en las siguientes áreas
    • uso de herramientas
    • uso de computadoras
    • programación
    • comprensión multimodal
  • Este lanzamiento, junto con la presentación de Muse Image, se conecta con el avance hacia la visión de “personal superintelligence” que plantea Meta
  • Los desarrolladores pueden acceder a Muse Spark 1.1 a través de la Meta Model API, disponible en vista previa pública
  • En la app de Meta AI y en meta.ai está disponible en modo “Thinking”

Tareas de agentes y manejo de contexto largo

  • Planifica y orquesta el flujo de ejecución en tareas de agentes personales que abarcan múltiples apps y servicios externos
  • Generaliza en zero-shot a native tools, MCP servers y custom skills
  • Fue entrenado para manejar proyectos complejos mucho más rápido que Muse Spark
    • El agente principal recopila contexto, traza un plan y delega la ejecución a subagentes en paralelo
    • Los subagentes siguen la tarea asignada, entienden las herramientas disponibles y escalan al agente principal cuando es necesario
  • Gestiona activamente una ventana de contexto de 1 millón de tokens
    • recuerda las acciones realizadas
    • recupera información de trabajos mucho anteriores
    • comprime el contexto para conservar los pasos clave necesarios en tareas posteriores

Automatización del uso de computadoras

  • Muse Spark 1.1 muestra fortaleza en flujos de trabajo de uso de computadoras donde se cambia entre varias aplicaciones y la información se actualiza en tiempo real
  • Mantiene el contexto incluso en sesiones largas, se adapta a requisitos cambiantes y explora interfaces no familiares con mínima intervención humana
  • No resuelve siempre las tareas de escritorio clic por clic, sino que elige entre automatización y manipulación directa según la situación
    • escribe scripts cuando la automatización es más rápida
    • usa clics cuando la interacción directa es más simple
    • genera varias acciones agrupadas en cada paso
  • En el ejemplo de preparación de una fiesta nocturna, detecta la aparición de nuevo contexto durante el proceso de pedido y realiza las actualizaciones necesarias sin intervención del usuario

Rendimiento en programación y flujo de trabajo de desarrollo

  • El rendimiento de Muse Spark 1.1 mejora notablemente en tareas reales de programación que implican bases de código grandes y complejas
  • Puede diagnosticar y corregir bugs complejos, implementar nuevas funciones en sistemas de nivel empresarial y realizar migraciones de código a gran escala
  • Muestra mejoras importantes frente al primer modelo en casos de uso como creación de aplicaciones web y preguntas y respuestas end-to-end
  • Fue entrenado para adaptarse con fluidez a distintos harnesses y manejar de forma estable comportamientos multivuelta complejos
    • planning mode
    • goal conditioning
    • subagent delegation
    • funciones comunes de programación para agentes como context compaction
  • En una demo de depuración con OpenCode, crea una app web de chat, detecta fallas visibles para el usuario con capturas de pantalla automáticas, rastrea el código relacionado, aplica la corrección y luego valida los cambios
  • Desarrolladores e investigadores internos de Meta ya usan Muse Spark 1.1 a diario, y en el Meta Internal Coding Bench muestra una mejora marcada frente a Muse Spark y resultados competitivos frente a alternativas importantes
  • Los investigadores también están usando Muse Spark 1.1 en sus flujos de trabajo para automatizar tareas de desarrollo y evaluación de modelos
  • En un ejemplo de evaluación de DeepSWE, autoevalúa dentro de OpenCode algunas tareas de DeepSWE con distintos niveles de intensidad de razonamiento y genera un panel de análisis basado en los resultados

Comprensión multimodal y ejecución

  • Muse Spark 1.1 también destaca en tareas que combinan percepción, razonamiento multimodal y uso de herramientas
  • Puede generar resultados fundamentados mientras interactúa con entornos reales
    • generación de código a partir de material visual
    • generación de captions muy detallados para imágenes y video
    • ejecución de flujos de trabajo de agentes para casos de uso multimodales
  • Sus capacidades multimodales son especialmente útiles cuando se requieren percepción y acción al mismo tiempo
    • inspecciona elementos visuales y de audio
    • conserva detalles durante flujos de trabajo largos
    • aprovecha esos detalles al manipular la computadora en nombre del usuario
  • En el ejemplo del agente para Facebook Marketplace, extrae fotos útiles de un video grabado con smartphone, infiere el producto y luego manipula el navegador del usuario para crear la publicación en Marketplace

Evaluación de seguridad

  • Antes del despliegue, Meta realizó una amplia evaluación de seguridad conforme al Advanced AI Scaling Framework
  • Este framework define evaluaciones, modelos de amenaza y criterios de despliegue para los modelos más avanzados de Meta
  • Las categorías evaluadas incluyen los siguientes frontier risks
    • Chemical & Biological
    • Cybersecurity
    • Loss of Control
  • En la evaluación de Meta, Muse Spark 1.1 opera dentro de márgenes de seguridad en todas las categorías de frontier risk
  • Muestra fuerte resistencia a jailbreaks directos, ataques indirectos provenientes de datos no confiables, prompt injection y ataques contra el developer prompt
  • Como resultado, mejora la robustez adversarial y reduce la tasa de hallucination y la sycophancy
  • Todo el contenido relacionado con seguridad está documentado en el Muse Spark 1.1 Evaluation Report

Reacción de socios iniciales y planes futuros

  • Con la vista previa pública de Meta Model API, los desarrolladores pueden empezar por primera vez a construir sobre Muse Spark 1.1
  • Los socios iniciales lo evalúan como un modelo base capaz de manejar cargas de trabajo de agentes a gran escala combinando contexto largo, programación y capacidades de razonamiento
  • El CEO de Replit, Amjad Masad, destacó que un solo modelo reúne contexto de 1 millón de tokens, soporte multimodal para imagen, video y PDF, búsqueda integrada con citas, salida estructurada, llamadas paralelas a herramientas y un paquete compatible con OpenAI
  • El CEO de Cline, Saoud Rizwan, señaló que quiso ofrecer acceso anticipado a los desarrolladores de Cline por combinar un fuerte uso de herramientas con un nivel de precio capaz de ejecutar cargas reales de programación a escala
  • Yashodha Bhavnani, de Box, evaluó que Muse Spark mostró capacidades empresariales competitivas frente a los principales modelos frontier actuales en el conjunto de evaluación de trabajo empresarial de Box
  • Dave Morin, de OpenClaw Foundation, calificó a Muse Spark 1.1 como un modelo rápido y potente para la ejecución de agentes
  • Meta está entrenando modelos con mayor rendimiento y planea compartir más adelante

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios de Hacker News

  • Hay muchísimos más detalles en el informe enlazado: https://ai.meta.com/static-resource/muse-spark-1-1-evaluatio...
    Si miras los detalles de Terminal-Bench-2.1, dice: “evaluamos las 89 tareas de Terminal-Bench 2.1 del repositorio oficial con un harness de agente exclusivo para herramientas bash, y los recursos se limitaron a CPU de 6 núcleos y 8 GB de RAM”, así que ese resultado queda descalificado
    Cada tarea de terminal bench tiene su propio límite de CPU y de RAM, y si excedes cualquiera de los dos, quedas descalificado. En tbench-2.1, de las 89 tareas, 0 permiten CPU de 6 núcleos, y solo 8 permiten 8 GB de RAM
    Este tipo de benchmarking sospechoso le quita por completo la gracia de construir harnesses para mejorar el rendimiento del modelo en benchmarks, porque hagas lo que hagas no puedes vencer las cifras inexactas del titular. Probablemente por eso este modelo no aparece en el leaderboard oficial https://www.tbench.ai/leaderboard/terminal-bench/2.1
    Como ex empleado de Meta, me deja un sabor amargo, pero no me sorprende tanto. Hasta que terminaba el PSC y pasabas a lo siguiente, subir los números era la métrica clave de evaluación de desempeño

    • No entiendo por qué habría que considerar los límites de recursos, salvo cuando el modelo por accidente provoca una fork bomb. Pensé que este benchmark medía el uso de terminal, especialmente la capacidad de encadenar muchas llamadas a herramientas de bash; ¿en qué casos de prueba importa esto?
    • Este es justamente el problema de los modelos cerrados. No sabemos con certeza si por lo que pagamos es por un modelo base superior o por un harness bien diseñado para maximizar el puntaje en benchmarks
    • Pregunta sincera: ¿con qué frecuencia los límites de recursos se vuelven el cuello de botella? ¿Qué ayuda aporta el harness aquí? ¿Limitar el paralelismo o usar herramientas más eficientes?
    • Entiendo el punto, pero no sé si sea tan importante
      ¿harbor / tb2.1 limitó el swap disponible para las ejecuciones de Docker? Antes había un bug donde ejecutar instancias de Docker podía usar más memoria de la especificada. Algunas de las tareas originales eran prácticamente imposibles de completar sin aprovechar swap, y si impedías que Docker accediera al swap, ni siquiera la solución oracle podía pasar
      Si no recuerdo mal, crack-7z-hash y filter-js-from-html tenían ese problema, pero no lo he visto en meses, así que no estoy seguro
    • No me parece un problema tan grande. Al evaluar cualquier producto, no tomas al pie de la letra lo que dice quien lo fabricó. Obviamente habrá sesgo. Para eso existen las pruebas independientes como https://artificialanalysis.ai

  • Pude usarlo unos días antes y durante ese tiempo hice un plugin para LLM. Puedes probar el modelo así desde la terminal
    uv tool install llm
    llm install llm-meta-ai
    llm keys set meta-ai
    # paste API key here
    llm -m meta-ai/muse-spark-1.1 "Generate an SVG of a pelican riding a bicycle"
    El resultado está aquí: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...
    Para comparar, el pelícano generado por Muse Spark 1 está aquí: https://simonwillison.net/2026/Apr/8/muse-spark/

    • Me pregunto cómo te das tiempo para previsualizar tantos modelos. Los lanzamientos recientes de modelos han sido una locura; ¿a veces no se siente como trabajo?

  • Quizá a Zuck le convenga más enfocarse en ser el spoiler del mercado de modelos que en competir de frente
    No necesita igualar los ingresos por modelos de Anthropic o OpenAI; basta con que pueda recortarlos en 99%. Puede seguir gastando miles de millones de dólares en desarrollar modelos frontier y publicarlos con pesos abiertos para convertir los modelos de código en un commodity. También hace falta un buen harness open source de referencia
    Casi no hay nadie en una posición desde la que pueda hacer esto y que además tenga sentido de negocio. De todos modos, es probable que la tendencia vaya hacia allá, y él podría acelerar mucho ese proceso. Igual que pasó con los compiladores, habría que esperar que los modelos pasen de ser productos monopólicos a commodities
    Podría ser una de las mejores cosas que Zuck puede hacer por el mundo

    • Si ellos pierden ingresos, ¿quién termina alquilando los recursos de cómputo de Meta?
    • Para ser el verdadero rey de los spoilers, tendría que liberar como open source el dataset de entrenamiento. Dudo que lleguen tan lejos
    • Los modelos de código no son el destino final. Son solo parte del proceso de bootstrapping hacia la inteligencia general
    • ¿No intentaron ya hacer eso con llama?
    • Lo que él tiene que hacer es demostrar que construir estos modelos ya no es tan difícil. El foso de estas empresas es la percepción de que construir modelos frontier es realmente difícil

  • El precio es ridículamente bueno. $1.25 de entrada y $4.5 de salida por cada 1 millón de tokens, y la entrada en caché cuesta $0.15
    https://dev.meta.ai/docs/getting-started/pricing-rate-limits

    • Esto es lo más comparable de forma directa con xAI Grok 4.5. Ambos apuntan más o menos a una “inteligencia nivel Opus al precio de Haiku”, y para los desarrolladores de aplicaciones que quieren meter un modelo así en sus apps, esto es algo enorme
      Estaba haciendo pruebas para reemplazar Haiku y Sonnet por Grok 4.5, y también pienso probar este. Sobre todo, el precio de caché es mucho más barato
    • La proporción de precio para entrada en caché es buena
      Grok 4.5 salió con $2/$6, pero silenciosamente cobra $0.50 por cada 1 millón de tokens de entrada en caché. Eso está al nivel de precio de Opus 4.8
    • Meta ahora mismo no está en el radar de la mayoría de la gente que elige modelos. Si de verdad tienen un buen modelo, tiene sentido subsidiarlo para ganar usuarios antes de igualar los precios de la competencia
    • Es más barato que Qwen 3.7 Max. Después de los $2 de entrada / $6 de salida de Grok 4.5, esta es la segunda señal de que los grandes laboratorios están sintiendo la presión de GLM 5.2
    • Aun así, sigue siendo absurdamente caro. Si piensas que tendrías que pagar $10 por 100 resultados de búsqueda de Google, en la práctica esto es eso
      De verdad no entiendo por qué alguien querría gastar más de $1.50 por cada 1 millón de tokens de salida, y ni hablar de $15~50. ¿De verdad hay consumidores pagando cobro por uso?

  • Hasta ayer parecía que OpenAI y Anthropic llevaban una ventaja irreversible, pero ahora xAI y Meta al menos ya sacaron cosas que pueden competir con los modelos prácticos y además son baratas
    Claro, si vemos Fable, y probablemente GPT-6 cuando salga pronto, sigue en pie la idea de que los dos laboratorios líderes van adelante, pero no es un juego completamente terminado como lo venía diciendo la gente que marca la conversación pública

    • Los modelos ya son, en general, lo suficientemente buenos. Si no hay un gran avance, lo único que importa de aquí en adelante es el costo
    • La gente interpretó mal que Google se quedara atrás como si Anthropic y OpenAI estuvieran lejísimos adelante. En realidad se parece más a que Google se rezagó, como pasó con Tensorflow, Angular y GCP
    • Ese matiz es un poco distinto
      Ya había mucha expectativa por GLM 5.2 desde antes. No es que xAI o Meta hayan creado una gran diferencia de otra manera, sino que están más cerca de resultados y precios similares a los de GLM 5.2

  • En lo personal no me gusta Meta, pero esto sí se reconoce. Mientras más competencia haya, mejor para el consumidor común y también para las empresas
    Que compitan modelos chinos, Grok, Meta, Google, OpenAI y Anthropic me parece una victoria. Estoy construyendo como loco para aprovechar al máximo estos tokens subsidiados mientras se pueda

    • En algún momento, los modelos llama locales de Meta fueron la cara de la IA de código abierto. De verdad ha cambiado muchísimo el panorama
    • Definitivamente me parece algo bueno. Pero todavía sigo debatiendo internamente si estos avances van a aumentar o reducir la cantidad de ingenieros de software necesarios en la era de la IA
      Por un lado, hacer productos se vuelve más fácil, así que más gente va a construir, y habrá más productos y más funciones. Mucha gente no técnica también va a intentar crear cosas, pero se va a topar con límites, y al final va a necesitar ingenieros. La cantidad total de productos que van a crear las empresas tecnológicas con experiencia, los fundadores no técnicos y los aspirantes a fundadores será enorme. Ahí está el escenario alcista en el que en el futuro cercano se necesitarán más ingenieros de software
      Por otro lado, dentro de un año la gente habrá creado un montón de estos productos, pero la mayoría no va a poder comercializarlos, venderlos ni monetizarlos. Al final podría no hacer falta tanta gente de software. Aun así, en términos generales, creo que el escenario alcista probablemente gane en efecto neto
    • Si se amplía la lista de modelos chinos, están DeepSeek, GLM(Z.ai), Minimax, Kimi(Moonshot), Hy3(Tencent) y Qwen(Alibaba)
      En cada caso se pueden descargar los pesos para ejecución local
    • Él publicó esta noticia en X, no en su propio Meta Threads. Eso muestra hasta qué punto quiere amplificarla. Claro, mientras estas empresas sigan quemando efectivo, desde nuestro lado los costos pueden seguir en un nivel manejable
    • Esta es la mayor competencia tecnológica que he visto hasta ahora. Entraron las empresas más ricas, la gente más inteligente y los países más ricos
      No sé si la competencia sea buena; lo veremos en unos años. Tengo ganas de que llegue el día en que vuelva a tener un trabajo físico

  • ¿Cómo puede ser que todas las empresas logren hacer que parezca que son las número 1 en todos los benchmarks?

    • Primero ven qué modelos salen peor en un conjunto de benchmarks escogidos por ellos mismos
      Luego comparan con la versión anterior del modelo de la competencia. Si aun así no se ve bien, entonces comparan con su propio modelo anterior
    • Porque no hay un gran foso, las mejoras son graduales y siempre se puede escoger qué modelos meter en la comparación
      Siendo justos, si la fortaleza principal es el precio, sí parece más apropiado comparar con modelos de rendimiento similar
    • Ahora compararse con Gemini ya se siente como una casilla gratis del bingo
    • Para la gente que conoce a fondo el tema de IA, ¿cuál se considera el benchmark estándar en coding?
    • Solo tienen que esperar el momento exacto en que su modelo supere al menos en N benchmarks y anunciarlo entonces

  • Se me pasó que Meta estaba desarrollando y lanzando un modelo de pesos cerrados. Qué lástima. Ojalá hubiera más avances en modelos estadounidenses de pesos abiertos

  • Lo hice funcionar con codex dentro de un contenedor. Como referencia, parece que hay un bug que aparece en la mayoría de los casos con la interfaz Codex:Muse
    Por lo que veo, codex no esperaba llamadas de herramientas del lado del servidor, y por la manera en que Meta maneja esos IDs, se produce una especie de error de parsing o de integración. Las primeras veces que ejecuté codex con muse, falló en la primera llamada que no era de búsqueda web
    Ya lo corregí, y personalmente todavía no estoy del todo convencido con las llamadas de herramientas del lado del servidor personalizadas ni con el almacenamiento indefinido de archivos, pero hasta ahora me parece un modelo bastante genial y lo estoy usando con gusto
    https://github.com/accretional/awesome-muse-spark/blob/main/...

  • Al ver los benchmarks publicados, parece que también es bastante bueno en programación y multimodalidad, pero su tasa de éxito en llamadas a herramientas parece ser muy buena
    ¿Cuál sería el caso de uso que mejor encaja con este tipo de rendimiento?

    • La depuración y el diagnóstico implican muchísimas llamadas a herramientas. Incluye desde hacer grep o transformar logs, hasta invocar profilers o trazadores, e incluso redactar informes de incidentes
      El diagnóstico de bugs es un área donde hay que programar hasta cierto punto, pero donde también se necesita aprovechar mejor las herramientas. Si hay un buen informe de diagnóstico, la corrección se le puede dejar a Opus
      Opus también redacta informes hasta cierto punto, pero en documentos de typst todavía se equivoca seguido con el ancho de las tablas, y termina llenando de texto la última columna aunque su ancho sea de apenas unos pocos caracteres
    • Gemini 3.5 Flash es mejor que Fable en llamadas a herramientas. Las llamadas a herramientas probablemente sean una de las áreas que se pueden mejorar con relativa facilidad mediante postentrenamiento
    • Me pregunto si veremos este patrón en cada nuevo lanzamiento a futuro. El uso de herramientas puede cambiar muy rápido, así que el modelo más reciente podría tener siempre ventaja sobre el modelo más inteligente
    • Esto suena un poco inútil. Es interesante que el rendimiento de un decodificador restringido como JSON sea excelente, pero en un decodificador general, un bucle donde se pasa por un validador de herramientas, se recibe un buen mensaje de error y luego se reintenta casi siempre logra hacer funcionar la herramienta en el segundo intento. Como la entrada queda en caché, el costo tampoco es caro.