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

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

Esta página relata três métricas das mesmas execuções, e elas respondem a perguntas diferentes. p50 (a mediana) é o tempo de inferência por página em regime estacionário no modo warm_then_scored — uma passagem fixa de aquecimento precede a passagem pontuada, e o carregamento do modelo é excluído — então ela responde "quão rápido é este motor por página quando 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 é o throughput em tempo real, incluindo a inicialização do modelo — o número que governa trabalhos em lote e horas de GPU faturadas.

As três métricas não são intercambiáveis e não se espera que concordem. O p50 em regime estacionário exclui o carregamento do modelo; as páginas/min em tempo real o incluem; 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 métrica está sendo mostrada — trate "108.7 ms" (p50, sem carregamento) e "449 páginas/min" (tempo real, com carregamento) 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 de páginas (p95 e além) — para um usuário esperando por 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 estacionária, que aparece como amostras iniciais lentas em uma execução. Throughput em tempo real conta cada milissegundo da execução, incluindo a inicialização. No protocolo deste benchmark, p50/p95 são medições em regime estacionário e páginas/min é em tempo real — a diferença entre eles é a inicialização mais a sobrecarga de agendamento.

SROIE 2019: Classificação por Latência Mediana por Página

Em 361 recibos em inglês, os motores OCR tradicionais de duas etapas ocupam a extremidade rápida e os VLMs de análise de documentos a extremidade lenta — 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 com 694,3 ms, ainda é mais lento que todos os motores tradicionais.

Fonte: summary_metrics.csv — coluna latency_p50_ms, linhas sroie_2019. docTR 108,7, PaddleOCR 297,0, EasyOCR 413,6, Tesseract 670,9 (somente CPU), PaddleOCR-VL 694,3, Docling 732,0, Unlimited-OCR 1.600,7, Surya2 2.668,0. Latência em estado estacionário, modo de medição aquecimento seguido de pontuação (exclui carregamento do 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). As razões p95/p50 foram calculadas pela divisão dos valores do CSV (ex.: 3331.3505 / 296.9897 = 11.22). O Tesseract foi executado apenas em CPU (compute_type=cpu); todos os outros em GPU. A latência em regime 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 da família — motores tradicionais ocupam as posições 1–4, VLMs as posições 5, 7, 8, com Docling (um analisador de pipeline, não um motor OCR puro ou um VLM) no meio — mas a lacuna dentro de cada família é ampla. O cluster de VLMs 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 preditor fraco do pior caso. O p95 do PaddleOCR no SROIE (3.331,4 ms) é 11,2× 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, essa razão, e não o p50, decide se um usuário espera 0,3 segundos ou 3,3. O p95 do docTR (281,4 ms) permanece apertado em 2,6× seu p50.

O mecanismo é o efeito de primeira página/prefill: motores GPU pagam um custo de inicialização único antes da inferência estável, e o agendamento em lote pode serializar amostras lentas. Esse é um comportamento específico do protocolo — esses valores de p95 refletem o padrão de execução deste benchmark (divisão de teste fixa, aquecimento-então-pontuação), 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: calculada a partir de summary_metrics.csv — latency_p95_ms ÷ latency_p50_ms, linhas sroie_2019 (razão derivada pela divisão dos valores publicados, por exemplo, 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 o que a razão não diz: uma razão p95/p50 apertada não é uma afirmação de velocidade. Unlimited-OCR tem a cauda mais apertada do benchmark (1,6×) — mas seu p50 (1.600,7 ms) e p95 (2.521,9 ms) são ambos muito mais lentos que o p95 do docTR (281,4 ms). A razão mede a forma da distribuição, não onde a distribuição está situada. Leia os dois números juntos: uma cauda apertada em torno de uma mediana lenta ainda é lenta.

Throughput Conta uma História Diferente: páginas/min vs p50

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

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

Tabela: summary_metrics.csv — latency_p50_ms / pages_per_minute, linhas sroie_2019. Wall-clock ms/página é uma estimativa derivada (60,000 ÷ pages_per_minute, ex.: 60,000 / 79.7130 = 752.7) — cálculo aritmético sobre o throughput medido, não uma figura medida separadamente. Sobrecarga = wall-clock derivado ÷ p50 medido. Páginas/min é wall-clock incluindo inicialização do modelo; p50 é estado estacionário excluindo carga.

Uma segunda nota de reconciliação nos extremos: o Tesseract, o único motor CPU, mantém 78.6 páginas/min no SROIE — essencialmente igualando os 79.7 do PaddleOCR na GPU — com seu p50 (670.9 ms, CPU) e wall-clock (763.0 ms) quase idênticos, porque um motor CPU de thread único tem pouca sobrecarga de inicialização para ocultar. Seu p95 (1.507,0 ms) é 2.2× seu p50 — uma das caudas mais apertadas no 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 por uma única página, 1.000 ms é um limite útil — aproximadamente a fronteira do que se sente responsivo. Lendo no p50, seis dos oito motores ficam abaixo dele 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). Apenas Unlimited-OCR (1.600,7 ms) e Surya2 (2.668,0 ms) o ultrapassam na mediana.

