Este modelo local de OCR com 1,2B supera o GPT-5.2 e roda em GPU de 8 GB — TeleOCR

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: This Local 1.2B OCR Model Beats GPT-5.2 (and Runs on 8GB GPU) — TeleOCR · Canal: Prompt Engineer 48 · 17:43 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Modelos locais e open source, Modelos multimodais, Open source e ecossistemas de software

Resumo

O vídeo apresenta o TeleOCR, um modelo de 1,2 bilhão de parâmetros para interpretar documentos, inclusive fotos inclinadas, dobradas ou com sombras, que pode rodar localmente com cerca de 2,5 GB de VRAM. O apresentador explica sua abordagem em duas etapas, que usa polígonos para representar o contorno dos blocos de texto, e resume os dados de treinamento e os resultados em benchmarks. Em testes próprios, o modelo extraiu texto, tabelas, fórmulas, código e dados de gráficos, mas falhou ao tentar ler uma página fotografada inteira em uma única etapa. O vídeo também mostra como montar um pipeline local para detectar o layout, processar cada bloco e reunir o resultado em Markdown, além de apontar limitações de velocidade e de leitura de textos pequenos muito deformados.

Pontos-chave

O TeleOCR tem 1,2 bilhão de parâmetros, ocupa cerca de 2,7 GB em disco e usou aproximadamente 2,53 GB de VRAM no teste descrito.
Segundo os resultados apresentados, ficou em primeiro lugar no OmniDocBench 1.6 e no Wild OmniDocBench, além de alcançar resultados de destaque em outros benchmarks.
O modelo separa a detecção do layout da leitura dos blocos e representa seus contornos com polígonos, em vez de presumir que sejam retângulos.
O pipeline de treinamento combina dados rotulados por consenso entre modelos, deformações sintéticas de páginas, verificação visual e treinamento em quatro etapas.
O modelo pode extrair tabelas com células mescladas, representar fórmulas em LaTeX, reconhecer código e converter gráficos científicos em tabelas.
Ler uma foto de página inteira em uma única etapa produziu resultados ruins; o apresentador recomenda detectar o layout primeiro e processar cada bloco separadamente.
No laptop com RTX 4060, a execução com transformers alcançou cerca de 14 tokens por segundo, e o processamento de páginas completas variou de 40 segundos a 3 minutos.
O modelo é voltado para chinês e inglês; em textos pequenos e muito deformados, pode trocar alguns caracteres.

Capítulos

Início	Capítulo	Resumo
00:00	Apresentação do TeleOCR e resultados anunciados	O vídeo demonstra a leitura de uma conta fotografada e apresenta o modelo, seus requisitos locais e seus resultados no OmniDocBench.
01:06	Como o modelo lida com documentos fotografados	O apresentador compara abordagens de análise de documentos e explica o uso de polígonos para representar blocos curvos.
03:10	Dados, arquitetura e treinamento	O vídeo descreve os componentes do TeleOCR e seis técnicas de treinamento, incluindo consenso entre modelos e verificação por imagens.
06:15	Benchmarks e instalação local	São apresentados resultados em diferentes benchmarks e as dependências, configurações e requisitos de memória para executar o modelo.
08:21	Testes com texto, tabelas, fórmulas e código	O apresentador testa tarefas específicas do modelo e avalia exemplos de texto, tabelas, fórmulas, código, gráficos e layout.
11:28	Testes próprios e pipeline em duas etapas	Os testes incluem documentos manuscritos ou deformados; após uma falha na leitura da página inteira de uma vez, o apresentador monta um pipeline por blocos.
15:07	Interface, velocidade e limitações	O vídeo mostra uma interface local, discute desempenho e limitações e resume possíveis usos do TeleOCR para processar documentos em privado.

Citações

Este modelo minúsculo encontrou cada bloco da conta e leu tudo de volta para mim como Markdown limpo. — 00:00

Em vez de uma caixa com dois cantos, ele prevê um polígono, um conjunto de pontos que acompanha o formato curvo real do bloco de texto. — 02:06

Este modelo não foi feito para ler uma foto inteira de uma só vez. — 13:00

Em textos pequenos muito deformados, alguns caracteres saem errados. — 16:40

Conceitos e entidades

TeleOCR (modelo): Modelo de OCR para documentos que detecta blocos e extrai seu conteúdo, inclusive em páginas fotografadas e deformadas.
Xingchen AGI (empresa): Organização indicada como responsável pelo modelo TeleOCR.
China Telecom (empresa): Empresa cuja equipe de pesquisa em IA é apresentada como responsável pelo desenvolvimento do TeleOCR.
OmniDocBench (benchmark): Benchmark de análise de documentos usado no vídeo para comparar o TeleOCR com outros modelos.
Doc3D (repo): Conjunto de dados citado como fonte de mapas de deformação usados para criar páginas sintéticas.
Qwen2.5-VL (modelo): Modelo citado como origem do encoder visual do TeleOCR e como base do modelo usado para julgar verificações visuais.
Qwen3-0.6B (modelo): Modelo de linguagem indicado no vídeo como componente do TeleOCR.
vLLM (ferramenta): Ferramenta usada no pipeline oficial do TeleOCR para processar os blocos em paralelo.
Transformers (ferramenta): Biblioteca usada pelo apresentador para carregar o modelo e adaptar o pipeline para Windows.
llama.cpp (ferramenta): Projeto citado como opção para executar uma conversão comunitária do modelo no formato GGUF.
Gradio (ferramenta): Ferramenta usada para criar uma interface local que recebe imagens e exibe o layout e o Markdown extraído.
Tesseract OCR (ferramenta): Sistema de OCR mencionado como referência em um dos exemplos de texto extraído.

