Local models on the Mac

Tengo una Mac mini M2 Pro con 16 GB al lado de un Windows. Quería saber qué se le puede pedir de verdad a esa Mac con modelos locales, sin pagar por cada llamada. No me interesaba si los modelos “corren”: quería saber cuánto tardan, cuánta memoria piden y cuánto se equivocan. Los comandos están en los pasos 16, 17 y 18 de la guía.

La regla que manda: un modelo pesado a la vez

En Apple Silicon la memoria es unificada: lo que usa la GPU se le quita a todo lo demás. MLX dice que el techo práctico de la GPU en esta Mac es 12,7 GB. Con eso no caben dos modelos grandes juntos. Armé un gestor pequeño con una sola regla: cada trabajo corre en un proceso propio, y cuando el proceso termina el modelo sale de la memoria. No hay que descargarlo a mano. La API solo escucha en 127.0.0.1 y Windows llega por un túnel SSH. No hay ningún puerto abierto.

Lo que rinde

El dato que más me importa: unas 24 horas de audio por hora, separando quién dice qué, con 5,3 GB de memoria. La Mac queda usable mientras tanto. La imagen de la portada la generó esta misma Mac. También es lo único que se acerca al techo de memoria: 1024×1024 no lo probé.

La trampa de medir memoria

El primer trabajo me dio tres cifras distintas para la misma memoria: 1,4 GB según el sistema (RSS), 2,4 GB según MLX y 3,0 GB según el footprint de macOS. El RSS no ve la memoria que usa la GPU. Si mides con él, vas a creer que caben dos modelos donde solo cabe uno. Ahora el gestor guarda las tres cifras, y la que uso para decidir es el footprint.

El error que casi publico

Para medir errores necesitaba saber la respuesta correcta. Por eso no usé grabaciones mías: tienen gente que se puede identificar. Generé diálogos con voces sintéticas y guardé quién decía cada frase. La primera tanda dio entre 37 y 50 % de error, y los dos diarizadores que probaba fallaban exactamente en los mismos pares de voces. Que dos modelos distintos se equivoquen igual es sospechoso. El problema no estaba en los modelos: macOS solo trae dos voces en español. Cualquier otro nombre de voz cae en una de esas dos y produce el mismo audio, byte por byte. Mis audios “de 4 personas” tenían 2. Los modelos tenían razón y mi respuesta correcta estaba mal.

Con voces que de verdad eran distintas, el error quedó entre 4,6 y 8,8 %. Pero no lo presento como “lo que vas a obtener”: con voces sintéticas no hay ruido ni gente hablando a la vez.

El diarizador que elegí, Nemotron, tuvo además un fallo grave: 36,6 % en un audio de 5 minutos. Esta vez sí encontré la causa. Nemotron no agrupa voces al final; asigna casillas de hablante por orden de llegada y lo que decide al principio pesa en todo lo demás. En ese audio, lo que oyó en los primeros ~30 segundos lo llevó a meter la segunda voz en la casilla de la primera. Si corto esos 30 segundos, el error baja a 3,6 %; qué parte exacta del arranque lo provoca no lo aislé. El fallo se repite idéntico en cada corrida y bajar el umbral solo lo atenúa.

Con un audio real, de verdad

Después probé con una grabación real de 56 minutos, que no salió de la Mac. Whisper rindió igual: el pipeline completo con Nemotron tardó 158 s (unas 21 horas de audio por hora) con 5,3 GB.

Los hablantes fueron otra historia:

• sherpa, sin decirle cuántas personas había, encontró 129.
• Nemotron encontró 3, pero no coincide con sherpa. Le pasé a sherpa ese 3: ahora los dos dicen 3 personas y aun así no están de acuerdo sobre quién habla en un 38 % del tiempo, más un 11 % donde uno oye voz y el otro no.

No sé cuál acierta. Lo voy a saber leyendo los subtítulos, y esa es la conclusión honesta: con audio real, la separación de hablantes en una máquina local es un borrador que revisa una persona, no un resultado.

La Mac contra el Windows de al lado

Para las herramientas, la diferencia fue mayor de lo que esperaba. Los tests en bash del kit corrieron 14 a 17 veces más rápido en la Mac, y git entre 2 y 10 veces. En Python puro la diferencia fue de apenas 1,6×. Eso apunta a lo caro que es lanzar procesos en Windows con Git Bash, no a la potencia de la CPU.

Con claude -p separé dos tiempos. La parte del modelo en la nube es igual en las dos máquinas, 11–15 s. La parte local no: 30 s en Windows contra 4 s en la Mac. Al quitar los servidores MCP la brecha casi no se cierra, así que el grueso es la plataforma y no mi configuración.

Lo que no rinde: código con reglas exactas

Le di tres funciones pequeñas, con tests ocultos, al modelo local y a claude -p. Claude acertó 3 de 3 por US$ 0,91. El modelo local de 9B acertó 1 de 3, gratis, incluso con un reintento en el que veía los tests que fallaban. Le activé el modo de razonamiento: tardó 5 veces más y siguió en 1 de 3. Hoy no lo usaría para código que tiene que ser correcto. Sí lo usaría para resumir, clasificar o redactar borradores, donde un error se ve y cuesta poco.

En resumen

Una Mac mini de 16 GB sirve como máquina de transcripción (el texto sí; quién habló, a revisar) y como ejecutor rápido de herramientas. Para generar imágenes alcanza, pero justo. Para reemplazar a un modelo grande en código no alcanza. Lo que más aprendí fue a desconfiar de mis propios datos de prueba antes de culpar al modelo.