• Stefy Lanza (nextime / spora )'s avatar
    ocr: max_concurrency is a ceiling, and 4 was not one (v0.3.35) · 81235f2e
    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: 's avatarClaude Opus 5 <noreply@anthropic.com>
    Claude-Session: https://claude.ai/code/session_01PxYHWbCAjjjD7A1rhFKtaW
    81235f2e
Name
Last commit
Last update
..
admin Loading commit data...
api Loading commit data...
backends Loading commit data...
broker Loading commit data...
cluster Loading commit data...
compose Loading commit data...
frontproxy Loading commit data...
models Loading commit data...
ocr Loading commit data...
openai Loading commit data...
pydantic Loading commit data...
queue Loading commit data...
tasks Loading commit data...
util Loading commit data...
__init__.py Loading commit data...
cli.py Loading commit data...
config.py Loading commit data...
main.py Loading commit data...
platform_paths.py Loading commit data...
system_app.py Loading commit data...