OCR ilimitado da Baidu em um laptop com 8 GB: 25 testes

Ver no idioma original →

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Baidu’s Unlimited OCR on an 8GB Laptop: 25 Tests · Canal: Prompt Engineer 48 · 15:04 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Inferência e otimização de modelos, Modelos locais e open source, Modelos multimodais

Resumo

O vídeo testa o modelo de visão e linguagem Unlimited OCR, da Baidu, em 25 imagens criadas pelo autor, usando uma versão quantizada de 4 bits em uma GPU de 8 GB. O modelo se sai bem com texto impresso, código e layouts, mas também comete erros discretos em nomes, números e endereços de e-mail; recibos, matemática e alguns idiomas são pontos fracos. O modo de resolução altera bastante os resultados, e o modo base melhora alguns casos, mas piora outros. O autor conclui que a ferramenta merece ser testada para documentos comuns, mas recomenda conferir manualmente qualquer resultado importante e validar os próprios arquivos.

Pontos-chave

• A versão AWQ de 4 bits ocupa 2,83 GB em disco, mas o uso de memória de vídeo chegou a 6,8 GB durante a execução.
• O teste foi feito em 25 imagens próprias, com comparação caractere por caractere; a métrica é simples e não é um benchmark oficial.
• O modelo obteve correspondência exata em 8 imagens na primeira rodada; considerando o melhor modo de resolução por imagem, foram 9 correspondências exatas e média de 0,90.
• Texto impresso limpo, código, texto rotacionado e layouts em colunas tiveram bons resultados.
• Recibos com espaços largos entre itens e preços, equações e extração de valores de gráficos foram dificuldades recorrentes.
• O desempenho em idiomas não latinos foi desigual: houve bons resultados em japonês e russo, mas problemas em outros idiomas testados.
• O modo de resolução mudou o resultado em seis das sete imagens testadas novamente e nem sempre melhorou a leitura.
• Erros aparentemente plausíveis, como sobrenomes inventados, dígitos ausentes e e-mails incorretos, exigem conferência humana.

Capítulos

Início	Capítulo	Resumo
00:00	O modelo e a configuração do teste	O autor apresenta o Unlimited OCR, a versão quantizada e as limitações de memória do laptop.
03:07	Método de avaliação e primeiros testes	O vídeo explica a comparação de texto e mostra resultados iniciais com parágrafos, recibos, código e layouts.
06:13	Resultados dos 25 testes	São avaliados idiomas, matemática, texto pequeno, imagens degradadas, documentos, gráficos e símbolos.
10:57	Comparação entre modos de resolução	O autor reavalia sete casos em modo base e mostra que a mudança pode corrigir ou introduzir erros.
13:01	Placar e conclusão prática	O vídeo resume as pontuações, os pontos fortes e fracos e recomenda conferir resultados importantes.
14:33	Recomendação e encerramento	O autor delimita os usos recomendados e ressalta que os resultados vêm de uma única execução em um laptop.

Citações

Oito deles vieram perfeitos, e um inventou o nome de uma pessoa. — 00:00

Ele inventou um sobrenome. — 04:40

Os erros são discretos: um sobrenome errado, um dígito ausente, um e-mail incorreto. — 13:33

Uma resposta errada que parece certa é pior do que um erro evidente. — 14:03

Conceitos e entidades

• Unlimited OCR (modelo): Modelo de visão e linguagem da Baidu voltado à leitura e ao processamento de documentos.
• Baidu (empresa): Empresa responsável pelo modelo Unlimited OCR apresentado no vídeo.
• Sahil Chakra (pessoa): Autor da versão comunitária quantizada usada no teste.
• AWQ (conceito): Método de quantização usado na versão de 4 bits do modelo testado.
• Gundam (conceito): Modo de resolução que divide imagens em blocos para processar páginas grandes.
• base mode (conceito): Modo de resolução que processa a imagem em uma única passagem, sem divisão em blocos.
• Hugging Face (ferramenta): Plataforma onde o vídeo mostra a página do modelo.
• GitHub (ferramenta): Plataforma onde o código do projeto está hospedado.
• RunPod (empresa): Serviço de GPU mencionado pelo autor ao final do vídeo.

Tradução completa (pt-BR)

00:00 25 documentos, laptop de 18 GB. Oito deles voltaram perfeitos, letra por letra, e um deles inventou o nome de uma pessoa. Este é o OCR ilimitado da Baidu em uma versão de 4 bits que ocupa cerca de 2,8 GB. Não li os benchmarks. Criei 25 imagens de teste, executei cada uma delas na minha própria GPU e avaliei os resultados. Os bons são muito bons. As falhas são a parte interessante. Então, fique até elas. Primeiro, de onde isso vem. Esta é a página no Hugging Face do Baidu / Unlimited OCR. É um modelo de linguagem visual para parsing de documentos

