Benchmark de Latência de OCR
p50/p95, Throughput e Picos de Cauda (2026)

Três Medidas, Uma Página: p50, p95 e páginas/min

Esta página apresenta três medidas das mesmas execuções, e elas respondem a perguntas diferentes. p50 (a mediana) é o tempo de inferência por página em estado estável no modo warm_then_scored — uma passada de aquecimento fixa precede a passada avaliada, e o carregamento do modelo é excluído — portanto, responde: “quão rápido é este mecanismo por página, uma vez que já está em execução?” p95 é a mesma medição no percentil 95: 5% das páginas levaram mais tempo que isso. Páginas por minuto é a vazão em tempo real, incluindo a inicialização do modelo — o número que rege trabalhos em lote e horas de GPU faturáveis.

As três medidas não são intercambiáveis e não se espera que concordem. O p50 em estado estável exclui o carregamento do modelo; páginas/min em tempo real o inclui; o p95 captura efeitos de primeira página/prefill e comportamento de agendamento em lote que o p50 ignora. Cada gráfico e tabela nesta página indica qual medida mostra — trate “108,7 ms” (p50, sem carga) e “449 páginas/min” (tempo real, com carga) como dois fatos diferentes sobre o docTR, não uma contradição.

Três termos usados ao longo do texto: latência de cauda é o comportamento dos poucos por cento mais lentos das páginas (p95 e além) — para um usuário esperando uma única página, a cauda, não a mediana, decide a experiência. Efeito de primeira página/prefill é o custo único de preparar um modelo ou pipeline antes da inferência estável, que aparece como amostras iniciais lentas em uma execução. Vazão em tempo real conta cada milissegundo da execução, incluindo a inicialização. No protocolo deste benchmark, p50/p95 são medições em estado estável e páginas/min é tempo real — a diferença entre eles é a inicialização mais a sobrecarga de agendamento.

SROIE 2019: Ranking de Latência Mediana por Página

Em 361 recibos em inglês, os motores OCR tradicionais de dois estágios ocupam o extremo rápido e os VLMs de análise de documentos, o extremo lento — mas a dispersão dentro de cada família é a surpresa. docTR (108,7 ms) é 2,7× mais rápido que o próximo motor tradicional (PaddleOCR, 297,0 ms), e os dois motores mais lentos são ambos VLMs (Unlimited-OCR 1.600,7 ms, Surya2 2.668,0 ms). No entanto, o VLM mais rápido, PaddleOCR-VL a 694,3 ms, ainda é mais lento que todos os motores tradicionais.

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 warm-then-scored (excluye el tiempo de carga del modelo).

Tabela: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, linhas sroie_2019 (361 amostras cada, error_rate 0.0 para todos os 8). Razões p95/p50 calculadas pela divisão dos valores do CSV (ex.: 3331.3505 / 296.9897 = 11.22). Tesseract executado apenas em CPU (compute_type=cpu); todos os demais em GPU. A latência em estado estacionário exclui o carregamento do modelo; páginas/min é o tempo real incluindo a inicialização.

O padrão de arquitetura é claro no nível de família — motores tradicionais ocupam as posições 1–4, VLMs as posições 5, 7, 8, com Docling (um parser de pipeline, não um motor OCR puro nem um VLM) no meio — mas a lacuna dentro de cada família é ampla. O cluster de VLM abrange 3,8× (694,3 a 2.668,0 ms) e o cluster tradicional 6,2× (108,7 a 670,9 ms), o que significa que “VLM” e “tradicional” não são categorias de latência — o design individual do motor decide muito mais do que a pertença à família.

p50 Esconde a Cauda: Razões p95/p50 Entre Motores

A mediana é um mau preditor do pior caso. O p95 do PaddleOCR no SROIE (3.331,4 ms) é 11,2× o seu p50 (297,0 ms) — 5% das páginas levaram mais de 3,3 segundos, embora a página mediana tenha levado menos de 300 ms. Para cargas de trabalho interativas, esta razão, não o p50, decide se um utilizador espera 0,3 segundos ou 3,3. O p95 do docTR (281,4 ms) permanece apertado em 2,6× o seu p50.