Lendo no p95, o quadro se inverte: apenas dois motores ainda cabem abaixo de 1 segundo — docTR (281,4 ms) e EasyOCR (960,4 ms). A cauda de todos os outros 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, sroie_2019 rows). Se "interativo" significa que o pior caso deve parecer responsivo, a cauda — não a mediana — é o critério de seleção, e apenas dois motores se qualificam.

O processamento em lote é o outro regime, e ele muda a economia a favor dos motores. A inicialização do modelo é paga uma vez por processo/lote, então o processamento sequencial ou em lote amortiza o custo de inicialização em mais páginas — a latência por página e o custo por página caem à medida que o tamanho do lote aumenta. Este é um argumento derivado da base de medição (páginas/min inclui init; p50 exclui), não uma nova execução de benchmark — o mesmo raciocínio e sua aritmética aparecem na página de custos.

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

Troque o conjunto de documentos e os rankings se mantêm aproximadamente — docTR continua mais rápido e Surya2 continua 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× seu próprio p50 (1.485,3 ms) e o evento de cauda extrema do benchmark — enquanto 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 disparar para esperas de meio minuto em recibos em indonésio.

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 também serve como um teste de estresse entre idiomas. Seus recibos são mais curtos e menos densos em texto que os do SROIE, razão pela qual 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 do ranking do SROIE neste benchmark (idioma diferente, estrutura de ground-truth diferente); o ponto desta tabela é que a latência varia com o conjunto de documentos e a cauda pode variar dramaticamente.

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 estável, aquecimento-antes-da-avaliação (exclui carregamento do modelo).

Tabela: summary_metrics.csv — latency_p50_ms / latency_p95_ms / pages_per_minute, linhas cord_v2 (100 amostras cada). As razões p95/p50 foram calculadas pela divisão dos valores do CSV (ex.: 26976.9306 / 1485.3493 = 18.16). O Tesseract foi executado apenas em CPU. A latência em regime estacionário exclui o carregamento do modelo; páginas/min é o tempo real incluindo a inicialização.

O p95 do CORD do Surya2 de 26.976,9 ms é o maior evento de cauda no benchmark — uma página em vinte levou cerca de 27 segundos em um conjunto de dados onde sua mediana era de 1,5 segundos. Para contexto, isso é 114× o p95 do CORD do docTR (235,9 ms). Dois motores que estavam quase idênticos no SROIE (Surya2 2,2×, Unlimited-OCR 1,6× de razão p95/p50) divergem drasticamente 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 sozinho.

Latência e Custo Rodam no Mesmo Relógio

