"¿Por qué la OCR es tan lenta?"
3 causas raíz del procesamiento lento por lotes — y cómo solucionar cada una

Causa n.º 1: Sin aceleración por GPU en un proceso de alto consumo computacional

Síntoma. La CPU se satura al 100 % durante el procesamiento y cada página tarda más de un segundo en documentos limpios. El rendimiento no mejora al añadir más archivos a un lote: el proceso está saturado.

Causa raíz. No todos los motores de OCR son iguales internamente. Tesseract, el referente de código abierto mantenido por Google, es un motor puramente basado en CPU. Utiliza pipelines tradicionales de visión artificial — análisis de componentes conectados, análisis de diseño de página y reconocimiento de caracteres basado en LSTM — ninguno de los cuales aprovecha el paralelismo de la GPU. Un investigador midió Tesseract 5 en aproximadamente 0,8 segundos por página en una CPU moderna con texto impreso limpio. Aceptable para unas pocas páginas. Insoportable para 500.

EasyOCR adopta un enfoque arquitectónico diferente. Su núcleo de aprendizaje profundo (detección de texto CRAFT + una red de reconocimiento PyTorch) puede ejecutarse en GPU y, cuando lo hace, es drásticamente más rápido. Pero hay un detalle que muchos pasan por alto: EasyOCR recurre automáticamente a la CPU si no detecta una GPU compatible. En CPU, el mismo pipeline de aprendizaje profundo que hace preciso a EasyOCR también lo vuelve de tres a cuatro veces más lento que en modo GPU. Pruebas en una NVIDIA T4 muestran EasyOCR en GPU alcanzando ~0,6 segundos por página — comparable a Tesseract — mientras que EasyOCR en CPU se alarga hasta ~2,5 segundos por página.

La solución. Verifica si tu pipeline de OCR está usando realmente una GPU:

• Para EasyOCR, comprueba que reader = easyocr.Reader(['en'], gpu=True) detecte CUDA. Si la biblioteca retrocede silenciosamente, el tiempo por página se duplicará. Ejecuta nvidia-smi durante el procesamiento — si el uso de GPU es 0 %, tu pipeline se ejecuta en CPU.
• Para Tesseract, no hay opción de GPU — simplemente no admite aceleración por GPU. Si procesas más de unos cientos de páginas, considera cambiar a un motor compatible con GPU.
• Motores de OCR dedicados como PaddleOCR están diseñados para GPU desde el inicio. Pruebas de velocidad independientes sitúan a PaddleOCR en una RTX 3090 en aproximadamente 190 páginas por minuto — más de 3 páginas por segundo — gracias a la inferencia por lotes optimizada y la integración con CUDA.

Si tu hardware es fijo (portátil sin GPU dedicada, servidor compartido, VM en la nube sin GPU), la ruta de GPU no está disponible directamente. En ese caso, un servicio de OCR en la nube que procese documentos en infraestructura con GPU — sin que tú debas aprovisionar el hardware — evita el problema por completo.

Para una comparativa detallada de motores de OCR compatibles con GPU, consulta nuestro resumen de las mejores herramientas de OCR de código abierto.

Causa #2: Imágenes mucho más grandes de lo que el OCR necesita

Síntoma. El procesamiento se detiene en páginas que se ven perfectamente legibles. Una foto de 12 megapíxeles de un recibo tarda de 5 a 8 segundos, mientras que un PDF escaneado del mismo documento tarda menos de 2 segundos.

Causa raíz. La mayoría de los motores de OCR procesan cada píxel de la imagen. Duplica la resolución en cada eje — de 150 DPI a 300 DPI — y cuadriplicas el número de píxeles: 2 veces el ancho por 2 veces el alto. Cuadruplicar la entrada significa aproximadamente 4 veces el tiempo de procesamiento para el mismo contenido. Una foto de smartphone a 4000×3000 píxeles contiene 12 millones de píxeles. El mismo documento escaneado a 300 DPI (aproximadamente 2550×3300 para tamaño carta) contiene 8,4 millones. Un documento escaneado a 200 DPI — perfectamente adecuado para la mayoría de los OCR — contiene solo 3,7 millones de píxeles.

La Guía de Rendimiento del Motor ABBYY FineReader, uno de los documentos más autorizados sobre ajuste de rendimiento de OCR, especifica 200–400 DPI como el rango de entrada recomendado. Por debajo de 150 DPI, el reconocimiento de caracteres se degrada. Por encima de 400 DPI, pagas tiempo de cómputo sin una ganancia medible en precisión. El mismo principio aplica a cualquier motor de OCR, de código abierto o propietario.

La solución. Agrega un paso de preprocesamiento que redimensione las imágenes antes de enviarlas al motor de OCR. El objetivo es 150–300 DPI en la imagen de salida — aproximadamente 1200–2500 píxeles en el lado más largo para un documento típico.

Un pipeline simple de preprocesamiento en Python con Pillow:

from PIL import Image

