- Berangkat dari wawasan bahwa "jika teks direpresentasikan sebagai gambar, informasi yang sama dapat dimuat dengan token yang jauh lebih sedikit"
- Model ini mengusulkan pendekatan baru yang mengompresi informasi teks ke representasi visual 2D, dan memverifikasi secara eksperimental konsep kompresi berbasis visi (Optical Compression) untuk menangani konteks panjang secara efisien
- Model terdiri dari DeepEncoder (encoder) dan DeepSeek3B-MoE-A570M (decoder), serta mencapai memori aktif rendah pada input beresolusi tinggi dan rasio kompresi token sekitar 10~20x
- Model mempertahankan presisi OCR 97% pada kompresi 10x dan akurasi di atas 60% pada kompresi 20x, yang menunjukkan kemungkinan nyata untuk riset kompresi konteks panjang dan mekanisme pelupaan memori
- Di OmniDocBench, model ini melampaui GOT-OCR2.0 dengan hanya 100 vision token dibanding 256 token/halaman, dan menunjukkan kinerja unggul dengan kurang dari 800 token dibanding MinerU2.0 yang rata-rata memakai 6000+ token/halaman
- Dengan satu GPU A100-40G, model ini dapat menghasilkan lebih dari 200 ribu halaman data per hari, sehingga memiliki nilai praktis tinggi sebagai data engine untuk pelatihan LLM/VLM skala besar
1. Latar belakang riset
- LLM konvensional memiliki keterbatasan struktural karena biaya komputasi meningkat secara kuadrat seiring panjang sekuens
- Makalah ini berangkat dari wawasan bahwa "jika teks direpresentasikan sebagai gambar, informasi yang sama dapat dimuat dengan token yang jauh lebih sedikit"
- Ini didefinisikan sebagai kompresi konteks panjang berbasis token visual (Context Optical Compression), dengan OCR dijadikan panggung eksperimennya
- Hasilnya menunjukkan jalur baru di mana representasi visual dapat meningkatkan efisiensi pemrosesan konteks pada LLM
2. Arsitektur model
- DeepSeek-OCR = DeepEncoder + decoder DeepSeek3B-MoE
- DeepEncoder: SAM(Window Attention) + CLIP(Global Attention) + kompresor token 16x
- DeepSeek3B-MoE: 6 dari 64 expert diaktifkan, total 570M parameter aktif
- Mendukung mode multi-resolusi (Tiny~Gundam)
- Mendukung input resolusi 512~1280, dan dapat memproses gabungan hingga 9 tile
- Mode Gundam ditujukan untuk dokumen beresolusi sangat tinggi (seperti koran), dengan penggunaan hingga 800 vision token
3. Data engine
- Total terdiri dari 3 jenis kombinasi data:
- Data OCR 1.0: 30M halaman berbasis dokumen dalam 100 bahasa, termasuk anotasi layout dan teks yang rinci
- Data OCR 2.0: 16M data untuk pengenalan kompleks seperti chart, rumus kimia (SMILES), dan bentuk geometri
- Data visi umum: untuk mempertahankan pemahaman visual berbasis CLIP, sebanyak 20% dari total
- Data teks murni: porsi 10% untuk melengkapi kemampuan bahasa
- Rasio komposisi seluruh data pelatihan
- OCR 70% / visi 20% / teks 10%
4. Pipeline pelatihan
- Dilatih dalam dua tahap: DeepEncoder → DeepSeek-OCR
- Pada total 20 node (8×A100 GPU), digunakan data parallelism DP=40, dengan global batch 640
- Kecepatan pelatihan: 90B token/hari untuk data teks, 70B token/hari untuk data multimodal
5. Hasil evaluasi
(1) Eksperimen kompresi (benchmark Fox)
- Akurasi 97% pada kompresi 10x, dan tetap di atas 60% pada kompresi 20x
- Kinerja menurun saat dokumen makin panjang atau kompleks, tetapi ini ditafsirkan sebagai kemungkinan simulasi “mekanisme pelupaan”
- Pada rasio kompresi 10x ke bawah, pemulihan konteks nyaris tanpa kehilangan dimungkinkan
(2) Pengenalan dokumen nyata (OmniDocBench)
- Perbandingan mode Tiny(64 token)~Gundam(800 token)
- Unggul dari GOT-OCR2.0(256 token) pada mode Small(100 token)
- Melampaui MinerU2.0(7.000 token) dengan Gundam(800 token)
- Jumlah token yang dibutuhkan berbeda menurut jenis dokumen
- Slide, laporan: cukup 64~100 token
- Koran, paper: butuh 400~800 token
6. Analisis kualitatif (Qualitative Study)
- Mode Deep Parsing
- Memungkinkan ekstraksi terstruktur dengan satu prompt untuk chart, bentuk, rumus kimia, hingga gambar alami
- Pengenalan multibahasa
- Mendukung PDF dalam sekitar 100 bahasa, termasuk bahasa minoritas seperti Arab dan Sinhala
- Pemahaman visual umum
- Dapat melakukan deskripsi gambar, deteksi objek, hingga grounding
- Saat dihubungkan dengan LLM, dapat dimanfaatkan sebagai model dasar untuk penalaran gabungan vision-language
7. Diskusi dan implikasi
- DeepSeek-OCR adalah eksperimen pertama yang mengeksplorasi batas kompresi teks panjang berbasis vision token,
dengan mengkuantifikasi konsep bahwa "satu gambar memuat seribu kata"
- Pemulihan hampir tanpa kehilangan tetap dimungkinkan bahkan pada kompresi 10x → dapat diperluas ke kompresi riwayat percakapan, optimasi memori jangka panjang, dan lain-lain
- Melalui cara menurunkan resolusi gambar seiring waktu, model ini mengusulkan simulasi peluruhan token yang mirip dengan kurva pelupaan biologis
8. Kesimpulan
- DeepSeek-OCR adalah model pembuktian empiris untuk pemetaan kompresi 10~20x antara teks dan visual,
yang menghadirkan paradigma baru untuk mengatasi keterbatasan pemrosesan konteks panjang pada LLM
- Melampaui OCR, ke depannya model ini diperkirakan dapat diperluas ke pretraining campuran digital-optik dan
model konteks ultra-panjang berbasis 'Optical Context Memory'
- Kodenya telah dipublikasikan dan dapat dimanfaatkan untuk riset maupun data engine komersial
- Dibandingkan OCR open source yang sudah ada, DeepSeek-OCR mendapat perhatian sebagai arsitektur berbasis model bahasa besar (LLM) yang mengenkode informasi visual secara efektif
- Dengan dukungan berbagai resolusi (512×512~1280×1280) serta mode Gundam untuk resolusi dinamis, model ini sangat adaptif terhadap beragam lingkungan
- Dengan desain prompt yang jelas, model ini mendukung berbagai mode tugas seperti deskripsi gambar umum, konversi Markdown, OCR yang mengabaikan layout, dan parsing diagram
- Kinerjanya telah diverifikasi melalui benchmark industri seperti Fox, OminiDocBench serta eksperimen pemrosesan dokumen nyata
- Implementasinya mengadopsi keunggulan dan ide dari proyek populer lain seperti GOT-OCR2.0 dan PaddleOCR
- Resolusi yang didukung
- Tiny: 512×512 (64 vision tokens)
- Small: 640×640 (100 vision tokens)
- Base: 1024×1024 (256 vision tokens)
- Large: 1280×1280 (400 vision tokens)
- Dynamic mode(=Gundam): resolusi bebas (n×640×640 + 1×1024×1024)
- Inferensi paralel untuk PDF dan gambar serta kecepatan pemrosesan tinggi
- Berdasarkan GPU A100, pemrosesan PDF hingga sekitar 2.500 token/detik
- Latar belakang teknis dan keterkaitan ekosistem
- Diimplementasikan 100% dengan Python
- Mendukung dua lingkungan inferensi utama: vLLM dan Transformers
- Memanfaatkan benchmark dan framework evaluasi utama seperti OpenChart, Fox, OminiDocBench
- Terhubung dengan model terdahulu seperti GOT-OCR2.0, PaddleOCR, dan Vary, sekaligus mengadopsi ide serta memperkuat performanya
1 komentar
Opini Hacker News
Makalah ini bukan sekadar VLM lain untuk OCR, tetapi melangkah ke topik yang lebih menarik seperti kompresi
Misalnya, ada kutipan: "Kami melakukan studi awal untuk mengeksplorasi batas kompresi vision-text, dengan melihat berapa banyak token visi yang diperlukan untuk mendekode token teks. Hasil awal menunjukkan DeepSeek-OCR mencapai kompresi OCR hampir tanpa kehilangan pada rasio sekitar 10x, dan bahkan pada kompresi 20x masih mempertahankan akurasi 60%"
Secara intuitif, ini berarti satu token visi memuat informasi setara 10 token teks
Saya ingin ada yang menjelaskan, dengan cara yang bisa dipahami pemula, mengapa hasil seperti ini muncul dari sudut pandang teori informasi
Apakah karena token teks masih terlalu terpecah-pecah (atau redundan) dan belum mendekati entropy coding, atau karena saat beralih ke pendekatan token visi kita keluar dari batasan 'berbasis kata' sehingga bisa lebih dekat ke entropi (seperti perbedaan arithmetic encoding dan Huffman coding)
Dan makalah ini juga membahas bahwa saat menangani konteks berukuran besar, mereka benar-benar melakukan downscale pada gambar, sehingga ada pembahasan tentang hubungan antara kehilangan informasi di domain teks dan domain gambar
Token teks adalah subunit terkuantisasi (subword), sedangkan token visi hanya ada di ruang embedding
Pada LLM, cara tokenisasi teks pada dasarnya berupa struktur lookup table dari ID token (kecil) ke embedding vektor (besar)
Saat teks dikirim ke LLM, string dipotong di batas token, diubah menjadi ID token, lalu vektor diambil dari lookup table untuk membentuk matriks (context matrix)
Pengiriman urutan token teks yang sebenarnya efisien, karena hanya perlu mengirim array angka (ID), biasanya dari sekitar ~100 ribu ID token unik
Sebaliknya, mengirim matriks embedding itu sendiri tidak efisien, karena embedding terdiri dari ribuan angka float
Gambar dienkode secara berbeda. Data gambar dipraproses lalu langsung dimasukkan ke image encoder berbasis neural network untuk diubah menjadi vektor, dan vektor-vektor ini digabungkan ke dalam konteks
Artinya, token gambar tidak punya ID token maupun lookup table; ia langsung beralih dari data ke embedding
Akibatnya, untuk mengirim token gambar, yang harus dikirim adalah embedding itu sendiri, sehingga tidak efisien
Meskipun gambar bisa dienkode dengan jumlah token lebih sedikit, kapasitas tiap token jauh lebih besar
Singkatnya, token teks adalah integer yang punya pemetaan jelas dari (0~n) ke vektor, sehingga ada ‘n’ pilihan
Sementara token gambar adalah array float berdimensi m (vektor), sehingga ruang tokennya jauh lebih besar
Dari sisi pola juga begitu: token teks berkorespondensi langsung dengan byte UTF-8 yang berurutan, dan kebanyakan tidak melampaui batas kata, sehingga pola global (misalnya “dialog ini milik Hamlet”, “bagian ini berbahasa Spanyol”) tidak bisa direpresentasikan oleh satu token saja
Saya tidak yakin persis bagaimana input gambar di-embedding pada multimodal LLM, tetapi pemahaman dasarnya adalah gambar dipotong menjadi grid lalu tiap area dienkode
Dalam eksperimen DeepSeek, tampaknya yang utama bukan sifat teori informasinya, melainkan seberapa jauh resolusi bisa diturunkan atau ukuran grid (patch) bisa diperkecil namun tetap menyimpan detail yang cukup untuk OCR akurat
Saya berharap Karpathy memperluas NanoChat ke multimodal dan membagikan pengetahuan praktis tentang proses encoding seperti ini
Rasio kompresi yang tepat pada akhirnya pasti bergantung pada ukuran relatif antara resolusi tiap karakter dan ukuran patch tiap token visi
Hanya dengan begitu jumlah token teks yang diekstrak lewat OCR pada akhirnya bisa tetap independen dari resolusi gambar
Setiap token teks umumnya berada pada level subword, tetapi token visi pada VLM berada di ruang semantik
Ruang semantik bisa mengompresi informasi jauh lebih kuat daripada pemecahan subword
Catatan: saya bukan ahli, ini hanya pemikiran spontan
LLM adalah arsitektur di mana biaya komputasi meningkat kuadrat terhadap jumlah token
Karena itu, pada VLM orang mencoba mengompresi token teks menjadi token visi
Sepertinya mereka mencoba lebih dulu merender teks menjadi gambar lalu melakukan tokenisasi untuk mengurangi biaya komputasi
PyTorch agak rewel di NVIDIA Spark (ARM64), tetapi saya bisa menjalankannya setelah menjalankan Claude Code sebagai root di container Docker baru
Catatan detailnya bisa dilihat di sini
Hasil nyatanya bisa dilihat di tautan ini, dan diuji pada gambar OCR asli (di sini)
Hasil OCR-nya secara umum sangat solid
Hanya saja, pada paragraf tepat di bawah kutipan model menambahkan hal yang tidak perlu sehingga berhalusinasi, lalu menyambungkannya ke kolom berikutnya
Terima kasih sudah melakukan pengujian cepat ini
Bisa dipahami juga bahwa model melewatkan huruf "A" di awal teks (mungkin proporsi artikel berita di dataset-nya rendah)
Tetapi saya justru lebih tertarik karena seluruh bagian "Hallucination is a risk and...", topik (“theme”) di samping penulis, dan bagian email terakhir juga terlewat sepenuhnya
Eksperimen ini sendiri rasanya layak dijadikan postingan terpisah
"menjalankan Claude Code sebagai root di container Docker baru"
Saya ingin tahu lebih spesifik bagaimana mengaturnya agar berjalan dengan hak root
(kalau penjelasannya memang ada, saya akan cek di artikel)
Tidak ada penyebutan Anna’s Archive di makalah ini
Saya rasa mungkin saja DeepSeek benar-benar memanfaatkan tawaran dari pihak Anna untuk memberi peneliti OCR akses ke koleksi nonfiksi Tiongkok berisi 7,5 juta buku (350TB)
Jumlah ini bahkan lebih besar daripada Library Genesis
Posting blog referensi
Dalam makalah DeepSeek sebelumnya, Anna’s Archive disebut secara langsung
"Menyaring 860K buku elektronik berbahasa Inggris, 180K buku elektronik berbahasa Tiongkok, serta jutaan soal ujian pendidikan K-12 dari Anna’s Archive"
Lihat makalah DeepSeek-VL
Saya ragu mereka benar-benar perlu meminta hak akses hanya karena menyimpan buku orang lain
Saya juga langsung teringat Anna’s Archive, dan penasaran kapan dataset yang sudah diproses OCR akan dirilis
Itu juga berarti dataset tersebut bisa jadi tidak akan pernah dibuka ke publik
Dalam situasi seperti ini saya khawatir Anna’s Archive pada akhirnya juga akan habis disalahgunakan oleh perusahaan LLM
META saja sudah mengeruk 70TB dari library genesis lewat torrent
Berbagi pengalaman tentang tingkat nyata benchmark yang berbeda dari kondisi saat ini
Benchmark OmniAI kurang bagus
Sebagai gantinya saya merekomendasikan OmniDocBench
Mistral OCR jauh tertinggal dibanding model OCR open source lain, dan juga dibanding Gemini
E2E OCR masih sangat sulit
Pendekatan pipeline (deteksi layout → penentuan urutan baca → OCR tiap elemen) bekerja lebih baik
Parsing tabel kompleks masih jadi masalah besar
Saya juga penasaran apakah Apple Vision Framework pernah dibandingkan lewat benchmark dengan model-model ini
Framework itu tertanam di hampir semua perangkat Apple dan dalam praktiknya menghasilkan OCR yang berkualitas tinggi dan cepat (terutama untuk konversi PDF), tetapi sepertinya orang jarang membicarakannya
Saya benar-benar penasaran posisinya di benchmark
Menurut benchmark OmniAI, Omni OCR menunjukkan performa terbaik
Sepertinya orang-orang akan menerima hasil seperti itu tanpa banyak mempertanyakannya
Saya penasaran apa kelebihan dan perbedaan OCR berbasis LLM dibanding layanan seperti Azure AI Document Intelligence(tautan) atau Google Vision API(tautan)
Di OmniAI, mereka membenchmark LLM internal mereka melawan OCR cloud
Benchmark blog OmniAI (per Februari 2025)
Sejak itu, LLM berkembang sangat cepat
Seri Qwen3-VL, khususnya Qwen3-VL-235B-A22B-Instruct, belakangan tampak memberikan hasil terbaik
Dugaan saya, model OCR komersial/proprietary masih akan terus lebih unggul pada dokumen dunia nyata
Itu berkat banyaknya dataset pelatihan privat berkualitas tinggi
LLM publik dilatih pada data yang berpusat pada makalah seperti arXiv, ebook, dan sejenisnya, jadi pada dokumen kerja nyata performanya cenderung kalah
Pendekatan LLM memang mengurangi kesalahan substitusi karakter (salah ketik, bentuk mirip), tetapi justru konsistensi pada tingkat satu halaman penuh lebih rendah
Ia juga bisa menghasilkan keluaran yang benar-benar melenceng seperti LLM non-OCR
Untuk karakter CJK, OCR tradisional masih sering menghasilkan substitusi yang tidak tepat
Ada terlalu banyak karakter yang sangat mirip, bahkan kadang hanya bisa dibedakan pada level mikroskopis atau biner
LLM dapat memberi batasan lebih kuat pada urutan karakter yang mungkin muncul, sehingga hasil yang lebih akurat bisa diharapkan
Setidaknya pertimbangan seperti ini menjadi motivasi untuk mengadopsi OCR berbasis LLM
Saya tidak tahu model lain, tetapi perusahaan kami menjalankan sistem parsing resume dengan Azure AI Document Intelligence dan kami cukup puas
Di awal hanya perlu sedikit perhatian untuk tuning, dan selama sekitar satu tahun terakhir hampir tidak perlu disentuh lagi
Saya sudah menguji berbagai VLM (Granite, Qwen, dari model kecil sampai besar), dan kesimpulannya mengecewakan kalau mau dijadikan pengganti penuh OCR tradisional
Sistem kami menerima dokumen pelanggan lalu mengembalikan dokumen standar yang dimarkup sesuai permintaan (bitmap multi-halaman berbasis raster)
Bagi kami, presisi ekstraksi koordinat sampai level karakter atau kata sangat penting, tetapi dalam praktiknya informasi posisi dari VLM terlalu tidak konsisten, sepenuhnya halusinatif, atau terlalu ambigu sehingga tidak bisa menjamin akurasi/kerincian yang kami butuhkan
Sampai sekarang kami tetap memakai Tesseract dengan rutinitas pembersihan hasil, dan hanya sesekali memanfaatkan keluaran teks dari VLM sebagai bantuan ketika tidak ada dataset terstruktur
Kebutuhan kami mungkin sangat niche, dan bagi kebanyakan orang mungkin cukup jika hanya bisa mendapatkan dump teks atau konversi ke Markdown/HTML
Tetapi saya merasa ada jarak yang cukup besar antara klaim bahwa model-model ini telah 'menyelesaikan OCR sepenuhnya' dan pengalaman di lapangan
Ada usulan apakah sudah mencoba model moondream 3 preview
Di posting blog-nya disebut mengungguli banyak VLM lain dan model ini ringan
Lihat halaman utama, model, dan blog
Saya penasaran apakah dokumen pelanggan juga mengandung teks tulisan tangan
Mungkin juga bisa memakai CNN untuk menemukan bounding box teks terlebih dahulu, lalu menjalankan VLM pada tiap kotak
Kesan pribadi saya, OCR terasa seperti masalah yang pada dasarnya sudah cukup terpecahkan
Benchmark OmniAI juga belum diperbarui dengan model terbaru, dan saya pikir alasannya adalah karena LLM umum sekarang sudah melampaui OCR benchmark itu sendiri
Faktanya, jika tiap gambar halaman dimasukkan ke Gemini 2.5 Flash Lite dan diminta diekstrak dalam format Markdown, biayanya hanya sekitar 20 sen per 1000 halaman dan hasilnya juga sangat bagus
Saya penasaran apa yang masih membuat OCR sulit sekarang
Bahkan kebanyakan OCR/LLM (terutama Gemini Pro 2.5) masih kesulitan untuk mengubah tabel kompleks menjadi Markdown/HTML
Masalah seperti multi-header, sel tergabung, kolom dengan checkbox sering muncul, dan tabel yang membentang di beberapa halaman juga tidak benar-benar dipahami
Llamaindex juga gagal parah dalam hal ini
Saya ingin tahu OCR/LLM mana yang lebih baik untuk masalah seperti ini
Contoh tabel kompleks, Contoh lengkap checklist ICAO
Sebenarnya bukan OCR, melainkan HTR (pembacaan/pengenalan tulisan tangan) yang masih sulit
Berkat LLM akurasinya memang jauh lebih baik, tetapi kesalahannya justru sangat sulit ditemukan manusia (bagian yang tidak terbaca malah diisi dengan karangan sendiri)
Kalau Anda bisa menerima hasil yang tidak memberi tahu "saya tidak tahu" pada bagian yang gagal dikenali, dan malah mengarang untuk mengisinya, maka ya, masalahnya memang terasa selesai
(bukan bermaksud sinis; untuk sebagian situasi itu memang bisa diterima)
Saya adalah penulis benchmark OmniAI
Alasan tidak ada pembaruan model terbaru adalah karena OCR API itu sendiri sedang diperkecil perannya di produk
Secara internal masih kami pakai, hanya benchmark-nya tidak diperbarui karena malas
Gemini adalah yang terbaik untuk OCR
Namun, jika hasilnya terlalu dekat dengan data pelatihan, sering muncul error 'recitation' di mana sekitar 10% output mendadak terpotong
Pada campuran PDF, jika ada halaman kosong, kadang muncul halusinasi lucu berupa isi baru yang sama sekali tidak relevan
OpenAI juga tidak terlalu buruk, tetapi GPT5 tidak ada bedanya dibanding GPT-4o atau 4.1
Sebagian konten seperti header/footer sering menghilang, dan kalau halaman diputar ke samping hasilnya jadi kacau
Model juga sering menolak sendiri saat berhadapan dengan kartu identitas, dokumen medis, atau konten dengan risiko PII tinggi
Menurut saya ini jelas belum menjadi masalah yang selesai
Coba saja OCR majalah dengan layout yang tidak biasa, itu nyaris mustahil
Saya mengoleksi majalah vintage dan selalu mencoba OCR dengan teknologi terbaru, tetapi pada akhirnya tetap butuh campur tangan manusia yang sangat besar
Saya penasaran apakah ada 'model OCR' kecil
Kasus saya hanya ingin mengambil serial number dari foto di lokasi produksi, tidak perlu parsing seluruh dokumen
Memakai model 3 miliar parameter untuk tugas seperti ini terasa berlebihan
Saya penasaran bagaimana DeepSeek-OCR dibandingkan dengan Tesseract(tautan)
Saya sangat suka ocrmypdf(tautan) dan memakainya secara lokal dengan hasil yang sangat baik
Kalau ternyata tesseract memberi 80% performa dan model terbaru naik ke 95%, tetapi sebagai gantinya harus membayar dengan hard disk 100x lebih besar, Kubernetes/Docker, GPU dengan 16GB VRAM, dan tuntutan infrastruktur lain, maka itu jelas layak dipertimbangkan
Saya belum bisa mengikuti riset terbaru, jadi ingin ada yang menjelaskan ini secara ELI5 (seolah menjelaskan ke anak 5 tahun): ini sebenarnya apa, dan kenapa penting
Judul di GitHub atau makalahnya tentang OCR, tetapi di ringkasan dan readme.md malah bicara soal kompresi konteks LLM, jadi membingungkan
Saya ingin ada yang menjelaskan bagaimana dua hal ini saling terhubung dalam konteks yang lebih besar
Gambar itu memuat informasi setara ‘1000 token’
Dalam praktiknya, gambar harus diubah dulu menjadi feature/embedding (didekode)
Jika gambar itu diproses sebagai 100 ‘token gambar’, lalu token gambar itu diubah menjadi 1000 ‘token teks’
Maka dari sudut pandang decoding murni, Anda telah menyampaikan informasi keluaran dengan kompresi 10x
Dari sudut pandang LLM, ini berarti jika representasi laten yang 10x lebih kecil bisa dipakai untuk mengompresi lebih dulu, maka model dapat menghasilkan hasil setara atau lebih baik tanpa harus membawa 1000 token/embedding itu sendiri