Como GPUs alugadas cobram por hora de relógio, latência e custo são a mesma medida vista duas vezes: o docTR é tanto o motor mais rápido (108,7 ms p50) quanto o mais barato (cost_per_1000_pages 0,0479 no SROIE); o Surya2 é tanto o mais lento (2.668,0 ms p50) quanto 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 o throughput de páginas/minuto de relógio (que inclui inicialização) enquanto o p50 o 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 é muito menor (79,7 vs 124,5 páginas/min; summary_metrics.csv cost_per_1000_pages / pages_per_minute, linhas sroie_2019). O ranking completo de custos, a fórmula de custo e a aritmética por trás dela estão na página irmã Custo do OCR por 1.000 Páginas — esta página mantém seu foco na latência e apenas empresta a correlação.

Perguntas Frequentes

Qual é o motor 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 OCR típica por página em uma GPU?

Entre 108,7 ms (docTR) e 2.668,0 ms (Surya2) p50 por página em 8 motores 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× em hardware idêntico. Estado estável, aquecimento seguido de pontuação, excluindo carregamento do modelo. Os mesmos motores 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?

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

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

Porque são medições diferentes. Páginas/min é o throughput de relógio real incluindo inicialização e agendamento do modelo; p50 é a inferência por página em estado estável excluindo carregamento do modelo. No SROIE, o p50 do PaddleOCR (297,0 ms) implica aproximadamente 200 páginas/min em estado estável puro, mas o throughput medido é de 79,7 páginas/min — um tempo de relógio real derivado de 752,7 ms por página, 2,5× 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, com base em p50 e p95.

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

Menos de 1.000 ms na cauda é o limite prático. No SROIE, seis de oito motores ficam 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 seu p95 abaixo de 1 segundo (summary_metrics.csv latency_p50_ms / latency_p95_ms, linhas sroie_2019). Se o pior caso precisa parecer responsivo, o p95 decide; se o caso típico é suficiente, o p50 decide.

Por que um motor 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× 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 motor × CORD — o conteúdo do idioma e o agendamento mudaram o comportamento da cauda, não apenas a mediana.

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

