Benchmark de Latencia OCR
p50/p95, Rendimiento y Picos de Cola (2026)

Tres medidas, una página: p50, p95 y páginas/min

Esta página reporta tres medidas de las mismas ejecuciones, y responden a diferentes preguntas. p50 (la mediana) es el tiempo de inferencia por página en estado estable en modo warm_then_scored — una pasada de calentamiento fija precede a la pasada puntuada, y la carga del modelo se excluye — por lo que responde a “¿qué tan rápido es este motor por página una vez que ya está en funcionamiento?” p95 es la misma medición en el percentil 95: el 5% de las páginas tardó más que esto. Páginas por minuto es el rendimiento en tiempo real incluyendo la inicialización del modelo — el número que gobierna los trabajos por lotes y las horas de GPU facturadas.

Las tres medidas no son intercambiables y no se espera que coincidan. El p50 en estado estable excluye la carga del modelo; las páginas/min en tiempo real la incluyen; el p95 captura los efectos de la primera página/prefill y el comportamiento de programación por lotes que el p50 ignora. Cada gráfico y tabla en esta página indica qué medida muestra — trate “108.7 ms” (p50, sin carga) y “449 páginas/min” (tiempo real, con carga) como dos hechos diferentes sobre docTR, no una contradicción.

Tres términos utilizados a lo largo: latencia de cola es el comportamiento del pequeño porcentaje más lento de páginas (p95 y más allá) — para un usuario esperando una sola página, la cola, no la mediana, decide la experiencia. Efecto de primera página/prefill es el costo único de preparar un modelo o pipeline antes de la inferencia estable, que se manifiesta como muestras iniciales lentas en una ejecución. Rendimiento en tiempo real cuenta cada milisegundo de la ejecución, incluyendo la inicialización. En el protocolo de este benchmark, p50/p95 son mediciones en estado estable y páginas/min es en tiempo real — la diferencia entre ellos es la inicialización más la sobrecarga de programación.

SROIE 2019: Clasificación de Latencia Mediana por Página

En 361 recibos en inglés, los motores OCR tradicionales de dos etapas ocupan el extremo rápido y los VLMs de análisis de documentos el extremo lento — pero la dispersión dentro de cada familia es la sorpresa. docTR (108.7 ms) es 2.7× más rápido que el siguiente motor tradicional (PaddleOCR, 297.0 ms), y los dos motores más lentos son ambos VLMs (Unlimited-OCR 1,600.7 ms, Surya2 2,668.0 ms). Sin embargo, el VLM más rápido, PaddleOCR-VL con 694.3 ms, sigue siendo más lento que todos los motores tradicionales.

Fuente: summary_metrics.csv — columna latency_p50_ms, filas sroie_2019. docTR 108.7, PaddleOCR 297.0, EasyOCR 413.6, Tesseract 670.9 (solo CPU), PaddleOCR-VL 694.3, Docling 732.0, Unlimited-OCR 1600.7, Surya2 2668.0. Latencia en estado estable, modo de medición calentado y luego evaluado (excluye carga del modelo).

Tabla: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, filas sroie_2019 (361 muestras cada una, error_rate 0.0 para las 8). Las relaciones p95/p50 se calcularon dividiendo los valores del CSV (ej., 3331.3505 / 296.9897 = 11.22). Tesseract se ejecutó solo en CPU (compute_type=cpu); los demás en GPU. La latencia en estado estable excluye la carga del modelo; páginas/min es el tiempo real incluyendo la inicialización.

El patrón de arquitectura es claro a nivel de familia — los motores tradicionales ocupan los puestos 1–4, los VLM los puestos 5, 7, 8, con Docling (un analizador de canalización, no un motor OCR puro ni un VLM) en medio — pero la brecha dentro de cada familia es amplia. El clúster VLM abarca 3,8× (694,3 a 2.668,0 ms) y el clúster tradicional 6,2× (108,7 a 670,9 ms), lo que significa que “VLM” y “tradicional” no son categorías de latencia — el diseño individual del motor decide mucho más que la pertenencia a la familia.

