MiniCPM-OCR: Pasangan Sumber Terbuka yang Membaca Dokumen dan Memeriksa Hasil Kerjanya Sendiri

Kebanyakan perangkat dokumen menyerahkan transkrip jadi dan meminta pengguna memercayainya begitu saja. MiniCPM-OCR melakukan hal yang lebih langka. Ia membaca dokumen, lalu model kedua memeriksa hasil bacaan itu wilayah demi wilayah. Model kedua memberi tahu bagian mana yang masih perlu diperiksa manusia. ModelBest dan OpenBMB mengumumkan seri MiniCPM-OCR sebagai sumber terbuka pada 31 Oktober 2026. Seri ini memasangkan pembaca dokumen berparameter 1,3 miliar, MiniCPM-OCR 1.0, dengan pemeriksa kebenaran berparameter 2 miliar, MiniCPM-OCR Jev (OpenBMB/MiniCPM-OCR, GitHub, diakses 1 November 2026). Bersama-sama, keduanya mengubah digitalisasi dokumen dari lompatan keyakinan menjadi antrean peninjauan. Wilayah yang andal lolos otomatis. Hanya wilayah yang meragukan sampai ke manusia.

Poin Penting

• MiniCPM-OCR 1.0 adalah model sumber terbuka berparameter 1,3 miliar. Ia membaca dokumen berbahasa Mandarin dan Inggris. Ia juga membaca PDF, hasil pindaian, dan foto menjadi teks, tabel, dan rumus.

• MiniCPM-OCR Jev adalah pemeriksa berparameter 2 miliar. Ia menilai hasil OCR wilayah demi wilayah dengan skor 0 sampai 1. Alur kerja dapat menerima otomatis wilayah yang andal. Sisanya diarahkan ke peninjauan manusia.

• Pembaca ini mencatat 93,68 pada Real5-OmniDocBench dan 54,7 pada OCRBench v2. Kecepatannya 1,217 halaman per detik pada satu RTX 5090. Semua angka itu berasal dari vendor dan perlu dibaca dengan hati-hati menurut liputan independen.

• Kedua model dirilis dengan lisensi Apache 2.0. Lisensi itu mencakup kode, dokumentasi, dan bobot model. Kedua model berjalan lokal melalui vLLM, SGLang, llama.cpp, dan Ollama.

• Jev bekerja dengan keluaran dari mesin OCR mana pun. Ia tidak hanya bekerja dengan MiniCPM-OCR 1.0. Tim dapat menambahkan pemeriksaan kualitas ke alur kerja yang sudah berjalan. Tim tidak perlu mengganti pembaca yang dipakai.

Peluncuran ini datang dalam dua tahap. Repositori proyek dibuka di GitHub pada 27 Oktober 2026, lalu pengumuman bersama ModelBest dan OpenBMB menyusul pada 31 Oktober 2026. Pada 1 November 2026, repositori itu telah mengumpulkan 719 star dan 48 fork, dengan 112 commit (OpenBMB/MiniCPM-OCR, GitHub, diakses 1 November 2026). Angka-angka awal itu lebih bercerita tentang waktu daripada tentang kematangan. Asupan dokumen adalah salah satu pekerjaan AI yang jelas cocok untuk model lokal yang kecil dan dapat diperiksa. Rilis ini memang dibangun untuk pekerjaan itu.

Apa Itu MiniCPM-OCR?

Pengenalan karakter optis (OCR) adalah tugas mengubah gambar berisi teks menjadi teks yang dapat dibaca mesin. Penguraian dokumen melangkah lebih jauh. Ia memulihkan struktur. Tabel tetap menjadi tabel. Rumus tetap menjadi rumus. Urutan baca tidak hilang. MiniCPM-OCR adalah keluarga model untuk penguraian dokumen dan pengenalan teks yang efisien. MiniCPM-OCR 1.0 adalah model khusus OCR pertamanya dalam keluarga MiniCPM-V (OpenBMB/MiniCPM-OCR, GitHub, diakses 1 November 2026). Model ini menangani dokumen dan PDF berbahasa Mandarin dan Inggris. Model ini juga menangani masukan yang lazim memenuhi arsip nyata. Masukan itu meliputi hasil pindaian, foto, halaman melengkung, halaman miring, dan tangkapan layar dokumen.