Em CPU, o Tesseract sustentou 78,6 páginas/min no SROIE 2019 com um p50 de 670,9 ms — mais lento que os motores 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 uma cauda apertada (2,2×). Ele é apenas CPU neste benchmark (summary_metrics.csv linha tesseract/sroie_2019); 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 um 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 (ela 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 relógio por página se aproxima do p50 em estado estacionário mais o agendamento. Os números do docTR no SROIE já estão perto desse piso (p50 108,7 ms vs relógio derivado 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 ser amortizada.

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

Cada valor é uma linha do benchmark publicado de primeira parte em results/summary_metrics.csv (latency_p50_ms, latency_p95_ms, pages_per_minute) hospedado em ImageToTableai/benchmark-ocr, com um manifest.json redatado por execução registrando o modo de medição (warm_then_scored), versões do modelo 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 um levantamento de alegações de terceiros. Apenas divisões de teste fixas: SROIE 2019 teste (361 recibos em inglês, campos planos empresa/data/endereço/total) e CORD v2 teste (100 recibos indonésios, campos aninhados menu/sub_total/total); divisões de treinamento nunca foram avaliadas. Cada par (motor × conjunto de dados) reutilizou as mesmas imagens, a mesma verdade de referência e o mesmo protocolo de medição (warm_then_scored: uma passagem de aquecimento fixa precede a passagem pontuada). Todas as 16 execuções foram concluídas com error_rate 0.0 (coluna error_rate do summary_metrics.csv). Os dados foram coletados em agosto de 2026.

Ambiente de Execução

• Hardware: todas as execuções em GPU em uma única NVIDIA RTX 4090 (24 GB). O Tesseract rodou apenas em CPU (compute_type=cpu) e é rotulado como tal em todas as tabelas. Um nível de GPU, um local/horário — a declaração de alcance nesta página.
• Motores: todos os modelos rodaram prontos para uso, sem ajuste fino. Versões bloqueadas conforme os manifestos 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 servido via vLLM, PaddleOCR-VL 1.6.
• Modo de medição: warm_then_scored — os valores de latência são inferência por página em regime estável, excluindo o carregamento do modelo; páginas/min é o tempo real incluindo a inicialização do modelo (conforme performance.run_wall_time_ms de cada execução nos manifestos redatados).
• 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).

Definições das Métricas

• p50 (latência mediana): tempo mediano de inferência por página em estado estacionário — 50% das páginas foram mais rápidas. Exclui o carregamento do modelo (aquecimento-antes-da-pontuação).
• p95 (latência de cauda): tempo de inferência por página no percentil 95 — 5% das páginas levaram mais tempo. Reflete efeitos de primeira página/prefilling e comportamento de agendamento em lote sob o protocolo desta execução; específico do protocolo, não uma constante universal do motor.
• Razão p95/p50: obtida pela divisão das duas colunas CSV (ex.: 3331.3505 / 296.9897 = 11.22). Um indicador de forma da cauda, não uma afirmação de velocidade.
• Páginas por minuto: throughput em tempo real incluindo inicialização do modelo. O lote de trabalhos e a visão de faturamento.
• ms/página em tempo real (derivado): 60.000 ÷ páginas/min — aritmética sobre o throughput medido, rotulado como uma estimativa derivada, não uma figura medida.

Lista de Fontes

1. summary_metrics.csv (GitHub raw). 16 linhas = 8 motores × 2 conjuntos de dados de recibos (sroie_2019, cord_v2). As colunas incluem latency_p50_ms, latency_p95_ms, pages_per_minute, compute_type, error_rate. Toda figura de latência e throughput nesta página rastreia até uma linha aqui.
2. Repositório ImageToTableai/benchmark-ocr. Repositório público hospedando os CSVs de resultados, manifestos de execução redatados, protocolo congelado (reports/receipt_v1_official_protocol.md) e listas de amostras de conjuntos de dados (divisões de teste fixas) para reprodução.
3. results/manifests/ (GitHub). Um manifesto.json redatado por execução publicada (16 execuções) com a impressão digital do ambiente, versões do modelo, modo de medição (warm_then_scored), tempo em tempo real e hashes de artefatos.
4. Huang et al., "ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction" (2019). Definição do conjunto de dados SROIE 2019, estrutura da tarefa e licença (CC-BY-4.0).
5. Park et al., "CORD: A Consolidated Receipt Dataset for Post-OCR Parsing" (2020). Definição do conjunto de dados CORD v2, esquema de campos aninhados e licença (CC-BY-4.0).

Limitações

• Tier de GPU único, local/horário único: todos os dados 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 latência e 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; as classificações acima não são generalizáveis além de recibos — e os resultados do CORD não são incorporados à classificação do 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, aquecimento-para-pontuação). 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 em tempo real) e nunca são apresentadas como o mesmo número. O tempo real derivado por página (60.000 ÷ páginas/min) é aritmético sobre o throughput medido, não uma figura medida separadamente.
• Assimetria CPU/GPU: Tesseract (CPU) é comparado a motores acelerados por GPU; sua latência reflete hardware de CPU. É marcado em todas as tabelas, mas a assimetria é inerente à comparação.
• Sem modelos cloud/API: AWS Textract, Google Document AI, Azure AI Document Intelligence e APIs de OCR/VLM hospedadas não são incluídos; seus modelos de latência (rede, cobrança por chamada, autoescalonamento) diferem fundamentalmente dos motores 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 cruzada com o 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. Versões mais recentes dos motores podem alterar a latência; diferenças de um dígito percentual devem ser tratadas como ruído.

Referências relacionadas: Custo de OCR por 1.000 Páginas · OCR Tradicional vs VLMs de Análise de Documentos · docTR vs Surya2: Empate em CER, Lacuna de Custo · docTR vs Docling: Passagem Única vs Pipeline · Tesseract vs PaddleOCR: CPU Legada vs GPU Moderna

Leitura relacionada: Precisão de AI OCR vs OCR Tradicional · Extração de Dados de Imagem com AI vs OCR Tradicional · Preços de Extração de Documentos com AI (2026)