DocDot

DocDot: Fast, Accurate, and Local Document Parsing Meets Apple Silicon

Contents

Introduction

Building powerful, LLM-driven document applications often starts with an accurate and efficient parser. But for many real-world workflows, privacy is non-negotiable—sensitive files must run locally on your laptop, without a single byte touching the cloud.

That local setup also has to be fast. An ideal parser should reach 5 to 10 frames per second, which means a 100-page document can be parsed in about 10 to 15 seconds, fast enough for users to move straight into interactive Q&A. But speed alone is not enough. The parser also has to handle complex layouts, dense tables, and paragraphs that span pages, scanned documents, and multiple languages.

To find out whether existing tools could meet those requirements, we thoroughly benchmarked every open-source parser that could run on Mac hardware. We compared their accuracy, speed, power consumption, and other metrics. The result was straightforward: there is no single model that beats everything. Different models are better at different trade-offs depending on the task.

That insight led us to build DocDot, a tool that helps non-technical users install document-parsing models on Apple laptops tailored to their needs and then connect those models to downstream AI tools, including Codex, Claude Code, OpenClaw, Hermes and WorkBuddy.

Hardware & Scope Note: Our preliminary research suggests that local document parsing with deep learning models is currently much more feasible on Apple laptops with M-series Apple Silicon chips. For that reason, the initial benchmark is limited to Apple MacBooks with M-series chips. Windows and Linux laptop testing will follow in a later evaluation phase.

Evaluation Process & Methodology

Selected Candidate Models

Given the number of open-source document parsing tools now available, we grouped the main technical approaches into two categories:

  1. Multimodal Large Language Model (VLM / MLLM) Approaches

    For edge deployment, large multimodal models remain impractical for real-time local processing. Even smaller edge-oriented multimodal models with roughly 1B parameters typically decode at only about 100 tokens per second on laptop hardware. In PDF-to-Markdown conversion, a single dense page can require thousands of tokens. This large computational cost, combined with the minimal conversion efficiency of standalone MLLM/VLM models, renders them impractical for high-performance edge parsing.

  2. Pipeline-Based Document Parsing

    Pipeline-based methods split the task into isolated, but dependent sub-modules that form a processing pipeline. Because these methods usually have fewer parameters, they may be a good choice for local execution on laptops.

Therefore, our evaluation focuses strictly on Pipeline Backend Document Parsing methods, including both open-source frameworks and commercial tools, as long as they support local deployment and are publicly accessible.

Detailed list of evaluated models and feature breakdowns

FeaturesNanoDoc v0.1.0PaddleOCR v3.7.0GLM-OCR v0.1.5MinerU v3.4.4LiteParse v2.5.1
Output Formatmarkdown, jsonmarkdown, jsonmarkdown, jsonmarkdown, jsonmarkdown, json
Scanned Docs
MultilingualCN, EN50 LangsCN, EN & 6 others50 LangsCN, EN
Layout Coordinates
Tables
Cross-Page Table
Formulas
Image Extraction-
Charts--
Handwriting××

Last updated July 29, 2026

Across the selected models, fundamental capabilities are broadly supported. The primary feature distinction among these models lies in language support:

  • Both PaddleOCR and MinerU provide broad multilingual support, while also supporting handwritten text recognition.
  • NanoDoc is purpose-built specifically for high-precision Chinese and English document understanding, and currently does not support handwritten text recognition.

Important Notes & Limitations:

Feature availability for third-party models is derived from their official public disclosures. Our empirical benchmark evaluation was conducted strictly on Chinese and English samples. Performance in other languages was not tested or compared.

Benchmark Dataset

To test parsing quality under realistic and difficult conditions, we built a single-page dataset with 4,231 page samples across 64 document categories, with no more than 100 pages per category.

Domain & Category Coverage:

  • Financial & Securities: annual reports, quarterly filings, audit reports, ESG disclosures, IPO prospectuses, bond prospectuses, credit ratings, industry research, fund reports, and exchange disclosures.
  • Government & Regulatory: official announcements, laws and policies, administrative documents, public forms, business licenses, and executed contracts.
  • Academic & Educational: research papers, academic journals, presentation decks, textbooks, exam papers, and academic posters.
  • Publishing & Media: print newspapers, weekly periodicals, magazines, and screenshots of web articles.
  • Professional Documents: patents, medical documents, account statements, and investment research records.

