Enterprises adding OCR (optical character recognition) to a document workflow, whether for RPA or for feeding a RAG-based chatbot, tend to hit the same two walls.
The first is GPU cost. Modern multilingual OCR models, especially the large vision-language ones, need GPU inference to run at usable speed. Cloud GPU instances cost several times more per hour than equivalent CPU instances, and document workloads are bursty by nature, so provisioning for peak demand leaves capacity idle most of the time.
The second is data risk. For financial institutions, healthcare providers, and any organization bound by Japan's Act on the Protection of Personal Information (APPI) or by GDPR, sending documents that contain personal or sensitive data to an external cloud API is often not an option at all. Pay-per-call API pricing also makes cost unpredictable as document volume grows.
The usual workaround, a lightweight CPU-based engine like Tesseract, solves the cost and privacy problem but fails on accuracy for anything beyond clean, well-lit scans, and struggles with non-Latin scripts.
What we actually built, and what it does not claim to do
VAON needed an OCR microservice that could read identifiers (serial numbers, IMEI, model numbers) from photographs of product labels, taken under real working conditions: tilted, unevenly lit, sometimes blurred. The requirement was CPU-only from the start, no GPU dependency.
Rather than train one model to handle every language at a high standard, we split the work into two engines.
The main engine is PP-OCRv6_medium, an existing open-source model, running as two parts: a 59 MB detection model and a 73 MB recognition model, 132 MB combined. It handles English, Japanese, Chinese and Latin-script text and runs on CPU only. Verified on real photographed labels, it reaches 0.997 confidence in English and 0.999 in Japanese, both fully correct reads.
The second engine exists because of one specific failure. When we tested Vietnamese text on the main engine, diacritics were dropped entirely. Sản phẩm Việt Nam came back as Sn phm Vit Nam, not degraded, just gone. Fine-tuning the main engine risked hurting the accuracy that was already working for the other languages, so we added a dedicated Vietnamese engine, VietOCR, instead. It is far heavier, 145 MB for weights alone and roughly 623 MB including its PyTorch runtime, so we load it only when a Vietnamese request actually arrives, controlled by an environment flag. With VietOCR handling Vietnamese, confidence reaches 0.913, a large improvement over a main engine that was effectively unusable for that language.
Each engine also runs behind its own semaphore, not a shared lock, so a heavy VietOCR request cannot make the much lighter PP-OCRv6 requests wait behind it.
We did not build a separate model to extract the identifiers themselves. That part runs on rule-based logic: regex pattern matching against known label formats, proximity matching using text coordinates on the image, and a Luhn checksum for IMEI numbers. Every extracted value can be traced back to the exact rule that produced it, which matters when a false positive needs investigating.
Security and testing, not as a slogan
The service enforces a 25-megapixel limit on uploaded images to block decompression-bomb attacks, verifies every downloaded model weight file against a SHA256 hash, and runs on a Pillow version patched against CVE-2023-4863. It is covered by 54 automated tests: 42 unit tests and 12 integration tests that run against the real models, not mocks.
What this proves, and where the limits are
Running CPU-only removes GPU cost as a line item, and because everything runs inside the client's own infrastructure, no image or extracted text has to leave it, which matters directly for organizations bound by APPI or GDPR. We are not claiming a specific certification here. VAON does not currently hold ISO 27001; our security practices are built on the ISO 27001 framework, with certification on our roadmap.
The 132 MB figure and the confidence scores above are what we measured on this specific test set of photographed labels. A different label design, camera angle, or lighting condition would need its own validation before we would commit to the same numbers for a specific deployment. That validation step is part of how we scope any real engagement, not something we skip to make a bigger claim upfront.
If you are evaluating a CPU-only or on-premise OCR pipeline for your organization, you can read the full technical case study, including test methodology and every number cited above, or reach out for a free consultation.
Website: https://vaon.com.vn/en