ocr: the three blockers to native Surya on rented pods
Reported from the Digesta host, where coderai runs GPU-less and proxies to
A40 pods.
1. surya-ocr's vLLM client probes {service_url}/health and reads anything
else as "backend down", so /v1/ocr never became ready against a coderai
front that only served /healthz. /health and /v1/health now alias it,
and /v1/health is exempt from the Bearer check — a readiness probe that
needs a token is not a readiness probe.
2. A rented pod ran the shared-workstation admission defaults (2 in
flight, 6 queued), so its own gate capped an A40 at ~6 pages/s and
everything above 16 concurrent got 429 while the GPU idled. The pod has
no config file, so the knobs now arrive as env
(CODERAI_SERVER_MAX_PARALLEL_REQUESTS / _QUEUE_MAX_SIZE) and are set
per model from the model page (pod_max_parallel_requests /
pod_queue_max_size), seeded when the pod is provisioned.
3. The image baked no surya venv, and could not have: ocr.txt put
surya-ocr in the MAIN venv, where its pillow<11 cap fights
coderai's pillow>=12. It now has its own ocr.venv-surya profile with a
deep check that proves the pin held. The venv belongs on the
orchestrator, not the card: with surya_serve=vllm the model runs in
vLLM on the pod and this side only renders and post-processes.
Also a bug that fix exposed: _resolve_venv_dir looked only at
/opt/coderai/<name>_venv while the image builder bakes
/opt/coderai/venvs/<alias>, so a baked venv was invisible and got rebuilt
on the cache mount at first use. ocr-paddle has been shipping a 2 GB
paddleocr venv nothing ever found.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Showing
Please
register
or
sign in
to comment