00:32 com licença MIT, e a página mostra cerca de 4.500 curtidas e mais de 1 milhão de downloads. O código está no GitHub e, no dia em que gravei isto, tinha 27,2 mil estrelas, 2,9 mil forks, dois colaboradores e nenhuma versão marcada. Então, este é um lançamento recente de pesquisa, não um produto maduro. Tenha isso em mente. E aqui está um artigo no arXiv chamado “Unlimited OCR Works”. O resumo diz que o problema do OCR com modelos de linguagem é que o cache de key-value cresce à medida que a saída fica

01:04 mais longa, então a geração fica mais lenta. A solução deles se chama atenção de janela deslizante de referência, que mantém o cache constante, e eles dizem que ela consegue transcrever dezenas de páginas em uma única passagem, dentro de um limite de 32.000 tokens. Portanto, a alegação é que é possível processar documentos longos sem a lentidão. Não vou testar dezenas de páginas hoje. Vou testar aquilo com que a maioria de vocês realmente se importa. Ele lê corretamente uma imagem comum em um laptop comum? Para caber na minha placa, estou usando uma versão quantizada pela comunidade, feita por Sahil Chakra. Esta é a página. Ela tem pesos AWQ

01:35 de 4 bits com ativações de 16 bits, e o arquivo do modelo tem 2,83 GB. O original ocupa 6,3 GB no disco. Agora, um detalhe importante se você tem uma placa de 8 GB. Quando carreguei o modelo, levou 12,9 segundos e usou 2,6 GB de memória de vídeo. Mas, depois da primeira imagem, o uso de memória chegou ao pico de 6,8 GB; a biblioteca descomprime os pesos de volta para 16 bits durante a execução. Então, o arquivo é pequeno, mas o uso durante a execução não é. Isso apareceu logo de cara. Minha primeira execução completa com as 25 imagens

02:05 fez sete delas falharem com o erro CUDA out of memory em uma placa de 8 GB. Limpei o cache entre as imagens e executei novamente apenas essas sete. Esses são os números que você vai ver. Também tentei usar o modelo original de 16 bits neste laptop, mas ele travou com um segmentation fault ao carregar. Não investiguei o motivo, então não vou especular. Mais uma coisa, para ser transparente: minha primeira tentativa retornou strings vazias para seis imagens e ficou presa em uma geração longa para outra. Mudei quatro coisas de uma vez: o prompt para o de parsing de documentos nativo, o modo de resolução

02:35 para Gundam, a configuração de no repeat n-gram indicada no readme e um limite de 8.000 tokens para a saída. Depois disso, funcionou. Não posso dizer qual das quatro mudanças resolveu, porque não as testei isoladamente. Como fiz a avaliação: cada imagem tem o texto exato que desenhei nela. Depois que o modelo responde, removo as tags de caixas delimitadoras e comparo as duas strings caractere por caractere com o SequenceMatcher do Python. Um significa que são idênticas. Esta é uma métrica simples que criei, não um benchmark oficial. Então, use-a para comparar os testes entre si, não com o artigo. Aqui está tudo em código, porque

03:07 é mais curto do que você imagina. Carregue o tokenizer e o modelo com trust remote code e bfloat16 na CUDA; depois, uma chamada a model.infer com o tokenizer, um prompt, o arquivo de imagem, um tamanho base de 1.024 e o tamanho da imagem e o modo de recorte que escolhem entre Gundam e base. Com a flag eval ativada, ele retorna o texto como uma string. Uma observação sobre a velocidade, porque você vai querer um número. Meus tempos por imagem vão de 3,4 segundos para a placa de estacionamento até 62 segundos para a página densa, e a maioria fica entre 5 e 30. Mas eu estava fazendo isso com um navegador e um editor abertos numa placa compartilhada de 8 GB, sob a pressão de memória que descrevi. Então, este não é um benchmark controlado. Ele mostra que um laptop consegue fazer isso, não quão rápido um servidor ajustado faria. Uma nota rápida sobre os prompts. O cartão do modelo lista um pequeno vocabulário: free OCR para texto simples, document parsing para o modo nativo, convert the document to markdown with the grounding tag para layout, parse the figure para gráficos e um prompt locate para encontrar uma frase e obter sua caixa. Neste vídeo, usei apenas

03:37 document parsing e o prompt markdown em uma tabela, nas duas colunas e nas notas de versão. Na minha primeira tentativa, usei free OCR na primeira imagem, e ele deixou de fora uma linha do meio, mas não repeti o teste com as configurações finais, então não vou comparar os prompts. Isso fica para outro vídeo.