Tradução completa (pt-BR)

00:00 Certo. Neste vídeo, vamos conhecer o TeleOCR, e você pode ver o que ele está fazendo aqui. Esta é uma foto de uma conta de restaurante tirada de um ângulo, sobre uma mesa com sombras. Este modelo minúsculo encontrou cada bloco da conta: o título, o endereço, a tabela de itens, os impostos e o total. Depois, transcreveu tudo para mim em Markdown bem organizado, com os itens em uma tabela adequada e todos os números corretos. Vale lembrar que tudo o que você vai ver neste vídeo está rodando no meu sistema local, neste laptop com uma RTX 4060, que tem apenas 8 GB de VRAM.

00:34 O modelo inteiro ocupa cerca de 2,5 GB. Então, não se trata de um modelo gigante na nuvem. É algo que você pode rodar hoje na sua própria máquina, e está licenciado sob Apache 2.0. E o motivo de eu ter ficado empolgado com ele é o benchmark. No Omnidoc Bench versão 1.6, que é o principal placar de análise de documentos, este modelo de 1,2 bilhão de parâmetros alcança 96,87 no total. Isso é o primeiro lugar. Ele fica acima do Gemini 3 Pro, do GPT 5.2 e do Qwen 3 VL com 235 bilhões de parâmetros.

01:06 Então, vamos ver se isso se confirma nos meus próprios documentos. Esta é a página do Hugging Face. O modelo se chama TeleOCR, é da Xingchen AGI, e a equipe por trás dele é o grupo de pesquisa em IA da China Telecom. Ele foi lançado inicialmente com o nome Navid COCR e, em setembro, foi renomeado para TeleOCR. Você pode ver que já tem mais de 27 mil downloads e mais de 700 curtidas. Agora, deixe-me explicar o problema que ele resolve, porque esse é realmente o ponto principal do modelo. Existem dois tipos de documentos,

01:36 documentos digitais, como um PDF exportado do Word, em que tudo é plano e reto, e documentos capturados por câmera, quando alguém tira uma foto com o celular e a página está curvada, dobrada, inclinada e com sombras. A maioria dos analisadores de documentos é muito boa com o primeiro tipo, mas falha no segundo. E o motivo está na forma como esses analisadores são construídos. Há duas famílias. Os modelos de ponta a ponta observam a página inteira e escrevem tudo de uma só vez. Eles lidam melhor com distorções, mas, em páginas grandes e de alta resolução, tendem a

02:06 se repetir e alucinar. Depois, há os modelos desacoplados, que primeiro detectam o layout, as caixas, e então leem cada caixa separadamente. Eles são mais precisos em páginas limpas, mas partem do pressuposto de que cada bloco é um retângulo certinho. E, em uma foto curvada, um retângulo simplesmente não serve, então os erros se acumulam. O que o TeleOCR faz é continuar desacoplado, em duas etapas, mas abandonar o pressuposto do retângulo. Em vez de uma caixa com dois cantos, ele prevê um polígono, um conjunto de pontos que acompanha o formato curvo real do bloco de texto na página. Você pode ver isso aqui nesta página

02:38 curvada: cada bloco tem um contorno torto que acompanha o texto. Basicamente, o modelo aprendeu a corrigir a distorção da página dentro da própria rede, sem nenhum modelo separado para corrigir a distorção. Agora, vamos ver o que há dentro dele. São cerca de 1,2 bilhão de parâmetros e três partes. Um codificador visual derivado do Qwen 2.5 VL, com 32 camadas, que lê a imagem em recortes de 14 pixels. Depois, um pequeno alinhador, que é um perceptron multicamada treinado do zero. E então o modelo de linguagem é o Qwen 3 0.6B, com 28 camadas, que escreve o texto. Eu conferi o

03:10 arquivo de configuração, e é exatamente isso que está escrito nele. E no cartão do modelo há seis ideias principais listadas: votação por consenso entre vários modelos para criar rótulos, modelagem com atenção à geometria para fotos tiradas por câmera, amostragem Douglas-Peucker guiada pela curvatura, autoverificação de imagem para imagem, um pipeline de treinamento progressivo em quatro etapas e aprendizado desacoplado de conteúdo e estrutura para tabelas e fórmulas. Vou explicar cada uma delas, porque são realmente engenhosas e explicam por que um modelo tão pequeno consegue superar modelos gigantes. A primeira tem a ver com os dados. Rotular

03:41 documentos manualmente é muito caro. Então, o que eles fazem é passar a mesma página por vários modelos diferentes, com arquiteturas diferentes, e medir o quanto esses modelos concordam entre si. Para o texto, usam distância de edição. Para tabelas, usam uma pontuação de similaridade de tabela. Para layouts, usam sobreposição de caixas. A resposta que mais concorda com as demais se torna o rótulo. E, se ninguém concordar o suficiente, a página passa por uma etapa de correção ou vai para uma pessoa. Assim, a maior parte dos dados de treinamento não precisou de anotação manual. A segunda ideia é a geometria. Eles