p50 Oculta la Cola: Relaciones p95/p50 Entre Motores

La mediana es un mal predictor del peor caso. El p95 de PaddleOCR en SROIE (3.331,4 ms) es 11,2× su p50 (297,0 ms) — el 5% de las páginas tardó más de 3,3 segundos aunque la página mediana tardó menos de 300 ms. Para cargas de trabajo interactivas, esta relación, no el p50, decide si un usuario espera 0,3 segundos o 3,3. El p95 de docTR (281,4 ms) se mantiene ajustado en 2,6× su p50.

El mecanismo es el efecto de primera página/prefill: los motores GPU pagan un costo de inicialización único antes de la inferencia estable, y la programación por lotes puede serializar muestras lentas. Ese es un comportamiento específico del protocolo — estos valores p95 reflejan el patrón de ejecución de esta referencia (división de prueba fija, calentamiento y luego puntuación), no una propiedad universal de los motores. Lo que muestran los datos es la forma de la cola de cada motor bajo este protocolo: PaddleOCR y Docling tienen colas largas y pesadas en SROIE; docTR, EasyOCR y Unlimited-OCR mantienen las suyas cerca de la mediana.

Fuente: calculado a partir de summary_metrics.csv — latency_p95_ms ÷ latency_p50_ms, filas sroie_2019 (relación derivada por división de los valores publicados, por ejemplo, 3331,3505 / 296,9897 = 11,22). PaddleOCR 11,2×, Docling 4,4×, docTR 2,6×, EasyOCR 2,3×, Tesseract 2,2×, Surya2 2,2×, PaddleOCR-VL 1,7×, Unlimited-OCR 1,6×.

Observe lo que la relación no dice: una relación p95/p50 ajustada no es una afirmación de velocidad. Unlimited-OCR tiene la cola más ajustada de la referencia (1,6×) — pero su p50 (1.600,7 ms) y su p95 (2.521,9 ms) son ambos mucho más lentos que el p95 de docTR (281,4 ms). La relación mide la forma de la distribución, no dónde se sitúa la distribución. Lea los dos números juntos: una cola ajustada alrededor de una mediana lenta sigue siendo lenta.

El rendimiento cuenta otra historia: páginas/min vs p50

Al clasificar los motores por páginas por minuto, el orden cambia. Los 449.3 páginas/min de docTR frente a los 12.1 de Surya2 representan una diferencia de 37× — mayor que la diferencia de 24.5× en p50. Pero PaddleOCR, con una cola p95 de 11.2×, aún mantiene 79.7 páginas/min: cerca de los 124.5 de EasyOCR, por delante de los 68.2 de PaddleOCR-VL y los 56.7 de Docling. Una mediana lenta y una cola pesada no impiden un rendimiento por lotes respetable.

La reconciliación está en la base de medición: las páginas/min son el rendimiento de tiempo real que incluye la inicialización del modelo y la programación, mientras que el p50 es la inferencia de una página en estado estable que excluye la carga. La tabla a continuación convierte las páginas/min en el tiempo real promedio por página que implica (60,000 ÷ páginas/min — una estimación derivada, no una cifra medida) y muestra la diferencia con el p50. El tiempo real por página implícito de PaddleOCR (752.7 ms) es 2.5× su p50 en estado estable (297.0 ms); el de Surya2 (4,940.0 ms) es 1.9× su p50 (2,668.0 ms). La sobrecarga — inicialización, programación, costos por llamada del pipeline — es invisible en el p50 por sí solo, por lo que un p50 bajo no significa automáticamente un alto rendimiento.

