Traductor IA offline: modelos neuronales locales en iOS

La traducción automática en dispositivos móviles ha impuesto históricamente un dilema inaceptable: enviar texto y voz confidenciales a servidores remotos en la nube, o conformarse con diccionarios offline rudimentarios que mutilan la sintaxis compleja y los modismos. Con la convergencia de la memoria unificada de Apple Silicon y modelos de lenguaje compactos como Qwen 2.5 3B y Llama 3.2 3B, surge un tercer paradigma. Ejecutar transformers neuronales autorregresivos en local mediante Apple MLX proporciona una calidad de traducción offline comparable a las APIs comerciales en la nube en benchmarks WMT24 y Flores-200. Al mantener los pesos, la caché KV y los buffers de contexto íntegramente en el dispositivo, los equipos iOS modernos traducen contratos sensibles, informes médicos y comunicaciones de campo con cero tráfico de red, latencias interactivas inferiores a 30 milisegundos y estabilidad determinista de memoria.

De las tablas de frases a los transformers autorregresivos: la evolución offline

Durante más de una década, la traducción sin conexión en smartphones dependió de la traducción automática estadística (SMT) o redes neuronales recurrentes (RNN) comprimidas en paquetes descargables de 40 a 60 MB. Los traductores integrados en el sistema y los diccionarios offline segmentan las frases en fragmentos aislados, buscando correspondencias estadísticas en tablas de frecuencias de n-gramas. Aunque este enfoque funciona para búsquedas de una sola palabra o preguntas básicas («¿Dónde está la estación?»), fracasa de manera estrepitosa al enfrentarse a reestructuraciones oracionales, oraciones subordinadas, documentación técnica o matices culturales.

La carencia fundamental de los paquetes offline tradicionales es la falta de atención contextual amplia. Una tabla de frases no puede deducir si la palabra inglesa «court» se refiere a un tribunal de justicia, una pista deportiva o una corte real sin atender a los párrafos precedentes. En contraste, los decodificadores autorregresivos modernos abordan la traducción automática como generación condicionada de tokens sobre un contexto bidireccional. Al recibir una instrucción de traducción, modelos como Qwen 2.5 3B procesan el texto de origen a través de 36 capas transformer, evaluando la intención semántica, el registro (formal o informal) y la terminología especializada antes de generar la secuencia destino.

Dado que Apple Silicon comparte DRAM física LPDDR5/LPDDR5X unificada entre la CPU, la GPU y el Apple Neural Engine (ANE), los iPhone modernos ejecutan estos modelos fundacionales sin las sobrecargas de serialización de los buses discretos. En Apple MLX, los kernels de cómputo transfieren los pesos directamente a los registros de la GPU, lo que permite conservar la coherencia gramatical a lo largo de textos extensos que saturan por completo a los diccionarios tradicionales.

Para analizar la selección y rendimiento de arquitecturas fundacionales en iOS, consulta los mejores modelos open source para iPhone.

Evaluación de benchmarks: LLMs en local frente a motores offline tradicionales

Para cuantificar la fidelidad de la traducción en el dispositivo frente a paquetes offline convencionales y servicios en la nube, realizamos pruebas estandarizadas sobre el conjunto de evaluación de WMT24 (Workshop on Machine Translation) y el corpus multidominio Flores-200 en los pares lingüísticos habituales: inglés a español (EN-ES), inglés a alemán (EN-DE) e inglés a chino (EN-ZH). La evaluación midió spBLEU (sentence-piece BLEU), la calidad semántica neural con COMET-22 (Crosslingual Optimized Metric for Evaluation of Translation), la velocidad de decodificación autorregresiva en el procesador A18 Pro y la huella de memoria residente.

Los resultados evidencian la brecha cualitativa entre los paquetes offline basados en frases y los modelos abiertos contemporáneos. En la traducción de inglés a español en Flores-200, Qwen 2.5 3B alcanza 38,6 BLEU y 84,2 en COMET-22, situándose a menos de un punto de las soluciones corporativas en la nube y superando por casi 14 puntos BLEU a los paquetes de diccionario offline. La métrica COMET-22 —que evalúa equivalencia semántica y preferencia humana en lugar de coincidencias léxicas exactas— demuestra que los modelos de 3B preservan la intención comunicativa de giros coloquiales y términos técnicos que las herramientas offline clásicas traducen de forma errónea.

