"¿Por qué el OCR es tan lento?"
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 flujo de procesamiento de alta exigencia computacional

Síntoma. Su CPU alcanza el 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 flujo está saturado.

Causa raíz. No todos los motores OCR son iguales por dentro. Tesseract, el referente de código abierto mantenido por Google, es un motor puramente basado en CPU. Utiliza flujos de visión por computadora tradicionales: 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 benchmark de 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. Doloroso a 500.

EasyOCR adopta un enfoque arquitectónico diferente. Su red neuronal 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ápida. Pero aquí está el detalle que la mayoría pasa por alto: EasyOCR vuelve a la CPU automáticamente si no detecta una GPU compatible. En CPU, el mismo flujo de aprendizaje profundo que hace preciso a EasyOCR también lo hace de tres a cuatro veces más lento que en modo GPU. Los benchmarks en una NVIDIA T4 muestran EasyOCR en GPU alcanzando ~0,6 segundos por página — comparable a Tesseract — mientras que EasyOCR en CPU se estira a ~2,5 segundos por página.

La solución. Compruebe si su flujo de OCR está utilizando realmente una GPU:

• Para EasyOCR, verifique que reader = easyocr.Reader(['en'], gpu=True) realmente detecta CUDA. Si la biblioteca retrocede silenciosamente, su tiempo por página se duplicará con creces. Ejecute nvidia-smi durante el procesamiento: si la utilización de la GPU muestra 0%, su flujo está funcionando en CPU.
• Para Tesseract, no hay interruptor de GPU — simplemente no admite aceleración por GPU. Si está procesando más de unos pocos cientos de páginas, considere cambiar a un motor compatible con GPU.
• Los motores OCR dedicados como PaddleOCR están construidos para GPU desde el principio. Los benchmarks 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 su 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 OCR en la nube que procese documentos en infraestructura respaldada por GPU — sin requerir que usted aprovisione el hardware — evita el problema por completo.

Para una comparación lado a lado de motores OCR compatibles con GPU, consulte nuestro resumen de las mejores herramientas OCR de código abierto.

Causa #2: Imágenes Mucho Más Grandes de lo que el OCR Realmente Necesita

Síntoma. El procesamiento se ralentiza en páginas que a usted le parecen perfectamente legibles. Una foto de 12 megapíxeles de un recibo tomada con el teléfono 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. Si duplica la resolución en cada eje — de 150 DPI a 300 DPI — cuadruplica el recuento de píxeles: 2 veces el ancho por 2 veces la altura. Cuadruplicar la entrada significa aproximadamente 4 veces el tiempo de procesamiento para el mismo contenido. Una foto de teléfono inteligente de 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 el ajuste del rendimiento del 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, usted está pagando tiempo de cómputo sin una ganancia medible en precisión. El mismo principio se aplica a cualquier motor de OCR, de código abierto o propietario.

La solución. Agregue 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 sencillo pipeline 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 en un 40–70% dependiendo de sus imágenes de origen, sin ningún impacto en la precisión de la extracción. Para una guía completa sobre la preparación de imágenes — incluyendo binarización, corrección de inclinación y normalización de contraste — lea nuestra guía de preprocesamiento de imágenes para OCR.

Causa #3: Procesamiento secuencial cuando podría ejecutarse en paralelo

Síntoma. El uso de la CPU se mantiene alrededor del 30–40% durante una ejecución por lotes. El pipeline procesa los archivos uno a la vez: usted observa cómo avanza la barra de progreso, archivo por archivo, sin acelerarse nunca.

Causa raíz. La mayoría de los pipelines de OCR se escriben como bucles simples: for file in files: ocr. Esto es de un solo hilo 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 fácilmente paralelizable: el OCR de una página es independiente del OCR de cualquier otra página. No hay estado compartido que sincronizar. Esto significa que puede procesar N páginas simultáneamente en una máquina de N núcleos y, en teoría, lograr un rendimiento N×. En la práctica, la escalabilidad es casi lineal hasta 4–8 núcleos, con rendimientos decrecientes más allá de eso debido al ancho de banda de memoria y la contención de E/S.

La solución. Envuelva su 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 de Python: Use multiprocessing.Pool para distribuir archivos entre procesos de trabajo. 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: Las herramientas dedicadas de OCR por lotes como OCRmyPDF admiten procesamiento paralelo integrado. Su parámetro --jobs controla la concurrencia. Combinarlo con GNU Parallel (limitando parallel 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. Escale el paralelismo para que coincida con su presupuesto de memoria antes de alcanzar el límite de núcleos de CPU.

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

Cuándo escalar: cambie de herramienta en lugar de ajustar

Si ha verificado las tres causas (su GPU está activa, sus imágenes tienen el tamaño correcto y su canalización se ejecuta en paralelo), pero el procesamiento sigue siendo demasiado lento para su carga de trabajo, el cuello de botella puede ser arquitectónico y no de configuración.

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

1. Su volumen es constantemente alto. Si procesa 500+ páginas al día y el tiempo de finalización de lotes es un punto de dolor recurrente, ajustar una canalización OCR local siempre quedará rezagado frente a lo que puede ofrecer un servicio en la nube diseñado para este fin. Los servicios de extracción en la nube funcionan con clústeres de GPU de grado servidor con balanceo de carga automático: un solo lote puede distribuirse entre docenas de trabajadores en paralelo sin que usted deba aprovisionar ningún hardware.

2. Sus documentos son diversos y no procesados. Una canalización optimizada 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 parámetros de preprocesamiento diferentes. ImageToTable.ai utiliza modelos de visión y lenguaje que leen documentos de forma semántica: interpretan el diseño de la página igual que lo haría una persona, sin necesidad de ajustes por tipo de documento. No requiere un paso de preprocesamiento separado para normalizar la resolución porque la canalización en la nube maneja el escalado automáticamente antes de la inferencia.

3. Necesita resultados en minutos, no en horas. Si un lote de 300 páginas debe procesarse y exportarse durante una pausa para almorzar, una canalización local secuencial — incluso una ajustada para la velocidad — no dará resultados. El procesamiento por lotes en la nube se paraleliza en todo el volumen del documento. Un lote de 300 páginas que tarda 3–4 horas en una máquina equipada 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 en paralelo.

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.