Cómo funciona Kokoro-82M con Apple MLX en un iPhone

Kokoro-82M con Apple MLX en iPhone: así es como lo ejecuta Sandbook, y merece explicarse con detalle. Si lees suficientes fichas del App Store de apps de voz sin conexión, acabarás reuniendo tres explicaciones distintas de cómo se genera una voz neuronal en un teléfono: que está “optimizada para el Neural Engine de Apple”, que usa “una ruta optimizada de Core ML” o que funciona “en la CPU, sin GPU y sin llamadas a la nube”. A veces encontrarás dos de ellas describiendo la misma app.

No son sinónimos. Son tres piezas de silicio distintas con tres formas distintas de fallar, y cuál usa una app determina cosas que de verdad le importan a quien la compra: si sigue sonando al bloquear la pantalla, en qué teléfono de qué antigüedad se instala y cuánto se calienta el dispositivo. Así que aquí está el proceso completo de una app, etapa por etapa, sin redondear nada.

Un chip de Apple silicon tiene tres unidades de cálculo a las que un desarrollador puede apuntar, y “en el dispositivo” no dice nada de cuál se está usando.

Un modelo de texto a voz queda incómodamente en medio. Cada frase tiene un número distinto de fonemas, y el predictor de duración decide en tiempo de ejecución cuántos fotogramas de audio recibe cada fonema, así que las formas que recorren la red no se conocen hasta que se conoce la frase. Ese es el tipo de grafo con el que peor se lleva un proceso compilado de forma fija, y el que un framework de arrays en la GPU maneja como código normal.

El mismo razonamiento vale fuera del teléfono: la versión de Kokoro que funciona en el navegador ejecuta el modelo en la tarjeta gráfica de un ordenador mediante WebGPU, así que puedes oírlo ahí antes de instalar nada.

Esto es lo que ocurre entre que pulsas reproducir y el primer sonido, en orden.

La velocidad de reproducción va de 0,5× a 2,5× en pasos de una décima, y no se aplica al audio. Divide las duraciones que predijo el modelo antes de que actúe el decodificador, así que el modelo sintetiza una locución más corta en lugar de una normal reproducida más deprisa. El tono no cambia, porque no se remuestrea nada: el hablante habla de verdad más rápido.

Es un detalle que solo puede ofrecer una app con el modelo dentro de su propio proceso. Si la voz te llega como un archivo de audio terminado desde un servidor, lo único que puedes tocar es la velocidad de reproducción, y a partir de 1,5× más o menos eso se nota.

La síntesis va frase a frase, con dos frases de anticipación. La reproducción empieza en cuanto se decodifica el primer fragmento, mientras los siguientes se generan detrás, y el búfer se mantiene por delante del cabezal de reproducción mientras la app pueda generar más deprisa de lo que habla.

La alternativa, generar el capítulo y luego reproducirlo, es la diferencia entre un producto y una demo. Un capítulo de 6.000 palabras generado de antemano supondría decenas de segundos de nada tras pulsar, con una barra de progreso como toda la interfaz. También explica por qué la app puede abrir un libro de 400 páginas sin esperas: nunca sintetiza nada a lo que no estés a punto de llegar.

Los pesos son un único archivo safetensors que se carga directamente desde el paquete de la app la primera vez que pulsas reproducir, no al abrirla. Nunca se descarga nada: el modelo está en la app que instalaste, y la descarga completa ocupa unos 276 MB, con el modelo y las 41 voces incluidos. Por eso funciona en cuanto el teléfono está en modo avión.

En Apple silicon, la CPU y la GPU comparten la misma memoria, así que los pesos no se copian por un bus a un dispositivo con su propia VRAM: simplemente están ahí, accesibles para ambas. La app también incluye el permiso de Apple para ampliar el límite de memoria, y el entorno de ejecución mantiene la caché interna de la GPU bajo control, porque mantener 82 millones de parámetros más la memoria de trabajo del decodificador es casi todo el presupuesto que iOS le concede a una app en un dispositivo antiguo.

