1 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • En una nueva medición de una VM con macOS 26.4.1 en una Mac mini M4 Pro, incluso con una configuración de 5 núcleos virtuales y 16 GB de vRAM, el rendimiento de CPU de un solo núcleo y de la GPU se acercó al del host
  • Según Geekbench 6.7.1, la CPU de un solo núcleo obtuvo VM 3,855 / host 3,948, y la GPU Metal VM 106,896 / host 111,970, lo que equivale aproximadamente al 98% y 95% del host, respectivamente
  • La CPU multinúcleo marcó VM 13,222 / host 23,342; como el host tiene 14 núcleos (10 P + 4 E) y la VM 5 núcleos virtuales, la comparación directa es difícil, pero el rendimiento de la VM es bastante bueno
  • La parte más débil fue el Neural Engine virtual: en pruebas de CoreML de media precisión y cuantización fue mucho más lento que el host, por lo que en la VM puede esperarse que las tareas de IA se procesen con CPU y GPU
  • En pruebas de configuración mínima, incluso con solo 2 núcleos virtuales y 4 GB de memoria pudo manejar sin problemas tareas ligeras como Safari y el análisis de almacenamiento en Configuración; considerando las actualizaciones de macOS, un almacenamiento de al menos 60 GB para la VM resulta adecuado

Contexto de la prueba

  • Las cifras de rendimiento usadas en una revisión de la virtualización de macOS en Apple silicon correspondían a mediciones anteriores y no abordaban las especificaciones mínimas de una VM utilizable
  • Con el creciente interés en ejecutar una VM en una MacBook Neo, se volvió a comprobar el rendimiento y la configuración mínima con base en macOS Tahoe

Medición e interpretación del rendimiento

  • El host de pruebas es una Mac mini M4 Pro con macOS 26.4.1, 14 núcleos (10 P + 4 E), 48 GB de RAM y SSD interno de 2 TB
  • A la VM invitada se le asignaron 5 núcleos virtuales y 16 GB de RAM virtual
  • Las puntuaciones de Geekbench 6.7.1 fueron ligeramente más rápidas que antes tanto en el host como en la VM
  • Los resultados fueron los siguientes
    • CPU de un solo núcleo: VM 3,855, host 3,948
    • CPU multinúcleo: VM 13,222, host 23,342
    • GPU Metal: VM 106,896, host 111,970
    • Neural Engine CoreML: VM 5,291 / 8,577 / 6,877, host 5,973 / 41,251 / 56,616
  • Las tres cifras de Neural Engine CoreML corresponden, en ese orden, a las pruebas de precisión simple, media precisión y cuantización
  • El resultado de CPU multinúcleo es difícil de comparar directamente porque el host tiene más del doble de núcleos que la VM, y 4 de ellos son núcleos E
  • La comparación del rendimiento de GPU se obtuvo bajo la condición de que el host no estuviera compitiendo por usar la GPU al mismo tiempo
  • Al ejecutarse en una VM, puede esperarse que macOS procese las tareas de IA con CPU y GPU en lugar del Neural Engine

Prueba de configuración mínima

  • Desde la aparición de la MacBook Neo, existía interés en saber si sería posible ejecutar una VM en ese equipo
  • Como host Linux parecía viable, pero había dudas sobre si una VM de macOS podría servir para trabajo útil; en las pruebas reales sí fue posible
  • Para comprobar la configuración mínima, la misma VM con macOS 26.4.1 se ejecutó en Viable reduciendo gradualmente la asignación de núcleos de CPU y memoria
  • La ventana de visualización de la VM se configuró en el estándar 1600 × 1000
  • Se usó Safari de varias maneras y se realizaron tareas cotidianas ligeras, incluido el análisis de almacenamiento en Configuración
  • Los resultados por configuración fueron los siguientes
    • Con 4 núcleos virtuales y 8 GB de vRAM, la VM se comportó de forma completamente fluida y usó alrededor de 5 GB de memoria
    • Con 3 núcleos y 6 GB, el uso de memoria bajó a 3.9 GB y todo funcionó bien
    • Con 2 núcleos y 4 GB de memoria, solo se usaron 3.1 GB y siguió manejando normalmente las tareas ligeras
  • Una VM de macOS con solo 2 núcleos virtuales y 4 GB de memoria también parece viable en una MacBook Neo y podría realizar tareas cotidianas sin problema
  • No es un entorno para probar LLM, pero sí resulta suficientemente útil para tareas ligeras de macOS

Almacenamiento y limitaciones de actualización

  • Al crear una VM en una Mac con SSD interno pequeño, hay que prestar atención al tamaño de la VM
  • Una VM de macOS mucho menor a 50 GB ya no podrá realizar actualizaciones de macOS
  • Para tener margen y seguridad, conviene apuntar a un mínimo de 60 GB
  • En APFS, la VM se guarda como un archivo disperso, por lo que incluso una VM base de 100 GB solo necesita alrededor de 54 GB reales en disco
  • Una configuración así podría encajar mejor en una MacBook Neo con SSD de 512 GB