Overall, the dataset encompasses Chinese, English, and mixed Chinese-English pages, featuring a combination of natural publishing layouts, office document layouts, and high-density tabular layouts.

Ground Truth: The ground truth data on each page include: manually annotated bounding boxes for each content element (paragraph, table, figure, equation etc.), reading order sequences, and structural table representations.

Annotation Format: Final ground-truth data are structured in Markdown/HTML format. Text blocks are linearized in strict reading order, tables retain full structural hierarchy via native HTML <table> tags, and embedded graphics/figures are extracted as standalone PNG references.

Evaluation Metrics

Our evaluation framework measures both extraction quality and hardware performance.

1. Accuracy Metrics

  • Text Edit Distance (Text Edit): character-level normalized edit distance between the parsed text which is NOT inside any table and formula and the ground truth.

  • Table TEDS (Tree Edit Distance Score): Tree Edit Distance (TED) between table parsing prediction and ground truth.

  • Formula CDM (Character Degree Match): Visual character matching rate between rendered images of parsed formulas and ground truths.

  • Overall Quality Score:

    Overall Score=(1Text Edit)+Table TEDS+Formula CDM3\text{Overall Score} = \frac{(1 - \text{Text Edit}) + \text{Table TEDS} + \text{Formula CDM}}{3}

2. Performance & Hardware Metrics

  • FPS (Frames Per Second): total page throughput per second.
  • Peak Memory: maximum RAM usage during execution.
  • Avg Total Power: average total system power during parsing, in watts.
  • Avg CPU Power: average CPU power consumption, in watts.
  • Avg GPU Power: average GPU power consumption, in watts.
  • Avg ANE Power: average Apple Neural Engine power consumption, in watts.
  • Model Storage Footprint: Total disk space required to download and store the local model weights on disk.
  • Model Size on Disk: Total disk space required to store the local model weights on disk.

Experimental Results

Accuracy Metrics

MetricNanoDoc v0.1.0PaddleOCR v3.7.0GLM-OCR v0.1.5MinerU v3.4.4LiteParse v2.5.1
Overall ↑83.661571.6373.3565.7426.98
Table TEDS ↑83.192258.6764.0447.2430.04
Formula CDM ↑82.553482.4886.6484.170
Overall Edit ↓0.17030.26940.34030.350.7156
Text Edit ↓0.147610.26260.30630.34180.491
Table Edit ↓0.13240.32160.46980.49090.6557
Formula Edit ↓0.23090.22390.24490.21731

NanoDoc achieves the highest Overall Quality Score (83.66) and Table TEDS (83.19) across the entire benchmark suite. It delivers balanced, well-rounded performance across text, tables, and complex formulas, maintaining superior accuracy without exhibiting weak spots in any single metric.

Model Size on Disk

Model Size Comparison
Model Size Comparison

Model size varies significantly across different parsers, with GLM-OCR, MinerU, and PaddleOCR occupying a heavy 2.57 GB to 3.71 GB of local storage. By contrast, NanoDoc requires just 534 MB, delivering top-tier parsing accuracy with a remarkably lightweight footprint.

Runtime Metrics

NOTE

Methodology note: mathematical formulas significantly increase parsing complexity and visual recognition workload, so runtime benchmarks are split into two distinct document test suites (over 100 pages each) to isolate this impact.

General PDF

Comprises standard business, government, and publishing documents with no mathematical formulas.

MetricNanoDoc v0.1.0PaddleOCR v3.7.0GLM-OCR v0.1.5MinerU v3.4.4LiteParse v2.5.1
FPS ↑9.250.0560.330.1215.14
Peak Memory ↓1.78 GB11.31 GB14.07 GB14.15 GB2.70 GB
Avg Total Power ↓9.61 W7.16 W8.90 W6.75 W8.13 W
Avg CPU Power ↓7.13 W7.16 W7.95 W1.89 W8.13 W
Avg GPU Power ↓0.20 W-0.95 W4.86 W0.00 W
Avg ANE Power ↓2.27 W----

Formula PDF

Comprises dense academic research papers with complex mathematical formulas.

MetricNanoDoc v0.1.0PaddleOCR v3.7.0GLM-OCR v0.1.5MinerU v3.4.4LiteParse v2.5.1
FPS ↑4.240.0370.510.0636.7
Peak Memory ↓2.98 GB12.19 GB6.55 GB13.79 GB2.61 GB
Avg Total Power ↓10.82 W6.68 W8.51 W5.20 W6.52 W
Avg CPU Power ↓8.72 W6.68 W6.23 W1.75 W6.52 W
Avg GPU Power ↓0.47 W-2.28 W3.45 W-
Avg ANE Power ↓1.64 W----