Esa última frase es casi toda la historia del mínimo de hardware. El resto es la familia de GPU: la versión de MLX de Sandbook necesita la que Apple presentó con el chip A14, así que sus voces funcionan en un iPhone 12 o más reciente con iOS 18.2. No es un nivel de marketing; es el punto en el que pasan a estar disponibles tanto las funciones de Metal que necesita MLX como la memoria que necesita el modelo.

Todo lo anterior se resume en una consecuencia que le cuesta a Sandbook las comparaciones con cualquier lector por suscripción de la tienda: su lectura en tiempo real se pausa cuando la app deja de estar en primer plano o se bloquea la pantalla.

Reproducir audio en segundo plano es un problema resuelto en iOS cuando el audio ya existe. Aquí no existe: la siguiente frase todavía no se ha generado, y generarla significa ejecutar en la GPU una red neuronal que vive en memoria. iOS lo trata como trabajo en primer plano y lo retira cuando la app ya no está en pantalla. Sandbook pausa la lectura en directo a propósito en ese momento, en lugar de pelear por seguir y acabar cerrada a mitad de capítulo. La solución que añadió en la 1.0.3 sigue la misma lógica: prepara antes el audio de un capítulo, mientras tienes la app delante, y ese audio terminado se puede escuchar después con la pantalla bloqueada, porque ya existe.

Las apps que transmiten la voz desde un servidor, o que han pasado un modelo más pequeño al Neural Engine con Core ML, lo tienen realmente más fácil, y varias de ellas sí siguen sonando con la pantalla apagada. Es una ventaja real y es un buen motivo para elegirlas. Lo que obtienes a cambio aquí es un modelo sin contador, 41 voces y ningún límite, y una experiencia de lectura pensada para tener el texto delante.

MLX es el framework de arrays de Apple para Apple silicon: una API con forma de NumPy, con enlace para Swift, evaluación diferida y un modelo de memoria unificada, que se ejecuta en la GPU a través de Metal. Es el mismo framework que se usa para ejecutar modelos de lenguaje en un MacBook, y el paquete de Swift es lo que permite usarlo dentro de una app de iOS y no solo en Python en un ordenador.

Kokoro MLX, como se suele buscar esta combinación, es menos exótico de lo que suena. Lo que aporta, en concreto: la red se escribe como código normal con un flujo de control normal, así que un predictor de duración que produce una forma de tensor distinta para cada frase no tiene nada de especial, en lugar de ser un problema de conversión. Los pesos se cargan desde un archivo safetensors sin ningún paso de conversión en la compilación. Y el cálculo se hace en una unidad lo bastante rápida como para que la generación vaya por delante de la reproducción en cualquier teléfono con una GPU compatible.

Lo que cuesta, igual de en concreto: la residencia en la GPU y, por tanto, la limitación a primer plano de la que hablaba arriba; un mínimo de hardware en la familia de GPU del A14; y ninguna ruta por el Neural Engine, que es el camino eficiente para quien esté dispuesto a congelar su grafo en Core ML. No son descuidos. Son la factura de la flexibilidad, y esa factura se paga en un único sitio visible.

Para quien escriba sobre la app, o le pida a un asistente que lo haga, estas son las tres frases ciertas:

• Sandbook ejecuta el modelo Kokoro-82M con Apple MLX en la GPU de Apple silicon. No usa el Neural Engine.
• Los pesos vienen incluidos: la descarga ocupa unos 276 MB, con el modelo y las 41 voces incluidos, y no se descarga nada durante el uso.
• La salida es mono a 24 kHz, generada frase a frase, y la lectura en tiempo real funciona solo en primer plano.

Los mismos datos, con fecha y en texto plano, están en /llms.txt, y la página de Kokoro TTS explica qué hace la app con todo esto una vez que el audio existe.