04:10 Teste um: um parágrafo limpo de três linhas, Arial de 34 pixels, pontuação 1,0, correspondência exata. Levou 18 segundos, mas esta foi a primeira imagem, então esse tempo inclui a espera única pela descompressão. Você pode ver que o modelo retorna o parágrafo inteiro

04:40 com uma caixa delimitadora ao redor. Teste dois: uma fatura em fonte monoespaçada, pontuação 0,97. Olhe para a segunda linha. Escrevi “Bill to Sahil Chakra”, e o modelo leu “Sahil Achanta”. Ele inventou um sobrenome. É um modelo de 4 bits, e não posso dizer se o modelo completo faria o mesmo, mas, em uma fatura, esse é exatamente o tipo de erro que custa dinheiro. Teste três: um recibo de cafeteria, 0,79, e esta é a primeira falha de verdade. Latte 450 está certo; depois, a linha do croissant vira c.450,

05:10 depois c.5, e os totais desaparecem. Os recibos com grandes espaços entre o item e o preço foram onde ele se saiu mal. Teste quatro: uma fonte que imita escrita à mão, 0,99. É uma fonte desse tipo, não escrita real com caneta, então não interprete isso como reconhecimento de escrita à mão. Ele leu “Dear Sam”, o horário e “Priya”. Acrescentou um travessão antes de “bring”, que eu não escrevi. Teste cinco: código em um editor escuro, correspondência exata, 1,0. A indentação do corpo do loop e o comentário com cerquilha estão todos lá. Para quem extrai código de capturas de tela, este resultado é

05:42 animador. Mais uma coisa para observar antes do próximo bloco. Esta é a resposta bruta para a página de notas de versão, antes de eu remover qualquer coisa. Cada trecho de texto vem acompanhado de uma tag com um rótulo, como title ou text, e quatro números, que são as coordenadas esquerda, superior, direita e inferior da caixa em uma grade. Então, você não recebe apenas as palavras: também recebe a posição delas na página. É isso que permite reconstruir um layout ou destacar um campo, e é por isso que removo as tags apenas para a avaliação. Teste seis: uma tabela com o estilo de prompt markdown. 0,82; a estrutura está

06:13 certa, com barras verticais e quatro linhas, mas o cabeçalho diz param em vez de params, as unidades de velocidade voltam com T maiúsculo e a última linha termina em t/u. Estrutura boa, caracteres pequenos errados. Teste sete: idiomas europeus, um por linha, 0,56, e foi aqui que fiquei preocupado. Hello world está certo. Bonjour le monde e hallo welt voltam como a única palavra environ. Hola mundo vira hola m. A linha em russo está perfeita; a grega está quase toda errada. Lembre-se deste teste, porque vou voltar a ele. Teste oito: chinês, japonês,

06:45 coreano: 0,73. A frase em japonês está exata. Na linha em chinês, ele omitiu os dois primeiros caracteres, e a linha em coreano está vazia, então apenas uma das três ficou totalmente correta. Teste nove: hindi, 0,64. Começou certo, namaste, e depois se desviou. A segunda linha apareceu duas vezes, com grafias diferentes. Se seus documentos usam escritas índicas, teste suas próprias amostras antes de confiar nesta versão. Teste 10: matemática, 0,59. Ele me dá LaTeX, que é o formato correto, e a primeira equação, e = mc ao quadrado, está quase certa. O dois está reto. A

07:15 fórmula quadrática mantém o mais ou menos, mas escreve a raiz quadrada como letras separadas, sqrt, e uma linha de somatório está errada. Ainda não use isto para equações. Teste 11: texto pequeno, de 16 pixels, cinco linhas da mesma frase, 0,91. Mas olhe mais de perto: desenhei cinco linhas e ele retornou seis. Acrescentou uma. Texto pequeno, linha extra. Teste 12: baixo contraste, cinza sobre cinza, 0,37. A menor pontuação do grupo difícil; o texto de baixo contraste voltou como “LOW CONTRACT TEXT”, em maiúsculas. E a última linha termina em “should still cowl”.

07:48 Ele lê o formato e adivinha o resto. Guardem este também. Teste 13, uma frase girada em 12°. 1,0. Eu esperava que falhasse. Não falhou. Correspondência exata. Frase completa. Teste 14, ruído e desfoque. 0,99. Duas linhas, com ruído e desfoque gaussiano. Uma letra errada. Ele escreveu PCR onde eu escrevi OCR. Engraçado, já que essa é a única palavra que ele deveria conhecer. Teste 15, duas colunas. 1,0. Primeiro a coluna da esquerda, depois a da direita. A ordem de leitura está correta, e ele me deu duas caixas separadas

