This Local 1.2B OCR Model Beats GPT-5.2 (and Runs on 8GB GPU) — TeleOCR

Author: Prompt Engineer 48 · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: This Local 1.2B OCR Model Beats GPT-5.2 (and Runs on 8GB GPU) — TeleOCR · Channel: Prompt Engineer 48 · 17:43 · Watch on YouTube

Topics: AI evaluation and benchmarks, Local and open-source models, Multimodal models, Open source and software ecosystems

Summary

The video reviews TeleOCR, an open-source 1.2-billion-parameter document parser that the presenter runs locally on an RTX 4060 with 8 GB of VRAM. Its two-stage approach uses polygon layouts to handle curved or distorted camera photos, and the video explains the model’s design, training ideas, benchmarks, installation, and examples. Tests show strong results on text, tables, formulas, code, charts, and photographed pages, though reading an entire camera photo in one pass fails and heavily warped small text can contain errors. The presenter also demonstrates a local pipeline and Gradio app, discusses speed and limitations, and suggests private document-processing use cases.

Key points

TeleOCR is presented as a 1.2-billion-parameter model using about 2.5 GB of VRAM, with an Apache 2.0 license.
The presenter cites a score of 96.87 on OmniDocBench 1.6 and first-place results on several other benchmarks, including the camera-captured Wild OmniDocBench.
Unlike rectangular-box layout systems, TeleOCR predicts polygon outlines that follow curved text blocks in bent or folded pages.
The described architecture combines a Qwen 2.5 VL vision encoder, a small aligner, and a Qwen 3 0.6B language model.
The model card’s methods include consensus-based labeling, synthetic page deformation, curvature-guided point sampling, image-to-image self-verification, four-stage training, and structure-first learning for tables and formulas.
In the presenter’s tests, the model handles text, merged-cell tables, LaTeX formulas, code, charts, and page layouts; results are especially strong on table structure.
For camera photos, the intended workflow is to detect or segment the layout first, extract each block with an appropriate prompt, and then assemble the output.
A custom pipeline accurately extracts the contents and totals of a photographed restaurant bill; the presenter also demonstrates a Gradio interface running locally.
On the presenter’s laptop, generation runs at about 14 tokens per second, and full pages take roughly 40 seconds to 3 minutes; the layout step can be slow.
Limitations include failure when the whole photo is requested in one pass, occasional character errors on heavily warped small text, and a Windows setup that requires adapting the official VLLM pipeline.

Chapters

Start	Chapter	Summary
00:00	TeleOCR introduction and headline results	The presenter introduces TeleOCR, its local 8 GB GPU setup, and its reported benchmark performance.
01:06	Why polygon layouts help with camera photos	The video contrasts digital and camera-captured documents, then explains TeleOCR’s polygon-based two-stage approach and architecture.
03:10	Training methods and benchmark scores	The presenter describes the model’s data and training techniques, then reviews its results across document benchmarks.
07:18	Installation and model-card examples	The video covers setup requirements, memory use, and demonstrations on text, tables, formulas, code, charts, and layouts.
11:28	Custom tests and the full document pipeline	The presenter tests unseen documents, shows where one-shot photo reading fails, and builds a layout-first extraction pipeline.
15:07	Gradio demo, speed, limitations, and use cases	The video demonstrates the app, discusses performance and limitations, and summarizes practical local document-parsing uses.

Quotes

This is not a giant cloud model. This is something you can run on your own machine today — 00:34

Instead of a box with two corners, it predicts a polygon — 02:06

This model is not meant to read a whole photo in one go. — 13:00

That is not fast. — 15:37

On heavily warped small text, you get a few wrong characters. — 16:40

Concepts and entities

TeleOCR, Xingchen AGI, China Telecom, OmniDocBench, Doc3D, Qwen2.5-VL, Qwen3-0.6B, vLLM, Transformers, llama.cpp, Gradio, Tesseract OCR

Full transcript (original language)

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.