Seis motores de OCR numa RTX 4070 de notebook: o que medi e o que a vazão esconde
Medi seis modelos abertos de OCR no vLLM, numa RTX 4070 de notebook, para escolher um motor de OCR que rode em Linux. Com uma página por vez e a GPU ociosa, o tempo saiu cerca de três vezes maior. O escolhido foi o LightOnOCR-2-1B.
Eu precisava de um motor de OCR que rodasse em Linux. O que eu usava no Mac era o Vision, o OCR nativo da Apple.
A primeira pesquisa de opções não teve nenhuma medição própria: os números de desempenho vinham dos fabricantes ou de um ensaio de 26/09 feito no Mac. Antes de decidir, eu quis investigar opções além das sugestões iniciais.
Como montei o ensaio
A máquina foi um notebook com RTX 4070 Laptop (8 GB, cerca de 95 W sob carga, 2,34 GHz, sem estrangulamento) e i9-13900HX, numa distro WSL dedicada ao ensaio, com 8 núcleos e 12 GB. Usei o vLLM, exceto para o Unlimited-OCR-2, que rodou em transformers, com um modelo por vez, porque dois não cabem na GPU.
As 126 páginas vieram de um caso real, em duas amostras de 63: uma geral e outra só com páginas difíceis de ler. Antes do ensaio, as imagens foram reduzidas para 1540 pixels no lado maior.
A referência foi a transcrição feita por um modelo de visão. Com ela dá para comparar quanto cada motor concorda com a referência, mas ela não diz o acerto absoluto de cada um.
Alguns cuidados do método tornam os números comparáveis entre os motores:
- Cliente dentro do notebook, com tráfego local até o vLLM. Medindo a partir do Mac, a vazão mediria o Wi-Fi: a rede entre o Mac e o notebook chegou a cerca de 5 s por página só de envio.
- Limpeza antes das métricas: um script tira tags HTML, tokens <|…|> e caixas de grounding, para que a saída em HTML ou Markdown não suje o Jaccard. Em texto puro, ele não muda nada.
- Sinais de problema: a razão entre as letras da saída e as da referência, nas páginas com pelo menos 100 letras de referência, marca sobra quando passa de 2x e falta quando fica abaixo de 0,3x. Também conto as repetições que a referência não tem e as respostas cortadas no teto de 4096 tokens.
- Métricas: Jaccard, números e ordem (média e mediana), páginas sem texto útil e tempo por página.
- Aquecimento: uma página descartada por motor antes de começar a medir.
A rodada de uma página por vez
Para simplificar, algumas rodadas usaram concorrência 1 (conc 1): cada pedido ao vLLM levava uma página, e só um pedido ficava em andamento por vez. O ensaio parecia levar o dia todo, mesmo com modelos como o LightOnOCR-2, de 1 bilhão de parâmetros. O Unlimited-OCR levou 18 minutos na amostra geral e 26 na difícil com conc 1, contra 7 minutos na amostra geral com conc 8, ou seja, até 8 páginas ao mesmo tempo. O log do vLLM mostrava o cache KV abaixo de 29% de uso: a GPU estava sobrando, e o conc 1 só serializava o trabalho.
Ficou registrado que a vazão se mede com paralelismo (8 páginas no ensaio da 4070), porque, no uso previsto, o motor vai receber várias páginas ao mesmo tempo. Quem precisar de conc 1 para avaliar qualidade deve rodar só uma subamostra e avisar no relatório que aquele tempo não é a vazão com páginas em paralelo. E, antes de concluir que um motor é lento, vale olhar o cache KV no log do vLLM. Abaixo de uns 30% com conc 1, há espaço livre no cache KV; isso sozinho não indica que a GPU está ociosa, e o modelo não é necessariamente pesado.
Aqui a vazão com páginas em paralelo pesa tanto quanto a qualidade, porque a pergunta era se vale alugar uma GPU pela vazão. No RunPod, uma RTX 4090 sai a partir de US$ 0,34 por hora na Community Cloud e US$ 0,89 na Secure Cloud, em novembro de 2026.
O que os números mostraram
A tabela abaixo traz, para cada motor, a vazão com 8 páginas em paralelo, o Jaccard e as páginas sem texto útil da amostra difícil e o tempo de uma página isolada. O PaddleOCR-VL liderou a vazão, com 1,02 pág/s.
| Braço | Vazão com 8 em paralelo (pág/s) | Difícil: Jaccard | Difícil: páginas sem texto útil (de 63) | Tempo de 1 página |
|---|---|---|---|---|
| PaddleOCR-VL-1.6, só o VLM | 1,02 | 0,798 | 24 | 2,8 |
| Surya 2.5 | 0,84 | 0,800 | 19 | 4,9 |
| LightOnOCR-2-1B | 0,48 | 0,811 | 10 | 4,7 |
| Chandra OCR 2, AWQ 4 bits da comunidade | 0,26 | 0,800 | 8 | 14,8 |
| Unlimited-OCR, FP8 | 0,14 | 0,036 | 22 | 5,3 |
Fonte: Pesquisa de OCR da versão web do Fuad Next, ensaio na RTX 4070 de notebook (03/11/2026)commit 72203f191d5dMetodologiaBaixar JSONBaixar CSV
Na concordância com a referência, Surya, LightOnOCR e Chandra ficaram na frente. O LightOnOCR-2-1B teve mediana de Jaccard de 0,909 na página comum e de 0,811 na difícil. O Unlimited-OCR-2 em transformers, a cerca de 0,01 pág/s, é inviável na prática.
O gráfico abaixo cruza a vazão com o Jaccard da amostra difícil. O Unlimited-OCR (FP8) ficou fora dele: com Jaccard de 0,036 na amostra difícil, ele achataria a escala dos outros quatro, que ficaram entre 0,798 e 0,811.
Vazão com 8 em paralelo (pág/s)
Fora do gráfico: Unlimited-OCR, FP8 (Difícil: Jaccard 0,036, Vazão com 8 em paralelo (pág/s) 0,14)
Ver os números em tabela
| Braço | Difícil: Jaccard | Vazão com 8 em paralelo (pág/s) | Fronteira |
|---|---|---|---|
| LightOnOCR-2-1B | 0,811 | 0,48 | na fronteira |
| Surya 2.5 | 0,800 | 0,84 | na fronteira |
| PaddleOCR-VL-1.6, só o VLM | 0,798 | 1,02 | na fronteira |
| Chandra OCR 2, AWQ 4 bits da comunidade | 0,800 | 0,26 | fora da fronteira |
| Unlimited-OCR, FP8 | 0,036 | 0,14 | fora do gráfico |
Fonte: Pesquisa de OCR da versão web do Fuad Next, ensaio na RTX 4070 de notebook (03/11/2026)commit 72203f191d5dMetodologiaBaixar JSONBaixar CSV
O LightOnOCR-2-1B tem 2 GB de pesos. No vLLM 0.33 (torch 2.14, CUDA 13), com 8 páginas em paralelo, temperatura 0 e teto de 4096 tokens, ele fez 0,48 página por segundo e 4,7 s por página isolada, com a GPU entre 97% e 99% e o cache KV em até 29%.
Também medi a latência do Surya em 10 páginas da amostra geral: 5,89 s por página em média, com mediana de 4,94 s.
A frente de CPU foi descontinuada no mesmo dia, porque o ensaio é com GPU. Ela não chegou a medir vazão, e o Docling não rodou nas amostras. Os números de CPU (Tesseract, RapidOCR e LiteParse) ficam como referência de concordância, não de vazão.
| Braço | Difícil: Jaccard | Geral: Jaccard | Difícil: páginas sem texto útil (de 63) | Tempo de servidor por página |
|---|---|---|---|---|
| RapidOCR PP-OCRv6 small | 0,800 | 0,875 | 14 | 3,80 |
| RapidOCR PP-OCRv5 latino | 0,781 | 0,875 | 15 | 2,10 |
| Tesseract best | 0,660 | 0,860 | 24 | 1,20 |
| Tesseract fast | 0,633 | 0,854 | 24 | 1,00 |
| LiteParse (Tesseract fast) | 0,613 | 0,876 | 28 | 0,73 |
Fonte: Pesquisa de OCR da versão web do Fuad Next, ensaio na RTX 4070 de notebook (03/11/2026)commit 72203f191d5dMetodologiaBaixar JSONBaixar CSV
O que ficou decidido
Escolhi o LightOnOCR-2-1B. O PaddleOCR-VL-1.6 ficou como alternativa.
O ensaio tem um limite: a vazão numa GPU de servidor não foi medida. A 4070 de notebook dá para comparar qualidade, não para dimensionar a produção.
Medi os seis modelos e fechei o relatório da frente de GPU.
Num teste de carga de ponta a ponta feito depois, o serviço com o motor escolhido sustentou 0,848 pág/s em 768 páginas, sem nenhuma falha.
Rascunho de agente a partir das fontes listadas; revisado e aprovado por Lucas Fuad