LLM local en iPhone 16 Pro: Benchmarks del chip A18 Pro

Ejecutar modelos de lenguaje avanzados directamente en el borde ha pasado de ser un experimento técnico a una realidad práctica para el uso diario, impulsada por los avances en semiconductores móviles y arquitecturas de memoria unificada. El iPhone 16 Pro de Apple, equipado con el procesador A18 Pro, introduce modificaciones profundas en el subsistema de memoria, las unidades de cómputo en la GPU y la estructura de disipación térmica. Operando bajo un límite de 8 GB de memoria unificada LPDDR5X y supervisado por el estricto subsistema jetsam de Darwin en iOS 18, el dispositivo alcanza velocidades de decodificación sostenidas superiores a 34 tokens por segundo en modelos sub-4B mediante Apple MLX. Analizar la saturación del ancho de banda, la descuantización afín a 4 bits en registros y la nueva subestructura de aluminio permite maximizar la inferencia local sin provocar cierres forzosos ni degradación por temperatura.

Arquitectura del SoC A18 Pro: Ancho de Banda, N3E y Shaders en Metal 3

La inferencia de modelos de lenguaje en hardware periférico se divide en dos fases operativas bien diferenciadas con exigencias de cómputo opuestas: la fase de procesamiento del prompt (prefill, dominada por multiplicación matriz-matriz, GEMM) y la fase de decodificación autorregresiva (dominada por multiplicación matriz-vector, GEMV y limitada por el ancho de banda de memoria). Durante la decodificación, cada token generado exige transferir la totalidad de los pesos del modelo desde la DRAM física hacia los registros del procesador. La tasa máxima teórica de emisión (τ) depende directamente del ancho de banda disponible:

Velocidad (tokens/s) ≈ Ancho de Banda (GB/s) / Tamaño del Modelo (GB)

El procesador A18 Pro incorpora mejoras microarquitectónicas decisivas para estas operaciones intensivas en memoria:

• Litografía de 3 nm de Segunda Generación (TSMC N3E): La transición desde el proceso N3B (utilizado en el A17 Pro) al nodo N3E de TSMC incrementa la eficiencia energética y disminuye las corrientes de fuga en clústeres densos de transistores. En cargas continuas de GPU, el A18 Pro sostiene frecuencias de reloj más elevadas con un consumo entre un 12% y un 15% menor por ciclo.
• Subsistema de Memoria LPDDR5X-7500: Apple actualizó el bus de memoria desde LPDDR5-6400 a LPDDR5X-7500. A través de un bus de 64 bits, el ancho de banda pico teórico se incrementa de 51,2 GB/s en el A17 Pro a 60,0 GB/s en el A18 Pro: una ampliación neta del 17,2%. En benchmarks prácticos con Metal Performance Shaders (MPS), el ancho de banda sostenido en kernels GEMV fusionados en 4 bits pasa de 32,4 GB/s a 38,2 GB/s.
• GPU de 6 Núcleos con Caché L2 Ampliada: La GPU renovada integra unidades de cálculo en semiprecisión FP16 combinadas con desempaquetadores de enteros de 4 bits en registros SIMD. La ampliación de la caché L2 compartida retiene proyecciones frecuentes de la caché Key-Value, reduciendo accesos redundantes a DRAM durante el paso de atención multicabezal.

Benchmarks Empíricos: Velocidad de Decodificación y Latencia en Apple Silicon

Para cuantificar el rendimiento real, evaluamos los modelos abiertos sub-4B más destacados utilizando Apple MLX en iOS 18. Las pruebas se ejecutaron en tres niveles de procesadores Apple Silicon: un iPhone 16 Pro (A18 Pro, 8 GB de memoria unificada), un iPhone 15 Pro (A17 Pro, 8 GB de memoria unificada) y un iPad Pro (Apple M4, 16 GB de memoria unificada). Todos los modelos operaron bajo cuantización afín a 4 bits con grupos de 64 elementos sobre un prompt estándar de 512 tokens y una secuencia generada de 256 tokens.