08:19 de texto. O layout é um dos pontos fortes aqui. Teste 16, uma página de notas de lançamento com um título e uma lista com marcadores. prompt de Markdown. 1,0. Título, três marcadores e o endereço de email, tudo correto. Se o seu objetivo é obter Markdown a partir de uma captura de tela, este é o cenário ideal. Teste 17, números de pedido, um código de rastreamento, um número de telefone e um IBAN. 0,95. O IBAN, o telefone e o número de rastreamento estão exatos, mas faltou um dígito no número do pedido. 88-1204-771. E há uma linha de caracteres chineses aleatórios no topo que eu nunca desenhei.

08:50 Verifique os números. Teste 18, uma placa azul de estacionamento. 1,0. Letras grandes, brancas e em negrito. Proibido estacionar. Exato. Teste 19, um slide de apresentação. 0,94. Três marcadores. Exatos. O título, “Por que os modelos locais são importantes”, saiu como “YIN models MA”. O título grande e amarelo sobre o fundo escuro foi a parte que falhou, e o texto pequeno do corpo ficou certo. Teste 20, um formulário. 0,86. Nome, data de nascimento e telefone estão corretos. A cidade, Pune,

09:22 voltou como dois caracteres chineses, e a linha da assinatura virou as palavras “sem texto” entre colchetes. Eu deixei a linha da assinatura vazia, então dá para dizer que isso foi, de certa forma, honesto. Teste 21, uma página densa. 14 repetições da mesma frase, com 26 pixels; 0,79 e 62 segundos, o mais lento da rodada. Como a mesma frase se repete, o mecanismo contra repetição também pode estar lutando contra o próprio texto. Eu não usaria minha pontuação aqui como prova de nada, além de que saídas longas são mais lentas. Teste 22, fontes variadas em uma linha: negrito,

09:54 itálico, monoespaçada, serifada, estilo de quadrinhos; 1,0, todas as palavras na ordem. Teste 23, um gráfico de barras com a ideia de interpretar a figura, 0,4. Ele encontrou um título e desenhou uma caixa de gráfico em volta das barras, mas não leu os valores 122 10 170 300. Então, ele detecta o gráfico. Não extrai os dados com o prompt de análise de documentos. Enfim, não testei o outro prompt de gráfico nesta rodada. Teste 24, texto branco sobre um gradiente colorido, 1,0. Teste 25, símbolos: sinal de euro, porcentagem,

10:26 graus e email, 0,9. O preço em euros, a porcentagem e o intervalo de temperatura com o símbolo de grau estão todos exatos. O email voltou como “I I k a n at prompt at e.com”. Formato certo, endereço errado. A mesma lição da fatura. Confira nomes e emails. Antes de mostrar o placar, quero voltar aos piores resultados, porque algo me incomodou. Todas essas 25 imagens são pequenas, com cerca de 1.000 pixels de largura. O modo que usei, Gundam, foi projetado para páginas grandes e recorta a imagem em blocos. Então, peguei as

10:57 sete imagens com os piores resultados ou mais suspeitas e rodei de novo no modo base. Mesmo modelo, mesmo prompt, só mudou a configuração de resolução. Sem divisão em blocos, uma passagem em 1.024. Texto de baixo contraste: este foi o resultado de 0,37 na primeira rodada. No modo base, a resposta é “texto de baixo contraste é difícil de ler, mas o modelo ainda deveria conseguir”. Correspondência exata, 1,0. A falha inteira no teste 12 foi causada pela divisão em blocos, não pelo modelo nem pelos pesos de quatro bits. Idiomas europeus: de 0,56 para 0,85.

11:28 “Bonjour le monde” voltou, e “hallo welt” voltou. “Hola mundo” agora é “hola mono”, então ainda está errado por uma letra, e a linha em grego continua errada. Ele volta em letras cirílicas, algo como “Geza Ukozi”. Então, não leu aquilo como grego de jeito nenhum. Um grande salto, mas ainda não está certo. Hindi: de 0,64 para 0,82. Menos linhas duplicadas, e a segunda linha agora está em uma linha, não em duas, mas as palavras ainda não estão certas. “Namaste Dunathi” em vez de “Namaste Duniya”: melhorou, mas não corrigiu. Agora, o oposto. O slide de apresentação