Cakupan model ini lebih luas daripada paragraf biasa. Ia membaca teks, tabel, rumus, diagram, dan stempel. Ia juga mendukung ekstraksi informasi kunci. Ekstraksi itu mengambil kolom tertentu dari faktur, kartu identitas, dan laporan keuangan sesuai instruksi bisnis (pengumuman ModelBest dan OpenBMB). Kombinasi itu penting karena sebagian besar pekerjaan dokumen bukan membaca demi membaca. Pekerjaan itu memberi makan sistem di hilir: buku besar, indeks pencarian, atau arsip kontrak. Pembaca yang menghilangkan struktur tabel dalam perjalanan memaksa setiap langkah berikutnya untuk menebak.

Cara Kerja Pembaca

Alur dokumen punya tiga tugas: menemukan wilayah, membacanya, dan menyusunnya kembali sesuai urutan. MiniCPM-OCR 1.0 mengikuti pola itu. Model tata letak mendeteksi wilayah dokumen dan urutan baca. Model pengenalan membaca tiap potongan wilayah. Hasilnya disusun menjadi Markdown sesuai urutan baca. Tabel diubah menjadi HTML. Rumus dipertahankan sebagai LaTeX, menurut analisis independen atas rilis ini.

Kecepatan datang dari akselerator pendekodean bernama DSpark. Dengan akselerasi pendekodean DSpark, proyek ini melaporkan peningkatan efisiensi sebesar 55 persen. Peningkatan itu diukur ujung ke ujung (OpenBMB/MiniCPM-OCR, GitHub, diakses 1 November 2026). Angka itu berasal dari vendor, dan sebaiknya dibaca sebagai klaim tentang konfigurasi yang dipercepat, bukan jaminan untuk setiap dokumen. Meski begitu, arahnya jelas. Model ini sengaja dibuat sempit, hanya untuk membaca dokumen. Model ini pun dapat tetap kecil dan cepat. Model visi umum akan lebih besar dan lebih lambat.

Bagi tim yang tidak ingin menjalankan sendiri, proyek ini juga menyediakan API gratis dan demo daring. Proyek ini juga menyediakan berkas skill yang memberi tahu agen coding cara menyiapkan lingkungan, mengunduh model, dan membaca dokumen pertama (OpenBMB/MiniCPM-OCR, GitHub, diakses 1 November 2026). Demo adalah pemberhentian pertama yang tepat. Demo menunjukkan apa yang dilakukan pembaca terhadap pindaian yang berantakan. Pengguna pun belum perlu menghabiskan waktu untuk pemasangan.

Mengenal Jev, Sang Pemeriksa

MiniCPM-OCR Jev adalah model penentu kebenaran OCR untuk teks, rumus, dan tabel. Dengan diberi gambar dan hasil OCR yang sesuai, ia mengembalikan skor kualitas 0 sampai 1. Skor itu membantu memilih hasil yang andal. Skor itu juga menemukan konten yang perlu ditinjau (OpenBMB/MiniCPM-OCR, GitHub, diakses 1 November 2026). Skor yang lebih tinggi berarti kandidat tersebut lebih mungkin benar. Jev tidak membaca ulang halaman dari awal. Ia membandingkan potongan wilayah asli dengan teks kandidat. Ia juga membandingkannya dengan gambar yang dirender dari kandidat itu. Ia pun dapat menilai keluaran dari pembaca mana pun. Ia tidak hanya menilai model saudaranya.

Rancangan itu membuka tiga cara kerja. Pertama, penerimaan otomatis berbasis ambang. Beri skor tiap wilayah. Teruskan wilayah yang melewati ambang. Kirim sisanya ke peninjau manusia. Kedua, pemilihan terbaik dari beberapa kandidat: biarkan beberapa pembaca membaca wilayah yang sama dan pertahankan kandidat berskor tertinggi. Ketiga, pemilihan batch lintas blok. Satu dokumen utuh disusun dari kandidat terbaik sesuai urutan baca, seperti dijelaskan dalam analisis independen atas rilis ini. Ambang bukan angka yang dapat ditetapkan lalu dilupakan. Diagram bebas tinjau proyek itu menunjukkan ambang antara 0,984 dan 0,995. Ambang itu menghasilkan porsi bebas tinjau dari 35 persen sampai 85 persen, tergantung jenis dokumen. Tim sebaiknya menyetel ambang pada dokumennya sendiri, bukan mengadopsi nilai bawaan.

