macOS Tahoe en VM rinde al 98% del host con Apple Silicon

La virtualización macOS sobre Apple Silicon dejó de ser una curiosidad técnica para volverse una herramienta de uso diario. En su análisis del 2 de mayo de 2026, Howard Oakley publicó nuevos resultados que muestran que una máquina virtual con macOS Tahoe (26.4.1) sobre un Mac mini M4 Pro alcanza el 98% del rendimiento single-core del host en Geekbench 6.7.1, y que basta con asignarle 2 núcleos virtuales y 4 GB de RAM para que cumpla tareas reales sin complicaciones. La pregunta que durante años fue "¿se puede?" ahora es "¿qué tan pequeña puede ser?".

Para los equipos de desarrollo en LATAM, donde el costo del hardware aún pesa fuerte en cada decisión, este dato cambia varias ecuaciones: probar versiones nuevas de macOS sin comprometer la máquina principal, mantener entornos de CI locales, o aislar herramientas problemáticas, todo eso se puede hacer en una VM que casi no degrada el desempeño del host. La virtualización macOS pasó de ser una opción cara o lenta a ser una solución de primera línea cuando el host es Apple Silicon.

Qué pasó: nuevos benchmarks de virtualización macOS

Howard Oakley, autor de la herramienta Viable y referente en virtualización sobre Apple Silicon, publicó una actualización a su revisión sobre máquinas virtuales en macOS, esta vez ejecutada sobre macOS 26.4.1 Tahoe. El experimento usó un Mac mini M4 Pro con 14 núcleos (10 P + 4 E), 48 GB de RAM y SSD interno de 2 TB. La VM se configuró inicialmente con 5 núcleos virtuales y 16 GB de RAM virtual, y se midió con Geekbench 6.7.1.

Después de los números puros, Oakley repitió la prueba pero al revés: en lugar de buscar el techo, fue bajando recursos hasta encontrar el piso. Llegó a 2 núcleos virtuales y 4 GB de RAM, configuración pensando explícitamente en el rumoreado MacBook Neo, el equipo más austero de la línea de Apple para 2026. Encontró que la VM no solo arrancaba: era usable para Safari, configuración del sistema y tareas cotidianas.

La VM comparte el chip Apple Silicon directamente, sin emulación intermedia.

Contexto e historia: por qué la virtualización macOS importa hoy

Durante años, virtualizar macOS fue una historia frustrante. En la era Intel, la licencia de Apple permitía correr macOS en VM solo sobre hardware Apple, pero el rendimiento dejaba mucho que desear y herramientas como VMware Fusion o Parallels Desktop arrastraban una capa de emulación gruesa. Con la transición a Apple Silicon en 2020, Apple introdujo el framework Virtualization.framework, una API nativa que permite correr macOS y Linux como huéspedes con acceso casi directo al hardware, vía hipervisor tipo 2 ligero.

Esto cambió todo. Apps como UTM, VirtualBuddy, Tart y Viable pudieron levantar VMs de macOS sin emular CPU, simplemente compartiendo los núcleos físicos del Apple Silicon con un sobrecosto mínimo. CI services como GitHub Actions y BuildJet adoptaron Tart y máquinas con M2/M3 para ofrecer runners de macOS más baratos, y proyectos como Cirrus Runners escalaron sobre esta arquitectura.

El experimento de Oakley confirma con números lo que esos proyectos venían sospechando: el sobrecosto del hipervisor sobre Apple Silicon es despreciable para tareas de CPU, y mínimo para GPU. La gran limitación restante es el Neural Engine, que sí pierde rendimiento dentro de una VM, sobre todo en cargas half-precision y cuantizadas.

Datos y cifras: la virtualización macOS bajo Geekbench

Los resultados completos del experimento (Geekbench 6.7.1, Mac mini M4 Pro como host) son los siguientes:

• CPU single-core: VM 3,855 vs host 3,948 (la VM corre al 98%).
• CPU multi-core: VM 13,222 vs host 23,342. La comparación directa no aplica porque el host tiene más núcleos físicos, pero al normalizar por núcleos disponibles la VM rinde al menos tan bien como el host.
• GPU Metal: VM 106,896 vs host 111,970 (95% del rendimiento).
• Neural Engine CoreML: VM 5,291 / 8,577 / 6,877 vs host 5,973 / 41,251 / 56,616 (single, half, quantized).