NanoDoc shows a dramatic speed advantage, reaching 9.25 FPS on General PDFs and 4.24 FPS on Formula PDFs. This throughput lead stems from its architectural optimization for the Apple Neural Engine (ANE). In contrast, alternative models rely heavily on GPU/CPU execution paths, leading to memory bloat and severe throughput bottlenecks.

DocDot: The Ultimate Solution for Document Parsing

Rooted in these empirical benchmark insights, we built DocDot to help non-technical users easily install and run document-parsing models on Apple Silicon laptops tailored to their specific needs, and effortlessly connect them to downstream AI tools.

1. Tailored Model Selection Interface

DocDot provides a simple, intuitive terminal interface that enables non-technical users to choose and install parsing models aligned with what matters most to them—whether that is maximum accuracy, a smaller memory footprint, or higher processing throughput (FPS).

Supported parsers include:

  • NanoDoc (our in-house parser)
  • PaddleOCR
  • GLM-OCR
  • LiteParse
  • MinerU

Getting started with these models is straightforward through simple CLI commands:

  • Install DocDot: curl -fsSL https://docdot.ai | bash
  • Install a provider: docdot install <PROVIDER>
  • Switch your default provider: docdot use <PROVIDER>
  • Parse a document to Markdown: docdot -i <INPUT> -o <OUTPUT> --format markdown

2. High-Volume Parsing & Server Modes

When processing large batches of documents, reloading heavy AI model weights for every individual file wastes time and computational resources. To eliminate this, DocDot can run as a long-running server that other applications, scripts, or your web browser can communicate with directly.

DocDot offers persistent server modes to suit different needs:

  • Local Provider Server (Daemon / Background Mode): Runs directly in the background to handle continuous parsing requests from local scripts or terminal tools. Controlled using simple management commands:

    Start the background server daemon

    docdot serve start
    

    Parse files while the server is running

    docdot -i <INPUT> -o <OUTPUT> --format markdown
    

    Check server health and status

    docdot serve status
    

    Stop the server daemon

    docdot serve stop
    
  • Graphical Web UI Server: Designed for users who prefer a visual workflow over command-line interactions:

    docdot web
    

    Once launched, navigate to http://127.0.0.1:8173 in your web browser. This interface allows you to drag-and-drop documents, preview Markdown/JSON outputs in real time, and compare parsing quality side-by-side across different parsers.

    (To stop the web server when finished, run docdot serve stop or press Ctrl+C in the active terminal window).

3. Agent & Downstream Integration

Install Agent Skill

Upon installation, DocDot automatically scans your system for supported AI agent environments—including Codex, OpenClaw, Claude Code, Hermes and WorkBuddy. Through an interactive terminal prompt, DocDot installs the required skills for your agents.

If you install an agent tool after setting up DocDot, run: docdot skills install. This command configures the integration and replaces your agent's default PDF parser with DocDot.

Model Context Protocol (MCP) Integration

DocDot supports the Model Context Protocol to serve document parsing context directly to compatible agents and applications.

To launch the MCP server: docdot mcp. Refer to your specific agent's documentation to complete the client-side configuration.

For advanced options including custom host addresses, port settings, and transport protocols—run: docdot mcp --help

4. Get Started with DocDot

  • Installation: curl -fsSL https://docdot.ai/install.sh | bash
  • Official Website: http://docdot.ai

For comprehensive configuration options, workflows, and advanced usage, please refer to our User Manual.

Conclusion

By fully unlocking the hardware potential of Apple Silicon through Apple Neural Engine (ANE) acceleration, DocDot (powered by NanoDoc) delivers unmatched local document parsing performance, achieving top-tier extraction accuracy and multi-FPS parsing speeds without cloud latency or privacy risks.

Limitations & Future Roadmap

  • Language & Script: NanoDoc currently specializes strictly in Chinese and English document parsing and does not currently support handwritten text recognition.
  • Roadmap: Handwritten text recognition is actively under development for upcoming releases. Additionally, native support for Windows and Linux operating systems is currently in progress.

DocDot remains committed to maintaining an open, modular ecosystem, and will continuously evaluate, benchmark, and integrate newly released parsing models so users always have access to the best local document-understanding tools.