Tabla: summary_metrics.csv — filas latency_p50_ms / pages_per_minute, sroie_2019. El reloj real ms/página es una estimación derivada (60,000 ÷ pages_per_minute, por ejemplo, 60,000 / 79.7130 = 752.7) — un cálculo aritmético sobre el rendimiento medido, no una cifra medida por separado. Sobrecarga = reloj real derivado ÷ p50 medido. Páginas/min es el reloj real incluyendo la inicialización del modelo; p50 es el estado estable excluyendo la carga.

Una segunda nota de conciliación en los extremos: Tesseract, el único motor de CPU, mantiene 78.6 páginas/min en SROIE — prácticamente igualando las 79.7 de PaddleOCR en GPU — con su p50 (670.9 ms, CPU) y reloj real (763.0 ms) casi idénticos, porque un motor de CPU de un solo hilo tiene poca sobrecarga de inicialización que ocultar. Su p95 (1,507.0 ms) es 2.2× su p50 — una de las colas más ajustadas del benchmark. La paridad de rendimiento CPU-vs-GPU se analiza en detalle en Tesseract vs PaddleOCR.

Interactivo vs por lotes: La lectura del umbral de 1.000 ms

Para un usuario esperando una sola página, 1.000 ms es un límite útil — aproximadamente el borde de lo que se siente receptivo. Leyendo en p50, seis de ocho motores se mantienen por debajo en SROIE: docTR (108,7 ms), PaddleOCR (297,0 ms), EasyOCR (413,6 ms), Tesseract (670,9 ms, CPU), PaddleOCR-VL (694,3 ms), Docling (732,0 ms). Solo Unlimited-OCR (1.600,7 ms) y Surya2 (2.668,0 ms) lo superan en la mediana.

Leyendo en p95, la imagen se invierte: solo dos motores siguen por debajo de 1 segundo — docTR (281,4 ms) y EasyOCR (960,4 ms). La cola de todos los demás motores lo supera: PaddleOCR 3.331,4 ms, Docling 3.239,8 ms, Unlimited-OCR 2.521,9 ms, Tesseract 1.507,0 ms, PaddleOCR-VL 1.154,3 ms, Surya2 5.872,2 ms (summary_metrics.csv latency_p95_ms, sroie_2019 rows). Si “interactivo” significa que el peor caso debe sentirse receptivo, la cola — no la mediana — es el criterio de selección, y solo dos motores califican.

El procesamiento por lotes es el otro régimen, y cambia la economía a favor de los motores. La inicialización del modelo se paga una vez por proceso/lote, por lo que el procesamiento secuencial o por lotes amortiza el costo de inicialización en más páginas — la latencia por página y el costo por página disminuyen a medida que crece el tamaño del lote. Este es un argumento derivado de la base de medición (páginas/min incluye init; p50 lo excluye), no una nueva ejecución de benchmark — el mismo razonamiento y su aritmética desarrollada aparecen en la página de costos del método.

CORD (Recibos Indonesios): Misma Historia, Colas Diferentes

Cambie el conjunto de documentos y las clasificaciones se mantienen aproximadamente — docTR sigue siendo el más rápido y Surya2 el más lento — pero el cambio de idioma remodela las colas. En CORD v2, el p95 de Surya2 se dispara a 26,976.9 ms (≈27 s), 18.2× su propio p50 (1,485.3 ms) y el evento de cola extrema del benchmark — mientras que su relación de cola en SROIE fue modesta de 2.2×. El contenido del idioma cambia el comportamiento de las colas; un VLM estable en recibos en inglés puede dispararse a esperas de medio minuto en recibos en indonesio.

CORD v2 es un conjunto de datos en indonesio con campos anidados (menu, sub_total, total); ninguno de los 8 motores fue entrenado predominantemente en indonesio, por lo que también sirve como una prueba de estrés entre idiomas. Sus recibos son más cortos y menos densos en texto que los de SROIE, razón por la cual la mayoría de los motores se vuelven más rápidos aquí — docTR baja a 100.4 ms p50 (500.4 páginas/min), PaddleOCR a 108.2 ms p50 (141.0 páginas/min). CORD se mantiene deliberadamente separado de la clasificación de SROIE en este benchmark (diferente idioma, diferente estructura de ground-truth); el punto de esta tabla es que la latencia se mueve con el conjunto de documentos y la cola puede moverse drásticamente.