La conclusión es clara: para CPU y GPU el costo de virtualizar es prácticamente cero. Para inferencia de IA con el Neural Engine, sin embargo, la VM se queda muy atrás (sobre todo en half-precision, donde rinde apenas un 21% del host) y conviene fallback al CPU/GPU para esos workloads dentro de la VM.

💭 Clave: el bajo rendimiento del Neural Engine virtualizado sugiere que macOS dentro de una VM no es buen entorno para correr LLMs locales pesados. Para esto, mejor usar el host directamente o un GPU dedicado.

Hasta dónde se puede achicar una VM de macOS

El segundo experimento es aún más interesante para quienes tienen hardware modesto. Oakley fue bajando recursos progresivamente:

• 4 núcleos / 8 GB RAM: VM "perfectamente ágil", uso real ~5 GB.
• 3 núcleos / 6 GB RAM: uso real cae a 3.9 GB, todo funciona.
• 2 núcleos / 4 GB RAM: uso real 3.1 GB, Safari y configuración funcionan normales.

El piso para una VM de macOS Tahoe usable son entonces 2 núcleos virtuales y 4 GB de RAM. No es entorno para correr Xcode + simuladores ni para entrenar modelos, pero sí alcanza para una segunda instancia de macOS dedicada a navegación, correo, mensajería o pruebas de configuración.

Tamaño en disco: APFS al rescate

El otro recurso crítico es el disco. Una VM de macOS por debajo de 50 GB no puede actualizar su sistema operativo (los instaladores requieren ese espacio mínimo en /), por lo que Oakley recomienda al menos 60 GB nominales. La buena noticia es que APFS almacena las VMs como sparse files: una VM declarada de 100 GB ocupa apenas ~54 GB reales en disco mientras no se llene. Esto hace viable correr una VM de macOS incluso en un Neo con SSD de 512 GB.

Una VM de macOS funcional puede correr con apenas 2 núcleos virtuales y 4 GB de RAM.

Impacto y análisis: por qué la virtualización macOS importa para LATAM

Para muchos developers en Centroamérica y Sudamérica, comprar dos Macs es impensable. Pero virtualizar la segunda dentro del primero, con apenas un 2% de pérdida de rendimiento single-core, sí es viable. Algunos casos concretos donde esto cambia decisiones:

• Probar betas de macOS sin arriesgar la máquina principal. Tahoe 26.5 sale en beta y querés probar antes que tu cliente; en una VM podés.
• CI local de iOS: correr Tart o un runner de GitHub Actions self-hosted dentro de una VM dedicada, aislando el entorno del proyecto.
• Soporte a clientes con Macs viejos: tener una VM con macOS Sonoma para reproducir bugs sin sacar tu Mac viejo del armario.
• Sandboxing de herramientas: instalar utilidades de origen dudoso en una VM efímera y descartarla.
• Onboarding rápido: clonar la VM con todo configurado y entregarla a un nuevo dev en lugar de configurarle el equipo a mano.

Cómo levantar una VM de macOS en cada plataforma

El framework de virtualización solo corre en Apple Silicon, pero las herramientas para gestionar VMs sí varían entre sistemas y son útiles para CI o automatización. Acá los comandos básicos:

macOS (Tart, recomendado para CI):

brew install cirruslabs/cli/tart
tart clone ghcr.io/cirruslabs/macos-sequoia-base:latest sequoia-vm
tart run sequoia-vm --cpu 2 --memory 4096

macOS (UTM, GUI con interfaz amigable):

brew install --cask utm
# Luego: File > New > Virtualize > macOS 12+
# Configurar: 2 cores, 4 GB RAM, 60 GB disco

Linux (cliente Tart vía SSH para administrar runners remotos):

curl -L https://github.com/cirruslabs/tart/releases/latest/download/tart-cli-linux-amd64.tar.gz | tar xz
./tart list --remote ghcr.io/cirruslabs

Windows (PowerShell, vía WSL para gestionar VMs remotas Apple Silicon):

wsl --install
# Dentro de WSL:
ssh [e-mail] "tart list"

💡 Tip: si vas a correr una VM de macOS para CI, asignále al menos 4 núcleos virtuales y 8 GB de RAM. Los 2/4 GB son el piso experimental, no el sweet spot productivo.

Arquitectura: cómo el hipervisor reparte el chip

