DeepSeek-OCR 3B kompresuje strony do setek tokenów. Nowy VLM do OCR i strukturyzacji dokumentów

DeepSeek-AI udostępnił DeepSeek-OCR 3B – system OCR/VLM, który traktuje strony jak nośniki skondensowanego kontekstu optycznego. Zamiast wpychać tysiące symboli do dekodera, model sprowadza obraz do niewielkiej liczby tokenów wizualnych, a dopiero potem rekonstruuje treść językowym dekoderem. W praktyce oznacza to krótsze sekwencje, niższy koszt inferencji i lepszą kontrolę nad budżetem obliczeń.

Co w architekturze jest naprawdę nowe

System składa się z dwóch elementów: wizualnego enkodera DeepEncoder oraz dekodera językowego MoE DeepSeek3B‑MoE‑A570M. Enkoder zaprojektowano pod wysokie rozdzielczości przy niskim koszcie aktywacji i z ograniczoną liczbą tokenów wyjściowych. Wykorzystuje etap okienkowej atencji oparty na SAM do percepcji lokalnej, dwuwarstwowy kompresor konwolucyjny (16× downsampling tokenów) oraz gęstą atencję globalną inspirowaną CLIP do agregacji wiedzy wizualnej. Taki układ trzyma w ryzach pamięć aktywacji na dużych obrazach i utrzymuje małą liczbę tokenów wizualnych.

Dekoder to model Mixture‑of‑Experts o łącznej wielkości 3B parametrów, z ok. 570 mln aktywnych parametrów na token. To kompromis: duża pojemność na potrzeby rekonstrukcji tekstu i struktury dokumentu, ale bez konieczności przetwarzania wielotysięcznych sekwencji jak w klasycznych pipeline’ach OCR+LM.

Tryby rozdzielczości i budżety tokenów

DeepEncoder oferuje tryby natywne i dynamiczne. W natywnych: Tiny generuje 64 tokeny przy 512×512 px, Small – 100 tokenów przy 640×640, Base – 256 przy 1024×1024, a Large – 400 przy 1280×1280. To czytelne budżety, które pozwalają dobrać koszt do złożoności strony.

Tryby dynamiczne Gundam i Gundam‑Master łączą płytki lokalne z jednym widokiem globalnym. Przykładowo: n×100 + 256 tokenów lub n×256 + 400 tokenów, gdzie n mieści się w zakresie 2–9. Zespół podaje też wzór na liczbę tokenów „ważnych” dla wariantów z paddingiem – mniejszą od surowego zliczenia i zależną od proporcji strony. W praktyce: łatwiej pogodzić gęste łamy i drobne fonty z ograniczonym budżetem dekodera.

Wyniki kompresji: gdzie są granice

Na benchmarku Fox precyzję liczono jako dokładne dopasowanie tekstu po dekodowaniu. Dla 100 tokenów wizualnych strony zawierające 600–700 tokenów tekstu osiągają 98,5% przy kompresji 6,7×. Przy 900–1000 tokenach tekstu jest to 96,8% przy 9,7×. Gdy budżet zmniejszyć do 64 tokenów wizualnych, dokładność spada przy rosnącej kompresji – dla 1200–1300 tokenów tekstu to 59,1% przy ~19,7×. Uogólniając: około 10× kompresji daje wyniki bliskie bezstratności, dalsze ściskanie szybko odbija się na jakości.

Na OmniDocBench w streszczeniu podano, że DeepSeek‑OCR przewyższa GOT‑OCR 2.0 już przy 100 tokenach wizualnych na stronę, a pozostając <800 tokenów wyprzedza MinerU 2.0, który średnio wykorzystuje ponad 6000 tokenów na stronę. Zestawienie wyników oparto na odległości edycyjnej, co sprzyja ocenie faktycznej jakości tekstu. Warto jednak pamiętać, że różne budżety tokenów komplikują bezpośrednie porównania koszt/jakość i wymagają własnych testów progowych.