def resize_for_ocr(image_path, max_dim=2000):
    img = Image.open(image_path)
    # Solo reducir, nunca ampliar
    if max(img.size) > max_dim:
        ratio = max_dim / max(img.size)
        new_size = (int(img.size[0] * ratio),
                    int(img.size[1] * ratio))
        img = img.resize(new_size, Image.LANCZOS)
    return img

Este único paso puede reducir el tiempo de procesamiento por página entre un 40 y un 70% dependiendo de tus imágenes de origen, sin impacto en la precisión de extracción. Para una guía completa de preparación de imágenes — incluyendo binarización, corrección de inclinación y normalización de contraste — lee nuestra guía de preprocesamiento de imágenes para OCR.

Causa #3: Procesamiento secuencial cuando podrías ejecutar en paralelo

Síntoma. El uso de la CPU se mantiene entre el 30 y el 40 % durante un proceso por lotes. El pipeline procesa los archivos uno por uno: ves cómo avanza la barra de progreso, archivo por archivo, sin acelerar nunca.

Causa raíz. La mayoría de los pipelines de OCR se escriben como bucles simples: for file in files: ocr(file). Esto es monohilo por defecto. Las CPU modernas tienen 4, 8 o 16 núcleos, pero un bucle secuencial usa exactamente uno de ellos. Los demás núcleos permanecen inactivos mientras las páginas se acumulan en la cola.

La solución es eminentemente paralela: el OCR de una página es independiente del OCR de cualquier otra página. No hay estado compartido que sincronizar. Esto significa que puedes procesar N páginas simultáneamente en una máquina de N núcleos y, en teoría, lograr un rendimiento N veces mayor. En la práctica, la escalabilidad es casi lineal hasta 4-8 núcleos, con rendimientos decrecientes más allá debido al ancho de banda de la memoria y la contención de E/S.

La solución. Envuelve tu llamada de OCR en un marco de ejecución paralela:

• GNU Parallel (Linux/macOS): El enfoque más simple para pipelines basados en scripts. parallel -j 4 ocrmypdf {} output/{} ::: *.pdf ejecuta cuatro procesos de OCR simultáneamente.
• Multiprocesamiento en Python: Usa multiprocessing.Pool para distribuir archivos entre procesos trabajadores. Cada trabajador obtiene su propia instancia del motor de OCR y los resultados se recopilan a medida que se completan.
• Herramientas de procesamiento por lotes: Herramientas de OCR por lotes dedicadas como OCRmyPDF admiten el procesamiento paralelo integrado. Su parámetro --jobs controla la concurrencia. Combinarlo con GNU Parallel (limitando el paralelismo a 2 trabajos para evitar la saturación de E/S) es un patrón de producción documentado.

La consideración práctica clave: cada trabajador paralelo necesita suficiente memoria para contener la imagen de su página y los búferes intermedios. Ejecutar 8 trabajadores en una máquina con 8 GB de RAM provocará intercambio (swapping). Un punto de partida seguro es 2 GB de RAM por trabajador paralelo para imágenes de documentos estándar. Escala el paralelismo para que coincida con tu presupuesto de memoria antes de alcanzar el límite de núcleos de tu CPU.

Para ver un tutorial completo sobre cómo configurar pipelines por lotes en paralelo, consulta nuestra guía sobre procesamiento por lotes de múltiples archivos.

Cuándo escalar — Cambia de herramienta en lugar de ajustar

Si has revisado las tres causas — tu GPU está activa, tus imágenes tienen el tamaño correcto y tu pipeline se ejecuta en paralelo — pero el procesamiento sigue siendo demasiado lento para tu carga de trabajo, el cuello de botella puede ser arquitectónico, no de configuración.

Tres señales indican que es momento de considerar un enfoque fundamentalmente diferente:

1. Tu volumen es constantemente alto. Si procesas 500+ páginas al día y el tiempo de finalización de lotes es un problema recurrente, ajustar un pipeline local de OCR siempre quedará por detrás de lo que puede ofrecer un servicio en la nube diseñado para ello. Los servicios de extracción en la nube se ejecutan en clústeres de GPU de nivel servidor con balanceo de carga automático — un solo lote puede distribuirse entre docenas de trabajadores paralelos sin que aprovisiones hardware.

2. Tus documentos son diversos y no están procesados. Un pipeline optimizado para PDFs escaneados limpios tendrá dificultades con fotos de teléfono, recibos arrugados o documentos con escritura a mano. Cada nuevo tipo de entrada requiere diferentes parámetros de preprocesamiento. ImageToTable.ai utiliza modelos de lenguaje-visión que leen documentos semánticamente — interpretando el diseño de la página de la misma manera que lo haría un humano, sin necesidad de ajustes por tipo de documento. No necesita un paso de preprocesamiento separado para normalizar la resolución porque el pipeline en la nube maneja el escalado automáticamente antes de la inferencia.