Fuente: summary_metrics.csv — columna latency_p50_ms, filas cord_v2. docTR 100.4, PaddleOCR 108.2, EasyOCR 192.8, PaddleOCR-VL 249.3, Docling 338.0, Tesseract 474.6 (solo CPU), Unlimited-OCR 608.2, Surya2 1485.3. Latencia en estado estable, calentado y evaluado (excluye carga del modelo).

Tabla: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, filas cord_v2 (100 muestras cada una). Las relaciones p95/p50 se calcularon dividiendo los valores del CSV (p. ej., 26976.9306 / 1485.3493 = 18.16). Tesseract se ejecutó solo con CPU. La latencia en estado estable excluye la carga del modelo; las páginas/min incluyen el tiempo de inicialización.

El p95 de Surya2 en CORD de 26.976,9 ms es el mayor evento de cola en todo el benchmark — una de cada veinte páginas tardó unos 27 segundos en un conjunto de datos donde su mediana era de 1,5 segundos. Para contextualizar, esto es 114× el p95 de docTR en CORD (235,9 ms). Dos motores que fueron casi idénticos en SROIE (relaciones de cola de 2,2× para Surya2 y 1,6× para Unlimited-OCR) divergen drásticamente en CORD (18,2× vs 2,4×) — un recordatorio de que el comportamiento de cola es una propiedad de la combinación motor × documento, no del motor solo.

Latencia y Costo se Miden en el Mismo Reloj

Dado que las GPUs alquiladas se facturan por hora de reloj, la latencia y el costo son la misma medición vista dos veces: docTR es tanto el motor más rápido (108,7 ms p50) como el más barato (cost_per_1000_pages 0,0479 en SROIE); Surya2 es tanto el más lento (2.668,0 ms p50) como el más caro (1,0609) — misma división, misma tarifa. Los VLMs pesados son lentos y caros juntos; los motores tradicionales ligeros son rápidos y baratos juntos.

La correlación no es exacta, porque el costo sigue las páginas/min de reloj (que incluye la inicialización) mientras que el p50 la excluye — el p50 de PaddleOCR (297,0 ms) es más rápido que el de EasyOCR (413,6 ms), sin embargo el costo por 1.000 páginas de PaddleOCR (0,2214) es aproximadamente el doble que el de EasyOCR (0,1098) porque su rendimiento de reloj es mucho menor (79,7 vs 124,5 páginas/min; summary_metrics.csv cost_per_1000_pages / pages_per_minute, filas sroie_2019). La clasificación completa de costos, la fórmula de costos y la aritmética detrás de ella se encuentran en la página hermana Costo OCR por 1.000 Páginas — esta página mantiene su enfoque en la latencia y solo toma prestada la correlación.

Preguntas Frecuentes

¿Cuál es el motor OCR más rápido por página?

docTR fue el más rápido en esta referencia: 108.7 ms p50 y 281.4 ms p95 por página en SROIE 2019 (summary_metrics.csv latency_p50_ms / latency_p95_ms, fila doctr/sroie_2019), manteniendo 449.3 páginas/min. El más lento medido, Surya2, fue 24.5× más lento en p50 (2,668.0 ms) y 37× más lento en rendimiento (12.1 páginas/min).

¿Cuál es una latencia OCR típica por página en una GPU?

Entre 108.7 ms (docTR) y 2,668.0 ms (Surya2) p50 por página en 8 motores de código abierto en una RTX 4090, recibos de SROIE 2019 (summary_metrics.csv latency_p50_ms, filas sroie_2019) — un rango de 24.5× en hardware idéntico. Estado estable, precalentado y luego evaluado, excluyendo la carga del modelo. Los mismos motores en CORD v2 abarcan de 100.4 a 1,485.3 ms p50.