O mecanismo é o efeito de primeira página/prefill: os motores GPU pagam um custo único de inicialização antes da inferência estável, e o agendamento em lote pode serializar amostras lentas. Isso é um comportamento específico do protocolo — estes valores de p95 refletem o padrão de execução deste benchmark (divisão de teste fixa, aquecido-depois-avaliado), não uma propriedade universal dos motores. O que os dados mostram é a forma da cauda de cada motor sob este protocolo: PaddleOCR e Docling têm caudas longas e pesadas no SROIE; docTR, EasyOCR e Unlimited-OCR mantêm as suas próximas da mediana.

Fonte: calculado a partir de summary_metrics.csv — latency_p95_ms ÷ latency_p50_ms, linhas sroie_2019 (razão derivada pela divisão dos valores publicados, ex., 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 o que a razão não diz: uma razão p95/p50 apertada não é uma afirmação de velocidade. O Unlimited-OCR tem a cauda mais apertada no benchmark (1,6×) — mas o seu p50 (1.600,7 ms) e p95 (2.521,9 ms) são ambos muito mais lentos do que o p95 do docTR (281,4 ms). A razão mede a forma da distribuição, não onde a distribuição se situa. Leia os dois números em conjunto: uma cauda apertada em torno de uma mediana lenta ainda é lenta.

O Throughput Conta Outra História: páginas/min vs p50

Classifique os motores por páginas por minuto e a ordem muda. Os 449,3 páginas/min do docTR vs os 12,1 do Surya2 representam uma diferença de 37× — maior que a diferença de 24,5× do p50. Mas o PaddleOCR, com uma cauda p95 de 11,2×, ainda sustenta 79,7 páginas/min: próximo aos 124,5 do EasyOCR, superando os 68,2 do PaddleOCR-VL e os 56,7 do Docling. Uma mediana lenta e uma cauda pesada não impedem um throughput de lote respeitável.

A reconciliação está na base de medição: páginas/min é o throughput de tempo real, incluendo a inicialização do modelo e o agendamento, enquanto o p50 é a inferência de página única em estado estável, excluindo a carga. A tabela abaixo converte páginas/min no tempo médio de reloj por página que isso implica (60.000 ÷ páginas/min — uma estimação derivada, não uma cifra medida) e mostra a diferença em relação ao p50. O tempo de reloj implícito por página do PaddleOCR (752,7 ms) é 2,5× seu p50 em estado estável (297,0 ms); o do Surya2 (4.940,0 ms) é 1,9× seu p50 (2.668,0 ms). A sobrecarga — inicialização, agendamento, custos de pipeline por chamada — é invisível apenas no p50, razão pela qual um p50 baixo não significa automaticamente alto throughput.

Tabela: summary_metrics.csv — latency_p50_ms / pages_per_minute, linhas sroie_2019. Tempo real ms/página é uma estimativa derivada (60.000 ÷ pages_per_minute, ex.: 60.000 / 79,7130 = 752,7) — aritmética sobre o throughput medido, não uma medição separada. Overhead = tempo real derivado ÷ p50 medido. Páginas/min inclui o tempo real com inicialização do modelo; p50 é estado estável, excluindo carga.

Uma segunda nota de reconciliação sobre os extremos: Tesseract, o único motor em CPU, sustenta 78,6 páginas/min no SROIE — praticamente igualando os 79,7 do PaddleOCR em GPU — com seu p50 (670,9 ms, CPU) e tempo real (763,0 ms) quase idênticos, pois um motor de CPU de thread única tem pouco overhead de inicialização a esconder. Seu p95 (1.507,0 ms) é 2,2× o p50 — uma das caudas mais apertadas do benchmark. A paridade de throughput CPU-vs-GPU é analisada em detalhes em Tesseract vs PaddleOCR.

Interativo vs. Lote: A Leitura do Limite de 1.000 ms

Para um usuário esperando em uma única página, 1.000 ms é um limite útil — aproximadamente a fronteira do que parece responsivo. Lido no p50, seis de oito motores permanecen abaixo no 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). Somente Unlimited-OCR (1.600,7 ms) e Surya2 (2.668,0 ms) o ultrapassam na mediana.

