-
Stefy Lanza (nextime / spora ) authored
It shipped at 4, which made it the binding limit for every install. The limiter is meant to be each engine's own `*_instances` -- the pool hands out one instance per page and an engine is not reentrant -- while a RunPod fleet can hold max_pods x scale_up_inflight_per_pod pages in flight: 64 x 16 = 1024 on the Digesta install. A ceiling of 4 capped that at a quarter of ONE pod. Measured on one A40, same page, same install: N surya req/s p50 chandra pg/s p50 1 0.93 1.1s 0.21 4.6s 8 3.79 2.0s 1.31 6.1s 16 7.11 2.2s 1.88 8.4s <- both peak 24 5.89 4.1s 2.09 10.6s 32 5.44 +13 err 3.5s 1.44 +21 err 7.5s 48 ALL FAILED Both peak at 16 and both fail outright by 32 -- a cliff, not a degradation. Default raised 4 -> 64: four pods' worth at the measured knee, far above what a single-box install can feed, so it stops being the limiter while staying finite. NOT higher, because every admitted page holds a rasterised bitmap (~18 MB for A4 at 250 DPI): 64 in flight is ~1.2 GB, 1024 would be ~18 GB of page images before any engine does work. Trading a throughput limit for an OOM is not an upgrade. docs/ocr.md carries the table and spells out the three settings that bound this, which are easy to confuse: the per-model scale-out threshold, the per-engine instance count (the real limiter, and for the SUBPROCESS engines it is what the box can host -- a surya worker is a separate interpreter at ~750 MB), and this ceiling. Also recorded there: surya's req/s is BLOCKS, not pages, since it calls once per layout block; and its worker protocol is synchronous, so a worker handles one page at a time and concurrency is the process count. In served mode that worker only scales an image and makes an HTTP call, so making it concurrent -- or skipping the subprocess entirely, as chandra does -- is what would let surya use a large fleet. Co-Authored-By:Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PxYHWbCAjjjD7A1rhFKtaW
81235f2e