04:11 pegam páginas digitais limpas, cujo layout correto já conhecem, e as curvam artificialmente usando mapas de deformação reais de um conjunto de dados chamado Doc3D. Ao curvar a imagem, também curvam os contornos do layout e uma grade de pontos de controle. Assim, o modelo vê milhões de páginas curvadas e sabe exatamente para onde cada elemento foi deslocado. No artigo, só a etapa dois usa 4 milhões de amostras de layout digital e 2 milhões de amostras sintéticas de câmera. A terceira é o truque de amostragem, o Douglas-Peucker guiado pela curvatura. Se você descreve um contorno curvo com pontos,

04:42 onde coloca os pontos? O espaçamento uniforme desperdiça pontos em bordas planas e não detecta vincos acentuados e cantos. O algoritmo Douglas-Peucker mantém pontos onde a forma mais se desvia, e eles aumentam essa pontuação usando a curvatura local. Assim, vincos e cantos recebem mais pontos, e bordas planas recebem menos. O mesmo limite de pontos, mas uma forma muito melhor. A quarta é a autoverificação, e eu gosto muito dessa ideia. Para conferir se um rótulo está correto, eles renderizam a previsão de volta em uma imagem. A tabela vira uma imagem de tabela HTML. A fórmula é renderizada. O layout é desenhado em

05:14 uma tela. Depois, um modelo avaliador treinado a partir do Qwen 2.5 VL 7B compara a imagem original com a imagem renderizada. Assim, eles transformaram uma comparação difícil entre imagem e texto em uma comparação mais fácil entre imagem e imagem. Eu mencionei que até o Qwen 3VL 235B, usado sem exemplos, detectou menos de 40% dos erros, e é por isso que eles treinaram seu próprio avaliador. A quinta ideia é que o treinamento acontece em quatro etapas. A etapa um alinha o codificador visual a um modelo de linguagem. Com o modelo de linguagem congelado, a etapa dois é o treinamento ciente de deformações

05:44 de que acabamos de falar. A etapa três é o aprendizado desacoplado de conteúdo e estrutura, e a etapa quatro é o aprendizado por reforço para aprimorar a qualidade da saída em páginas reais e desorganizadas. E a sexta ideia, o desacoplamento entre conteúdo e estrutura, é o motivo de as tabelas e fórmulas saírem tão limpas. Para uma tabela, o modelo primeiro prevê o esqueleto, a estrutura em um formato chamado OTSL, que é apenas uma grade de tokens de célula: célula preenchida, célula vazia, mesclar à esquerda, mesclar acima, nova linha. Só então ele preenche o texto de cada célula. Assim, não precisa inventar o HTML

06:15 e ler caracteres chineses ao mesmo tempo. Você verá essa saída OTSL nos meus testes daqui a pouco. Certo, agora os números no OmniDoc Bench 1.6: 96,87 no total, primeiro lugar. A melhor pontuação em tabelas de toda a lista: 97,05 na métrica de tabelas. Vale lembrar que o Ovis OCR 2 e o Paddle OCRVL 1.6 vêm logo atrás, a menos de meio ponto de distância, e o Ovis tem pontuações um pouco melhores em texto e fórmulas. Então, a disputa no topo é acirrada, mas o TeleOCR está em primeiro. Depois, no Wild OmniDoc Bench, que é a versão para documentos

06:47 capturados por câmera, ou seja, fotos reais de documentos, ele alcança 88,53, novamente em primeiro lugar, à frente do Ovis OCR 2, com 87,91, e do Paddle OCRVL, com 87,36. A diferença é maior nas tabelas. O TeleOCR alcança 89 em tabelas, enquanto os outros ficam em torno de 85. É exatamente aí que o layout poligonal deveria ajudar, e ajuda. E tem mais. No Pure Doc Bench, a pontuação geral em documentos limpos é 86,9, quase cinco pontos acima do próximo modelo. Ele ficou em primeiro lugar no desafio Sci Image Miner do ICDAR

07:18 2026, que trata de transformar gráficos científicos de volta em tabelas. E, no desafio Doctor Doc Bench, ele alcança 67,96, enquanto o Miner U 2.5 Pro fica com 62. Então, em quatro benchmarks diferentes, fica em primeiro lugar ou bem no topo. Isso é realmente ótimo para um modelo de 1,2 bilhão de parâmetros. Certo, então vamos instalar. Primeiro, baixei o modelo com o comando snapshot download do Hugging Face Hub para uma pasta local. O pacote inteiro tem 2,7 GB. Um arquivo safetensors, e o download levou menos de 2 minutos. No

07:50 No lado do Python, já tenho torch 2.11 com CUDA 12.8 e transformers 4.57. Agora, aqui está a primeira coisa que me pegou. O model card só diz para executar pip install transformers torch pillow, mas, quando rodei, deu erro dizendo que o processador automático de vídeo requer a biblioteca torchvision. Então, você também precisa do torchvision, e ele precisa corresponder à sua versão do torch. No meu caso, era torchvision 0.26 com CUDA 12.8. Depois disso, carregou normalmente. E mais uma coisinha no Windows: a saída em chinês travou a impressão no meu console. Então, defina a codificação de entrada e saída do Python como

08:21 UTF-8. E este é o código. Peguei o início rápido do model card e o envolvi em um pequeno script. Você carrega o processador e o modelo com trust_remote_code e bfloat16, e os move para CUDA. Então, para cada tarefa, há um prompt específico. O texto tem seu próprio prompt; as tabelas têm um prompt próprio que pede OTSL; as fórmulas pedem LaTeX; e há prompts para código, layout e figuras científicas. Você passa a imagem e o prompt, e o modelo gera a saída de forma gulosa, até 4096 tokens. E, quando executo, o modelo carrega em cerca de 8 segundos e

