LensVLM de Apple: comprimir 4.3x sin perder precisión

¿Qué es LensVLM y por qué debería importarte?

Un Vision Language Model (VLM) es un modelo que entiende imágenes y texto a la vez. Recientes trabajos han mostrado que pueden «leer» texto renderizado como imagen, en lugar de tokenizarlo palabra por palabra. La promesa: con menos tokens visuales, el modelo procesa contextos largos gastando menos cómputo y memoria, porque la atención escala de forma cuadrática con la longitud de la secuencia.

El problema, hasta ahora, es que cuando la imagen se comprime demasiado, los caracteres dejan de ser legibles para el encoder visual. A un ratio de compresión 15x, la precisión del VLM colapsa de 72.4% (texto completo) a apenas 31.3%, según muestran los autores en siete benchmarks de QA sobre texto. La información simplemente no está en los píxeles.

LensVLM (publicado por Apple en colaboración con Duke University) ataca exactamente ese cuello de botella: en lugar de pedir al VLM que lea perfectamente cualquier imagen, lo entrena para escanear imágenes comprimidas y luego expandir selectivamente solo las relevantes a su forma original mediante una herramienta aprendida. El código y los pesos están disponibles en github.com/apple/ml-lensvlm.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Cómo funciona la arquitectura selection-then-expansion

El framework tiene tres etapas claras:

Compresión por renderizado. El texto se convierte en imágenes deterministas con PIL (fuente DejaVuSans, sin redimensionar). Cada imagen ocupa 24, 48 o 72 tokens visuales según el preset (5x, 10x, 15x de compresión). Un documento de 10.000 tokens pasa de necesitar 5.6x a 15.4x de compresión solo ajustando el ancho de la imagen renderizada.
Selección + Expansión. El VLM recibe todas las imágenes comprimidas y una pregunta. Identifica cuál contiene la evidencia y llama a una herramienta Expand que devuelve esa imagen en su forma original (texto fuente, OCR extraído o imagen de alta resolución). Cada turno expande exactamente una imagen; en consultas multi-hop, las expansiones se encadenan condicionadas al contenido ya recuperado.
Post-entrenamiento. La política se entrena primero con SFT sobre trayectorias sintéticas generadas por Qwen3.5-397B a partir de evidencia con respuesta conocida, y luego con RL on-policy usando el algoritmo DAPO. El reward combina correctness (juzgada por un LLM) más un bono de uso de herramienta gateado por respuesta correcta. En promedio, los autores miden solo 1.3 llamadas a Expand por trayectoria.

Resultados clave: 4.3x compresión, precisión casi idéntica al texto completo

Sobre siete benchmarks de QA (NQ, HotpotQA, MuSiQue, HELMET en entrenamiento; RULER, Qasper y LongBench v1 out-of-distribution), construidos sobre Qwen3.5-9B-Base como backbone:

A 4.3x de compresión efectiva (ECR), LensVLM mantiene 68.9% de accuracy, muy cerca del 72.4% del upper bound de texto completo.
A 10.1x ECR, supera a todos los baselines probados: BM25, BGE-M3, Jina-v4, Qwen3-Emb, ColPali y Jina-v4-MM, además del método de compresión visual Glyph (basado en GLM-4.1V-9B) y LLMLingua-2.
En RULER, Qasper y LongBench (OOD), LensVLM alcanza 62.1% promedio frente a 21.0% del baseline de imagen comprimida a 10x ECR.
La mejora escala con la compresión: donde la lectura visual colapsa, la ganancia de LensVLM crece.

Un beneficio secundario que importa a equipos con presupuesto GPU: la caché KV se reduce un 78.6% a 15x de compresión con 20 imágenes (de 334 MiB a 71 MiB en GPUs B200), y un 84.2% con 100 imágenes (de 1.602 MiB a 253 MiB). El costo es latencia por la decodificación multi-turno (17 s frente a 8 s con un solo Expand), no memoria.

Hallazgos secundarios que vale la pena recordar

El entrenamiento elimina la sensibilidad al renderizado. Antes de entrenar, la misma compresión producía variaciones de accuracy de hasta 18 puntos según la configuración de fuente y márgenes; después, esa brecha colapsa a 0.5 puntos. Eso significa que ya no necesitas hacer una búsqueda exhaustiva del «rendering óptimo» antes de desplegar.
La atención migra hacia el texto expandido. Tras el post-entrenamiento, la atención a la respuesta de la herramienta crece de 23.5% a 38.2-41.0% según la compresión, y la atención a imágenes distractoras cae. El modelo literalmente aprende a leer el contenido expandido en vez de intentar decodificar píxeles ilegibles.
La elección de la herramienta de expansión depende del input. Para texto renderizado, expandir a texto fuente original funciona mejor; para documentos nativos (PDFs escaneados), la imagen de alta resolución preserva señales de layout que el OCR pierde.
Transferencia zero-shot a código. Sobre RepoQA, LensVLM mejora al baseline de imagen comprimida en todos los niveles de compresión sin entrenamiento específico, aunque el gap con el texto completo (92.4%) sigue siendo grande.

¿Qué significa esto para tu startup?

Si estás construyendo sobre VLMs o pasarelas RAG para documentos largos, esta arquitectura cambia tres reglas de cálculo.

1. KV cache ya no es el cuello de botella principal. Pasar de texto completo a LensVLM a 15x reduce la huella de VRAM un 78-84%. Para una startup que sirve 50.000 documentos legales, contratos o papers en producción, eso puede significar hasta 4x más concurrencia por GPU sin tocar el modelo ni la infraestructura. Antes de comprar más tarjetas, vale la pena medir si tu cuello de botella es realmente atención o lo puedes mover a SSD (los autores calculan que la GPU es ~200x más cara por GB que el SSD para los recursos expandidos).

2. RAG clásico no siempre es la respuesta correcta. Los autores comparan LensVLM contra BM25, BGE-M3, Jina-v4, ColPali y otros retrievers. Los retrievers top-K funcionan cuando la evidencia está concentrada en pocos chunks y el coste de indexar se amortiza. LensVLM brilla cuando la evidencia está distribuida o cuando indexar todo el contexto offline no es viable (PDFs uno-a-uno, tickets de soporte, chats largos). Para fundadores: si tu dataset de documentos no se precomputa limpiamente o tu caso de uso es per-query pesado, LensVLM desplaza a RAG; si reindexas a diario, RAG sigue ganando.

3. Acciones concretas que puedes hacer esta semana:

Evalúa cuánto de tu inferencia actual depende de contextos >32K tokens. Si es poco, sigue con RAG clásico.
Si trabajas con VLMs (GPT-4o, Claude con visión, Qwen-VL, InternVL), prueba renderizar tus documentos a tamaño «incomodo» y mide si notas caídas de precisión. Es el mismo problema que LensVLM cuantifica.
Considera el patrón tool-use multi-turn en productos de QA documental. Ya no es exclusivo de agentes: un VLM bien entrenado puede decidir qué página abrir a resolución completa por sí solo, sin tu RAG en el loop.

Conclusión

LensVLM demuestra que «comprimir el contexto» no es una operación one-way: el modelo puede aprender a deshacer la compresión justo donde hace falta. Para founders, el takeaway es menos «hay un nuevo modelo de Apple» y más «la compresión visual con expansión selectiva es una arquitectura de inferencia viable que cambia el trade-off memoria vs. precisión en producción». El código está publicado y el método es model-agnóstico: incluso Sonnet 4.6 gana 4.8-9.0 puntos sin entrenamiento, según reportan los autores.