1 comentarios

 
GN⁺ 1 시간 전
Comentarios de Hacker News
  • Es un buen recordatorio de que hay cierta cantidad de memoria asociada a cada núcleo. Probablemente tenga que ver sobre todo con page cache o con cosas como el manejo de concurrencia

    • Yo apostaría por la hipótesis nula. Si se mantuviera fijo el número de núcleos y solo se ajustara el tamaño de memoria de la VM, probablemente habría aparecido la misma variación en el uso de memoria
    • En general, la cantidad de memoria física instalada en una computadora también debería ser proporcional al número de hilos de hardware que ofrece la CPU
      No solo porque el sistema operativo puede asignar algo de memoria por hilo, sino porque las apps multihilo que usan todos los hilos, como compilar proyectos grandes de software, muchas veces reservan memoria de trabajo en proporción a la cantidad de hilos
      También he visto muchas apps multihilo que funcionan bien solo si tienen hasta unos 2 GB por hilo, así que en una CPU de escritorio de 32 hilos como la Ryzen 9 9950X, 64 GB encajan bastante bien
      Al compilar proyectos como Chrome/Chromium con una CPU de 16 núcleos/32 hilos, si solo tienes 32 GB, tienes que reducir la cantidad de compilaciones simultáneas con parámetros adecuados como make -j y dejar algunos núcleos ociosos. Si no, puedes encontrarte con un error de falta de memoria
    • Sí hay un overhead por núcleo, pero parece más probable que esta reducción de uso se deba a que al disminuir la memoria disponible cambia la forma en que el kernel asigna memoria
      Cuando hay mucha memoria, el kernel mantiene por más tiempo la caché de lectura, prefiere la compresión de memoria antes que el swap a disco y limpia con menos frecuencia la memoria recuperable. El tamaño de los buffers internos y de la tabla de vnode también se ajusta según la memoria total
      Eso está bien en el sentido de que aprovecha al máximo los recursos disponibles de forma dinámica, pero a cambio dificulta ver cuál es la línea base mínima necesaria para el funcionamiento real
      Un comando interesante para revisarlo es vm_stat, donde puedes ver valores como páginas free/active/inactive/wired/purgeable, compressor, pagein/pageout y swapin/swapout. Edición: no sé si no hay soporte para Markdown con cercas de código o si hice algo mal
  • Compré hace poco una M5 Air y es mi primera vez con macOS, así que estoy tratando de entender esta parte, pero parece que obtener pytorch, aceleración por GPU y aislamiento a nivel de VM/contenedor al mismo tiempo es prácticamente imposible
    La capa virtio-gpu parece lo más cercano, pero da la impresión de que solo expone GPU gráfica y no GPU de cómputo, así que pytorch no funciona

    • Yo también necesitaba eso y busqué bastante hace un año. Aún no he tenido tiempo de revisar los cambios recientes en Docker Model Runner (vllm-metal) o en podman libkrun, ¿ninguno de los dos te funcionó?
    • Logré ejecutar torch con éxito en una instancia de Cirruslabs Tart
  • La única VM que he usado en macOS es colima+docker, y es relativamente dolorosa e ineficiente. Aun así, se puede usar

    • Vale la pena probar el container CLI de Apple. Hace unas semanas, durante un fin de semana, migré uno de mis proyectos desde colima+docker con bastante facilidad
      https://github.com/apple/container
    • Compré un Mac Mini para CI local y estuve revisando bastante el ecosistema para usarlo con Forgejo Actions, pero al final terminé yéndome por compilar en el host
      Aislar del host la configuración de firmado y notarización parecía demasiado difícil de manejar, incluso usando agentes. Aun así, ahora los builds de macOS son realmente rápidos, y el firmado/notarización se resuelve con unas 200 líneas de Bash
    • OrbStack está bastante bien. No lo siento particularmente ineficiente
  • https://github.com/trycua/cua/tree/main/libs/lume mostró un enfoque interesante para este problema

  • Aunque al iniciar la VM use solo 5 GB, ¿no terminaría queriendo los 8 GB completos asignados cuando ejecutes apps dentro de la VM, en vez de esos 5 GB del arranque?

    • No pensaba que la virtualización de macOS fuera lo bastante avanzada como para soportar memory ballooning, ¿no se trata de eso?
      Edición: yo estaba equivocado
  • Creo que yo tengo la más pequeña. docker.io/gotson/crossbuild latest d96ea9b7054b 3 years ago 6.71 GB, y la uso para cross-build de Darwin

  • Sinceramente, parece que macOS podría bajar mucho más que eso en una VM si desactivas las cosas que no son estrictamente necesarias
    El primer iPhone solo tenía 128 MiB de RAM, y según entiendo corría una versión recortada de macOS Tiger. Hasta ahora simplemente no había motivo para reducirlo porque la RAM ha sido bastante abundante, pero sin duda es posible y probablemente ni siquiera tan difícil. Solo haría falta volver a intentarlo

    • Los primeros iPhone no tenían multitarea de apps, así que la diferencia es bastante grande. Cuando cerrabas una app, se terminaba
  • ¿Se puede ejecutar macOS en una PC? O al menos, ¿se puede hacer de alguna manera desarrollo para Mac desde una PC?

    • Se puede arrancar macOS con QEMU, pero no puedes usar gráficos con aceleración por hardware ni algunas otras funciones
  • Pregunta un poco fuera de tema, pero ¿será posible inscribir en Intune una VM de macOS como dispositivo personal?

  • Me pregunto por qué nadie crea un entorno de agente dedicado para macOS. Estaría bueno que el agente se lanzara dentro de un entorno Mac