¿Por qué la latencia p95 de OCR es mucho mayor que la p50?

Debido al efecto de la primera página/prefill y al comportamiento de programación por lotes: los motores GPU pagan costos de inicialización únicos y las muestras lentas pueden serializarse, por lo que el 5% más lento de las páginas — por definición del percentil 95 — se aleja mucho de la mediana. El p95 de PaddleOCR en SROIE (3,331.4 ms) es 11.2× su p50 (297.0 ms); el p95 de docTR (281.4 ms) es solo 2.6× su p50 (summary_metrics.csv latency_p95_ms / latency_p50_ms, filas sroie_2019). Los valores p95 son específicos del protocolo — reflejan el patrón de ejecución de esta referencia, no una propiedad universal del motor.

¿Por qué la latencia de OCR y las páginas por minuto no coinciden?

Porque son mediciones diferentes. Las páginas/min son el rendimiento de reloj de pared incluyendo la inicialización del modelo y la programación; el p50 es la inferencia por página en estado estable excluyendo la carga del modelo. En SROIE, el p50 de PaddleOCR (297.0 ms) implica aproximadamente 200 páginas/min en estado estable puro, pero el rendimiento medido es de 79.7 páginas/min — un tiempo de reloj de pared derivado de 752.7 ms por página, 2.5× su p50 (summary_metrics.csv latency_p50_ms / pages_per_minute, fila paddleocr/sroie_2019). Para trabajos por lotes, planifique en función de páginas/min; para esperas interactivas, en función de p50 y p95.

¿Qué es una buena latencia de OCR para uso interactivo?

Menos de 1,000 ms en el percentil 95 es el umbral práctico. En SROIE, seis de ocho motores se mantienen bajo 1 segundo en p50 (docTR 108.7, PaddleOCR 297.0, EasyOCR 413.6, Tesseract 670.9, PaddleOCR-VL 694.3, Docling 732.0 ms), pero solo docTR (281.4 ms) y EasyOCR (960.4 ms) mantienen su p95 bajo 1 segundo (summary_metrics.csv latency_p50_ms / latency_p95_ms, filas sroie_2019). Si el peor caso debe parecer receptivo, decide el p95; si el caso típico es suficiente, decide el p50.

¿Por qué un motor de OCR tardó 27 segundos en un recibo?

El p95 de Surya2 en CORD v2 fue de 26,976.9 ms (≈27 s) — 18.2× su propio p50 (1,485.3 ms) y el evento de cola más grande en el benchmark (summary_metrics.csv latency_p95_ms / latency_p50_ms, fila surya2/cord_v2). Su cola en SROIE fue modesta de 2.2×, por lo que el pico es específico de la combinación motor × CORD — el contenido del idioma y la programación cambiaron el comportamiento de la cola, no solo la mediana.

¿Es Tesseract OCR lo suficientemente rápido sin una GPU?

En CPU, Tesseract mantuvo 78.6 páginas/min en SROIE 2019 con un p50 de 670.9 ms — más lento que los motores tradicionales con GPU pero más rápido que los tres VLMs en rendimiento (PaddleOCR-VL 68.2, Docling 56.7, Unlimited-OCR 34.4, Surya2 12.1 páginas/min) y con una cola ajustada (2.2×). Es solo CPU en este benchmark (summary_metrics.csv fila tesseract/sroie_2019); si es “suficientemente rápido” depende de su volumen y si necesita campos en lugar de texto — vea el perfil de costo en CPU en Tesseract vs PaddleOCR.

¿El OCR se vuelve más rápido por página a medida que procesa más páginas?

