An agent that only types is half an agent — often it needs to actually read the text on screen: button labels, prices, error messages, captcha hints. Cloud OCR adds privacy and network dependencies; local OCR is the long-term answer. This post documents a full PaddleOCR run on this machine — environment, tuning, serving — all measured on a CPU-only, 6-core, no-dGPU box.

Env: Windows / Python 3.13 venv / paddleocr 3.7.0 + paddlex 3.7.2 + paddlepaddle 3.2.0 / CPU 6 cores, no dGPU. Tested 2026-09.

Pit #1: paddlepaddle must be pinned to 3.2.0

The system only has Python 3.13 and Paddle needs 3.x wheels, so I built an isolated venv. Installing 3.3.1 crashed on PP-OCRv6: NotImplementedError: ConvertPirAttribute2RuntimeAttribute not support ... (a oneDNN instruction-path bug). Downgrading to 3.2.0 fixed everything. And you must explicitly disable oneDNN at the very top of any script, or some ops still hit that path:

python -m venv C:\paddleocr\venv
C:\paddleocr\venv\Scripts\pip.exe install paddleocr
C:\paddleocr\venv\Scripts\pip.exe install paddlepaddle==3.2.0   # 必须锁 3.2.0

import paddle
paddle.set_flags({'FLAGS_use_onednn': 0})
from paddleocr import PaddleOCR
ocr = PaddleOCR(lang='ch', use_doc_orientation_classify=False,
                use_doc_unwarping=False, use_textline_orientation=False)

Two API changes along the way: 3.x uses ocr.predict(img) (the old ocr.ocr() is deprecated), returning a dict with rec_texts (text), dt_boxes (4-point boxes per line, pixel coords) and rec_scores (confidence). The Windows console is GBK, so special chars in results throw UnicodeEncodeError — sys.stdout.reconfigure(encoding='utf-8') at the top of scripts fixes it.

Real screenshots: 7 images in one sweep

Mixed CN/EN recognition is accurate (京东, M.2固态硬盘, 大模型显卡 AI 算力天梯 all correct). Two patterns:

• Speed is driven by pixel count and text-box count, barely by file size — a 12MB tall screenshot took 19.7s, faster than the 746KB ladder (24.3s)
• Default max_side_limit=4000 auto-shrinks over-long edges, so huge files don't blow up proportionally
• Too-small images drop text: the same image at 0.25× (320×200) yields 2 texts vs 191 at full size

Two linear laws: pixels & text count

Two controlled sweeps that make latency predictable. First, resize one image (constant text density):

Time scales roughly linearly with megapixels (0.06→4.10MP, 1.6s→28.9s) — but too small loses text. Next, fixed 1200×1600 with varying line counts:

Recognition time grows roughly linearly with text-box count; past 50 lines detection starts missing boxes (38 found) — when text is too dense, detection drops boxes. Scaling screenshots up a bit before OCR is a safer bet for agents.

Free 10-15%: disable 3 auxiliary models

Doc orientation, UVDoc unwarping and textline orientation only matter for rotated/scanned documents. On upright screenshots, turning them off costs nothing and even improves recall:

About 10-15% faster, yet more text found (191→202, 129→152 — better recall). The recommended config is in the init snippet above.

Switches that didn't help

• Batch predict predict([img1,img2,...]): CPU is single-stream, no gain (44.2s ≈ separate runs)
• Lower text_det_limit_side_len: only helps giant images; negligible on normal screenshots and may miss tiny text (960 → 45.2s)
• Thread count: 6 cores already saturated; tuning is pointless

Real ways to go faster

• NVIDIA GPU + paddlepaddle-gpu: 5-20× faster. This machine has only an AMD iGPU, which Paddle doesn't support on Windows
• Lighter mobile models: roughly half the time, slight accuracy cost; the 3.x wrapper doesn't expose model-name args, so not adopted

For agents: resident serving (9.9s → 3.0s)

An agent reads screenshots repeatedly; spawning a process and reloading the model (~6.5s) each time is a non-starter. A resident HTTP service keeps the model in memory, paying load time once and inference each call:

# 启动常驻 OCR 服务（模型加载约 2.6s，之后常驻内存）
$env:FLAGS_use_onednn = "0"
C:\paddleocr\venv\Scripts\python.exe C:\mcp-server\engines\ocr_service.py
# 健康检查
Invoke-RestMethod http://127.0.0.1:8200/health

Going further, the service is exposed over MCP to local opencode and LAN machines: ocr_extract_text (extract), ocr_locate_text (locate keywords), ocr_visualize (draw boxes), ocr_smart_region (locate then crop).

Region cropping: up to 5.8× faster

Latency = pixels + text boxes, so cropping to a region cuts both at once. Measured (warm model):

# 方式 A：直接给 region（原图像素坐标）
ocr_extract_text(image_path="x.png", region=[x, y, w, h])

# 方式 B：给关键词，工具自动 locate 并裁出匹配框周围 margin 区域再识别
ocr_smart_region(image_path="x.png", keyword="价格", margin=20)

Typical pattern: locate the rough region on the full image, then crop and re-OCR just that block (prices, brands, buttons) — fast and cheap. Region coords are in original-pixel space; no scaling math needed.

Cross-machine: base64 instead of a shared filesystem

The OCR service reads local file paths only. A LAN client (say a NAS) passing a path gets 'file not found' — base64-encode the image and send it; the server decodes to a temp PNG and recognizes it:

import base64, json, urllib.request

img_b64 = base64.b64encode(open("/vol2/.../some.png", "rb").read()).decode()
req = urllib.request.Request("http://<LAN-IP>:8200/extract",
    data=json.dumps({"image_base64": img_b64}).encode(),
    headers={"Content-Type": "application/json"})
print(json.load(urllib.request.urlopen(req, timeout=60)))

Note: base64 adds ~33% size; watch HTTP body limits for very large (>~15MB) images; the MCP endpoint has no auth — trusted LAN only.

Memory: the cost of residency

Task Manager's default Memory column shows the ~616MB working set; only the 'Commit size' column reveals ~1.8GB. The working set is trimmed under memory pressure but the model stays loaded. Both services are registered with nssm for auto-start.

Summary

• One env pit: pin paddlepaddle 3.2.0 and disable oneDNN at the top of scripts
• Latency is predictable: pixels + text boxes ≈ linear; scaling up before OCR prevents missed text
• Free 10-15%: disable 3 auxiliary models; recall improves too
• Right setup for agents: resident service + region cropping + base64 cross-machine — sub-second per call