OCR Latency Benchmark
p50/p95, rendimiento y picos de cola (2026)

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

Esta página informa tres medidas de las mismas ejecuciones, y responden a preguntas distintas. p50 (la mediana) es el tiempo de inferencia por página en estado estable en el modo warm_then_scored — una pasada de calentamiento fija precede a la pasada puntuada, y la carga del modelo queda excluida — 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 de reloj, incluida la inicialización del modelo — la cifra que rige 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 de reloj la incluyen; el p95 captura los efectos de primera página/prefill y el comportamiento de programación de lotes que el p50 ignora. Cada gráfico y tabla de esta página indica qué medida muestra — trate “108,7 ms” (p50, sin carga) y “449 páginas/min” (tiempo de reloj, con carga) como dos datos distintos sobre docTR, no como una contradicción.

Tres términos usados en todo el documento: latencia de cola es el comportamiento del pequeño porcentaje de páginas más lento (p95 y más allá) — para un usuario que espera 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 aparece como muestras iniciales lentas en una ejecución. Rendimiento en tiempo de reloj cuenta cada milisegundo de la ejecución, incluida la inicialización. En el protocolo de este benchmark, p50/p95 son mediciones en estado estable y páginas/min es tiempo de reloj — la diferencia entre ambos es la inicialización más la sobrecarga de programación.

