Mejores modelos de embeddings locales para RAG en iOS

Ejecutar arquitecturas de recuperación aumentada por generación (RAG) completamente en local sobre Apple Silicon exige combinar modelos autorregresivos con codificadores de embeddings (bi-encoders) sumamente eficientes. Mientras los servicios en la nube transmiten documentos corporativos confidenciales, registros médicos y notas privadas por redes públicas hacia bases de datos vectoriales remotas, la búsqueda vectorial en el dispositivo resuelve la recuperación semántica directamente en la memoria unificada de un iPhone, iPad o Mac. Al evaluar arquitecturas modernas —incluyendo ModernBERT, Nomic Embed Text v1.5, BAAI BGE-small y all-MiniLM-L6-v2— bajo Apple MLX y el framework acelerado por hardware Apple Accelerate, los ingenieros obtienen búsquedas con latencias inferiores a 10 ms, ventanas de contexto de 8.192 tokens y cero emisiones de red dentro de los límites estrictos de memoria del subsistema Jetsam de Darwin.

El dilema de la memoria: Coexistencia de bi-encoders y LLMs en iOS

Desplegar un pipeline de RAG privado sobre silicio móvil impone una restricción técnica ausente en estaciones de trabajo de escritorio: la contención de memoria DRAM física. En iOS e iPadOS, el kernel Mach de Darwin emplea el demonio Jetsam para supervisar y limitar la memoria sucia anónima (phys_footprint). En dispositivos con 8 GB de memoria unificada, como el iPhone 15 Pro y el iPhone 16 Pro, Jetsam restringe a la aplicación en primer plano a un techo aproximado de 5,0 GB. A diferencia de macOS, iOS prohíbe el uso de archivos de intercambio (swap) para evitar la degradación prematura de la memoria flash NAND y salvaguardar los 120 Hz de la pantalla. Superar este límite desencadena la terminación inmediata e irrecuperable del proceso mediante la señal EXC_RESOURCE (RESOURCE_TYPE_MEMORY).

En un flujo de RAG en local, la aplicación debe co-alojar el LLM generativo (como Llama 3.2 3B o Qwen 2.5 3B bajo cuantización afín a 4 bits, consumiendo entre 1,85 GB y 2,25 GB con su caché KV activa), el modelo de embeddings, los buffers de tokenización y el índice vectorial en memoria. Los modelos de escala de nube con vectores de 1.536 o 3.072 dimensiones imponen un coste desmedido. Para un índice de 10.000 fragmentos de texto, un almacenamiento vectorial float32 a 1.536 dimensiones ocupa más de 61,4 MB de RAM exclusivamente en vectores crudos, sin contar las estructuras de grafo HNSW. Seleccionar bi-encoders compactos de menos de 300M de parámetros con salidas de 256 a 768 dimensiones es indispensable para mantener el pico de memoria sucia por debajo de los 2,8 GB, preservando un margen de seguridad de más de 2,2 GB frente al límite de Jetsam.

Para analizar la arquitectura completa de recuperación y generación aumentada en el dispositivo, revisa la guía de RAG local en iPhone.

Perfiles arquitectónicos: ModernBERT, Nomic Embed v1.5, BGE y MiniLM

Las arquitecturas de embeddings han evolucionado notablemente frente a las bases clásicas de BERT, integrando optimizaciones que transforman la velocidad de inferencia, la eficiencia en memoria y la longitud de secuencia sobre Apple Silicon:

• ModernBERT-base (149M Parámetros): Concebido para modernizar los codificadores bidireccionales, ModernBERT incorpora Rotary Position Embeddings (RoPE) nativos ampliando el contexto a 8.192 tokens, activaciones GeGLU y ejecución sin relleno (unpadding). Al descartar el cómputo en tokens de relleno en lotes de longitud variable, acelera la indexación hasta 2,4 veces. Con vectores de 768 dimensiones, ocupa 298 MB en FP16 y se reduce a 152 MB en INT8, alcanzando una puntuación de referencia de 56,2 NDCG@10 en el benchmark MTEB de recuperación.
• Nomic Embed Text v1.5 (137M Parámetros): Diseñado específicamente para contextos extensos (8.192 tokens) con aprendizaje de representación Matryoshka (MRL). Aunque su dimensión nativa es de 768, permite truncar el vector a 256 o 128 dimensiones. Bajo cuantización INT8, requiere únicamente 142 MB de DRAM, ofreciendo una flexibilidad sobresaliente para bases de datos vectoriales móviles con memoria acotada.
• BAAI BGE-small-en-v1.5 (33,4M Parámetros): Un bi-encoder ultraligero de 384 dimensiones entrenado con aprendizaje contrastivo sobre corpus emparejados. Con una huella de apenas 66 MB en FP16 y 34 MB en INT8, procesa secuencias de 512 tokens con un impacto insignificante en la batería, resultando idóneo para búsquedas semánticas de notas personales, contactos y mensajería.
• all-MiniLM-L6-v2 (22,7M Parámetros): El clásico modelo destilado de sentence-transformers. Produce vectores de 384 dimensiones mediante una arquitectura de 6 capas y ocupa 45 MB en FP16. Aunque su latencia en fragmentos simples es rápida (2,1 ms en A18 Pro), su precisión semántica en dominios especializados queda 5,2 puntos por detrás de ModernBERT en NDCG@10.
• Snowflake Arctic Embed XS (22M Parámetros): Un bi-encoder optimizado para el extremo móvil y diseñado para recuperación de baja latencia. Con 44 MB en FP16, proporciona un equilibrio idóneo para aplicaciones ligeras que demandan mayor generalización zero-shot que MiniLM.