Sí, hasta un límite de estado estable — como un efecto derivado de la base de medición, no una nueva ejecución. La inicialización del modelo se paga una vez por proceso/lote (está dentro de páginas/min pero fuera del p50), por lo que el procesamiento por lotes o secuencial lo amortiza: a alto volumen, el tiempo de reloj por página se acerca al p50 de estado estable más la programación. Los números de docTR en SROIE ya están cerca de ese límite (p50 108.7 ms vs reloj derivado 133.5 ms por página); los de Surya2 (p50 2,668.0 vs 4,940.0 ms) muestran más sobrecarga de inicialización por amortizar.

¿De dónde provienen los números de latencia de esta página?

Cada cifra es una fila del results/summary_metrics.csv publicado del benchmark de primera parte (latency_p50_ms, latency_p95_ms, pages_per_minute) alojado en ImageToTableai/benchmark-ocr, con un manifest.json redactado por ejecución que registra el modo de medición (warm_then_scored), las versiones del modelo y las huellas del entorno. Las definiciones de los conjuntos de datos provienen de los artículos SROIE 2019 y CORD citados a continuación.

Metodología y Fuentes

Protocolo

Esta página reporta la dimensión de latencia de una ejecución de benchmark independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros. Solo se usaron divisiones de prueba fijas: SROIE 2019 test (361 recibos en inglés, campos planos empresa/dirección/fecha/total) y CORD v2 test (100 recibos en indonesio, campos anidados menú/sub_total/total); las divisiones de entrenamiento nunca fueron evaluadas. Cada par (motor × conjunto de datos) reutilizó las mismas imágenes, la misma verdad de referencia y el mismo protocolo de medición (warm_then_scored: un pase de calentamiento fijo precede al pase de puntuación). Las 16 ejecuciones completadas tuvieron error_rate 0.0 (columna error_rate de summary_metrics.csv). Los datos fueron recopilados en agosto de 2026.

Entorno de Ejecución

• Hardware: todas las ejecuciones en GPU se realizaron en una única NVIDIA RTX 4090 (24 GB). Tesseract se ejecutó solo en CPU (compute_type=cpu) y está etiquetado como tal en cada tabla. Un solo nivel de GPU, una ubicación/hora — la declaración de rango en esta página.
• Motores: todos los modelos se ejecutaron fuera de la caja, sin ajuste fino. Versiones bloqueadas según los manifiestos de ejecución: Tesseract 5.3.4, PaddleOCR 3.7.0, EasyOCR 1.7.2, docTR v1.0.1, Docling 2.119.0, Surya2 0.22.1, Unlimited-OCR vLLM-served, PaddleOCR-VL 1.6.
• Modo de medición: warm_then_scored — las cifras de latencia son la inferencia por página en estado estable, excluyendo la carga del modelo; las páginas/min incluyen el tiempo de pared con la inicialización del modelo (el performance.run_wall_time_ms de cada ejecución en los manifiestos redactados).
• Nivel de ejecución: las 16 ejecuciones son official; solo las ejecuciones oficiales son elegibles para publicación según el protocolo del benchmark (reports/receipt_v1_official_protocol.md).

Definición de Métricas

• p50 (latencia mediana): el tiempo de inferencia mediano por página en estado estable — el 50% de las páginas fue más rápido. Excluye la carga del modelo (calentar-para-puntuar).
• p95 (latencia de cola): el percentil 95 del tiempo de inferencia por página — el 5% de las páginas tardó más. Refleja los efectos de la primera página/prefill y el comportamiento de programación por lotes bajo el protocolo de esta ejecución; específico del protocolo, no una constante universal del motor.
• Relación p95/p50: obtenida por división de las dos columnas CSV (por ejemplo, 3331.3505 / 296.9897 = 11.22). Un indicador de forma de la cola, no una afirmación de velocidad.
• Páginas por minuto: rendimiento de reloj de pared incluyendo la inicialización del modelo. El lote de trabajos y la vista de facturación.
• ms/página de reloj de pared (derivado): 60,000 ÷ páginas/min — aritmética sobre el rendimiento medido, etiquetado como una estimación derivada, no una cifra medida.

Lista de Fuentes