Satu detail operasional patut diperhatikan sebelum penerapan apa pun. Layanan penilaian mengembalikan putusan bersama skor, dan hanya putusan scored yang berarti model benar-benar berjalan. Kegagalan praperiksa, perenderan, atau proses maju mengembalikan nilai tetap. Nilai itu tidak boleh dibaca sebagai skor rendah, menurut analisis independen atas rilis ini. Alur yang mengabaikan putusan itu akan diam-diam memperlakukan permintaan yang rusak sebagai dokumen yang gagal. Itulah jenis kesalahan senyap yang justru hendak dicegah Jev.

For example, tim keuangan yang memindai faktur pemasok dapat menerima otomatis tiap wilayah yang melewati ambang. Tim itu hanya mengirim total serta tanggal yang berskor rendah ke peninjau. Cara ini mengubah pemeriksaan manual atas tiap halaman menjadi antrean pengecualian yang pendek. For example, perpustakaan universitas yang mendigitalkan arsip tesis dapat memusatkan staf pada halaman rusak dan catatan tulis tangan. Staf tidak perlu memeriksa halaman bersih yang sudah dibaca model dengan benar.

Metode Artikel Ini

Metode artikel ini sederhana. Artikel ini berangkat dari README proyek dan pengumuman bersama. Artikel ini lalu memeriksa silang tiap angka utama dengan analisis independen. Artikel ini juga menandai angka dari vendor sebagai angka vendor. Bila sumber membingkai angka secara berbeda, artikel ini melaporkan kedua konfigurasi. Contohnya konfigurasi MinerU2.5 Pro di balik angka 3,62 kali. Artikel ini tidak hanya melaporkan konfigurasi yang paling menguntungkan.

Apa Kata Tolok Ukur, dan Apa yang Tidak Dikatakannya

Menurut angka vendor, MiniCPM-OCR 1.0 mencatat 93,68 pada Real5-OmniDocBench. Tolok ukur itu dibangun dari tangkapan sulit di dunia nyata. Model ini juga mencatat 54,7 pada OCRBench v2 untuk kemampuan OCR umum (OpenBMB/MiniCPM-OCR, GitHub, diakses 1 November 2026). Analisis independen menambahkan gambaran yang lebih lengkap. Model ini mencatat 92,39 pada Wild-OmniDocBench. Model ini mencatat 96,51 pada OmniDocBench v1.6 dan 82,7 pada olmOCR-Bench. Rata-rata berbobot samanya sebesar 91,32 pada empat tolok ukur penguraian (analisis Flowtivity). Keunggulan atas model berikutnya yang melaporkan keempat tolok ukur itu adalah 0,39 poin. Model itu adalah Xiaomi-OCR-0 pada 90,93. Keunggulan itu nyata, bukan kemenangan telak.

Angka Jev secara relatif lebih kuat. Dengan hanya 2 miliar parameter, ia mencapai AUROC 93,6 pada JevOCRBench. Nilai itu mengungguli pesaing berparameter 35 miliar pada 90,1. Nilai itu juga mendekati model berparameter 397 miliar pada 93,8 (OpenBMB/MiniCPM-OCR, GitHub, diakses 1 November 2026). AUROC adalah ukuran baku tentang seberapa baik sistem penilaian memisahkan hasil yang benar dari hasil yang salah. Nilai yang lebih tinggi berarti pemisahan yang lebih baik. Pada hasil penguraian dari empat mesin OCR yang berbeda, AUROC Jev berkisar 91,9 sampai 93,4. Hal itu mendukung klaim bahwa ia dapat dipakai lintas pembaca. Ia tidak hanya menilai model saudaranya.

Dua catatan perlu diletakkan dalam paragraf yang sama dengan pujian. Pertama, setiap angka tolok ukur di sini berasal dari vendor. Berkas tolok ukur proyek itu sendiri yang dapat dibaca mesin menandai beberapa baris sebagai menunggu konfirmasi. Skor yang belum terselesaikan dibiarkan kosong (analisis Flowtivity). Kedua, vendor tidak melaporkan skor CHAOS-Bench untuk modelnya sendiri, sementara setiap model lain dalam tabel perbandingannya punya nilai. Semua itu tidak membuat angka-angka tersebut salah. Tim yang memilih mesin OCR sebaiknya menjalankan dokumennya sendiri lewat demo dan API gratis. Lakukan itu sebelum memercayai diagram apa pun.

Seberapa Cepatkah Model Ini?