Szkolenie i wydajność

Trening przebiegał dwuetapowo. Najpierw uczono sam enkoder DeepEncoder na zadaniu przewidywania kolejnego tokenu z użyciem zbiorów OCR 1.0 i 2.0 oraz 100 mln próbek LAION. Następnie trenowano pełny system, wykorzystując równoległość potokową w czterech partycjach. Sprzęt: 20 węzłów, każdy z 8× A100 40 GB, optymalizator AdamW. Zgłoszona prędkość: 90 mld tokenów na dobę dla danych tekstowych i 70 mld dla multimodalnych.

Na potrzeby produkcji zespół deklaruje możliwość generowania ponad 200 tys. stron dziennie na pojedynczym węźle z A100 40 GB. To ambitny wynik, ale rzeczywista przepustowość zależy od stosu I/O, rozdzielczości wejść i konfiguracji trybów, więc rozsądnie jest zweryfikować go we własnym pipeline’ie.

W praktyce: jak to wpiąć do stosu

Dla typowych raportów i książek sensownym punktem startowym jest tryb Small (100 tokenów). Gdy odległość edycyjna okaże się zbyt duża, zwiększaj budżet. W przypadku bardzo gęstych stron, drobnych fontów lub wysokich liczności tokenów tekstu, lepsze będą warianty Gundam – łączą szeroki kontekst z „zajawką” lokalnych detali, a przy tym trzymają się przewidywalnych limitów.

Jeżeli w dokumencie dominują tabele, wykresy czy struktury chemiczne, warto skorzystać z funkcji „deep parsing” i projektować wyjścia pod walidowalny format: HTML‑tabele, SMILES, czy reprezentacje geometrii. To ułatwia automatyczne testy jakości i wykrywanie regresji.

Gotowość środowiska i koszt wejścia

Model udostępniono w ekosystemie Transformers, z przetestowaną konfiguracją: Python 3.12.9, CUDA 11.8, PyTorch 2.6.0, Transformers 4.46.3, Tokenizers 0.20.3 i Flash Attention 2.7.3. Repozytorium zawiera pojedynczy plik wag w formacie safetensors (~6,67 GB), co ułatwia pracę na popularnych GPU.

Konkurencja, ale i zastrzeżenia

Kluczowa teza DeepSeek‑OCR brzmi: „optyczna kompresja kontekstu” pozwala znacząco skrócić sekwencję dla dekodera bez dużych strat jakości – mniej więcej do 10× kompresji. Dane z Fox to wspierają, ale przy 20× precyzja spada do ok. 60%, co wyznacza praktyczny próg. Porównania z GOT‑OCR 2.0 i MinerU 2.0 wyglądają obiecująco z perspektywy efektywności tokenowej, lecz różnice w budżetach i metrykach sugerują ostrożność przy ekstrapolacji na własne zbiory.

Warto też odnotować charakter dekodera MoE: ok. 570 mln aktywnych parametrów na token to rozsądny koszt jak na 3B‑klasę, ale schemat ekspercki ma własne narzuty (routing, balans eksperckich gałęzi). Prawdziwym sprawdzianem będzie stabilność i koszt w długotrwałych przetworzeniach wsadowych.

Wnioski: mniej tokenów, więcej kontroli

DeepSeek‑OCR 3B przekonująco pokazuje, że można przesunąć ciężar z długich sekwencji tekstowych na zwarty opis optyczny strony. Jasno zdefiniowane tryby i budżety tokenów ułatwiają planowanie kosztów, a wyniki na Fox i OmniDocBench sugerują, że przy rozsądnych limitach kompresji dekoder MoE odtwarza tekst niemal bezstratnie. Ostateczne słowo należy jednak do realnych wdrożeń: warto replikować deklarowane ~97% przy ~10× na własnych dokumentach, z naciskiem na tabele, drobny druk i „brudne” skany, gdzie modele wizualno‑językowe najłatwiej gubią szczegóły.