08:53 usa 2,53 GB de VRAM. Ele informa 1,26 bilhão de parâmetros e, durante o teste mais pesado, o pico de memória foi de apenas 3,37 GB. Então, em uma placa de 8 GB, sobra bastante espaço. Vamos analisar os exemplos um por um. Primeiro, texto simples. Este é um parágrafo de um artigo, e você pode ver a saída à direita: palavra por palavra, perfeita, em cerca de 6 segundos. Em seguida, uma tabela, e esta é difícil. É uma tabela chinesa de inspeção com células mescladas. A primeira coluna tem uma

09:24 célula que ocupa quatro linhas, e os cabeçalhos ocupam duas colunas. O modelo gera OTSL e, depois de converter para HTML, você obtém isto. O rowspan de quatro está correto, os colspan estão corretos, e as marcas de seleção estão nas colunas certas. Isso levou cerca de 20 segundos. As únicas coisinhas que notei foram alguns caracteres isolados que ele leu como caracteres chineses parecidos, como na palavra para “aparência”, mas a estrutura está perfeita. Depois, uma fórmula. Esta é uma derivação em várias linhas, com coeficientes binomiais, e ela retorna um array LaTeX correto, alinhado nos

09:55 sinais de igual, com os binômios, as frações e os fatoriais. E você pode ver à direita que, quando renderizo esse LaTeX, ele corresponde à imagem. 12 segundos. Depois, código. É uma captura de tela de JavaScript, com uma bola quicando em um canvas, e o modelo não só lê o código como também detecta a linguagem. Você pode ver que a etiqueta diz JavaScript, e ele mantém a indentação. Cerca de 27 segundos, porque são 364 tokens de saída. E este é o meu exemplo oficial favorito. É um gráfico de barras, uma imagem, e o prompt pede para extrair a tabela representada por

10:25 esta figura, e ele retorna uma tabela, ano por ano. 2016 com 24,9%, 2017 com 15% e assim por diante. Esta é a tarefa de figuras científicas que lhes rendeu o desafio do ICDAR, e levou menos de 7 segundos. Agora, o modo de layout. Você fornece uma página inteira e pede que ele analise o layout. O resultado é uma lista de caixas, cada uma com coordenadas de 0 a 1.000, um rótulo como título, texto, equação, tabela ou rodapé, e uma direção de leitura. Nesta página densa de matemática, com duas colunas, ele encontrou 31 blocos e, quando eu

10:57 os desenho, todas as equações, todos os parágrafos, a tabela e até o número da página ficam separados corretamente. E esta é a saída bruta, para você ver como fica: caixa, rótulo e, depois, para o modo de câmera, é diferente. Em vez de quatro números, você recebe uma lista de pontos, um polígono com seis, oito ou dez pontos, dependendo de quão curvado é o bloco. Isso é a amostragem guiada pela curvatura em ação. Blocos planos recebem quatro pontos; os curvados recebem mais. Certo, esses foram os exemplos do model card e, é claro, os exemplos dos autores sempre

11:28 ficam bons. Então, agora montei meu próprio conjunto de testes, com coisas que este modelo nunca viu. Uma foto de câmera de uma conta de restaurante, uma tabela curvada, um bilhete manuscrito, uma captura de tela de código com tema escuro, um aviso misturando chinês e inglês e o próprio artigo sobre Tesseract OCR. Vamos testar tudo isso. Primeiro, o bilhete manuscrito. Ele está escrito com uma fonte que imita a caligrafia, em uma folha pautada de caderno ligeiramente inclinada, e o modelo lê tudo. As anotações da reunião, “enviar a demonstração até sexta-feira”, “comparar com Tesseract OCR VL e Miner U”. O orçamento de US$ 1.250,

11:59 o número da fatura A-2291. O único erro é um sinal de mais extra depois de “orçamento”. 6 segundos. Depois, o aviso com idiomas misturados: chinês e inglês, linha por linha, com uma data, um intervalo de horário, um e-mail e um número de telefone. As seis linhas estão corretas. As únicas diferenças são que ele transformou o travessão em um hífen comum e removeu um ponto final. Para documentos bilíngues, isso é muito bom. E a captura de tela de código com tema escuro. Na verdade, este é meu próprio script, o que está executando esta demonstração, renderizado com números de linha em um fundo

12:29 escuro. Ele detectou Python corretamente, removeu os números de linha e leu todas as linhas, incluindo a f-string com os especificadores de formato. Isso é muito útil se você precisar extrair código de um vídeo ou de uma captura de tela. Agora, a tabela curvada. Peguei a mesma tabela chinesa e a distorci com uma ondulação e uma rotação, de modo que as linhas ficaram curvas. A estrutura continuou perfeita. A extensão de quatro linhas, os spans das colunas, todas as marcas de seleção. Mas o texto ficou um pouco pior. Alguns caracteres mudaram. Por exemplo, um cabeçalho que significa “inspeção de fábrica” virou “preço de fábrica”, e uma célula recebeu uma expressão errada entre colchetes. Então,