OpenBMB mengukur kecepatan pada satu NVIDIA GeForce RTX 5090. Pengukuran memakai seluruh 1.651 gambar dalam OmniDocBench v1.6. Konkurensi tingkat gambar sebesar 1 dipakai. Tiap sistem berada pada konfigurasi yang dipercepat. MiniCPM-OCR 1.0 mencapai 1,217 halaman per detik. Angka itu 1,49 kali PaddleOCR-VL-1.6 pada 0,818 halaman per detik. Angka itu juga 3,62 kali MinerU2.5 Pro pada 0,336 halaman per detik dalam konfigurasi Advanced (analisis Flowtivity). Proyek itu melaporkan rasio yang kurang-lebih sama pada README-nya sendiri (OpenBMB/MiniCPM-OCR, GitHub, diakses 1 November 2026).

Bacalah catatan kecilnya sebelum menentukan ukuran antrean. Angka 3,62 kali itu dibandingkan dengan MinerU2.5 Pro dalam konfigurasi Advanced. Dibandingkan dengan konfigurasi Standard pada 0,531 halaman per detik, selisihnya adalah 2,29 kali. Pesaing terdekat adalah GLM-OCR pada 1,179 halaman per detik. Selisihnya kurang dari 3 persen dari MiniCPM-OCR 1.0. Predikat tercepat di sini tipis, bukan telak (analisis Flowtivity). Pada konkurensi 8 di kartu yang sama, kecepatan naik menjadi 2,133 halaman per detik. Angka itu kira-kira 7.700 halaman per jam. Kecepatan nyata akan bergerak mengikuti isi halaman, backend, konkurensi, dan perangkat keras. Perlakukan angka-angka ini sebagai panduan penentuan ukuran, bukan jaminan tingkat layanan.

Cara Menjalankan MiniCPM-OCR

Jalur praktis dimulai dari berkas skill di repositori. Berkas itu memandu agen coding dalam penyiapan, pengunduhan model, dan pembacaan pertama, baik untuk pembaca maupun Jev (OpenBMB/MiniCPM-OCR, GitHub, diakses 1 November 2026). Untuk penerapan lokal, pembaca mendukung vLLM, SGLang, llama.cpp, dan Ollama sejak hari pertama. Versi terkuantisasi GGUF, AWQ, dan GPTQ diterbitkan saat rilis. Jejak gabungannya sekitar 3,5 miliar parameter. Jejak itu muat dengan nyaman pada satu GPU 24GB. Versi GGUF memungkinkan alur yang sama berjalan pada perangkat keras tanpa GPU (analisis Flowtivity). Penyetelan lanjutan didukung lewat LLaMA-Factory dan Swift untuk pembaca, dan Swift untuk Jev.

Perkirakan hambatan pemasangan pada penerapan pertama. FAQ proyek mendokumentasikan mode kegagalan nyata. CUDA 13 membutuhkan driver versi 580 atau lebih baru. Lingkungan SDK dan inferensi bersama-sama membutuhkan sedikitnya 20GB ruang disk. Penguraian macet kecuali vLLM dijalankan dengan penanda kepercayaan tertentu untuk argumen kata kunci multimodal (analisis Flowtivity). Adaptasi perangkat keras hari pertama mencakup AMD, Arm, Intel, dan NVIDIA. Adaptasi itu juga mencakup cip AI dan cip tepi lewat tumpukan perangkat lunak FlagOS. Apple Mac pada Arm termasuk di dalamnya (pengumuman ModelBest dan OpenBMB). Penerapan pertama memakan waktu seharian, bukan lima belas menit. Tidak ada bagian alur yang membutuhkan panggilan awan. Dokumen sensitif pun tidak harus meninggalkan gedung.

Siapa yang Sebaiknya Memakai, dan Siapa yang Tidak

MiniCPM-OCR 1.0 adalah pilihan tepat bila dokumen pengguna berbahasa Mandarin atau Inggris. Model ini cocok bila sebagian besar dokumen datang sebagai foto atau hasil pindaian, bukan PDF bersih. Model ini juga cocok bila data tidak boleh meninggalkan jaringan sendiri. Model ini juga cocok bila pengguna menginginkan penyaluran peninjauan, bukan keluaran yang sekadar dipercaya. Model ini bukan pilihan tepat bila pengguna membutuhkan cakupan multibahasa yang luas sejak awal. Model ini juga kurang cocok dalam dua keadaan. Pertama, pengguna sudah menjalankan layanan OCR awan dengan perjanjian tingkat layanan. Kedua, kasus penurunan mutu yang diukur CHAOS-Bench menjadi pusat beban kerja. Vendor belum menerbitkan skornya sendiri di sana.