Lido no p95, o quadro se inverte: somente dois motores ainda caben em menos de 1 segundo — docTR (281,4 ms) e EasyOCR (960,4 ms). A cauda de todos os outros motores o ultrapassa: 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, linhas sroie_2019). Se “interativo” significa que o caso peor deve parecer responsivo, a cauda — não a mediana — é o critério de seleção, e somente dois motores se qualificam.

O processamento em lote é o outro regime, e isso muda a economia a favor dos motores. A inicialização do modelo é paga uma vez por processo/lote, portanto o processamento sequencial ou em lote amortiza o custo de inicialização em mais páginas — tanto a latência por página como o custo por página caen à medida que o tamanho do lote cresce. Este é um argumento derivado da base de medição (páginas/min incluye init; p50 lo excluye), não uma nova execução de benchmark — o mesmo raciocinio e sua aritmética trabalhada aparecen no método da página de custos.

CORD (Recibos Indonésios): Mesma História, Caudas Diferentes

Troque o conjunto de documentos e as classificações praticamente se mantêm — docTR continua o mais rápido e Surya2 o mais lento — mas a mudança de idioma remodela as caudas. No CORD v2, o p95 do Surya2 dispara para 26.976,9 ms (≈27 s), 18,2× o seu próprio p50 (1.485,3 ms) e o evento de cauda extrema do benchmark — enquanto a sua razão de cauda no SROIE era modesta, de 2,2×. O conteúdo do idioma altera o comportamento da cauda; um VLM estável em recibos em inglês pode saltar para esperas de meio minuto em recibos indonésios.

O CORD v2 é um conjunto de dados em indonésio com campos aninhados (menu, sub_total, total); nenhum dos 8 motores foi treinado predominantemente em indonésio, então ele funciona também como um teste de estresse entre idiomas. Seus recibos são mais curtos e menos densos em texto do que os do SROIE, por isso a maioria dos motores fica mais rápida aqui — docTR cai para 100,4 ms p50 (500,4 páginas/min), PaddleOCR para 108,2 ms p50 (141,0 páginas/min). O CORD é deliberadamente mantido separado da classificação SROIE neste benchmark (idioma diferente, estrutura de ground-truth diferente); o objetivo desta tabela é mostrar que a latência acompanha o conjunto de documentos e que a cauda pode mudar drasticamente.

Fonte: summary_metrics.csv — coluna latency_p50_ms, linhas cord_v2. docTR 100,4, PaddleOCR 108,2, EasyOCR 192,8, PaddleOCR-VL 249,3, Docling 338,0, Tesseract 474,6 (somente CPU), Unlimited-OCR 608,2, Surya2 1485,3. Latência em estado estacionário, aquecido e depois pontuado (exclui carregamento do modelo).

Tabela: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, linhas cord_v2 (100 muestras cada). Razones p95/p50 calculadas por división de 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 de pared incluyendo la inicialización.

O p95 de 26.976,9 ms do Surya2 no CORD é o maior evento de cauda isolado no benchmark — uma página em cada vinte levou cerca de 27 segundos em um conjunto de dados onde sua mediana era de 1,5 segundo. Para contexto, isso é 114× o p95 do docTR no CORD (235,9 ms). Dois motores quase idênticos no SROIE (razões de cauda de 2,2× para Surya2 e 1,6× para Unlimited-OCR) divergem acentuadamente no CORD (18,2× vs 2,4×) — um lembrete de que o comportamento de cauda é uma propriedade da combinação motor × documento, não do motor isoladamente.