1. summary_metrics.csv (GitHub raw). 16 filas = 8 motores × 2 conjuntos de datos de recibos (sroie_2019, cord_v2). Las columnas incluyen latency_p50_ms, latency_p95_ms, pages_per_minute, compute_type, error_rate. Cada cifra de latencia y rendimiento en esta página se remonta a una fila aquí.
2. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que alberga los CSV de resultados, manifiestos de ejecución redactados, protocolo congelado (reports/receipt_v1_official_protocol.md) y listas de muestras de conjuntos de datos (divisiones de prueba fijas) para reproducción.
3. results/manifests/ (GitHub). Un manifest.json redactado por cada ejecución publicada (16 ejecuciones) con la huella del entorno, versiones del modelo, modo de medición (warm_then_scored), tiempo de reloj de pared y hashes de artefactos.
4. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definición del conjunto de datos SROIE 2019, estructura de tareas y licencia (CC-BY-4.0).
5. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definición del conjunto de datos CORD v2, esquema de campos anidados y licencia (CC-BY-4.0).

Limitaciones

• Un solo nivel de GPU, un solo lugar/hora: todas las cifras de GPU provienen de una sola RTX 4090 en un solo sitio, recopiladas en agosto de 2026. Otras GPUs, servicio multi-GPU y diferentes programaciones cambian la latencia y el rendimiento; mida en su propio hardware antes de comprometerse.
• Solo recibos: recibos de SROIE (inglés) y CORD (indonesio). La latencia en facturas, formularios, contratos o documentos largos no está medida; las clasificaciones anteriores no son generalizables más allá de los recibos — y los resultados de CORD no se fusionan en la clasificación de SROIE.
• El p95 es específico del protocolo: los valores de p95 reflejan efectos de primera página/prefill y la programación por lotes bajo el patrón de ejecución de esta referencia (divisiones fijas de 361/100 páginas, calentado y luego puntuación). Son una lectura de la forma de esta ejecución, no una garantía universal del peor caso.
• p50/p95 excluyen la carga del modelo, páginas/min la incluye: las dos bases son deliberadamente diferentes (inferencia en estado estable vs rendimiento en tiempo real) y nunca se presentan como el mismo número. El tiempo real derivado por página (60,000 ÷ páginas/min) es aritmético sobre el rendimiento medido, no una cifra medida por separado.
• Asimetría CPU/GPU: Tesseract (CPU) se compara con motores acelerados por GPU; su latencia refleja hardware CPU. Está marcado en cada tabla, pero la asimetría es inherente a la comparación.
• Sin modelos en la nube/API: AWS Textract, Google Document AI, Azure AI Document Intelligence y APIs de OCR/VLM alojadas no están incluidos; sus modelos de latencia (red, medición por llamada, autoescalado) difieren fundamentalmente de los motores locales medidos aquí.
• Sin barrido de tamaño de lote: la amortización de inicialización se deriva de la base de medición (páginas/min incluye la inicialización, p50 la excluye) y se referencia cruzada con el método de la página de costos — no se ejecutó ningún experimento de tamaño de lote, por lo que el escalado por lote es una estimación, no una medición.
• Tamaño de muestra y fijación de versiones: 361 + 100 muestras; los resultados son válidos para las versiones de modelo de agosto de 2026 listadas arriba. Versiones más nuevas de los motores pueden cambiar la latencia; diferencias de un solo dígito porcentual deben tratarse como ruido.

Referencias relacionadas: Costo de OCR por 1,000 Páginas · OCR Tradicional vs VLMs de Análisis de Documentos · docTR vs Surya2: Empate en CER, Brecha de Costos · docTR vs Docling: Pasada Única vs Pipeline · Tesseract vs PaddleOCR: CPU Heredada vs GPU Moderna

Lecturas relacionadas: Precisión de AI OCR vs OCR Tradicional · Extracción de Datos de Imágenes con AI vs OCR Tradicional · Precios de Extracción de Documentos con AI (2026)