- Parte de la idea de que "si el texto se representa como imagen, se puede contener la misma información con muchos menos tokens"
- Propone un nuevo enfoque que comprime la información textual en una representación visual 2D, y valida experimentalmente el concepto de compresión basada en visión (Optical Compression) para manejar contexto largo de forma eficiente
- El modelo está compuesto por DeepEncoder (codificador) y DeepSeek3B-MoE-A570M (decodificador), y logra baja memoria activa incluso con entradas de alta resolución junto con una tasa de compresión de tokens de 10 a 20 veces
- Mantiene 97% de precisión OCR con compresión de 10x y más de 60% de exactitud incluso con compresión de 20x, lo que sugiere una posibilidad real para investigar compresión de contexto largo y mecanismos de olvido de memoria
- En OmniDocBench superó a GOT-OCR2.0 (256 tokens/página) usando solo 100 vision tokens, y mostró mejor rendimiento que MinerU2.0 (promedio de 6000+ tokens/página) con menos de 800 tokens
- Con una sola GPU A100-40G puede generar más de 200 mil páginas de datos por día, por lo que tiene alto valor práctico como motor de datos para entrenamiento masivo de LLM/VLM
1. Contexto de la investigación
- Los LLM existentes tienen la limitación estructural de que el costo computacional crece cuadráticamente con la longitud de la secuencia
- El paper parte de la idea de que "si el texto se representa como imagen, se puede contener la misma información con muchos menos tokens"
- Define esto como compresión de contexto largo basada en tokens visuales (Context Optical Compression) y usa OCR como escenario experimental
- Como resultado, muestra una nueva vía en la que la representación visual puede mejorar la eficiencia del procesamiento de contexto en los LLM
2. Estructura del modelo
- DeepSeek-OCR = DeepEncoder + decodificador DeepSeek3B-MoE
- DeepEncoder: SAM (Window Attention) + CLIP (Global Attention) + compresor de tokens de 16x
- DeepSeek3B-MoE: activa 6 de 64 expertos, con 570M parámetros activos en total
- Soporta modo multirresolución (Tiny~Gundam)
- Soporta entradas de resolución 512~1280 y procesa de forma compuesta hasta 9 tiles
- El modo Gundam está orientado a documentos de ultra alta resolución (como periódicos) y usa hasta 800 vision tokens
3. Motor de datos
- Combinación de 3 tipos de datos:
- Datos OCR 1.0: 30M páginas basadas en documentos en 100 idiomas, con anotaciones detalladas de layout y texto
- Datos OCR 2.0: 16M datos para reconocimiento complejo como gráficas, fórmulas químicas (SMILES) y figuras geométricas
- Datos generales de visión: para mantener comprensión visual basada en CLIP, 20% del total
- Datos solo de texto: 10% para reforzar la capacidad lingüística
- Proporción total de los datos de entrenamiento
- OCR 70% / visión 20% / texto 10%
4. Pipeline de entrenamiento
- Entrenamiento en dos etapas: DeepEncoder → DeepSeek-OCR
- En un total de 20 nodos (8×A100 GPU), con paralelismo de datos DP=40 y batch global de 640
- Velocidad de entrenamiento: 90B tokens/día de datos de texto y 70B tokens/día de datos multimodales
5. Resultados de evaluación
(1) Experimento de compresión (benchmark Fox)
- 97% de exactitud con compresión de 10x, y más de 60% incluso con 20x
- A medida que el documento es más largo o complejo, el rendimiento cae, pero esto se interpreta como una posibilidad de simular un "mecanismo de olvido"
- Con una tasa de compresión de 10x o menor, es posible una restauración del contexto casi sin pérdida
(2) Reconocimiento de documentos reales (OmniDocBench)
- Comparación entre modos Tiny (64 tokens) y Gundam (800 tokens)
- Mejor que GOT-OCR2.0 (256 tokens) en modo Small (100 tokens)
- Supera a MinerU2.0 (7,000 tokens) con Gundam (800 tokens)
- La cantidad de tokens requerida varía según el tipo de documento
- Presentaciones, reportes: bastan 64~100 tokens
- Periódicos, papers: requieren 400~800 tokens
6. Análisis cualitativo (Qualitative Study)
- Modo Deep Parsing
- Permite extracción estructurada con un solo prompt para gráficas, figuras, fórmulas químicas e incluso imágenes naturales
- Reconocimiento multilingüe
- Soporta PDF en alrededor de 100 idiomas, incluyendo idiomas de baja presencia como árabe y cingalés
- Comprensión visual general
- Realiza descripción de imágenes, detección de objetos y grounding
- En combinación con un LLM, puede usarse como modelo base para razonamiento multimodal visión-lenguaje
7. Discusión e implicaciones
- DeepSeek-OCR es el primer experimento que explora los límites de la compresión de texto largo basada en vision tokens,
cuantificando la idea de que "una imagen contiene mil palabras"
- Incluso con compresión de 10x, es posible una restauración casi sin pérdida → puede extenderse a compresión del historial de conversación, optimización de memoria a largo plazo, etc.
- Propone una simulación de atenuación de tokens similar a la curva biológica del olvido mediante una estrategia de reducir la resolución de la imagen con el paso del tiempo
8. Conclusión
- DeepSeek-OCR es un modelo demostrativo de mapeo de compresión de 10 a 20 veces entre texto y visión,
que plantea un nuevo paradigma para superar los límites de los LLM al procesar contexto largo
- Más allá del OCR, se proyecta su expansión hacia preentrenamiento híbrido digital-óptico y
modelos de contexto ultralargo basados en 'Optical Context Memory'
- El código ya está disponible y puede aprovecharse como motor de datos tanto para investigación como para uso comercial
- DeepSeek-OCR destaca frente a otros proyectos open source de OCR existentes por su arquitectura basada en modelos de lenguaje grandes (LLM), que codifica la información visual de forma eficiente
- Incluye soporte para múltiples resoluciones (512×512~1280×1280) y modo Gundam para resolución dinámica, con gran capacidad de adaptación a distintos entornos
- Con un diseño de prompts claro, soporta varios modos de trabajo como descripción general de imágenes, conversión a Markdown, OCR ignorando el layout y parsing de tablas y gráficas
- Se verificó su rendimiento en integración con benchmarks de la industria como Fox y OminiDocBench, y mediante experimentos basados en procesamiento de documentos reales
- Su implementación incorpora ventajas e ideas de otros proyectos populares como GOT-OCR2.0 y PaddleOCR
- Resoluciones soportadas
- Tiny: 512×512 (64 vision tokens)
- Small: 640×640 (100 vision tokens)
- Base: 1024×1024 (256 vision tokens)
- Large: 1280×1280 (400 vision tokens)
- Dynamic mode(=Gundam): resolución libre (n×640×640 + 1×1024×1024)
- Inferencia paralela para PDF e imágenes y alta velocidad de procesamiento
- En una GPU A100, puede procesar PDF a ~2,500 tokens/segundo
- Base técnica e integración con el ecosistema
- Está implementado 100% en Python
- Soporta ambos entornos principales de inferencia: vLLM y Transformers
- Utiliza benchmarks y frameworks de evaluación importantes como OpenChart, Fox y OminiDocBench
- Se conecta con modelos previos como GOT-OCR2.0, PaddleOCR y Vary, tomando ideas y reforzando el rendimiento
1 comentarios
Opiniones en Hacker News
Este paper no se queda solo en ser otro VLM para OCR, sino que pasa a temas más interesantes como la compresión
Por ejemplo, incluye una cita: "Realizamos un estudio inicial sobre los límites de la compresión visión-texto para explorar cuántos tokens visuales se necesitan para decodificar tokens de texto. Los resultados preliminares muestran que DeepSeek-OCR logra una compresión OCR casi sin pérdidas con una proporción de ~10x, y aun con una compresión de 20x mantiene un 60% de exactitud"
Intuitivamente, eso implicaría que un token visual contiene tanta información como 10 tokens de texto
Me gustaría que alguien explicara por qué ocurre esto desde la teoría de la información de forma que lo entienda un principiante
No sé si es porque los tokens de texto todavía están demasiado fragmentados (o son redundantes) y no llegan al nivel de una codificación por entropía, o si al pasar al esquema de tokens visuales se supera la limitación del “nivel palabra” y se puede acercar más a la entropía, como en la diferencia entre codificación aritmética y código Huffman
Además, el paper también habla de reducir realmente la escala de las imágenes al manejar contextos grandes, y de la correspondencia entre la pérdida de información en el dominio del texto y en el dominio de la imagen
Los tokens de texto son subunidades cuantizadas (subwords), mientras que los tokens visuales solo existen en el espacio de embeddings
En un LLM, la tokenización de texto es básicamente una tabla de búsqueda entre IDs de token (pequeños) y embeddings vectoriales (grandes)
Cuando le pasas texto a un LLM, cortas la cadena en límites de tokens, la conviertes en IDs de token y luego recuperas los vectores desde la tabla para formar una matriz de contexto
Transmitir la secuencia real de tokens de texto es eficiente, porque solo mandas un arreglo de números (IDs), normalmente sobre ~100 mil tokens únicos
En cambio, transmitir la matriz de embeddings en sí es ineficiente, porque los embeddings consisten en miles de números flotantes
Las imágenes se codifican distinto. Los datos de imagen se preprocesan y se pasan directo a un codificador de imágenes basado en redes neuronales, que los convierte en vectores y los integra al contexto
Es decir, los tokens de imagen no tienen IDs de token ni tabla de búsqueda: pasan directo de los datos al embedding
Como resultado, para transmitir tokens de imagen tendrías que enviar los embeddings mismos, lo cual es ineficiente
Aunque la imagen se codifique con menos tokens, la capacidad de cada token es mucho mayor
En resumen, los tokens de texto son enteros (0~n) con un mapeo claro a vectores, así que hay ‘n’ opciones posibles
En cambio, los tokens de imagen son arreglos de floats de dimensión m (vectores), así que el espacio de tokens es muchísimo mayor
También en términos de patrones, los tokens de texto corresponden directamente a bytes UTF-8 consecutivos y casi nunca salen de los límites de palabra, así que un patrón global (por ejemplo, “esta línea es de Hamlet” o “esta parte está en español”) no puede representarse con un solo token
No tengo del todo claro cómo se embebe la entrada de imagen en un LLM multimodal, pero entiendo que básicamente divide la imagen en una grilla y codifica cada región
En los experimentos de DeepSeek, más que aparecer una propiedad de teoría de la información, me parece que la clave es cuánto puedes bajar la resolución o agrandar el tamaño de la grilla (patches) y aun así conservar suficiente detalle para hacer OCR con precisión
Ojalá Karpathy amplíe NanoChat a multimodal y comparta know-how sobre este proceso de codificación
La tasa de compresión adecuada al final depende inevitablemente del tamaño relativo entre la resolución de cada carácter y el tamaño de cada patch del token visual
Solo así el número de tokens de texto extraídos por OCR puede mantenerse, en última instancia, independiente de la resolución de la imagen
Cada token de texto suele ser una subword, pero los tokens visuales de un VLM están ubicados en un espacio semántico
El espacio semántico puede comprimir información mucho mejor que una segmentación en subwords
Aclaro: no soy experto, solo estoy improvisando una idea
Los LLM tienen una arquitectura donde el costo computacional crece al cuadrado con la cantidad de tokens
Por eso en los VLM se busca comprimir tokens de texto en tokens visuales
Supongo que están intentando primero renderizar el texto como imagen y luego tokenizarlo para reducir el costo de cómputo
En NVIDIA Spark (ARM64), PyTorch fue algo complicado, pero logré hacerlo funcionar ejecutando Claude Code como root dentro de un contenedor Docker nuevo
Hay notas detalladas aquí
El resultado real puede verse en este enlace, usando como prueba la imagen OCR original (aquí)
El resultado del OCR en general es bastante sólido
Pero justo debajo de una cita agregó contenido innecesario y mostró una alucinación, además de unirlo con la columna siguiente
Gracias por haber hecho una prueba rápida
Se entiende que haya omitido la "A" del inicio del texto (quizá el dataset tenía poca proporción de artículos de noticias)
Pero me parece más interesante que también se haya saltado por completo todo "Hallucination is a risk and...", el tema junto al autor ("theme") y la parte final del correo
Solo este experimento ya me parece que amerita una publicación aparte
"Ejecutar Claude Code como root en un contenedor Docker nuevo"
Me da curiosidad cómo configuraste eso exactamente para que corra con permisos de root
(si ya está explicado, lo revisaré en el post)
El paper no menciona Anna’s Archive
Creo que DeepSeek podría haber aprovechado la oferta de Anna de dar acceso a investigadores de OCR a una colección china de no ficción de 7.5 millones de libros (350 TB)
Eso es incluso más grande que Library Genesis
Post de referencia
En un paper anterior de DeepSeek sí mencionan explícitamente a Anna’s Archive
"Curamos 860K libros electrónicos en inglés, 180K en chino y millones de preguntas de examen K-12 de Anna’s Archive"
Ver el paper de DeepSeek-VL
Me pregunto si de verdad necesitas pedir acceso solo porque alguien almacena libros ajenos
Yo también pensé de inmediato en Anna’s Archive, y me pregunto cuándo liberarán un dataset procesado por OCR
También significa que quizá nunca vayan a liberar el dataset
Me preocupa que en una situación así Anna’s Archive termine desapareciendo por abuso de parte de las empresas de LLM
Como si no bastara con que META ya sacara 70 TB por torrent desde library genesis
Comparto experiencia sobre el nivel real de los benchmarks frente a lo que se muestra hoy
El benchmark de OmniAI no es bueno
En cambio recomiendo OmniDocBench
Mistral OCR queda claramente por debajo de los modelos OCR open source y también de Gemini
El OCR E2E sigue siendo muy difícil
El enfoque por pipeline (detección de layout → orden de lectura → OCR por elemento) funciona mejor
El parsing de tablas complejas sigue siendo un gran problema
También me da curiosidad ver comparativas de benchmark con Apple Vision Framework
Viene integrado en casi todos los dispositivos de Apple y en la práctica produce OCR rápido y de muy buena calidad (especialmente para conversión de PDF), pero parece que poca gente lo conoce
Me interesa muchísimo saber en qué lugar quedaría en un benchmark
Según el benchmark de OmniAI, Omni OCR muestra el mejor rendimiento
Siento que muchos aceptarían ese resultado sin cuestionarlo
Me pregunto qué ventajas y diferencias tiene el OCR basado en LLM frente a servicios como Azure AI Document Intelligence(enlace) o Google Vision API(enlace)
En OmniAI comparan su propio LLM con OCR en la nube en benchmarks cruzados
Benchmark del blog de OmniAI (febrero de 2025)
Desde entonces los LLM han avanzado rápido
Últimamente los mejores resultados los está dando la familia Qwen3-VL, especialmente Qwen3-VL-235B-A22B-Instruct
Mi impresión es que los modelos OCR comerciales/propietarios van a seguir siendo mejores en documentos reales
Tienen muchos datasets privados de entrenamiento de alta calidad
Los LLM públicos se entrenaron con datos más centrados en papers de arXiv, ebooks, etc., así que inevitablemente rinden peor en documentos de trabajo reales
El enfoque LLM reduce errores de sustitución de caracteres (typos, variaciones), pero a nivel de consistencia de página completa en realidad puede ser peor
Incluso puede producir salidas completamente absurdas, como cualquier LLM que no sea OCR
En caracteres CJK, el OCR tradicional sigue produciendo muchas sustituciones inadecuadas
Hay demasiados caracteres muy parecidos, a veces distinguibles solo casi a nivel microscópico o binario
Un LLM puede imponer más restricciones sobre las secuencias plausibles de caracteres, así que se puede esperar un resultado más preciso
Al menos ese tipo de preocupación sí motiva adoptar OCR basado en LLM
No sé sobre otros modelos, pero en nuestra empresa corremos un sistema de parsing de CVs con Azure AI Document Intelligence y estamos bastante satisfechos
Solo hubo que ajustar bien al inicio, y en el último año casi no ha requerido mantenimiento
He probado varios VLM (desde modelos pequeños hasta grandes, como Granite y Qwen) y mi conclusión es que decepcionan como reemplazo total del OCR tradicional
Nuestro sistema recibe documentos de clientes y devuelve un documento estándar marcado según lo solicitado (bitmaps raster multipágina)
Para nosotros es importante la precisión en la extracción de coordenadas hasta nivel de carácter o palabra individual, y en la práctica la información posicional de los VLM es demasiado inconsistente, totalmente alucinada o demasiado ambigua como para garantizar la exactitud/granularidad que necesitamos
Hasta ahora seguimos con una base de Tesseract y rutinas de limpieza del resultado, y solo usamos ocasionalmente la salida de texto de un VLM como apoyo cuando no hay datasets estructurados
Seguramente nuestro caso es una necesidad bastante específica, y para la mayoría de la gente basta con obtener un volcado de texto o una conversión a Markdown/HTML
Pero siento que hay una brecha importante entre las afirmaciones de que estos modelos “ya resolvieron el OCR por completo” y la experiencia real
Sugiero probar el modelo moondream 3 preview
En un post del blog dicen que supera el rendimiento de varios VLM y además es ligero
Ver página principal, modelo y blog
Me da curiosidad si los documentos de los clientes incluyen texto escrito a mano
También podría funcionar detectar primero las cajas delimitadoras del texto con una CNN y luego correr un VLM para cada caja
Mi impresión personal era que el OCR ya estaba más o menos resuelto
El benchmark de OmniAI tampoco se ha actualizado con modelos recientes, y pensé que la razón era que los LLM de propósito general ya superaron al OCR de ese benchmark
De hecho, si a cada imagen de página la metes en Gemini 2.5 Flash Lite y le pides extraerla como Markdown, el costo fue de unos 20 centavos por cada 1000 páginas y el resultado fue muy bueno
Me pregunto cuál es la parte difícil del OCR hoy en día
La mayoría de los OCR/LLM (especialmente Gemini Pro 2.5) todavía tienen muchas dificultades para convertir tablas complejas a Markdown/HTML
Son frecuentes los problemas con múltiples encabezados, celdas combinadas, columnas con checkboxes, etc., y tampoco entienden bien tablas que continúan en varias páginas
Llamaindex también falla gravemente en esto
Me interesa saber qué OCR/LLM funciona mejor en ese tipo de casos
Ejemplo de tablas complejas,
Ejemplo completo del checklist de ICAO
En realidad no es OCR sino HTR (transcripción/reconocimiento de escritura a mano), y eso sigue siendo complicado
Los LLM han mejorado mucho la precisión, pero también hacen que los errores sean mucho más difíciles de detectar por humanos (inventan por completo lo que no pueden leer)
Si aceptas como válido que donde no puede reconocer algo simplemente lo imagine y lo complete arbitrariamente, entonces sí, está “resuelto” sin problemas
(no lo digo con sarcasmo; en algunos contextos de verdad puede ser aceptable)
Yo soy el autor del benchmark de OmniAI
La razón de que no esté actualizado con los modelos más nuevos es que el producto mismo redujo su enfoque en OCR API
Internamente todavía lo usamos y el benchmark simplemente quedó desactualizado por flojera
Gemini es el mejor en OCR
Pero cuando el resultado se parece demasiado a los datos de entrenamiento, a menudo aparece un error de "recitation" donde alrededor del 10% de la salida se corta de golpe
También tiene alucinaciones graciosas donde, si en una mezcla de PDFs entra una página en blanco, inventa contenido completamente ajeno
OpenAI tampoco está mal, pero GPT5 no muestra diferencia respecto a GPT-4o o 4.1
Algunas partes como headers/footers suelen desaparecer, y si la página está rotada lateralmente se vuelve loco
También rechaza con frecuencia documentos de identidad, documentos médicos o contenido con alto riesgo de PII
Para nada siento que sea un problema resuelto
Intenta hacer OCR de revistas con layouts poco comunes y verás que es imposible
Colecciono revistas vintage y siempre pruebo OCR con la tecnología más nueva, pero igual hace falta muchísimo trabajo manual
Me pregunto si habrá un “modelo OCR” pequeño
En fotos de planta industrial solo necesito extraer números de serie, no parsear un documento completo
Usar un modelo de 3 mil millones de parámetros para algo así me parece excesivo
Me pregunto cómo se compara DeepSeek-OCR contra Tesseract(enlace)
Yo uso muchísimo ocrmypdf(enlace) y me funciona increíble en local
Pero incluso si Tesseract da 80% de rendimiento y los modelos más nuevos llegan a 95%,
si el costo es multiplicar por 100 el uso de disco, además de requerir Kubernetes/Docker y GPU con 16 GB de VRAM, entonces definitivamente vale la pena pensarlo bien
Como alguien que no logra seguir el ritmo de la investigación reciente, me gustaría que alguien me lo resumiera en modo ELI5 (como si tuviera 5 años): qué es esto y por qué importa
El título en GitHub o en el paper es sobre OCR, pero en el resumen y en el readme.md hablan de compresión de contexto para LLM, así que me confunde
Busco una explicación de alto nivel sobre cómo se conectan ambas cosas
La imagen contiene información equivalente a ‘1000 tokens’
En la práctica, la imagen tiene que convertirse (decodificarse) a features/embeddings
Si la imagen se procesa como 100 ‘tokens de imagen’ y esos tokens de imagen se convierten en 1000 ‘tokens de texto’
Entonces, desde una perspectiva puramente de decodificación, transmitiste la información de salida con una compresión de 10x
Desde la perspectiva del LLM, eso implica que si puedes precomprimir en una representación latente 10 veces más pequeña, puedes producir el mismo o incluso mejor resultado sin necesitar 1000 tokens/embeddings