Latência e Custo Corre no Mesmo Relógio

Como GPUs alugadas são cobradas por hora de relógio de parede, latência e custo são a mesma medição vista duas vezes: o docTR é ao mesmo tempo o motor mais rápido (108,7 ms p50) e o mais barato (cost_per_1000_pages 0,0479 no SROIE); o Surya2 é ao mesmo tempo o mais lento (2.668,0 ms p50) e o mais caro (1,0609) — mesma divisão, mesma taxa. Os VLMs pesados são lentos e caros juntos; os motores tradicionais leves são rápidos e baratos juntos.

A correlação não é exata, porque o custo segue páginas/min de relógio de parede (que inclui a inicialização) enquanto o p50 a exclui — o p50 do PaddleOCR (297,0 ms) é mais rápido que o do EasyOCR (413,6 ms), mas o custo por 1.000 páginas do PaddleOCR (0,2214) é aproximadamente o dobro do EasyOCR (0,1098) porque seu throughput de relógio de parede é muito menor (79,7 vs 124,5 páginas/min; summary_metrics.csv cost_per_1000_pages / pages_per_minute, linhas sroie_2019). A classificação completa de custos, a fórmula de custo e a aritmética por trás dela estão na página irmã Custo de OCR por 1.000 Páginas — esta página mantém o foco na latência e apenas toma emprestada a correlação.

Perguntas Frequentes

Qual é o motor de OCR mais rápido por página?

docTR foi o mais rápido neste benchmark: 108,7 ms p50 e 281,4 ms p95 por página no SROIE 2019 (summary_metrics.csv latency_p50_ms / latency_p95_ms, linha doctr/sroie_2019), sustentando 449,3 páginas/min. O mais lento medido, Surya2, foi 24,5× mais lento no p50 (2.668,0 ms) e 37× mais lento no throughput (12,1 páginas/min).

Qual é a latência típica de OCR por página em uma GPU?

Entre 108,7 ms (docTR) e 2.668,0 ms (Surya2) p50 por página em 8 mecanismos de código aberto em uma RTX 4090, recibos SROIE 2019 (summary_metrics.csv latency_p50_ms, linhas sroie_2019) — uma variação de 24,5× no mesmo hardware. Estado estável, aquecido e pontuado, excluindo o carregamento do modelo. Os mesmos mecanismos no CORD v2 variam de 100,4 a 1.485,3 ms p50.

Por que a latência p95 do OCR é tão maior que a p50?

Por causa do efeito de primeira página/prefill e do comportamento de agendamento em lote: os mecanismos de GPU pagam custos únicos de inicialização e amostras lentas podem ser serializadas, então os 5% mais lentos das páginas — por definição do percentil 95 — ficam longe da mediana. O p95 do PaddleOCR no SROIE (3.331,4 ms) é 11,2× o seu p50 (297,0 ms); o p95 do docTR (281,4 ms) é apenas 2,6× o seu p50 (summary_metrics.csv latency_p95_ms / latency_p50_ms, linhas sroie_2019). Os valores de p95 são específicos do protocolo — eles refletem o padrão de execução deste benchmark, não uma propriedade universal do mecanismo.

Por que a latência do OCR e as páginas por minuto não coincidem?

Porque são medições diferentes. Páginas/min é a taxa de transferência em tempo real incluindo a inicialização do modelo e o agendamento; p50 é a inferência por página em estado estável excluindo o carregamento do modelo. No SROIE, o p50 do PaddleOCR (297,0 ms) implica cerca de 200 páginas/min em estado puramente estável, mas a taxa de transferência medida é de 79,7 páginas/min — um tempo real derivado de 752,7 ms por página, 2,5× o seu p50 (summary_metrics.csv latency_p50_ms / pages_per_minute, linha paddleocr/sroie_2019). Para trabalhos em lote, planeje com base em páginas/min; para esperas interativas, em p50 e p95.

Qual é uma boa latência de OCR para uso interativo?