13:00 a estrutura é muito robusta. O texto de caracteres pequenos muito distorcidos é onde o modelo começa a falhar. E agora, uma falha sincera. Peguei a foto da conta feita com a câmera e simplesmente pedi o texto da imagem inteira de uma vez. Você pode ver o que voltou: um amontoado de palavras sem sentido, dois números e algumas palavras aleatórias. Então, isto é importante: este modelo não foi feito para ler uma foto inteira de uma só vez. É um modelo de duas etapas. Você deve primeiro executar o layout e, depois, ler cada bloco. Então, foi isso que implementei. O pipeline completo oficial no repo do GitHub usa vLLM, que não funciona no Windows. Então, eu

13:32 adaptei a lógica para usar apenas transformers. Etapa um: redimensionar a página para 1.036 pixels e pedir o layout. Etapa dois: para cada polígono, recortar a área correspondente da imagem original e mascarar tudo que está fora da forma. Etapa três: enviar cada recorte com o prompt correto: texto, tabela ou fórmula. E etapa quatro: juntar tudo em Markdown. Agora, veja o layout da mesma conta. Encontrou 11 blocos: o título, o endereço, o número fiscal, a data e toda a área dos itens como uma única tabela. E depois, a saída: Blue Lotus Cafe, o endereço, o número da conta

14:04 e os itens como uma tabela de verdade. Masala dosa, 2 × 120 = 240. Café filtrado, 3 × 45. As seis linhas. Subtotal, 1.035. Os dois impostos, de 25,88, e o total, 1.086,75. Todos os números estão corretos, a partir de uma foto inclinada. Isso é realmente incrível. Depois, dei ao modelo páginas do próprio artigo. Na página um, ele encontrou o título, os autores, o resumo, os três gráficos de benchmark como imagens e a legenda, e até o carimbo vertical R Sigir na lateral, identificado como texto lateral

14:36 com a direção de leitura marcada como esquerda. Na página seis, ele leu os parágrafos e converteu as equações para LaTeX em linha e em bloco. Cerca de 40 a 70 segundos por página no meu laptop. E a mais difícil: a página amassada e enrolada de antes. 21 blocos poligonais, e o resultado é, sinceramente, lindo. O teorema, a demonstração, todas as equações em LaTeX, o exemplo com m = 221 e os quatro exercícios, tudo extraído de uma folha que parece ter sido tirada de uma lixeira. 2 minutos e 13 segundos do início ao fim. E

15:07 para facilitar o uso, envolvi todo o pipeline em um pequeno app do Gradio. Você solta uma imagem, escolhe detecção para páginas digitais ou segmentação para fotos feitas com câmera e clica em analisar. Só para deixar claro: isto está rodando ao vivo na minha máquina. A parte da espera aqui está acelerada. Depois, você vê o layout à direita, o Markdown renderizado com a tabela e o Markdown bruto, que pode copiar. E aqui está a página amassada no mesmo app. A etapa de layout desta página leva cerca de um minuto e meio, porque o modelo gera muitos pontos poligonais. Depois vem a extração e, na aba de renderização, você

15:37 Dá para ver as fórmulas exibidas corretamente, o teorema, a prova e os exercícios. Tudo isso a partir da nossa foto no estilo de celular, totalmente offline. Agora, vamos falar de velocidade. Honestamente, com transformers simples neste laptop, com uma RTX 4060, ele roda a cerca de 14 tokens por segundo. Um parágrafo curto leva 6 segundos, uma tabela, 20, e uma página inteira, entre 40 segundos e 3 minutos, dependendo de quantos blocos ela tiver. Isso não é rápido. A etapa de layout é a mais lenta, porque os polígonos exigem muitos números para serem escritos. Mas lembre-se: isso é com a configuração mais simples possível. O

16:09 pipeline oficial usa VLLM com batching, então todos os blocos de uma página são lidos em paralelo, em vez de um após o outro. No Linux, com uma GPU adequada, isso será drasticamente mais rápido. E já existe uma conversão comunitária para GGUF com suporte a llama.cpp, então você também pode executá-lo dessa forma. Então, deixe-me resumir as limitações reais que encontrei. Ele foi projetado para funcionar em duas etapas, então pedir para processar a foto inteira de uma vez falha. O model card não informa a atribuição. O pipeline oficial completo precisa de VLLM, então, no

16:40 Windows, você precisa fazer o que eu fiz. Com transformers, ele roda a cerca de 14 tokens por segundo em um laptop. Em textos pequenos muito deformados, alguns caracteres saem errados. E, quanto aos idiomas, ele foi treinado para chinês e inglês. Agora, os pontos positivos, que são muitos. Primeiro lugar no OmniDocBench, primeiro no WildCamera Benchmark, primeiro no PureDocBench, primeiro no desafio ICDAR. Apenas 1,2 bilhão de parâmetros, 2,5 GB de VRAM, layout com polígonos que realmente funciona com páginas curvas e dobradas. Tabelas com células mescladas são geradas perfeitamente,

17:11 fórmulas em LaTeX, código com detecção de linguagem, gráficos convertidos de volta em tabelas. E ele está sob a licença Apache 2.0, então você pode usá-lo comercialmente. Então, onde eu realmente usaria isso? Para criar sistemas RAG em que os documentos de origem são digitalizados ou fotografados; digitalizar recibos e faturas a partir de fotos de celular; transformar documentos impressos antigos e livros didáticos com fórmulas em Markdown; extrair dados de tabelas de gráficos; e, basicamente, em qualquer pipeline em que você queira um analisador de documentos local e privado, em vez de enviar seus arquivos para uma API na nuvem. Então, neste vídeo,