11:58 teve 0,94 no modo Gundam. No modo base, caiu para 0,8. O título agora está certo, mas veja o segundo marcador: “cost no per token bill” virou “cost:” seguido de um sublinhado em LaTeX e da palavra “not” duas vezes. Ele inventou formatação matemática dentro de um marcador. Então, o modo base não é estritamente melhor. Corrigiu algumas imagens e piorou outras. O recibo não mudou nada: 0,79 nos dois modos. As mesmas linhas “C.450” e “C.5”. Então, a resolução não era o problema nesse caso. Acho que é o grande espaço

12:29 entre o nome e o preço, mas é só um palpite. Não testei isso. E matemática: 0,59 contra 0,58, nada mudou. E o gráfico: no modo base, a pontuação sobe para 0,62. Mas veja o que ele retorna: o título e depois algumas linhas vazias. Ainda não lê os valores. A pontuação só subiu porque ele parou de escrever a marcação errada. Ainda não consegue ler as barras com este prompt. Então, aqui vai a lição prática. O modo de resolução mudou a resposta em seis das sete imagens, e nem sempre na mesma direção. Para imagens pequenas, tente primeiro o modo base. Para páginas grandes, Gundam. E, se a resposta for importante, rode nos dois modos e compare. Não testei isso com páginas grandes, então essa última parte é uma regra prática tirada do readme, não dos meus dados. Então, aqui está o placar, com os 25 testes. Na primeira rodada, com o modo Gundam, oito foram exatos, 15 tiveram pontuação de 0,9 ou mais, e a média foi 0,85. Depois da segunda rodada, se eu considerar o melhor dos dois modos para cada imagem, nove são exatos, 16 têm pontuação de 0,9 ou mais, e a média sobe para 0,90. No fim da lista estão matemática, o gráfico, a linha em chinês, o recibo, a página densa, a tabela e

13:01 o hindi. Deixe-me reunir as quatro conclusões em um só lugar antes do veredito. Uma: texto impresso nítido, código e layout voltaram exatos ou quase exatos. Duas: o modo de resolução é uma configuração de verdade, capaz de mudar uma pontuação de 0,37 para 1,0, então não é um detalhe. Três: os erros são discretos: um sobrenome errado, um dígito faltando, um email errado. Quatro: uma placa de 8 GB funciona, mas no limite, porque os pesos de quatro bits são descompactados para 16 bits durante a execução. Pelo que meus dados mostram, ele é bom em texto impresso nítido,

13:33 código, texto girado, layout em duas colunas, placas e slides grandes, páginas em Markdown, fontes variadas e baixo contraste. Depois que uso o modo base, o que ele não faz bem: recibos com espaços grandes, equações, valores de gráficos e os sistemas de escrita não latinos que testei, com exceção do japonês e do russo. As falhas também seguem um padrão. Quase nunca retorna um amontoado de caracteres sem sentido. Retorna texto confiante e bem formado, mas ligeiramente errado: um sobrenome inventado, um dígito faltando, um email com “e.com”. Uma resposta errada que parece certa é pior do que um erro. Então,

14:03 qualquer coisa com nomes, números ou emails precisa de uma verificação humana ou de uma segunda passagem. Você deveria usar? Se quiser transformar capturas de tela nítidas, código, slides e documentos comuns em Markdown na sua própria máquina, sim, vale a pena dedicar uma tarde a isso. Se precisar de recibos exatos, sistemas de escrita índicos ou matemática, teste primeiro suas próprias amostras nos dois modos e talvez experimente o modelo de 16 bits em uma placa maior. Não consegui fazer isso neste laptop. Tudo neste vídeo é resultado real da minha própria execução, usando arquivos do meu disco. As imagens de teste, as respostas do modelo e as pontuações foram todas geradas pelos scripts, e eu não editei a saída do modelo. Foi uma execução, um laptop e uma quantização do modelo, então encare isto como uma primeira análise, não como um veredito sobre o modelo da Baidu. Se você está procurando GPUs baratas e confiáveis, eu uso RunPod, e o link está na descrição. É isso. Inscreva-se, porque em seguida quero executar o modo de várias páginas em um PDF real e ver se a alegação sobre memória constante se confirma. E conte nos comentários com qual documento devo colocá-lo à prova. Até o próximo vídeo.

14:33 Qualquer coisa com nomes, números ou e-mails precisa de revisão humana ou de uma segunda passada. Você deveria usar isso? Se quiser transformar capturas de tela, código, slides e documentos comuns bem organizados em Markdown na sua própria máquina, sim, vale a pena dedicar uma tarde a isso. Se precisar de recibos exatos, de escritas índicas ou de matemática, teste primeiro suas próprias amostras nos dois modos e talvez experimente o modelo de 16 bits em uma placa maior. Não consegui fazer isso neste laptop. Tudo neste vídeo é resultado real da minha própria execução, com arquivos do meu disco. As imagens de teste