Abaixo de 1.000 ms no extremo é a referência prática. No SROIE, seis dos oito mecanismos permanecem abaixo de 1 segundo no p50 (docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9, PaddleOCR-VL 694,3, Docling 732,0 ms), mas apenas docTR (281,4 ms) e EasyOCR (960,4 ms) mantêm o p95 abaixo de 1 segundo (summary_metrics.csv latency_p50_ms / latency_p95_ms, linhas sroie_2019). Se o pior caso precisar parecer responsivo, o p95 decide; se o caso típico for suficiente, o p50 decide.

Por que um mecanismo de OCR levou 27 segundos em um recibo?

O p95 do Surya2 no CORD v2 foi de 26.976,9 ms (≈27 s) — 18,2× o seu próprio p50 (1.485,3 ms) e o maior evento de cauda no benchmark (summary_metrics.csv latency_p95_ms / latency_p50_ms, linha surya2/cord_v2). Sua cauda no SROIE foi modesta, de 2,2×, então o pico é específico da combinação mecanismo × CORD — o conteúdo do idioma e o agendamento mudaram o comportamento da cauda, não apenas a mediana.

O OCR do Tesseract é rápido o suficiente sem GPU?

Na CPU, o Tesseract sustentou 78,6 páginas/min no SROIE 2019 com um p50 de 670,9 ms — mais lento que os mecanismos tradicionais com GPU, mas mais rápido que todos os três VLMs em throughput (PaddleOCR-VL 68,2, Docling 56,7, Unlimited-OCR 34,4, Surya2 12,1 páginas/min) e com cauda apertada (2,2×). Ele é somente CPU neste benchmark (linha tesseract/sroie_2019 em summary_metrics.csv); se é “rápido o suficiente” depende do seu volume e se você precisa de campos em vez de texto — veja o perfil de custo de CPU em Tesseract vs PaddleOCR.

O OCR fica mais rápido por página à medida que você processa mais páginas?

Sim, até um piso de estado estacionário — como efeito derivado da base de medição, não de uma nova execução. A inicialização do modelo é paga uma vez por processo/lote (está dentro de páginas/min, mas fora do p50), então o processamento em lote ou sequencial a amortiza: em alto volume, o tempo de parede por página se aproxima do p50 de estado estacionário mais o agendamento. Os números do docTR no SROIE já estão próximos desse piso (p50 108,7 ms vs. tempo de parede derivado de 133,5 ms por página); os do Surya2 (p50 2.668,0 vs. 4.940,0 ms) mostram mais sobrecarga de inicialização a amortizar.

De onde vêm os números de latência nesta página?

Cada figura é uma linha do results/summary_metrics.csv publicado do benchmark de primeira parte (latency_p50_ms, latency_p95_ms, pages_per_minute), hospedado em ImageToTableai/benchmark-ocr, com um manifest.json editado por execução registrando o modo de medição (warm_then_scored), versões dos modelos e impressões digitais do ambiente. As definições dos conjuntos de dados vêm dos artigos SROIE 2019 e CORD citados abaixo.

Metodologia e Fontes

Protocolo

Esta página relata a dimensão de latência de uma execução de benchmark independente e reproduzível (nível oficial) — não uma pesquisa de alegações de terceiros. Apenas divisões de teste fixas: teste SROIE 2019 (361 recibos em inglês, campos simples empresa/data/endereço/total) e teste CORD v2 (100 recibos em indonésio, campos aninhados menu/sub_total/total); divisões de treinamento nunca foram avaliadas. Cada par (engine × dataset) reutilizou as mesmas imagens, o mesmo ground truth e o mesmo protocolo de medição (warm_then_scored: uma passada de aquecimento fixa precede a passada avaliada). Todas as 16 execuções foram concluídas com error_rate 0.0 (coluna error_rate em summary_metrics.csv). Os dados foram coletados em agosto de 2026.

Ambiente de Execução

