待翻译：How Baidu Unlimited-OCR Works: Solving Long-Document Transcription

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

--> Unlimited-OCR Explained: How Baidu Solved Long-Document AI India's Most Futuristic AI Conference Is Back – Bigger, Sharper, Bolder d : h : m : s Career GenAI Prompt Engg ChatGPT LLM Langchain RAG AI Agents Machine Learning Deep Learning GenAI Tools LLMOps Python NLP SQL AIML Projects Reading list How to Become a Data Analyst in 2025: A Complete RoadMap A Comprehensive Learning Path to Tableau in 2025 A Comprehensive NLP Learning Path 2025 Learning Path to Become a Data Scientist in 2025 Step-by-Step Roadmap to Become a Data Engineer in 2025 A Comprehensive MLOps Learning Path: 2025 Edition Roadmap to Become an AI Engineer in 2025 A Comprehensive Learning Path to Master Computer Vision in 2025 Best Roadmap to Learn Generative AI in 2025 GenAI Roadmap for Enterprises Large Language Models Demystified: A Beginner’s Roadmap Learning Path to Become a Prompt Engineering Specialist How Baidu Unlimited-OCR Works: Solving Long-Document Transcription Shaik Hamzah Shareef Last Updated : 13 Aug, 2026 9 min read About a month ago, Baidu (often called the “Google of China”) introduced Unlimited-OCR, an advancement over DeepSeek OCR. The model was designed to transcribe long, multi-page documents with high accuracy while delivering fast and stable inference. Unlike conventional vision-language OCR systems, Unlimited-OCR addresses a major bottleneck in long-document transcription: the rapidly growing Key-Value (KV) cache, whose memory usage rises as more output tokens are generated. In this article, we examine how Baidu’s Unlimited-OCR improves efficiency and scalability for long-document OCR tasks. Table of contents How Vision-Language Models Read a Page The Two-Sided Token Problem How DeepSeek OCR Solved the Input Side How Baidu Solved the Output Side Understanding the KV Cache A Simple Analogy Reference Sliding Window Attention (R-SWA) Running Unlimited-OCR Running with vLLM Conclusion Frequently Asked Questions How Vision-Language Models Read a Page Visual token patch representation Unlike traditional OCR systems, Vision-Language Models do not read raw pixels directly. Instead, every document page is divided into a grid of small square regions known as patches. Each patch is converted into a numerical embedding and treated as a visual token, similar to how words are converted into text tokens inside a language model. As a result, an entire document page becomes a sequence of visual tokens that the transformer can process. Imagine reading a newspaper through a small window. Instead of looking at the entire page at once, you inspect one small square after another until you’ve seen the complete document. Vision models perform something very similar, except they represent every square mathematically. The number of patches here directly determines the number of input tokens it gives out. Using more patches means: Better preservation of the finer details Higher OCR accuracy Better understanding of tables and handwriting However, it also means: More input tokens Higher computational cost Increased GPU memory usage Slower inference Using fewer patches speeds up inference but sacrifices detail, making it harder to recognize small fonts or densely packed documents. Like many machine learning problems, this becomes a trade-off between speed and accuracy. The Two-Sided Token Problem Processing long documents introduces two independent computational challenges of its own. 1. Input Tokens First, the system must convert every page into visual tokens before the model can understand a document. A high-resolution page can easily generate thousands of visual tokens. For a document containing dozens of pages, the number of input tokens quickly becomes enormous, making inference computationally expensive. The first challenge therefore becomes: “How do we reduce the number of input tokens without losing important visual information?” 2. Output Tokens After processing the document, the model must generate the transcription token by token. This creates a second and often more difficult challenge. Suppose a document contains 100 pages or more. The generated transcription could easily contain tens of thousands of output tokens. In conventional transformer decoders, every newly generated token is stored inside the Key-Value (KV) cache so that future tokens can attend to it. As the transcription grows longer: More tokens are generated and appended. The KV cache keeps expanding each token. GPU memory consumption continuously increases. Attention computation becomes progressively slower. Unlike the input side, where the cost is fixed once the document has been encoded, the output side grows throughout decoding. For sufficiently long documents, the decoder eventually becomes the primary bottleneck. Therefore, long-document OCR presents two separate optimization problems: Reduce the number of input tokens while preserving document quality. Prevent the decoder’s memory from growing as more output tokens are generated. How DeepSeek OCR Solved the Input Side As we discussed earlier, the first challenge in long-document OCR is the sheer number of input tokens. The system converts every document page into visual tokens before it can process it with the language model, and high-resolution pages can easily generate thousands of tokens. Source: arXiv Large white spaces, page margins, and simple paragraphs contain far less information than dense tables, handwritten annotations, or complex diagrams. Processing every region at the same resolution therefore wastes valuable computation and resources. Image compression strategy implementation To address this, DeepSeek OCR introduced a compression strategy here say a page which translates to 1000 textual tokens normally but we compress the image up to 16x times smaller and feed it to the model which would end up to be of 128 textual tokens. In fact, if we passed this page as text to the model we would have burnt 1000 tokens, whereas converting it to these vision tokens decreases the size by a factor of 16. So we get detail of a high resolution page and everything on it but at a fraction of a cost, this is called optical compression. Now this isn’t completely loss less so we do pay a price for compressing the image so according to the DeepSeek paper at 10x compression it retains around 97% accuracy as we compress more and more quite a sharp drop in accuracy. When Deepseek OCR came out it came out with 5 different resolution modes to offer. Fewer tokens – lesser detail and vice versa. Source: arXiv Consequently, the lower the number of visual tokens, the faster and cheaper the inference becomes, but the model may lose some fine-grained details. Likewise, allocating more visual tokens preserves more information at the cost of increased computation. This optical compression strategy was one of the key innovations that made DeepSeek OCR significantly more efficient than earlier vision-language OCR models. However, it primarily addresses only the input side of the problem. Baidu’s Unlimited-OCR builds directly on top of DeepSeek OCR, using its visual encoder (specifically trained upon the Base and Gundam variants) to efficiently compress document pages. Rather than redesigning the visual encoder, Baidu focused on solving the second and arguably more difficult challenge: the ever-growing KV cache during autoregressive decoding. How Baidu Solved the Output Side DeepSeek OCR significantly reduced the cost of processing the input, but another bottleneck still remained the decoder. Imagine asking the model to transcribe a 40-page document in a single pass. Although the system has already compressed the document into a small number of visual tokens, the model still has to generate thousands of output tokens, one token at a time. This naturally raises an important question: “Why do long-document OCR models become slower and eventually run out of memory?” The answer lies in something called the Key-Value (KV) caching. Understanding the KV Cache Large Language Models and Vision-Language Models generate text autoregressively, meaning they predict one token at a time. Furthermore, the transformer stores its Key and Value representations inside memory every time it generates a new token. This KV cache allows the model to efficiently attend to everything that it has already generated instead of recomputing the entire sequence from scratch. Without a KV cache, generating long responses would be prohibitively slow. However, the KV cache comes with an important drawback here in our case. It grows with every output token. If the model generates: 100 tokens → small KV cache Moreover, a much larger KV cache results from 1,000 tokens. Finally, 10,000 tokens may already occupy several gigabytes of GPU memory. Meanwhile, as the model produces more text: GPU memory continuously increases Attention computations become more expensive Generation becomes progressively slower Eventually, the model may run out of memory altogether This means that even if DeepSeek OCR compresses the input document into only a few hundred visual tokens, generating the transcription of a long document still causes the decoder’s memory usage to grow without any limitations. This output-side bottleneck is exactly what Baidu Unlimited-OCR was designed to solve A Simple Analogy Imagine you’re copying a chapter from a book by hand. Every time you write the next word, you don’t reread every sentence you’ve already written. Instead, you mainly look at the original book you’re copying from and the last few words you’ve written to maintain continuity so you dont break aay from the flow. Similarly, the model rarely needs everything you wrote several pages ago. Humans naturally keep their attention focused on the source document while only remembering a short recent history of their own writing. Source: arXiv Baidu observed that document transcription works in much the same way. Unlike chatbots, which often require access to the entire conversation history, OCR models are simply copying information from a document. They rarely need to revisit thousands of previously generated output tokens. This observation became the foundation of Reference Sliding Window Attention (R-SWA). Reference Sliding Window Attention (R-SWA) Traditional transformer attention allows every newly generated token to attend to all previous output tokens. While this produces excellent language modelling capabilities, it also causes the KV cache to grow linearly with the length of the generated text. Standard Sliding Window Attention attempts to solve this by keeping only a fixed window of recent tokens. Nevertheless, if we applied this directly to OCR, the model would eventually forget the document image itself—the very information it is trying to transcribe—which we provided at the starting. Source: arXiv Baidu therefore introduced Reference Sliding Window Attention (R-SWA). Instead of treating every token equally, R-SWA divides attention into two separate segments: 1. Static Reference Prefix This contains the visual tokens representing the document pages along with the system prompt. These tokens never change during decoding and remain permanently visible to every generated token. 2. Causal Sliding Window This contains only the most recently generated output tokens (typically around 128 tokens). As the model continues decoding, this window slides forward. As a result, the system discards older output tokens from the attention window. Sliding window output management This means that every generated token can always attend to the entire document and only the recent output history. Older generated text gradually falls out of the attention window because it is no longer needed for accurate transcription. R-SWA maintains two fixed memory regions: Static Prefix (m): The compressed visual tokens produced b [truncated for AI cost control]