Langkah yang diam-diam paling menarik adalah memakai Jev sendirian. Karena ia menilai kandidat dari pembaca mana pun, sebuah bisnis dapat mempertahankan mesin OCR yang sudah berjalan. Bisnis itu dapat menambahkan pemeriksa berparameter 2 miliar di atasnya. Antrean peninjauan pun terbentuk tanpa migrasi atau pengindeksan ulang. Bila pembaca ingin membandingkan dengan pembaca dokumen sumber terbuka lain, bacalah artikel kami tentang Baidu Unlimited OCR 2. Artikel itu membahas pembaca dokumen panjang dengan pertukaran yang berbeda. Pembaca itu membaca satu buku utuh dalam sekali jalan, bukan pemeriksaan kualitas per wilayah.

Pertanyaan yang Sering Diajukan

Apakah MiniCPM-OCR gratis? Ya. Seluruh proyek dirilis dengan lisensi Apache 2.0. Lisensi itu mencakup kode, dokumentasi, dan bobot model untuk MiniCPM-OCR 1.0 dan MiniCPM-OCR Jev. Biaya pengguna adalah perangkat keras yang dipakai, atau API gratis dan demo bila memulai dari sana. Untuk pengertian dasarnya, baca penjelasan kami Apa Itu Open Source?.

Apa beda MiniCPM-OCR 1.0 dan Jev? MiniCPM-OCR 1.0 adalah pembacanya: ia membaca dokumen dan menghasilkan teks, tabel, dan rumus. Jev adalah pemeriksanya. Ia menilai keluaran pembaca wilayah demi wilayah dengan skor 0 sampai 1. Pengguna pun tahu wilayah mana yang dapat dipercaya. Pengguna juga tahu mana yang perlu dikirim ke peninjau manusia. Jev sendiri tidak melakukan OCR.

Dapatkah Jev memeriksa keluaran dari mesin OCR lain? Ya. Jev membandingkan gambar wilayah dengan kandidat hasil OCR. Ia pun bekerja dengan keluaran MiniCPM-OCR 1.0, GLM-OCR, PaddleOCR-VL-1.6, Xiaomi-OCR-0, dan pembaca lain. Penerapan lintas model itu adalah salah satu nilai jual utamanya.

Dapatkah saya menjalankan MiniCPM-OCR pada perangkat keras sendiri? Ya. Kedua model berjalan lokal lewat vLLM, SGLang, llama.cpp, atau Ollama, dengan versi terkuantisasi GGUF, AWQ, dan GPTQ. Pasangan ini berjumlah sekitar 3,5 miliar parameter. Pasangan ini muat pada satu GPU 24GB. Versi GGUF memungkinkan jalan tanpa GPU. Sediakan sedikitnya 20GB ruang disk untuk lingkungan SDK dan inferensi.

Haruskah saya mengganti tumpukan OCR saya dengan MiniCPM-OCR? Tidak hanya berdasarkan tolok ukur. Jalankan dokumen sendiri lewat demo terlebih dahulu. Setel ambang Jev pada batch kecil. Periksa mode kegagalan yang penting bagi pengguna. Perhatikan terutama cakupan multibahasa dan penurunan mutu gaya CHAOS-Bench. Skor vendor untuk hal itu belum diterbitkan. Bila hanya pemeriksaan kualitas yang dibutuhkan, menambahkan Jev adalah perubahan yang lebih kecil. Perubahan itu juga lebih aman.

Kesimpulan

Singkatnya, MiniCPM-OCR bukan rilis AI paling spektakuler minggu ini, dan justru itulah kekuatannya. Pembaca berparameter 1,3 miliar membaca pindaian berantakan. Pemeriksa berparameter 2 miliar mengakui wilayah mana yang diragukannya. Bersama-sama, keduanya menyelesaikan masalah yang tidak glamor tetapi benar-benar merugikan. Satu baris faktur yang salah terbaca dapat mengalir ke buku besar. Baris itu lalu diperlakukan sebagai fakta. Tolok ukurnya menjanjikan. Catatan kehati-hatiannya terbuka. Rilis berlisensi Apache 2.0 berarti tim mana pun dapat menguji pasangan ini pada dokumennya sendiri sebelum berkomitmen. Mulailah dari repositori GitHub dan pengumuman bersama ModelBest dan OpenBMB, atau baca versi Inggris artikel ini.