17:43 vimos o TeleOCR, um analisador de documentos com 1,2 bilhão de parâmetros que lidera os benchmarks, roda em um laptop com 8 GB de memória e lê páginas fotografadas, curvas e dobradas, que fazem a maioria dos outros analisadores falhar. Se tiver interesse, confira. Os links estão na descrição. Experimente no seu próprio sistema e me conte nos comentários como foi. Créditos à equipe do TeleOCR na China Telecom por disponibilizá-lo abertamente. Até o próximo vídeo. Confira o próximo vídeo.

Transcrição original

[00:00] All right. In this video, we are going to look at TeleOCR, and you can see what it is doing here. This is a photo of a restaurant bill taken at an angle on a table with shadows on it, and this tiny model found every single block on that bill, the title, the address, the table of items, the taxes, the total, and then it read all of it back to me as clean markdown with the items as a proper table, every number correct. Now, mind you that everything you’re going to see in this video is running on my local system on this laptop with an RTX 4060, which has only 8 GB of VRAM.

[00:34] The whole model takes about 2 and 1/2 GB. So, this is not a giant cloud model. This is something you can run on your own machine today, and it is Apache 2.0 licensed. And the reason I got excited about this one is the benchmark. On Omnidoc Bench version 1.6, which is the main leaderboard for document parsing, this 1.2 billion model scores 96.87 overall. That is number one. It is above Gemini 3 Pro, above GPT 5.2, and above Qwen 3 VL with 235 billion parameters.

[01:06] So, let’s go ahead and see if that holds up on my own documents. So, this is the Hugging Face page. The model is called TeleOCR from Xingchen AGI, and the team behind it is China Telecom’s AI research group. It was earlier released under the name Navid COCR, and in September they renamed it to TeleOCR. You can see it already has more than 27,000 downloads and over 700 likes. Now, let me explain the problem this solves because this is really the whole point of the model. There are two kinds of documents,

[01:36] digital documents like a PDF exported from Word where everything is flat and straight, and camera-captured documents where somebody takes a photo with a phone, and the page is bent, folded, tilted with shadows. Most document parsers are really good at the first kind and fall apart on the second kind. And the reason is how these parsers are built. There are two families end-to-end models look at the whole page and write out everything in one shot. They handle distortion better, but on big high-resolution pages, they tend to

[02:06] repeat themselves and hallucinate. Then there are decoupled models which first detect the layout, the boxes, and then read each box separately. These are more accurate on clean pages, but they assume every block is a neat rectangle. And on a curved photo, a rectangle is just wrong, so the errors cascade. So, what TeleOCR does is it stays decoupled, two-stage, but it throws away the rectangle assumption. Instead of a box with two corners, it predicts a polygon, a set of points that follow the actual curved shape of the text block on the page. You can see it here on this curled

[02:38] page, every block has a bent outline that hugs the text. The model basically learned how to dewarp the page inside its own head without any separate dewarping model. Now, let’s look at what is inside. It is about 1.2 billion parameters, and it has three parts. A vision encoder that comes from QN 2.5 VL, 32 layers, reading the image in 14 pixel patches. Then a small aligner, which is a multi-layer perceptron trained from scratch. And then the language model is QN 3.0.6 B 28 layers, which writes out the text. I checked the

[03:10] config file myself, and that is exactly what it says. And on the model card, there are six key ideas listed. Multi-node consensus voting for making labels, geometry-aware modeling for camera photos, curvature-guided Douglas-Peucker sampling, image-to-image self-verification, a progressive four-stage training pipeline, and content-structure decoupled learning for tables and formulas. Let me go through each of them because they are really clever, and they explain why such a small model can beat giant ones. The first one is about data. Labeling

[03:41] documents by hand is really expensive. So, what they do is they run the same page through several different models with different architectures, and they measure how much those models agree with each other. For text, they use edit distance. For tables, they use a table similarity score. For layouts, they use box overlap. The answer that agrees most with everyone else becomes the label. And if nobody agrees enough, that page goes to a correction step or to a human. So, most of the training data needed no manual annotation at all. The second idea is the geometry. They

[04:11] take clean digital pages where they already know the correct layout, and then they synthetically bend them using real deformation maps from a dataset called Doc3D. When they bend the image, they bend the layout outlines and a grid of control points along with it. So, the model sees millions of bent pages where it knows exactly where everything moved. In the paper, stage two alone uses 4 million digital layout samples and 2 million synthetic camera samples. Third is the sampling trick, curvature-guided Douglas-Peucker. If you describe a curved outline with points,

[04:42] where do you put the points? Uniform spacing wastes points on flat edges and misses sharp folds and corners. The Douglas-Peucker algorithm keeps points where the shape deviates most, and they boost that score using the local curvature. So, creases and corners get more points, flat edges get fewer. Same budget of points, much better shape. Fourth is self-verification, and I really like this one. To check if a label is correct, they render the prediction back into an image. The table becomes an HTML table image. The formula gets rendered. The layout gets drawn on

[05:14] a canvas. And then a judge model trained from Qwen 2.5 VL 7B compares the original image with the rendered image. So, they turned a hard image versus text check into an easier image versus image check. I mentioned that even Qwen 3VL 235B used zero-shot caught less than 40% of the errors, which is why they trained their own judge. Fifth, training happens in four stages. Stage one aligns the vision encoder with a language model. With the language model frozen, stage two is the deformation-aware training.