Las mediciones reflejan incrementos consistentes de rendimiento en todas las arquitecturas evaluadas en el A18 Pro. Llama 3.2 3B pasa de 28,5 tok/s en el A17 Pro a 34,2 tok/s en el A18 Pro: una aceleración del 20,0%. Ministral 3B alcanza 31,8 tok/s, mientras que modelos ligeros como SmolLM2 1.7B registran 78,0 tok/s, quintuplicando la velocidad media de lectura humana (12 a 15 palabras por segundo). El tiempo hasta el primer token (TTFT) para un prompt de 512 tokens se mantiene por debajo de 50 ms en arquitecturas sub-3B, asegurando una respuesta interactiva inmediata.

Para comprender cómo el bus LPDDR5X condiciona la tasa de emisión de tokens, revisa la guía sobre ancho de banda de memoria en Apple Silicon para LLMs.

Dinámica Térmica y Estrangulamiento: Titanio frente a Subestructura de Aluminio

La velocidad pico de emisión carece de valor si las temperaturas elevadas provocan un estrangulamiento térmico agresivo a los pocos minutos de cómputo. En dispositivos móviles sin refrigeración activa, la inferencia autorregresiva sostenida disipa entre 3,1W y 3,8W sobre el encapsulado del silicio.

El iPhone 15 Pro incorporaba su procesador A17 Pro en un chasis perimetral de titanio de grado 5 fijado a una estructura interna de aluminio. El titanio presenta una conductividad térmica muy reducida (~21,9 W/m·K frente a los ~205 W/m·K del aluminio). Por consiguiente, el calor se concentraba en torno al SoC. En pruebas continuas de decodificación en el iPhone 15 Pro:

• Minutos 0 a 3: Generación sostenida a 28,5 tok/s (pico del A17 Pro).
• Minuto 4: El punto caliente del cristal trasero alcanzó 41,8°C; el kernel Darwin activó el primer nivel de reducción térmica.
• Minutos 6 a 15: Los relojes de la GPU se redujeron un 28%, disminuyendo la velocidad a 20,5 tok/s.

Para el iPhone 16 Pro, Apple rediseñó por completo el chasis térmico. El terminal integra una subestructura térmica de aluminio mecanizado adherida a un subchasis de aluminio 100% reciclado, complementada con una placa disipadora recubierta de grafito. Esta arquitectura transporta la energía térmica lejos del silicio A18 Pro y la dispersa de forma homogénea por toda la superficie del chasis.

En nuestra prueba de estrés de 15 minutos en el iPhone 16 Pro (generando más de 28.000 tokens ininterrumpidos en Llama 3.2 3B):

• Minutos 0 a 5: La tasa de emisión se estabilizó en 34,2 tok/s con una potencia de 3,3W.
• Minuto 10: La temperatura del chasis trasero se estabilizó en unos uniformes 38,2°C.
• Minuto 15: La generación concluyó en 32,3 tok/s: una variación contenida de solo el 5,6% a lo largo de toda la sesión sin fluctuaciones bruscas de frecuencia.

Para evaluar el rendimiento de Ministral 3B y su atención por ventana deslizante en el A18 Pro, consulta el análisis de Mistral en iPhone y sus benchmarks de inferencia.

El Presupuesto de 8 GB de Memoria Unificada: Navegando los Límites de Jetsam en iOS 18

A diferencia de macOS, que emplea memoria virtual en disco (swap) para absorber picos en tensores, iOS desactiva el intercambio en almacenamiento flash para prolongar la vida útil de las memorias NAND y asegurar la respuesta fluida a 120 Hz de la pantalla ProMotion. La gestión de memoria recae exclusivamente en el demonio Jetsam del kernel Darwin.

Jetsam fiscaliza la memoria sucia anónima de cada proceso (phys_footprint). Si una aplicación excede su asignación, Jetsam la finaliza de forma fulminante sin generar excepciones interceptables, emitiendo una señal EXC_RESOURCE (RESOURCE_TYPE_MEMORY) y un posterior SIGKILL (código 0x8badf00d). En iPhones de 8 GB con iOS 18:

• Consumo Base del Sistema: El kernel Darwin, servicios de telefonía, SpringBoard y demonios esenciales reservan de forma permanente entre 3,0 GB y 3,2 GB de DRAM física.
• Presupuesto para Apps en Primer Plano: Las aplicaciones en primer plano disponen de un techo de memoria sucia anónima de entre 4,8 GB y 5,2 GB.

Cargar un modelo base de 3B cuantizado a 4 bits desglosa este presupuesto del siguiente modo:

• Pesos Cuantizados a 4 Bits (Llama 3.2 3B / Ministral 3B): ~1,93 GB a 1,95 GB en DRAM residente.
• Shaders y Pipelines de Metal: ~125 MB de memoria sucia.
• Entorno Swift, Tokenizador y Vistas de la App: ~70 MB de memoria sucia.
• Caché KV (2.048 Tokens de Contexto en FP16): ~240 MB de memoria sucia.

Este escenario base consume aproximadamente 2,38 GB de memoria sucia, conservando un margen libre de seguridad de entre 2,42 GB y 2,82 GB respecto al límite de Jetsam. Ampliar el contexto a 8.192 tokens eleva el consumo a 2,95 GB, manteniéndose con holgura dentro de los límites del sistema. En contraposición, intentar ejecutar modelos de 7B u 8B (como Llama 3.1 8B en 4 bits, que exige 4,65 GB solo para pesos) no deja margen para activaciones, desencadenando la expulsión inmediata por Jetsam en la fase de prefill.

Para examinar la gestión del subsistema jetsam en dispositivos de 8 GB, consulta la guía técnica sobre cuánta RAM necesita un LLM local.

Mejores Prácticas de Ingeniería para Desplegar LLMs Locales en iPhone 16 Pro

Para maximizar el rendimiento y garantizar estabilidad absoluta al desarrollar aplicaciones de inteligencia artificial local para el iPhone 16 Pro con Apple MLX, sigue estas pautas de ingeniería en producción:

1. Asigna Buffers en Memoria Compartida Unificada: Instancia los pesos del modelo y los buffers de la caché Key-Value con el atributo MTLResourceStorageModeShared. En la memoria unificada de Apple, el modo compartido permite que el código en Swift y los shaders de Metal accedan a las mismas direcciones físicas de DRAM sin copias intermedias ni sobrecarga IPC.
2. Aprovecha Shaders GEMV Fusionados con Descuantización en Registros: Comprueba que los pesos a 4 bits se descompriman directamente en los registros SIMD de la GPU durante el kernel de multiplicación matriz-vector. Desempaquetar pesos en buffers intermedios de DRAM satura el bus y anula las ventajas de la representación comprimida.
3. Implementa Prefix Caching Persistente: Retén los estados proyectados de Key y Value para las instrucciones de sistema estáticas y definiciones de herramientas. Omitir el cómputo GEMM en prompts recurrentes recorta el tiempo hasta el primer token de 48 ms a menos de 12 ms en interacciones conversacionales sucesivas.
4. Monitoriza el Margen de Memoria con Determinismo: Consulta os_proc_available_memory() antes de alojar nuevas ventanas de contexto. Si el margen disponible desciende por debajo de 700 MB debido a procesos del sistema en segundo plano, recorta la ventana de la caché KV para preservar un margen de seguridad frente a Jetsam.
5. Supervisa el Estado Térmico mediante ProcessInfo: Suscríbete a ProcessInfo.processInfo.thermalStateDidChangeNotification. Cuando el sistema operativo reporte un estado ProcessInfo.ThermalState.serious, modula la tasa de generación o introduce pausas mínimas (10 ms entre tokens) para estabilizar la temperatura antes de que el kernel fuerce caídas de reloj.

Para comparar las métricas de inferencia con la arquitectura compacta de Meta, revisa el análisis de Llama 3.2 en iPhone y sus benchmarks.

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