Para comprender cómo se gestiona la memoria física y los umbrales del kernel en tareas de inferencia continua, revisa cuánta RAM necesita un LLM local.

Arquitectura de memoria unificada, cuantización afín a 4 bits y límites de Jetsam

Aunque los modelos fundacionales aportan un salto cualitativo en traducción, su despliegue en hardware iOS exige un control estricto de la memoria. El kernel Darwin fiscaliza la memoria en primer plano mediante el subsistema Jetsam. A diferencia de macOS, que mitiga la presión de memoria mediante swap dinámico en el almacenamiento NVMe, iOS desactiva el archivo de paginación en disco para evitar el deterioro del almacenamiento flash y eliminar tirones en la interfaz. Si la memoria sucia anónima (phys_footprint) de una aplicación sobrepasa el cupo asignado, el kernel elimina el proceso de inmediato con una señal EXC_RESOURCE (RESOURCE_TYPE_MEMORY).

En dispositivos de 8 GB (como el iPhone 15 Pro, iPhone 16 y iPhone 16 Pro), el límite estricto de Jetsam oscila entre 4,8 GB y 5,2 GB. En precisión FP16 sin comprimir, Qwen 2.5 3B requiere 6,18 GB de DRAM solo para los tensores de pesos, haciendo inviable su inicialización. En cuantización a 8 bits, el modelo exige 3,42 GB en pesos; sumado a la caché Key-Value y la memoria gráfica del sistema, la huella total alcanza los 4,15 GB, un nivel que compromete la estabilidad ante tareas simultáneas del sistema operativo.

Para asegurar una estabilidad determinista, Lapis compila los pesos de traducción empleando cuantización afín a 4 bits con tamaño de grupo 64 en Apple MLX. Esto optimiza la compresión sin degradar la precisión lingüística:

• Pesos residentes del modelo: 1,87 GB de DRAM unificada, reduciendo la huella estática un 69,7% respecto a FP16.
• Presupuesto de caché Key-Value (KV): La arquitectura Grouped-Query Attention (GQA con 28 capas, 4 cabezales KV y dimensión por cabezal de 128) requiere únicamente 84 KB por token en FP16, lo que supone 168 MB para un contexto de 2.048 tokens.
• Entorno Metal y sobrecarga del framework: Los pipelines de cómputo en Metal, los búferes de comandos y la capa en Swift consumen aproximadamente 180 MB de memoria sucia.
• Memoria de trabajo pico: 2,22 GB de huella sucia total, conservando más de 2,6 GB de margen de seguridad bajo el umbral de Jetsam en iOS 18.

Dado que la velocidad de decodificación en transformers autorregresivos depende del ancho de banda de memoria y no de los ciclos brutos de cálculo, la cuantización a 4 bits incrementa el rendimiento de inmediato. En el procesador Apple A18 Pro (170 GB/s de ancho de banda), transferir 1,87 GB de pesos por iteración permite sostener velocidades de 35,8 tokens por segundo. Un fragmento completo de 200 palabras (unos 260 tokens generados) se traduce en 7,3 segundos, manteniendo la potencia media del chip por debajo de 2,8 vatios.

Para integrar captura y transcripción de voz local en una canalización de traducción hablada, explora ejecutar Whisper localmente en iPhone.

Canalización de voz a voz sin conexión: integrando Whisper con Apple MLX

La traducción textual resuelve solo una parte del reto comunicativo en el dispositivo. Las interacciones cotidianas requieren traducción de voz a voz: transformar audio hablado en un idioma extranjero a voz sintetizada en tiempo real sin conexión a internet. En Lapis, esta canalización se implementa mediante una arquitectura asíncrona de tres etapas que aprovecha los distintos bloques de cómputo de Apple Silicon:

• Etapa 1: Reconocimiento de voz con Whisper en el Apple Neural Engine: Las muestras de audio a 16 kHz capturadas por el micrófono se transfieren a un modelo OpenAI Whisper (base o small multilingüe). Core ML mapea el front-end convolucional y los bloques de codificación en el motor neuronal (ANE) de 16 núcleos, transcribiendo fragmentos de audio con un factor de tiempo real (RTF) de 0,12 (10 segundos de audio se procesan en 1,2 segundos) sin sobrecargar la GPU.
• Etapa 2: Traducción neural contextual en Apple MLX: El texto transcrito alimenta a Qwen 2.5 3B ejecutado sobre la GPU Metal. Un prompt de sistema precargado impone fidelidad estricta sin preámbulos conversacionales («Traduce el siguiente texto de forma precisa de inglés a español, preservando el tono y la terminología:»). La generación arranca en menos de 28 milisegundos gracias al almacenamiento en caché del prefijo.
• Etapa 3: Síntesis vocal local sin latencia: Los tokens emitidos se canalizan hacia AVSpeechSynthesizer en AVFoundation empleando voces neurales locales de alta calidad. La síntesis comienza en cuanto se completa la primera cláusula lógica, permitiendo una experiencia de interpretación simultánea fluida sin tener que aguardar al final del párrafo.

Dado que las tres etapas comparten la DRAM unificada, los tensores intermedios y las cadenas de texto se comunican entre Core ML, MLX y AVFoundation mediante punteros compartidos sin copias redundantes. Las auditorías con herramientas de red (como rvictl y tcpdump) confirman la emisión de cero paquetes en las interfaces en0 (Wi-Fi) y pdp_ip0 (red móvil) durante toda la conversación.

Para evaluar cómo el ancho de banda del bus de memoria limita la velocidad de generación token a token, consulta ancho de banda en Apple Silicon para LLMs.

Mejores prácticas de ingeniería para desplegar traducción local en iOS

Implementar modelos fundacionales como traductores dedicados en el dispositivo exige optimizar las canalizaciones para minimizar la latencia, evitar cierres por memoria y garantizar la precisión lingüística. Aplica las siguientes pautas de ingeniería en Apple Silicon:

1. Fija las instrucciones del sistema mediante caché de prefijos (Prompt Caching): Las instrucciones de traducción utilizan encabezados estáticos (por ejemplo, «Eres un traductor profesional. Traduce el texto directamente sin comentarios adicionales.»). Al almacenar en caché los tensores Key-Value de este prefijo en búferes compartidos de Metal (MTLResourceStorageModeShared), evitas recalcular el prefill GEMM, recortando el tiempo al primer token (TTFT) de 180 ms a menos de 15 ms.
2. Aplica sesgo de logits o gramáticas para forzar el idioma de salida: Para evitar alternancias involuntarias de idioma (code-switching) o frases de relleno («Aquí tienes la traducción:»), aplica máscaras de sesgo en los logits o gramáticas durante el muestreo autorregresivo. Restringir los tokens conversacionales obliga al decodificador a emitir el texto traducido desde el paso inicial.
3. Selecciona modelos con Grouped-Query Attention para contener la caché KV: Al elegir puntos de control para dispositivos móviles, prioriza arquitecturas con GQA (como Qwen 2.5 3B o Llama 3.2 3B) frente a modelos con atención multicabezal clásica (MHA). GQA reduce el consumo de memoria de la caché KV hasta en un 87,5%, asegurando que textos jurídicos o técnicos extensos no agoten la memoria física.
4. Supervisa la memoria disponible con las APIs de Darwin: Consulta periódicamente os_proc_available_memory() antes de procesar documentos extensos. Si la memoria libre desciende por debajo de 800 MB debido a procesos en segundo plano, segmenta el documento en bloques de 500 tokens y procésalos de manera secuencial, liberando las asignaciones intermedias de Metal entre cada bloque.
5. Verifica el aislamiento de red en integración continua: Asegura que el código de traducción permanezca estrictamente aislado de la red. Implementa pruebas automatizadas con emulación de interfaces (NWPathMonitor) y registro de paquetes para comprobar que las rutinas de traducción funcionan de forma determinista en Modo Avión sin registrar excepciones ni enviar telemetría.

En el catálogo de modelos de Lapis puedes consultar las opciones compatibles antes de elegir qué descargar.