• Hardware: todas as execuções de GPU em uma única NVIDIA RTX 4090 (24 GB). O Tesseract foi executado somente em CPU (compute_type=cpu) e está rotulado como tal em todas as tabelas. Um nível de GPU, um local/horário — a declaração de escopo nesta página.
• Engines: todos os modelos executados prontos para uso, sem fine-tuning. Versões fixadas conforme os manifests de execução: 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 medição: warm_then_scored — os números de latência são inferência por página em estado estacionário, excluindo o carregamento do modelo; páginas/min inclui o tempo de parede com a inicialização do modelo (conforme performance.run_wall_time_ms da execução nos manifests editados).
• Nível de execução: todas as 16 execuções são official; apenas execuções oficiais são elegíveis para publicação conforme o protocolo do 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 fueron más rápidas. Excluye la carga del modelo (calentamiento y luego puntuació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 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: derivada de la división de las dos columnas del CSV (p. ej., 3331.3505 / 296.9897 = 11.22). 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. La vista de trabajos por lotes y facturación.
• ms/página en tiempo real (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 rastrea hasta 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 muestras de conjuntos de datos (divisiones de prueba fijas) para 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 en 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).

Limitações

• Nível único de GPU, local e horário únicos: todos os números de GPU vêm de uma RTX 4090 em um único local, coletados em agosto de 2026. Outras GPUs, servidores multi-GPU e agendamentos diferentes alteram a latência e o throughput; meça em seu próprio hardware antes de se comprometer.
• Apenas recibos: recibos SROIE (inglês) e CORD (indonésio). A latência em faturas, formulários, contratos ou documentos longos não foi medida; os rankings acima não são generalizáveis além de recibos — e os resultados do CORD não são mesclados ao ranking SROIE.
• p95 é específico do protocolo: os valores de p95 refletem efeitos de primeira página/prefill e agendamento em lote sob o padrão de execução deste benchmark (divisões fixas de 361/100 páginas, aquecido e depois pontuado). Eles são uma leitura da forma desta execução, não uma garantia universal de pior caso.
• p50/p95 excluem carregamento do modelo, páginas/min inclui: as duas bases são deliberadamente diferentes (inferência em estado estável vs. throughput de tempo real) e nunca são apresentadas como o mesmo número. O tempo derivado por página (60.000 ÷ páginas/min) é aritmética sobre o throughput medido, não uma figura medida separadamente.
• Assimetria CPU/GPU: Tesseract (CPU) é comparado com mecanismos acelerados por GPU; sua latência reflete o hardware de CPU. Ele é marcado em todas as tabelas, mas a assimetria é inerente à comparação.
• Sem modelos de nuvem/API: AWS Textract, Google Document AI, Azure AI Document Intelligence e APIs OCR/VLM hospedadas não estão incluídos; seus modelos de latência (rede, medição por chamada, autoscaling) diferem fundamentalmente dos mecanismos locais medidos aqui.
• Sem varredura de tamanho de lote: a amortização de inicialização é derivada da base de medição (páginas/min inclui init, p50 exclui) e referenciada ao método da página de custo — nenhum experimento de tamanho de lote foi executado, então o escalonamento por lote é uma estimativa, não uma medição.
• Tamanho da amostra e fixação de versão: 361 + 100 amostras; os resultados valem para as versões de modelo de agosto de 2026 listadas acima. Lançamentos mais novos do mecanismo podem alterar a latência; diferenças de dígitos percentuais únicos devem ser tratadas como ruído.

Referências relacionadas: Custo de OCR por 1.000 páginas · Pipelines de OCR versus VLMs de parsing de documentos · docTR vs Surya2: Empate em CER, Diferença de Custo · docTR vs Docling: Passagem Única vs Pipeline · Tesseract vs PaddleOCR: CPU Legado vs GPU Moderna

Leitura relacionada: o que a precisão de OCR de IA realmente mede · extração de IA de imagens versus pipelines tradicionais de OCR · Preços de Extração de Documentos com IA (2026)