[05:44] We just talked about. Stage three is content structure decoupled learning and stage four is reinforcement learning to polish the output quality on messy real-world pages. And the sixth one, content structure decoupling is why tables and formulas come out so clean. For a table, the model first predicts the skeleton, the structure in a format called OTSL, which is just a grid of cell tokens, full cell, empty cell, merge left, merge up, new line, and only then it fills in the text of each cell. So, it is not trying to invent the HTML

[06:15] and read Chinese characters at the same time. You will see this OTSL output in my tests in a minute. Okay, so now the numbers on OmniDoc bench, 1.6 96.87 overall, first place. The best table score in the whole list, 97.05 on the table metric. Mind you, Ovis OCR 2 and Paddle OCRVL 1.6 are really close behind within half a point, and Ovis has slightly better text and formula scores. So, it is a tight race at the top, but Telli OCR is on top. Then on Wild OmniDoc bench, which is the camera

[06:47] captured version, real photos of documents, it scores 88.53, again number one, ahead of Ovis OCR 2 at 87.91 and Paddle OCRVL at 87.36, and the gap is bigger on tables here. Telli OCR gets 89 on tables, while the others are around 85. That is exactly where the polygon layout should help, and it does. And there is more. On Pure Doc bench, the clean overall score is 86.9, which is almost five points ahead of the next model. It took first place in the ICDAR

[07:18] 2026 Sci Image Miner challenge, which is about turning scientific charts back into tables. And on the Doctor Doc bench challenge, it scores 67.96, while Miner U 2.5 Pro scores 62. So, across four different benchmarks, it is either first or right at the top. That is really great for a 1.2 billion model. All right, so let’s go ahead and install this. First, I downloaded the model with the Hugging Face Hub snapshot download into a local folder. The whole thing is 2.7 GB. One safe tensors file and it came down in under 2 minutes. On the

[07:50] Python side, I already have torch 2.11 with CUDA 12.8 and transformers 4.57. Now, here’s the first thing that bit me. The model card only says pip install transformers torch pillow, but when I ran it, it crashed saying the auto video processor requires the torch up show library. So, you also need torch up show and it must match your torch build. For me, that was torch up show 0.26 with CUDA 12.8. After that, it loaded fine. And one more small thing on Windows, the Chinese output crashed my console printing. So, set python io encoding to

[08:21] UTF-8. And this is the code. I took the quick start from the model card and wrapped it in a small script. You load the processor and the model with trust remote code in bfloat16, move it to CUDA. Then, for each task, there’s a specific prompt. Text has its own prompt, tables have their own prompt that asks for O TSL, formulas ask for LaTeX, code, layout, and scientific figures. You pass the image and the prompt and it generates greedily up to 4096 tokens. And when I run it, the model loads in about 8 seconds and it

[08:53] takes 2.53 GB of VRAM. It reports 1.26 billion parameters and during the heaviest test, the peak memory was only 3.37 GB. So, on an 8 gig card, you have plenty of room left over. So, let’s go through the examples one by one. First, plain text. This is a paragraph from a paper and you can see the output on the right, word for word, perfect in about 6 seconds. Next, a table and this is a hard one. It is a Chinese inspection table with merged cells. The first column has one

[09:24] cell that spans four rows and the headers span two columns. The model writes out O TSL and after converting to HTML, you get this. The row span of four is correct, the column spans are correct, the check marks are in the right columns. This took about 20 seconds. The only small things I spotted are a few single characters where it read a similar looking Chinese character like in the word for appearance, but the structure is perfect. Then a formula. This is a multi-line derivation with binomial coefficients and it comes back as a proper LaTeX array aligned on the

[09:55] equal signs with the binomials, the fractions, and the factorials. And you can see on the right when I render that LaTeX, it matches the image 12 seconds. Then code. It is a screenshot of JavaScript, a bouncing ball on a canvas, and it not only reads the code, it detects the language. You can see the tag says JavaScript and it keeps the indentation around 27 seconds because this is 364 tokens of output. And this one is my favorite official example. This is a bar chart, a picture, and the prompt says extract the table implied by

[10:25] this figure, and it gives back a table year by year. 2016 at 24.9%, 2017 at 15%, and so on. This is the scientific figure task that won them the ICDAR challenge, and it took under 7 seconds. Now, the layout mode. You give it a full page and ask it to analyze the layout, and what comes back is a list of boxes, each with coordinates from 0 to 1,000, a label like title, text, equation, table, footer, and a reading direction. On this dense two-column math page, it found 31 blocks, and when I

[10:57] draw them, every equation, every paragraph, the table, and even the page number are separated correctly. And this is the raw output, so you can see what it looks like box for numbers label, and then up for the camera mode it is different. Instead of four numbers, you get a list of points, a polygon like six, eight, 10 points, depending on how curved the block is. That is the curvature guided sampling in action. Flat blocks get four points, bent ones get more. Okay, so those were the examples from the model card, and of course examples from the authors always

[11:28] look good. So now I made my own test set, things this model has never seen. A camera photo of a restaurant bill, a bent table, a handwritten note, a dark theme code screenshot, a mixed Chinese and English notice, and the Tesseract OCR paper itself. Let’s go ahead and test these out. First, the handwritten note. This is written in a handwriting style font on lined notebook paper slightly rotated, and it reads everything. The meeting notes, ship the demo by Friday, compare against Tesseract OCR VL and Miner U. The budget of $1,250,

