Asistente de voz offline en iPhone: Guía de IA local

Construir un asistente de voz offline en iPhone en tiempo real exige coordinar múltiples modelos de aprendizaje automático sobre Apple Silicon sin depender de llamadas de red. Mientras los asistentes de voz en la nube envían el audio del usuario a través de internet —introduciendo latencia variable, fluctuaciones de conexión y riesgos para la privacidad biométrica—, un agente de voz en local ejecuta la detección de actividad vocal (VAD), el reconocimiento del habla, la decodificación del modelo de lenguaje y la síntesis neural de voz directamente sobre el silicio del dispositivo. Lograr una latencia de turno conversacional inferior a 600 milisegundos requiere particionar el hardware con precisión: procesar audio en el Apple Neural Engine (ANE) de 16 núcleos, decodificar tokens con shaders de Apple MLX en la GPU Metal, canalizar frases a la síntesis de voz local y controlar la memoria sucia anónima frente a los límites de Jetsam en iOS.

El riesgo de privacidad de la voz en la nube frente al aislamiento Zero-Egress

La voz humana es la señal de datos más íntima que puede emitir un usuario. Una onda acústica contiene no solo palabras habladas, sino también características biológicas del tracto vocal, patrones de salud, entonación emocional, sonido ambiente y conversaciones de terceros alrededor. En el modelo de nube, fragmentos continuos de audio o paquetes comprimidos en Opus viajan por redes públicas hacia centros de datos remotos. Una vez allí, los datos se almacenan en colas de procesamiento, se evalúan en servidores multiinquilino y quedan expuestos a políticas de retención, brechas de seguridad o requerimientos externos.

Un asistente de voz offline en local elimina el vector del servidor mediante un aislamiento Zero-Egress respaldado por hardware. Al suprimir el entitlement com.apple.security.network.client de la app, el kernel Mach de Darwin bloquea la apertura de sockets de red a nivel de llamada al sistema. Cualquier intento de ejecutar socket() o connect() es cancelado de inmediato con el código EPERM (Operación no permitida). Los desarrolladores pueden verificar esta frontera conectando el iPhone por cable, creando una interfaz virtual con rvictl -s <UDID> y monitorizando el tráfico con tcpdump -i rvi0 -n, lo que confirma una transmisión exacta de cero paquetes durante conversaciones continuas.

Para profundizar en la precisión del reconocimiento acústico y los tiempos de transcripción de Whisper, revisa la guía de Whisper local en iPhone.

El pipeline tri-motor: VAD, Whisper en el ANE y MLX en streaming

Mantener una conversación fluida y natural requiere sustituir el modelo de petición-respuesta por un flujo asíncrono y segmentado entre los diferentes bloques de silicio:

• Detección de actividad vocal continua (VAD): El nodo de entrada de AVAudioEngine captura muestras de micrófono a 16 kHz mono en formato PCM de 32 bits en coma flotante. El audio pasa por un buffer circular hacia un modelo ligero de VAD neural que evalúa ventanas de 30 ms. Cuando detecta un silencio superior a 450 ms, el sistema marca el fin del turno y envía el fragmento de audio al motor de transcripción.
• Reconocimiento del habla con Whisper en el ANE: Ejecutar la transcripción en la GPU generaría cuellos de botella y frenaría la decodificación del LLM. Al desplegar Whisper Base cuantizado a 8 bits en el Apple Neural Engine (ANE) mediante Core ML o kernels optimizados de MLX, la extracción de espectrogramas y la decodificación acústica se ejecutan con cero uso de GPU. En el chip A18 Pro, Whisper Base transcribe 3,0 segundos de voz en ~138 ms, logrando un factor de tiempo real (RTF) de 0,058x.
• Generación de texto en streaming con Apple MLX: La transcripción se inyecta de inmediato en un modelo de lenguaje autorregresivo (como SmolLM2 1,7B o Llama 3.2 3B) ejecutándose en shaders de Metal. Gracias a la memoria unificada de Apple Silicon, la evaluación inicial del prompt tarda menos de 45 ms (Time-to-First-Token) y la generación avanza a 78 tok/s en el procesador A18 Pro.
• Síntesis de voz neural segmentada por cláusulas: El mayor cuello de botella en los asistentes de voz radica en esperar a que el modelo termine toda la respuesta antes de empezar a hablar. Una arquitectura offline optimizada analiza los tokens emitidos mediante un segmentador de puntuación. En cuanto se completa la primera cláusula o frase (tras 8 o 12 tokens), el texto se envía de inmediato al motor local de síntesis de voz (como AVSpeechSynthesizer con voces neurales o un vocoder local). La reproducción de audio se inicia mientras el LLM continúa generando las siguientes frases.

Para dominar la convivencia de modelos acústicos y de lenguaje bajo los límites del kernel, consulta cuánta RAM necesita un LLM local.

Límites de memoria Jetsam y concurrencia de baja latencia

El principal reto técnico de los sistemas de voz en local sobre iOS es la gestión de la memoria física DRAM. Mientras que macOS permite volcar páginas a la memoria de intercambio (swap) en el disco flash, iOS desactiva el archivo swap en aplicaciones de usuario para preservar la vida útil de las celdas NAND y garantizar los 120 Hz estables de ProMotion. Cada byte asignado está regulado por el demonio Jetsam de Darwin.

En dispositivos de 8 GB de memoria física unificada —como el iPhone 15 Pro y el iPhone 16 Pro—, Jetsam fija un techo de memoria sucia anónima (phys_footprint) cercano a los 5,0 GB para la aplicación activa. Superar este límite desencadena la terminación fulminante del proceso con la señal EXC_RESOURCE (RESOURCE_TYPE_MEMORY).

