• 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
..
superpowers Loading commit data...
README.md Loading commit data...
admin-forward-auth.md Loading commit data...
cluster.md Loading commit data...
deepseek-ds4.md Loading commit data...
dtype-auto-selection.md Loading commit data...
expressive-tts.md Loading commit data...
frontend-engine-split.md Loading commit data...
gguf-process-isolation.md Loading commit data...
glm-colibri.md Loading commit data...
install-from-packages.md Loading commit data...
kimi-k3.md Loading commit data...
ktransformers.md Loading commit data...
longcat-video.md Loading commit data...
minimax-h3.md Loading commit data...
modelli-digesta-e-container.md Loading commit data...
ocr.md Loading commit data...
orchestrator-runpod-guide.md Loading commit data...
piano-inferenza-su-coderai-prod.md Loading commit data...
process-isolation-plans.md Loading commit data...
reference-projects.md Loading commit data...
remote-execution.md Loading commit data...
reverse-proxy-nginx.md Loading commit data...
runpod.md Loading commit data...
tools-as-services.md Loading commit data...
video-compose.md Loading commit data...
vllm.md Loading commit data...
zimage-lora-training.md Loading commit data...