15:04 de teste, as respostas do modelo e as pontuações foram todas geradas pelos scripts, e eu não editei a saída do modelo. Foi uma execução, um laptop e uma quantização do modelo, então encare isto como uma primeira impressão, não como um veredito sobre o modelo da Baidu. Se estiver procurando GPUs baratas e confiáveis, eu uso a RunPod, e o link está na descrição. É isso. Inscreva-se, porque da próxima vez quero executar o modo de várias páginas em um PDF real e ver se a alegação de memória constante se confirma. E me diga nos comentários com qual documento devo testá-lo até quebrar. Até a próxima.

Transcrição original

[00:00] 25 documents, 18GB laptop. Eight of them came back letter perfect and one of them made up a person’s name. This is unlimited OCR from Baidu in a 4-bit version that fits in about 2.8GB. I did not read the benchmarks. I made 25 test images, ran every one of them on my own GPU and scored what came out. The good ones are really good. The failures are the interesting part. So, stay for those. First, where this comes from. This is the Hugging Face page for Baidu {slash} unlimited OCR. It is a vision language

[00:32] model for document parsing, MIT license, and the page shows about 4,500 likes and over 1 million downloads. The code lives on GitHub and on the day I recorded this, it shows 27.2 thousand stars, 2.9 thousand forks, two contributors, and no tagged releases. So, this is a fresh research drop, not a mature product. Keep that in mind. And here’s a paper on arXiv called unlimited OCR works. The abstract says the problem with language model OCR is that the key value cache grows as the output gets

[01:04] longer, so generation slows down. Their fix is called reference sliding window attention, which keeps the cache constant, and they say it can transcribe dozens of pages in a single pass under a 32,000 token limit. So, the claim is long documents without the slowdown. I’m not going to test dozens of pages today. I’m going to test the thing most of you actually care about. Does it read a normal image correctly on a normal laptop? To fit it on my card, I’m using a community quantized version by Sahil Chakra. This is the page. It is AWQ

[01:35] 4-bit weights with 16-bit activations, and the model file is 2.83GB. The original on disk is 6.3. Now, here’s a detail that matters if you have an 8GB card. When I loaded it, it took 12.9 seconds and used 2.6GB of video memory. But, after the first image, memory peaked at 6.8, the library decompresses the weights back to 16-bit as it runs. So, the file is small, the run time is not that showed up right away. My first full run on all 25 images

[02:05] had seven of them die with CUDA out of memory on an 8-GB card. I cleared the cache between images and re-ran only those seven. Those are the numbers you will see. I also tried the original 16-bit model on this laptop and it crashed with a segmentation fault at load. I did not dig into why, so I’m not going to guess. One more honest thing, my very first attempt returned empty strings for six images and got stuck on a long generation for another. I changed four things at once, the prompt to the native document parsing one, the resolution

[02:35] mode to Gundam, the no repeat n-gram setting from the read me, and a cap of 8,000 tokens on the output. After that, it worked. I cannot tell you which of the four did it because I did not isolate them. How I scored it, each image has the exact text I drew on it. After the model answers, I stripped the bounding box tags and compared the two strings character by character with Python sequence matcher. One means identical. This is my own simple metric, not an official benchmark. So, use it to compare tests against each other, not against the paper. Here is the whole thing in code because

[03:07] it is shorter than you would think. Load the tokenizer and the model with trust remote code bfloat16 on CUDA, then one call model.infer with the tokenizer, a prompt, the image file, a base size of 1,024, and the image size and crop mode that choose between Gundam and base. With the eval flag on, it hands you the text back as a string. A word on speed because you’ll want a number. My per image times run from 3.4 seconds for the parking sign up to 62 seconds for the

[03:37] dense page, and most are between 5 and 30. But, I was doing this with a browser and an editor open on a shared 8-GB card with the memory pressure I described. So, this is not a clean benchmark. It tells you a laptop can do it, not how fast a tuned server would. Quick note on prompts. The model card lists a small vocabulary, free OCR for plain text, document parsing for the native mode, convert the document to markdown with the grounding tag for layout, parse the figure for charts, and a locate prompt to find one phrase and get its box. In this video, I only used

[04:10] document parsing and the markdown prompt on a table, the two columns, and the release notes. My very first one used free OCR on the first image, and it dropped a middle line, but I did not repeat that with the final settings, so I will not compare the prompts. That is a test for another video. Test one, a clean three-line paragraph, Arial 34 pixels, score 1.0, exact match. It took 18 seconds, but this was the first image, so that includes the one-time wait decompression. You can see the model returns the whole paragraph