Mantener activos la captura de audio, el reconocimiento de voz, la inferencia del modelo de lenguaje y la síntesis requiere un reparto estricto de memoria:

• Pesos del modelo acústico: Whisper Base cuantizado a enteros de 8 bits ocupa ~145 MB de RAM. Mantener estos pesos en memoria compartida deja más de 4,8 GB de margen disponible para el modelo de lenguaje.
• Huella del LLM cuantizado: Un modelo de 3B sin cuantizar en FP16 exigiría 6,4 GB de DRAM, sobrepasando el límite de Jetsam de inmediato. La cuantización afín a 4 bits con group size 64 comprime SmolLM2 1,7B a ~1,05 GB y Llama 3.2 3B a ~1,82 GB.
• Límites de la caché KV: Para evitar el crecimiento lineal de la memoria durante conversaciones prolongadas, la caché de claves y valores utiliza buffers circulares acotados a 2.048 tokens. Con cuantización de caché KV a 8 bits, el consumo se mantiene bajo 180 MB en modelos de 1,7B y bajo 320 MB en modelos de 3B.
• Buffers de audio y síntesis: Los buffers de AVAudioEngine, los espectrogramas temporales y las colas de audio PCM ocupan ~90 MB en conjunto. El pico de memoria sucia de todo el asistente se mantiene en ~1,52 GB (con SmolLM2 1,7B) o ~2,45 GB (con Llama 3.2 3B), conservando más de 2,5 GB de margen frente al límite de Jetsam.

Para adaptar este pipeline de voz a la transcripción continua y el archivo de reuniones, revisa la arquitectura de apps de notas con IA offline en iOS.

Benchmarks empíricos: Latencia de turno conversacional y rendimiento en Apple Silicon

Para medir la velocidad de respuesta en condiciones reales, evaluamos el pipeline completo de voz en tres generaciones de procesadores Apple Silicon: iPhone 15 Pro (A17 Pro, 8 GB RAM, 51,2 GB/s de ancho de banda), iPhone 16 Pro (A18 Pro, 8 GB RAM, 68,0 GB/s) y iPad Pro (Apple M4, 16 GB RAM, 120,0 GB/s). Todas las pruebas se ejecutaron en modo avión verificado y con batería, utilizando una locución de entrada de 3,0 segundos de duración.

Los datos de rendimiento demuestran que en el procesador A18 Pro del iPhone 16 Pro, el retardo total entre turnos se sitúa en 554 milisegundos. Esta rapidez es posible porque el ANE completa la transcripción en 138 ms, MLX genera la primera cláusula de 10 tokens en 165 ms y el sintetizador local reproduce el audio en 72 ms. Este retardo inferior a 600 ms resulta natural en una conversación humana y supera con creces a los asistentes en la nube, cuyas respuestas suelen retrasarse entre 1.200 y 2.500 ms debido a la latencia de transporte de red y las colas de procesamiento remotas.

Para entender cómo se reparten el cálculo la ANE y la GPU en flujos de voz multimodales, consulta Apple Neural Engine vs GPU para LLMs.

Dúplex acústico acelerado por hardware y persistencia en el Secure Enclave

Un asistente de voz avanzado debe permitir interrupciones naturales mientras habla (barge-in). Lograr esta capacidad en local requiere cancelación de eco acústico (AEC). iOS incorpora esta función por hardware dentro de la unidad de audio Voice-Processing I/O de CoreAudio (kAudioUnitSubType_VoiceProcessingIO). El procesador DSP resta la señal que sale por el altavoz de la entrada del micrófono en tiempo real, permitiendo que el VAD detecte la voz del usuario sin acoples ni retroalimentación acústica.

Para proteger la privacidad de las conversaciones en el tiempo, el historial de mensajes y los datos de audio se almacenan en una base de datos SQLite cifrada bajo la Clase A de Protección de Datos de iOS (NSFileProtectionComplete). Las claves criptográficas están bajo la custodia exclusiva del Secure Enclave. Cuando la pantalla del dispositivo se apaga, el kernel purga las claves de la memoria activa. Incluso en caso de acceso físico no autorizado al almacenamiento flash, los registros de voz permanecen matemáticamente inaccesibles.

Mejores prácticas arquitectónicas para asistentes de voz en local

Para diseñar un asistente de voz interactivo, rápido y fiable en iOS, aplica estas directrices técnicas esenciales:

1. Aplica aislamiento Zero-Egress en el kernel Mach: Elimina com.apple.security.network.client de los entitlements de la app para asegurar que ninguna conexión de red pueda transmitir audio al exterior.
2. Deriva el reconocimiento acústico al Apple Neural Engine: Ejecuta Whisper en el ANE para preservar el 100% de la potencia y ancho de banda de la GPU para la inferencia del modelo de lenguaje.
3. Transmite tokens a la síntesis de voz en pausas de cláusula: Divide la salida del LLM según los signos de puntuación y envía la primera frase directamente al sintetizador para lograr respuestas bajo los 600 ms.
4. Estandariza en cuantización afín a 4 bits: Utiliza pesos a 4 bits con group size 64 en los modelos de lenguaje para garantizar que la memoria activa se mantenga lejos de los límites de Jetsam.
5. Activa la unidad Voice-Processing I/O para barge-in limpio: Configura CoreAudio con cancelación de eco por hardware para admitir interrupciones de voz fluidas sin realimentación de audio.

Puedes conocer las opciones de conversación por voz en la presentación de Lapis Live.