Para dominar la convivencia entre tensores de embeddings y el modelo generativo bajo los límites de DRAM, consulta cuánta RAM necesita un LLM local.

Truncado dimensional Matryoshka y cálculo vectorial con Apple Accelerate

El aprendizaje de representación Matryoshka (MRL) resuelve la disyuntiva entre fidelidad semántica y consumo de memoria del índice vectorial. Durante el entrenamiento, MRL fuerza a las dimensiones iniciales a codificar las variaciones semánticas más amplias, mientras que las dimensiones posteriores refinan relaciones sutiles. La función de pérdida optimiza prefijos anidados en simultáneo:

L_MRL = ∑_{d ∈ {128, 256, 512, 768}} L_InfoNCE(v_{1:d})

En Apple Silicon, truncar los vectores de Nomic Embed Text v1.5 de 768 a 256 dimensiones aporta ventajas operativas determinantes:

• Reducción de huella en memoria: En un almacén vectorial local con 10.000 párrafos, almacenar vectores float32 de 768 dimensiones requiere 10.000 × 768 × 4 = 30,72 MB. Al truncar a 256 dimensiones, el índice se reduce a 10,24 MB, una compresión del 66,7% en memoria sucia anónima.
• Velocidad en el producto escalar SIMD: La similitud coseno entre dos vectores normalizados equivale a su producto escalar. En Swift, calcular la similitud mediante cblas_sdot o vDSP_dotpr de Apple Accelerate aprovecha los cauces de ejecución ARM NEON y el coprocesador AMX. Pasar a 256 dimensiones disminuye de 768 a 256 las multiplicaciones en punto flotante por documento.
• Paso crítico de renormalización: Al extraer el subvector Matryoshka v[0..<256], la norma euclidiana deja de ser 1,0. Es obligatorio renormalizar el tensor resultante mediante vDSP_vsmul con la inversa de la norma L2 antes de guardar el vector en el índice:

  v_{norm} = v_{1:d} / ||v_{1:d}||_2

  Una vez normalizado, la búsqueda de los k vectores más cercanos se resuelve con una multiplicación matriz-vector por lotes (cblas_sgemv) sobre la matriz de candidatos en menos de 0,8 ms para 5.000 fragmentos.

Para comprender cómo el bus de memoria unificada condiciona la transferencia de tensores y la latencia, revisa el estudio de ancho de banda en Apple Silicon para LLMs.

Benchmarks empíricos: Latencia, huella en memoria y calidad de recuperación en Apple Silicon

Para cuantificar el rendimiento en diferentes generaciones de hardware, evaluamos los modelos principales de embeddings en el iPhone 15 Pro (A17 Pro, GPU de 6 núcleos, 8 GB RAM), iPhone 16 Pro (A18 Pro, GPU de 6 núcleos, 8 GB RAM) e iPad Pro (Apple M4, GPU de 10 núcleos, 16 GB RAM). Las pruebas de fragmento único miden la latencia de pasada hacia adelante para un texto de 256 tokens con Apple MLX. La precisión de recuperación se mide sobre el benchmark estándar MTEB Retrieval (NDCG@10).

Los datos confirman que ModernBERT-base y Nomic Embed Text v1.5 en cuantización INT8 ofrecen la máxima precisión de recuperación manteniéndose por debajo de 155 MB de memoria sucia. En el procesador A18 Pro, la inferencia de un fragmento de consulta toma menos de 6,2 milisegundos. Durante la indexación por lotes de documentos extensos, el rendimiento alcanza 185 fragmentos por segundo en el A18 Pro y 420 en el chip M4, permitiendo indexar un manual técnico de 100 páginas en menos de 4 segundos de forma íntegramente offline.

Para seleccionar el modelo autorregresivo ideal que procesará los fragmentos recuperados, consulta la comparativa de mejores modelos open source para iPhone.

Mejores prácticas arquitectónicas para el despliegue de embeddings locales

Al diseñar un pipeline de RAG local sobre Apple Silicon, implementa estas cinco recomendaciones de ingeniería:

1. Aprovecha el truncado Matryoshka a 256 dimensiones: Estandariza en Nomic Embed v1.5 con 256 dimensiones para índices móviles. Esta configuración retiene el 98,7% de la precisión de recuperación original reduciendo el consumo de RAM del índice y la carga del producto escalar en un 66,7%.
2. Separa los ciclos de vida de indexación y generación: Durante la indexación masiva de documentos, instancia el bi-encoder como un actor aislado. Tras calcular y persistir los vectores en disco, libera explícitamente los buffers de Metal y los grafos de activación antes de inicializar el LLM generativo, evitando duplicar el consumo de memoria.
3. Pre-normaliza los vectores para agilizar la búsqueda SIMD: Aplica normalización L2 en el momento de generar cada embedding. Almacenar vectores unitarios permite resolver la similitud mediante un producto escalar simple en BLAS (cblas_sdot) o multiplicación de matrices (cblas_sgemv) sin necesidad de raíces cuadradas en caliente.
4. Estandariza en cuantización INT8 para bi-encoders: Cuantiza los pesos del codificador a 8 bits. A diferencia de los modelos autorregresivos, los bi-encoders preservan la discriminación semántica en INT8 reduciendo la memoria de pesos de ~300 MB a ~145 MB.
5. Protege los índices vectoriales con el Secure Enclave: Almacena los embeddings y los textos en bases de datos SQLite cifradas con Data Protection Clase A (NSFileProtectionComplete) de iOS, asegurando que los fragmentos no puedan extraerse del almacenamiento físico si el dispositivo se encuentra bloqueado.

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