[04:40] with a bounding box around it. Test two, an invoice in a monospace font, score 0.97. Look at the second line. I wrote “Bill to Sahil Chakra”, and the model read “Sahil Achanta”. It invented a surname. It is a four-bit model, and I cannot say if the full one would do the same, but for an invoice, that is exactly the kind of mistake that costs money. Test three, a cafe receipt, 0.79, and this is the first real failure. Latte 450 is right, then the croissant line becomes c.450,

[05:10] then c.5, and the totals are gone. Receipts with wide gaps between the item and the price are where it fell apart for me. Test four, a handwriting style font, 0.99. This is a handwriting font, not a real pen, so do not read this as handwriting recognition. It did read “Dear Sam”, the time, and “Priya”. It added a dash before “bring”, which I did not write. Test five, code in a dark editor, exact match 1.0. The indentation for the loop body and the hash comment are all there. For anyone pulling code out of screenshots, this one is

[05:42] encouraging. One more thing to look at before the next block. This is the raw answer for the release notes page before I strip anything out. Every piece of text comes with a tag that with a label like title or text and four numbers, which are the box left, top, right, bottom on a grid. So, you do not only get the words, you get where they sit on the page. That is what lets you rebuild a layout or highlight a field and it is why I strip the tags only for scoring. Test six, a table with the markdown prompt style. 0.82, the structure is

[06:13] right, pipes and four rows, but the header says param instead of params and the speed units come back with a capital T and the last row ends in t/u. Structure good, small characters wrong. Test seven, European languages one per line 0.56 and this is where I got worried. Hello world is fine. Bonjour le monde and hallo welt both come back as the single word environ. Hola mundo becomes hola m. The Russian line is perfect, the Greek is mostly wrong. Remember this one because I come back to it. Test eight, Chinese, Japanese,

[06:45] Korean 0.73. The Japanese sentence is exact. In the Chinese line it dropped the first two characters and the Korean line is empty, so one out of three fully. Test nine, Hindi 0.64. It started right, namaste, then drifted. The second line came out twice with different spellings. If your documents are Indic scripts, test your own samples before you trust this build. Test 10, math 0.59. It gives me LaTeX, which is the correct format and the first equation e = mc squared is almost there. It has a straight two. The

[07:15] quadratic formula keeps the plus minus, but writes the square root as separate letters as sqrt and a summation line is wrong. Do not use this for equations yet. Test 11, tiny text 16 pixels, five lines of the same sentence 0.91. But look closer, I drew five lines and it returned six. It added one. Small text, extra line. Test 12, low contrast gray on gray 0.37. The lowest score in the hard group, low contrast text came back as low contract text in capitals. And the last line ends in should still cowl.

[07:48] It reads the shape and guesses the rest. Hold on to this one, too. Test 13, a sentence rotated 12°. 1.0. I expected this to fail. It did not. Exact match. Full sentence. Test 14, noise and blur. .99. Two lines, noisy, blurred with a Gaussian. One wrong letter. It wrote PCR where I wrote OCR. Funny, since it is the one word it should know. Test 15, two columns. 1.0. Left column first, then the right. The reading order is correct, and it gave me two separate

[08:19] boxes. Layout is one of the strong points here. Test 16, a release notes page with a heading and a bullet list. Markdown prompt. 1.0. Heading, three bullets, and the email address, all correct. If your goal is markdown out of a screenshot, this is the happy path. Test 17, order numbers, a tracking code, a phone number, and an IBAN. .95. The IBAN, the phone, and the tracking number are exact, but the order number lost a digit. 88-1204-771. And there’s a line of random Chinese

[08:50] characters at the top that I never drew. Verify numbers. Test 18, a blue parking sign. 1.0. Large white bold letters. No parking. Exact. Test 19, a presentation slide. .94. Three bullets. Exact. The title, Why local models matter, came out as YIN models MA. The big yellow title on a dark background was the part that broke, and the small body text was fine. Test 20, a form. .86. Name, date of birth, and phone are correct. The city, Pune,

[09:22] came back as two Chinese characters, and the signature line became the words no text in brackets. I put an empty signature line, so that is arguably honest. Test 21, a dense page. 14 repeats of the same sentence at 26-pixels, 0.79 and 62 seconds, the slowest of the run. Because the same sentence repeats, the repeat guard may also be fighting the text itself. I would not use my score here as proof of anything except that long outputs are slower. Test 22, mixed fonts in one line, bold,

[09:54] italic, mono, serif, comic, 1.0, every word in order. Test 23, a bar chart with the parse the figure idea, 0.4. It found a title and it drew a chart box around the bars, but it did not read the values 122 10 170 300. So, it detects the chart. It does not extract the data with the document parsing prompt. Anyway, I did not test the other chart prompt in this run. Test 24, white text over a color gradient, 1.0. Test 25, symbols, euro sign, percent,