SROIE 2019: Ranking 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 VLM 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 VLM (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 con calentamiento previo y luego puntuación (excluye la 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 (p. ej., 3331.3505 / 296.9897 = 11.22). Tesseract se ejecutó solo con CPU (compute_type=cpu); todos los demás en GPU. La latencia en estado estable excluye la carga del modelo; páginas/min es 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 canalizaciones, no un motor OCR puro ni un VLM) en el medio — pero la brecha dentro de cada familia es amplia. El grupo de VLM abarca 3.8× (694.3 a 2,668.0 ms) y el grupo 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 una 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 preparación único antes de la inferencia constante, y la programación por lotes puede serializar muestras lentas. Ese es un comportamiento específico del protocolo — estos valores de p95 reflejan el patrón de ejecución de este benchmark (división de prueba fija, calentamiento y luego evaluació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 de sroie_2019 (relación derivada por división de los valores publicados, p. ej., 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×.

Note 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 del benchmark (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

Clasifique los motores por páginas por minuto y el orden cambia. Los 449.3 páginas/min de docTR frente a los 12.1 de Surya2 suponen una diferencia de 37×, mayor que la de 24.5× en p50. Pero PaddleOCR, con una cola p95 de 11.2×, sigue sosteniendo 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 conciliación es la base de medición: páginas/min es el rendimiento de tiempo real que incluye la inicialización del modelo y la programación, mientras que p50 es la inferencia de una sola página en estado estable, excluyendo la carga. La tabla siguiente convierte 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 frente a p50. El tiempo real implícito por página 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 de canalización por llamada — es invisible en p50 solo, por lo que un p50 bajo no significa automáticamente un alto rendimiento.

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

Una segunda nota de conciliación sobre los extremos: Tesseract, el único motor de CPU, mantiene 78.6 páginas/min en SROIE — prácticamente igualando los 79.7 de PaddleOCR en GPU — con su p50 (670.9 ms, CPU) y su tiempo 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 que espera una sola página, 1,000 ms es un límite útil — aproximadamente el borde de lo que se siente receptivo. Leído 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.

Leído en p95, la imagen se invierte: solo dos motores siguen cabiendo en menos 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, filas sroie_2019). 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 caen 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 referencia — el mismo razonamiento y su aritmética desarrollada aparecen en el método de la página de costos.

CORD (Recibos de Indonesia): 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 reforma 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 extremo del benchmark — mientras que su relación de cola en SROIE fue un modesto 2.2×. El contenido del idioma cambia el comportamiento de las colas; un VLM estable con recibos en inglés puede dispararse a esperas de medio minuto con recibos en indonesio.

CORD v2 es un conjunto de datos en indonesio con campos anidados (menú, subtotal, total); ninguno de los 8 motores fue entrenado predominantemente en indonesio, por lo que funciona como una prueba de estrés entre idiomas. Sus recibos son más cortos y con menos densidad de texto que los de SROIE, por lo que la mayoría de los motores son 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 SROIE en este benchmark (idioma diferente, estructura de ground-truth diferente); 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, cálido y luego puntuado (excluye la 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 calculan 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; páginas/min es tiempo real de pared, incluida la inicialización.

El p95 de CORD de Surya2, de 26 976,9 ms, es el evento de cola más grande del benchmark — una página de cada veinte tardó unos 27 segundos en un conjunto de datos donde su mediana fue de 1,5 segundos. Para contexto, eso es 114× el p95 de CORD de docTR (235,9 ms). Dos motores que fueron casi idénticos en SROIE (Surya2 2,2×, Unlimited-OCR 1,6× de relación de cola) divergen marcadamente en CORD (18,2× frente a 2,4×) — un recordatorio de que el comportamiento de cola es una propiedad de la combinación motor × documento, no solo del motor.

La latencia y el costo corren en el mismo reloj

Debido a que las GPU alquiladas se facturan por hora de pared, la latencia y el costo son la misma medición vista dos veces: docTR es a la vez el motor más rápido (108,7 ms p50) y el más barato (cost_per_1000_pages 0,0479 en SROIE); Surya2 es a la vez el más lento (2 668,0 ms p50) y el más caro (1,0609) — misma división, misma tarifa. Los VLM pesados son lentos y costosos 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 pared (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), pero 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 pared es mucho menor (79,7 frente a 124,5 páginas/min; summary_metrics.csv cost_per_1000_pages / pages_per_minute, filas de sroie_2019). La clasificación completa de costos, la fórmula de costo y la aritmética detrás de ella viven en la página hermana OCR Cost per 1,000 Pages — 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 este benchmark: 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 la latencia típica de OCR 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 SROIE 2019 (summary_metrics.csv latency_p50_ms, filas sroie_2019) — una diferencia de 24.5× en hardware idéntico. Estado estable, caliente y luego puntuado, 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 más alta que la p50?

Por el efecto de primera página/prefill y el comportamiento de programación de lotes: los motores GPU pagan costos de preparació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 — está lejos 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 este benchmark, no una propiedad universal del motor.

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

Porque son mediciones diferentes. Páginas/min es el rendimiento de tiempo real incluyendo la inicialización del modelo y la programación; 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 real 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 según páginas/min; para esperas interactivas, según p50 y p95.

¿Cuál es una buena latencia de OCR para uso interactivo?

Menos de 1,000 ms en la cola es el estándar 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 sentirse receptivo, el p95 decide; si el caso típico es suficiente, el p50 decide.

¿Por qué un motor 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 del benchmark (summary_metrics.csv latency_p95_ms / latency_p50_ms, fila surya2/cord_v2). Su cola en SROIE fue un modesto 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 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 VLM 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 “lo suficientemente rápido” depende de su volumen y de si necesita campos en lugar de texto — consulte el perfil de costo de 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 efecto derivado de la base de medición, no de una nueva ejecución. La inicialización del modelo se paga una vez por proceso/lote (está dentro de páginas/min pero fuera de p50), por lo que el procesamiento por lotes o secuencial la amortiza: a alto volumen, el tiempo de pared por página se acerca al p50 de estado estable más la programación. Los números de SROIE de docTR ya están cerca de ese límite (p50 108,7 ms vs tiempo de pared derivado de 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 en 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 de SROIE 2019 y CORD citados a continuación.

Metodología y fuentes

Protocolo

Esta página informa la dimensión de latencia de una ejecución de referencia independiente y reproducible (nivel oficial) — no una encuesta de afirmaciones de terceros. Solo divisiones de prueba fijas: prueba SROIE 2019 (361 recibos en inglés, campos planos empresa/fecha/dirección/total) y prueba CORD v2 (100 recibos en indonesio, campos anidados menú/subtotal/total); las divisiones de entrenamiento nunca se evaluaron. Cada par (motor × conjunto de datos) reutilizó las mismas imágenes, la misma verdad fundamental y el mismo protocolo de medición (warm_then_scored: una pasada de calentamiento fija precede a la pasada evaluada). Las 16 ejecuciones se completaron con error_rate 0.0 (columna error_rate de summary_metrics.csv). Los datos se recopilaron en agosto de 2026.

Entorno de ejecución

• Hardware: todas las ejecuciones de GPU en una sola NVIDIA RTX 4090 (24 GB). Tesseract se ejecutó solo CPU (compute_type=cpu) y se etiqueta como tal en cada tabla. Un nivel de GPU, una ubicación/hora — la declaración de rango en esta página.
• Motores: todos los modelos se ejecutan listos para usar, sin ajuste fino. Versiones fijadas 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 servido por vLLM, PaddleOCR-VL 1.6.
• Modo de medición: warm_then_scored — las cifras de latencia son de inferencia por página en estado estable, excluyendo la carga del modelo; páginas/min es tiempo de pared incluyendo la inicialización del modelo (según 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 de referencia (reports/receipt_v1_official_protocol.md).

Definiciones de Métricas

• p50 (latencia mediana): el tiempo de inferencia mediano por página en estado estable — el 50% de las páginas fueron más rápidas. Excluye la carga del modelo (calentamiento y luego medición).
• p95 (latencia de cola): el percentil 95 del tiempo de inferencia por página — el 5% de las páginas tardaron más. Refleja los efectos de primera página/prefill y el comportamiento de programación por lotes bajo el protocolo de esta ejecución; es específico del protocolo, no una constante universal del motor.
• Relación p95/p50: se obtiene dividiendo las dos columnas del CSV (p. ej., 3331.3505 / 296.9897 = 11.22). Es un indicador de la forma de la cola, no una afirmación de velocidad.
• Páginas por minuto: rendimiento en tiempo real que incluye la inicialización del modelo. Es la vista de trabajos por lotes y facturación.
• ms/página en tiempo real (derivado): 60,000 ÷ páginas/min — cálculo aritmético sobre el rendimiento medido, etiquetado como una estimación derivada, no como 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. Toda cifra de latencia y rendimiento en esta página proviene de una fila aquí.
2. Repositorio ImageToTableai/benchmark-ocr. Repositorio público que aloja los CSV de resultados, manifiestos de ejecución redactados, protocolo congelado (reports/receipt_v1_official_protocol.md) y listas de muestra de los conjuntos de datos (divisiones de prueba fijas) para su reproducción.
3. results/manifests/ (GitHub). Un manifest.json redactado por ejecución publicada (16 ejecuciones) con la huella del entorno, versiones del modelo, modo de medición (warm_then_scored), tiempo real 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

• Solo un nivel de GPU, una ubicación y un momento: todas las cifras de GPU provienen de una RTX 4090 en un solo sitio, recopiladas en agosto de 2026. Otros GPU, el servicio con múltiples GPU y una programación diferente alteran 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 los efectos de la primera página/prefill y la programación por lotes según el patrón de ejecución de este benchmark (divisiones fijas de 361/100 páginas, cálido y luego puntuado). Son una lectura de la forma de esta ejecución, no una garantía universal de 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 de tiempo real) y nunca se presentan como el mismo número. La página derivada en tiempo real (60,000 ÷ páginas/min) es aritmética 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 el hardware de 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 las API de OCR/VLM alojadas no están incluidas; 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 init se deriva de la base de medición (páginas/min incluye init, p50 la excluye) y se contrasta con el método de la página de costos; no se realizó un experimento de tamaño de lote, por lo que la escala por lote es una estimación, no una medición.
• Tamaño de muestra y fijación de versiones: 361 + 100 muestras; los resultados se mantienen para las versiones de modelos de agosto de 2026 listadas anteriormente. Las nuevas versiones de motores pueden cambiar la latencia; diferencias de un solo dígito porcentual deben tratarse como ruido.

Referencias relacionadas: Costo de OCR por cada 1,000 páginas · pipelines de OCR frente a VLM de análisis de documentos · docTR vs Surya2: Empate en CER, brecha de costos · docTR vs Docling: paso único frente a pipeline · Tesseract vs PaddleOCR: CPU heredada frente a GPU moderna

Lectura relacionada: qué mide realmente la precisión de la IA en OCR · extracción de IA de imágenes frente a pipelines tradicionales de OCR · Precios de Extracción de Documentos con IA (2026)