[11:59] invoice number A-2291. The only mistake is one extra plus sign after budget, 6 seconds. Then the mixed language notice, Chinese and English line by line with a date, a time range, an email, and a phone number. All six lines correct. The only differences are that it turned the n- dash into a normal hyphen and dropped one full stop. For bilingual documents, that is really good. And the dark theme code screenshot. This is actually my own script, the one running this demo rendered with line numbers on a dark

[12:29] background. It correctly detected Python, dropped the line numbers, and read every line including the f-string with the format specifiers. That is really useful if you ever need to grab code out of a video or a screenshot. Now the bent table, I took the same Chinese table and warped it with a wave and a rotation, so the lines are curved. The structure still came out perfect. The four row span, the column spans, all the check marks, but the text got a bit worse. A few characters changed. For example, one header that means factory inspection became factory price, and one cell got a wrong phrase in brackets. So,

[13:00] structure is really robust. Text on heavily warped small characters is where it starts to slip. And now, an honest failure. I took the camera photo of the bill and just asked for the text of the whole image in one shot, and you can see what came back. Garbage, two numbers and some random words. So, this is important. This model is not meant to read a whole photo in one go. It is a two-stage model. You’re supposed to run layout first, then read each block. So, that is what I built. The official full pipeline in the GitHub repo uses VLLM, which does not run on Windows. So, I

[13:32] ported the logic to plain transformers. Step one, resize the page to 1,036 pixels and ask for the layout. Step two, for each polygon, cut it out of the original image and mask everything outside the shape. Step three, send each crop with the right prompt, text, table, or formula. And step four, stitch everything into markdown. And now look at the same bill layout. Found 11 blocks, the title, the address, the tax number, the date, and the whole items area as one table. And then the output, Blue Lotus Cafe, the address, the bill

[14:04] number, and the items as a real table. Masala dosa, 2 * 120 is 240. Filter coffee, 3 * 45. All six rows. Subtotal, 1,035. The two taxes of 25.88 and the total, 1,086.75. Every single number correct from a tilted photo. That is really amazing. Then I gave it pages from its own paper. Page one, it found the title, the authors, the abstract, the three benchmark charts as images and the caption, and even the vertical R Sigir stamp on the side labeled as a side text

[14:36] with the reading direction marked as left. On page six, it read the paragraphs and turned the equations into inline and display LaTeX. Around 40 to 70 seconds per page on my laptop. And the hardest one, the curled crumpled page from earlier. 21 polygon blocks, and the output is honestly beautiful. The theorem, the proof, every equation as LaTeX, the example with m = 221, and all four exercises from a sheet of paper that looks like it was pulled out of a bin. 2 minutes and 13 seconds end to end. And

[15:07] to make this easier to use, I wrapped the whole pipeline in a small Gradio app. You drop an image, pick detection for digital pages or segmentation for camera photos, and hit parse. Mind you, this is live on my machine. The waiting part here is sped up, and then you get the layout on the right, the rendered markdown with the table, and the raw markdown you can copy. And here’s the crumpled page in the same app. The layout step on this one takes about a minute and a half because it is writing out a lot of polygon points. Then the extraction, and in the rendered tab you

[15:37] can see the formulas displayed properly, the theorem, the proof, and the exercises. All of this from our phone-style photo fully offline. Now let’s talk speed. Honestly, with plain transformers on this laptop, RTX 4060 generation runs at about 14 tokens per second. A short paragraph takes 6 seconds, a table 20, a full page between 40 seconds and 3 minutes, depending on how many blocks it has. That is not fast. The layout step is the slowest part because polygons are a lot of numbers to write out. But mind you, that is with the simplest possible setup. The

[16:09] official pipeline uses VLLM with batching, so all the blocks on a page are read in parallel instead of one after another. On Linux with a proper GPU, that will be dramatically faster. And there is already a community GGUF conversion with llama.cpp support, so you can also run it that way. So let me summarize the honest limits I found. It is two-stage by design, so asking for the whole photo in one shot fails. The model card is missing attribution. The full official pipeline needs VLLM, so on

[16:40] Windows you have to do what I did. With transformers, it is around 14 tokens per second on a laptop. On heavily warped small text, you get a few wrong characters. And language-wise, it is trained for Chinese and English. And the good side, which is a lot. First place on OmniDocBench, first on the WildCamera Benchmark, first on PureDocBench, first in the ICDAR challenge. Only 1.2 billion parameters, 2 and 1/2 GB of VRAM, polygon layout that genuinely handles bent and folded pages. Tables with merged cells come out perfectly,

[17:11] formulas as LaTeX, code with language detection, charts back into tables. And it is Apache 2.0, so you can use it commercially. So where would I actually use this building REG systems where your source documents are scanned or photographed digitizing receipts and invoices from phone photos turning old printed papers and textbooks with formulas into markdown pulling data tables out of charts and basically any pipeline where you want a local private document parser instead of sending your files to a cloud API. So in this video

[17:43] we have seen Telio CR a 1.2 billion document parser that tops the benchmarks runs on an 8 gig laptop and reads bent folded photograph pages that break most other parsers. If you’re interested go ahead and check this out. The links are in the description and try it on your own system and let me know how it goes in the comments. Credit to the Telio CR team at China Telecom for releasing this openly. I will see you in another one. Check out the next video.