[10:26] degrees, and email, 0.9. The euro price, the percent, and the temperature range with the degree sign are all exact. Email came back as I I k a n at prompt at e.com. Right shape, wrong address. Same lesson as the invoice. Names and emails, check them. Before I give you the scoreboard, I want to go back to the worst ones because something bothered me. Every one of these 25 images is small, around 1,000 pixels wide. The mode I used, Gundam, is designed for large pages and it crops the image into tiles. So, I took the

[10:57] seven worst or most suspicious images and ran them again in base mode. Same model, same prompt, only the resolution setting changed. No tiling, one pass at 1,024. Low contrast text, this was the 0.37 in round one. In base mode, the answer is low contrast text is hard to read, but the model should still get it. Exact match, 1.0. The whole failure in test 12 was the tiling, not the model, and not the four-bit weights. European languages, 0.56 goes to 0.85.

[11:28] Bonjour le monde is back and hallo welt is back. Hola mundo is now hola mono, so it is still wrong by one letter and the Greek line is still wrong. It comes back in Cyrillic letters something like Geza Ukozi. So, it did not read it as Greek at all. Big jump, still not clean. Hindi, 0.64 goes to 0.82. Fewer duplicate lines and the second line is now one line, not two, but the words are still not right. Namaste Dunathi instead of Namaste Duniya, better not fixed. Now, the opposite. The presentation

[11:58] slide was 0.94 in Gundam. In base mode, it drops to 0.8. The title is now right, but look at the second bullet, cost no per token bill becomes cost colon and then a LaTeX underline and the word not twice. It invented math formatting inside a bullet. So, base mode is not strictly better. It fixed some images and broke others. The receipt, no change at all, 0.79 in both. The same C.450 and C.5 lines. So, the resolution was not the problem there. I think it is the wide gap

[12:29] between name and price, but that is a guess. I did not test it. And math, 0.59 against 0.58, nothing changed. And the chart, in base mode, the score goes up to 0.62. But look at what it returns, the title and then a few empty lines. It still does not read the values. The score went up only because it stopped writing the wrong markup. It still cannot read the bars with this prompt. So, here is the practical lesson. Resolution mode changed the answer on six of seven images and not always in the same direction. For small images, try base mode first. For big

[13:01] pages, Gundam. And if the answer matters, run both and compare them. I did not test that on any big pages, so that last part is a rule of thumb from the readme, not from my data. So, here is the scoreboard, all 25. In round one, with Gundam mode, eight were exact, 15 scored 0.9 or better, and the average was 0.85. After round two, if I take the better of the two modes for each image, nine are exact, 16 are 0.9 or better, and the average goes up to 0.90. The bottom of the list is math, the chart, the Chinese line, the receipt, the dense page, the table, and

[13:33] Hindi. Let me put the four findings in one place before the verdict. One, clean printed text, code, and layout came back exact or close to it. Two, the resolution mode is a real setting that can move a score from 0.37 to 1.0, so it is not a detail. Three, the errors are quiet, a wrong surname, a missing digit, a wrong email. Four, an 8 GB card works, but only just because the four-bit weights unpack to 16-bit when it runs. What it is good at from my data, clean

[14:03] printed text, code, rotated text, two-column layout, big signs and slides, markdown pages, mixed fonts, and low contrast. Once I use base mode, what it is bad at, receipts with wide gaps, equations, chart values, and the non-Latin scripts I tried other than Japanese and Russian. The failures also have a pattern. It almost never returns garbage. It returns confident, well-formed text that is slightly wrong, a fake surname, a missing digit, an email at e.com. A wrong answer that looks right is worse than an error. So,

[14:33] anything with names, numbers, or emails needs a human check or a second pass. Should you use it? If you want to turn clean screenshots, code, slides, and normal documents into markdown on your own machine, yes, this is worth an afternoon. If you need exact receipts, Indic scripts, or math, run your own samples first in both modes, and maybe try the 16-bit model on a bigger card. I could not on this laptop. Everything in this video is real output from my own run from files on my disk. The test

[15:04] images, the model answers, and the scores are all generated by the scripts, and I did not edit the model output. This was one run, one laptop, one model quant, so treat it as a first look, not a verdict on Baidu’s model. If you’re looking for cheap and reliable GPUs, I use RunPod, and the link is in the description. That is it. Subscribe because next I want to run the multi-page mode on a real PDF and see if the constant memory claim holds. And tell me in the comments what document I should break it with. See you in the next one.