graph LR
  Host["Host macOS Tahoe"] --> Hyp["Virtualization.framework"]
  Hyp --> VM["Guest macOS VM"]
  Host --> CPU["CPU físico (P+E cores)"]
  Host --> GPU["GPU Metal"]
  Host --> NPU["Neural Engine"]
  VM -. "98% acceso" .-> CPU
  VM -. "95% acceso" .-> GPU
  VM -. "21% acceso" .-> NPU

Como muestra el diagrama, el hipervisor es una capa muy delgada entre host y VM, y la pérdida de rendimiento depende del subsistema: CPU casi gratis, GPU mínimo, Neural Engine sí pierde mucho. Esto debería guiar las decisiones sobre qué cargas correr dentro de una VM y cuáles no.

Qué sigue: virtualización macOS en el horizonte 2026-2027

Con la llegada del MacBook Neo (la rumoreada Mac de entrada de gama 2026, con SSD desde 512 GB), Apple parece estar reconociendo que la virtualización es un caso de uso de masa, no de nicho. Algunos cambios esperables en los próximos meses:

• Mejor virtualización del Neural Engine: si Apple quiere que sus chips sean serios para correr LLMs locales, va a tener que cerrar el gap del 79% que hay hoy entre VM y host en half-precision.
• Más runners de CI iOS sobre Apple Silicon: GitHub Actions y CircleCI están migrando flotas enteras de macOS Intel a Apple Silicon, todas virtualizadas con Tart.
• Snapshots y branching más rápidos: Tart 2 (en beta) promete snapshots casi instantáneos vía APFS clones.
• Soporte oficial de Windows ARM: Parallels Desktop 19 ya corre Windows 11 ARM en Apple Silicon con buen rendimiento; en 2026 esto debería volverse mainstream.

⚠️ Ojo: la licencia de Apple permite correr hasta 2 instancias de macOS virtualizadas por cada host físico Apple. Si pensás montar una granja de runners, leé los términos antes de escalar.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Puedo correr macOS en VM sobre una PC con Windows o Linux?

No legalmente, y técnicamente con malos resultados. La licencia de Apple solo permite virtualizar macOS sobre hardware Apple, y el framework Virtualization.framework solo existe en Apple Silicon. Cualquier guía que muestre macOS sobre PC ("Hackintosh") viola los términos de servicio.

¿Cuál es la mejor herramienta para virtualizar macOS hoy?

Depende del caso: UTM es la mejor opción gratuita con GUI, VirtualBuddy y Viable son ideales para uso personal con buena UX, y Tart es el estándar para CI/CD por su soporte de imágenes OCI y comandos automatizables.

¿Cuánto rendimiento pierdo virtualizando macOS sobre Apple Silicon?

Según los benchmarks de mayo de 2026, alrededor del 2% en CPU single-core, 5% en GPU Metal y hasta 79% en Neural Engine half-precision. Para tareas de desarrollo, navegación y compilación el costo es prácticamente nulo.

¿Puedo correr Xcode dentro de una VM de macOS?

Sí, pero conviene asignarle al menos 4 núcleos virtuales y 8 GB de RAM, idealmente 6-8 cores y 16 GB. Los simuladores de iOS funcionan, aunque la GPU virtualizada tiene menos rendimiento que el host directo.

¿La VM de macOS puede actualizarse a nuevas versiones?

Sí, siempre que el disco virtual tenga al menos 50-60 GB libres. Por debajo de ese tamaño los instaladores fallan. Como las VMs son sparse files en APFS, declarar 100 GB ocupa solo ~54 GB reales en disco.

¿Es viable correr una VM de macOS en una Mac con 8 GB de RAM?

Es estrecho pero posible. Asignándole 4 GB a la VM dejás 4 GB al host, lo cual es el mínimo para macOS. El sistema usará swap intensivamente y la experiencia será lenta. Para uso productivo se recomiendan 16 GB en el host.

Referencias

• The Eclectic Light Company — Artículo original de Howard Oakley con los benchmarks de macOS Tahoe en VM.
• Tart en GitHub — Herramienta open source para virtualizar macOS en Apple Silicon, base de muchos runners de CI.
• UTM en GitHub — Virtualizador open source con GUI para macOS, iOS y Linux sobre Apple Silicon.
• Hacker News — Discusión técnica sobre virtualización macOS y casos de uso en CI/CD.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.