3. Necesitas resultados en minutos, no en horas. Si un lote de 300 páginas debe procesarse y exportarse durante una pausa para el almuerzo, un pipeline local secuencial — incluso uno ajustado para velocidad — no lo logrará. El procesamiento por lotes en la nube se paraleliza en todo el volumen de documentos. Un lote de 300 páginas que toma 3–4 horas en una máquina con una sola CPU puede completarse en 5–10 minutos en infraestructura en la nube que ejecuta el mismo trabajo en 20–40 trabajadores GPU paralelos.

Preguntas Frecuentes

¿Tesseract es más rápido que EasyOCR?

En CPU, Tesseract suele ser más rápido: aproximadamente 0,8 segundos por página frente a los 2,5 segundos de EasyOCR para texto impreso limpio. En GPU, la comparación se invierte: EasyOCR en una GPU NVIDIA procesa unas 0,6 segundos por página, igualando o superando el rendimiento de Tesseract, con una precisión significativamente mayor en imágenes degradadas, anotaciones manuscritas y diseños mixtos. La conclusión práctica: si tienes GPU, usa EasyOCR (o PaddleOCR). Si solo tienes CPU, Tesseract ofrece mejor rendimiento para documentos limpios, pero espera menor precisión en entradas complejas.

¿Qué resolución de imagen es mejor para la velocidad de OCR?

200–300 DPI es el punto óptimo para la mayoría de los motores de OCR. Por debajo de 150 DPI, la precisión del reconocimiento de caracteres disminuye notablemente, especialmente para fuentes pequeñas. Por encima de 400 DPI, pagas de 2 a 4 veces más tiempo de procesamiento para una ganancia de precisión nula o insignificante. Para un documento tamaño carta estándar (8,5"×11"), 200 DPI produce una imagen de aproximadamente 1700×2200 píxeles, unos 3,7 megapíxeles. Esto es mucho más pequeño que una foto típica de smartphone y se procesará en una fracción del tiempo.

¿Puedo usar varias GPU para acelerar el OCR?

Sí, si tu motor de OCR lo admite y tu carga de trabajo es lo suficientemente grande como para beneficiarse. PaddleOCR y EasyOCR se pueden distribuir entre varias GPU asignando diferentes lotes de documentos a distintas instancias de GPU. En la práctica, una sola GPU moderna (RTX 3090 o superior) ya procesa entre 150 y 190 páginas por minuto para documentos estándar, por lo que las configuraciones de múltiples GPU solo son necesarias para volúmenes muy altos (más de 10 000 páginas al día). El principal cuello de botella a esa escala pasa de la computación a la E/S (lectura de archivos, escritura de resultados), por lo que una configuración de múltiples GPU debe combinarse con almacenamiento rápido (SSD NVMe) y suficiente RAM.

¿Cuánto más rápido es GPU vs CPU para OCR?

Para un motor OCR basado en aprendizaje profundo como EasyOCR o PaddleOCR, la aceleración por GPU suele ofrecer una aceleración de 3 a 7 veces frente al procesamiento solo con CPU, según el modelo de GPU y las características de la imagen. En una NVIDIA T4 (una GPU en la nube común), EasyOCR funciona aproximadamente 4 veces más rápido que su alternativa en CPU. En GPU de consumo como la RTX 3090, PaddleOCR alcanza más de 190 páginas por minuto, una mejora de 5 a 7 veces frente a una CPU de 4 núcleos ejecutando el mismo proceso. Tesseract no admite aceleración por GPU, por lo que su velocidad depende totalmente del rendimiento de la CPU y no es directamente comparable.

¿Reducir el tamaño de la imagen reduce la precisión del OCR?

Reducir el tamaño de la imagen solo reduce la precisión si se baja de la resolución mínima que el motor OCR necesita para leer caracteres pequeños. Para la mayoría de documentos impresos, 200 DPI son suficientes para una precisión de caracteres superior al 99%. Por debajo de 150 DPI, se pueden perder detalles finos: notas al pie en fuente de 8pt, puntos decimales y caracteres en subíndice. El enfoque seguro es redimensionar a una resolución objetivo de 200–300 DPI: esto conserva la legibilidad mientras elimina los 4–5 megapíxeles de datos redundantes que solo ralentizan el procesamiento. Si tus documentos contienen texto muy pequeño (p. ej., letra pequeña legal de 6–8pt), usa 300 DPI como mínimo.

¿Cuándo debo dejar de ajustar y cambiar a otra herramienta?

Cuando el tiempo de procesamiento por lotes está dominado por la sobrecarga del proceso — preprocesamiento, E/S de archivos y serialización — en lugar del motor OCR en sí, has alcanzado el límite práctico del ajuste local. Señales de que es hora de cambiar: ya implementaste aceleración por GPU, normalización de resolución y procesamiento paralelo, pero un lote de 300 páginas aún tarda más de una hora; o tus documentos son tan diversos (fotos de teléfono, escaneos, capturas de pantalla, escritura a mano mezclada) que los parámetros de preprocesamiento necesitan ajuste por página. En estos casos, un servicio de extracción en la nube que paraleliza entre trabajadores GPU y lee documentos semánticamente — sin ajuste por tipo — superará a un proceso local ajustado tanto en velocidad como en precisión.