Ejecutar modelos de visión y lenguaje en local: MLX y Apple Silicon

El procesamiento de información visual—facturas confidenciales, informes médicos, planos técnicos o galerías personales de fotos—representa una vulnerabilidad crítica cuando se envía a través de APIs en la nube. Ejecutar modelos de visión y lenguaje (VLM) de forma local en Apple Silicon elimina este riesgo, combinando una comprensión óptica avanzada con cero transmisión de red. Al aprovechar la arquitectura de memoria unificada (UMA) y la aceleración nativa en Metal mediante MLX-VLM, los modelos compactos actuales logran razonamiento visual de alta fidelidad con latencia determinista y absoluta privacidad criptográfica.

Anatomía de un VLM en local: Codificador visual, proyector y decodificador de lenguaje

Un modelo de visión y lenguaje no es una red neuronal monolítica. Es un sistema acoplado que une dos modalidades radicalmente distintas—matrices de píxeles continuos y tokens lingüísticos discretos—a través de un flujo arquitectónico tripartito. Para ejecutar inferencia visual eficiente en dispositivos de consumo, cada componente debe optimizarse con precisión:

1. El codificador visual (Vision Backbone): Actúa como la interfaz perceptiva del modelo. Las arquitecturas modernas emplean Vision Transformers (ViT) o redes SigLIP (Sigmoid Loss for Language-Image Pretraining). Ante una imagen de entrada con alto H, ancho W y 3 canales de color, el codificador divide la superficie bidimensional en una cuadrícula de parches cuadrados contiguos de tamaño P × P (generalmente de 14×14 o 16×16 píxeles). Cada parche se proyecta linealmente como un vector de características enriquecido con codificaciones posicionales 2D.
2. El proyector intermodal (Cross-Modal Projector): La dimensión de los vectores del codificador visual (por ejemplo, 768 en SigLIP-Base o 1.152 en SigLIP-Large) no coincide con la dimensión oculta del modelo de lenguaje (como 2.048 en modelos de 3B o 4.096 en 7B). El proyector resuelve esta discrepancia. Mientras que los primeros modelos usaban proyecciones lineales simples, los sistemas modernos emplean Perceptrones Multicapa (MLP) de dos capas con activación GELU o remuestreadores espaciales para alinear los parches visuales en el espacio semántico del decodificador.
3. El decodificador autorregresivo de lenguaje: Una vez proyectados, los parches visuales se introducen en el modelo de lenguaje (como Qwen 2.5, SmolLM2 o Llama 3.2) como un prefijo de tokens. El transformador aplica mecanismos de atención cruzada y autoatención sobre los tokens visuales y el texto del usuario, generando la respuesta paso a paso de forma autorregresiva.

Dado que el decodificador es autorregresivo, la generación de texto opera igual que en un LLM puro. Sin embargo, la fase de prefill visual introduce dinámicas de hardware que cambian por completo la gestión de memoria en el dispositivo.

Para contrastar la viabilidad de modelos multimodales compactos en factores de forma móviles, consulta nuestra comparativa de modelos de visión locales para iPhone.

Resolución dinámica y división en parches: Cómo una imagen se convierte en miles de tokens

Las primeras arquitecturas multimodales forzaban un preprocesamiento rígido: cualquier imagen se recortaba o escalaba a dimensiones cuadradas fijas (como 384×384 o 448×448 píxeles). En casos de uso reales—como digitalizar tablas de hojas de cálculo, tickets verticales o capturas de código fuente—el reescalado cuadrado deforma la relación de aspecto, difumina caracteres pequeños y destruye la precisión del reconocimiento óptico de caracteres (OCR).

Los modelos actuales solucionan este problema mediante resolución dinámica nativa (pionera en Qwen2-VL y Qwen2.5-VL) y compresión por pixel shuffle (implementada en SmolVLM). En lugar de aplicar deformaciones geométricas, la cuadrícula se adapta a la geometría real de la imagen:

N_tokens_visuales = ⌈H / P⌉ × ⌈W / P⌉ + Tokens_Delimitadores_Espaciales

Aunque la resolución dinámica mejora notablemente la fidelidad visual, introduce un reto importante para la memoria local. Una captura móvil de 1080×1920 píxeles dividida en parches de 14×14 generaría más de 10.500 parches espaciales brutos—una carga inasumible para la DRAM de un teléfono. Para mantener el equilibrio entre detalle y consumo de recursos, los modelos modernos aplican técnicas de reducción espacial:

• Fusión espacial 2D (Qwen2.5-VL): Agrupa bloques contiguos de 2×2 parches en una única representación mediante convoluciones 2D, reduciendo el conteo de tokens a una cuarta parte (de 1.024 a 256 tokens).
• Compresión Pixel Shuffle (SmolVLM): Reorganiza canales de alta resolución en dimensiones espaciales compactas antes de alimentar el decodificador, manteniendo secuencias visuales por debajo de 512 tokens sin perder legibilidad en infografías densas.
• Codificación M-RoPE tridimensional: Descompone las frecuencias rotatorias posicionales en tres ejes independientes (temporal, vertical y horizontal), permitiendo al modelo interpretar cualquier proporción de imagen sin distorsión de coordenadas.

Para analizar en detalle la arquitectura de compresión por pixel shuffle y el consumo en iOS, revisa nuestro análisis sobre SmolVLM sin conexión en iOS.

El cuello de botella del prefill: Por qué los VLMs exigen el hardware de forma distinta a los LLMs

En un LLM de texto puro, las preguntas de los usuarios rara vez superan los 50 o 100 tokens. La fase de prefill (procesamiento inicial de la entrada) se resuelve en milisegundos. Según el modelo Roofline, la ejecución de texto puro está limitada casi por completo por el ancho de banda del bus de memoria durante la decodificación secuencial.

Los modelos de visión alteran radicalmente esta dinámica. Adjuntar una única imagen inyecta de golpe entre 512 y 1.536 tokens visuales en el canal del transformador. Esto genera dos cuellos de botella fundamentales:

1. Prefill limitado por cómputo (Time-To-First-Token, TTFT): Mientras que generar un token secuencial requiere una intensidad operacional inferior a 1,0 FLOP por byte transferido, procesar la matriz inicial de parches visuales está estrictamente limitado por la capacidad de cálculo de la GPU:

FLOPs_prefill ≈ 2 × N_parámetros × N_tokens_visuales

Para un modelo de 3B parámetros evaluando una imagen de 1.024 tokens, la GPU Metal debe ejecutar más de 6,1 billones de operaciones en coma flotante antes de emitir la primera palabra. En un chip Apple A18 Pro con ~35 TFLOPs de pico en GPU, esta fase requiere entre 180 ms y 320 ms. En un procesador M4 Pro para Mac, el mayor número de núcleos de GPU reduce esta latencia inicial a menos de 90 ms.

2. Picos de memoria en la caché KV: Antes de que el decodificador genere la primera palabra, los tensores de clave (Key) y valor (Value) de todos los parches visuales deben asignarse en la memoria DRAM para cada capa y cabezal de atención:

DRAM_KV = 2 × N_capas × N_cabezales × D_cabezal × N_tokens × Bytes_Precisión

En un modelo de 3B (32 capas, 16 cabezales de atención, dimensión 128 por cabezal y precisión FP16 de 2 bytes), una imagen de 1.024 tokens bloquea de inmediato ~268 MB de DRAM activa exclusivamente para la caché KV. Si el usuario adjunta varias fotos en la conversación, la huella de memoria se incrementa rápidamente. En dispositivos iOS controlados por el sistema Jetsam, un prefill visual descontrolado puede provocar el cierre forzoso de la aplicación (SIGKILL).

Dado que los parches visuales inyectan cientos de tokens instantáneos en memoria, consulta nuestra guía sobre cuantización de caché KV en Apple Silicon.

Estrategias de cuantización: Por qué la precisión mixta (FP16 en Visión + 4 bits en Lenguaje) es obligatoria

Para ejecutar modelos en dispositivos con presupuestos de 6 GB, 8 GB o 16 GB de memoria unificada, la cuantización resulta indispensable. Sin embargo, aplicar cuantización uniforme a 4 bits (como INT4 simple) en toda la arquitectura multimodal produce fallos inaceptables en tareas de visión.

Las pruebas empíricas demuestran una realidad técnica determinante: los codificadores visuales son extraordinariamente vulnerables a la pérdida de precisión. Los pesos de un Vision Transformer actúan como filtros espaciales de alta frecuencia. Cuantizarlos a 4 bits genera ruido geométrico, borra bordes tipográficos en documentos e introduce distorsiones en las líneas de tablas.

El estándar técnico para la ejecución de VLMs en local es la cuantización de precisión mixta:

• Codificador visual y proyector (FP16 / BF16): Se mantienen en coma flotante completa a 16 bits. Como el codificador visual representa una fracción pequeña del tamaño total (típicamente entre 150 MB y 400 MB, frente a los miles de millones de parámetros del modelo de lenguaje), mantener 16 bits añade un impacto de memoria mínimo mientras garantiza una extracción visual intacta.
• Decodificador de lenguaje (Cuantización afín a 4 bits): Se cuantiza a 4 bits por grupos (típicamente de 64 o 128 elementos, como implementa Apple MLX). El decodificador concentra entre el 85% y el 92% de los parámetros totales. Cuantizarlo reduce el peso en disco de un modelo de 3B desde ~6,2 GB hasta ~1,9 GB con una degradación lingüística prácticamente imperceptible.

Para comprender cómo el ancho de banda del bus de DRAM condiciona la velocidad de generación tras el prefill visual, revisa nuestro análisis sobre ancho de banda en Apple Silicon para LLMs.

Matriz comparativa de arquitecturas VLM en local: Memoria, TTFT y velocidad

La elección del modelo adecuado depende del techo de memoria unificada del equipo y del tipo de tarea visual requerida (descripción ligera de fotos frente a OCR técnico de alta densidad). La siguiente tabla resume las asignaciones prácticas, latencias de prefill y velocidades sostenidas en silicio Apple:

Para calcular el presupuesto total de DRAM sumando pesos, contexto e imágenes de alta resolución, consulta nuestra guía de cuánta RAM necesita un LLM local.

Canal Metal sin copias: Swift nativo con MLX-VLM frente a entornos Python u Ollama

En estaciones de trabajo x86 convencionales, la inferencia visual sufre una penalización notable por transferencias de datos. El sistema operativo carga la imagen del almacenamiento a la memoria RAM de la CPU, decodifica el JPEG mediante librerías de usuario, serializa el tensor RGB a través del bus PCIe 4.0 (limitado a ~31,5 GB/s) hacia la VRAM de la tarjeta gráfica y sincroniza el contexto CUDA. Este proceso introduce entre 50 ms y 150 ms de latencia acumulada.

Apple Silicon elimina por diseño estas transferencias redundantes gracias a su Arquitectura de Memoria Unificada (UMA). Al ejecutar modelos visuales con Apple Metal y librerías nativas en Swift:

• Memoria compartida sin copia (MTLStorageModeShared): La imagen se decodifica en la memoria unificada del sistema mediante los frameworks ImageIO acelerados por hardware. El búfer resultante se transfiere directamente al grafo de cálculo de MLX sin duplicar un solo byte por un bus externo. Tanto la CPU como la GPU Metal acceden exactamente a las mismas direcciones físicas.
• Eliminación del runtime de Python: Ejecutar modelos mediante contenedores Docker o scripts de Python introduce un consumo desproporcionado—bloqueando a menudo entre 600 MB y 1,2 GB de memoria únicamente para el intérprete, Torch y demonios secundarios. La compilación nativa en Swift erradica esa penalización, permitiendo arranques en frío inferiores a 150 ms.
• Grafo optimizado de Metal Performance Shaders (MPSGraph): Las convoluciones de los parches visuales y las multiplicaciones matriciales se despachan directamente a los núcleos tensores de la GPU de Apple Silicon, liberando los núcleos de CPU para gestionar la interfaz y el streaming reactivo.

Privacidad visual en la práctica: OCR, RAG documental e integración en Lapis

La ventaja decisiva de la IA multimodal local reside en el control de la información. Cuando se analizan declaraciones fiscales, documentos de identidad, historiales médicos o prototipos confidenciales de software, enviar imágenes sin cifrar a servidores externos genera un riesgo inaceptable de seguridad y cumplimiento legal. Un modelo ejecutándose en Apple Silicon opera en un entorno estrictamente aislado: los píxeles y los tokens generados residen temporalmente en la DRAM protegida del dispositivo y se liberan inmediatamente al cerrar la sesión.

En Lapis para iOS y macOS, este flujo está integrado de forma nativa. Gracias a Swift y MLXVLM, Lapis permite adjuntar fotografías, documentos y capturas directamente al chat. La imagen se procesa por completo en el silicio de Apple mediante Metal con ajuste dinámico de parches y gestión segura de la memoria. Ya sea en un iPhone en Modo Avión o en un Mac de sobremesa, Lapis ofrece inteligencia visual instantánea y privada sin cuotas de suscripción ni telemetría externa.

La presentación de las funciones de visión de Lapis explica cómo preguntar por imágenes con un modelo compatible.