Surya 2 用 vllm 后端时如何通过 --max-num-seqs 和 --max-num-batched-tokens 提升吞吐量【免费下载链接】suryaOCR, layout analysis, reading order, table recognition in 90 languages项目地址: https://gitcode.com/GitHub_Trending/su/surya在 NVIDIA GPU 上用 Surya 2 批量跑 OCR、版面分析或表格识别时吞吐量由推理后端决定layout / OCR / table_rec 共享同一个 VLM而 vllm 服务端能同时处理多少页上限就卡在--max-num-seqs最大并发请求数和--max-num-batched-tokens单批最大 token 数这两个服务端参数上。README 的 Performance tips 明确建议用 vllm 时raise--max-num-seqs/--max-num-batched-tokens或客户端侧的SURYA_INFERENCE_PARALLELto keep more pages in flight。这篇文章给出两条提升路径——自管 vllm 服务器直接写参数以及理解自动拉起服务器的默认值怎么算——并说明如何核对生效值与结果。前提是 NVIDIA GPU以及 Docker 加 NVIDIA Container Toolkitvllm 后端的前置要求。两个参数与客户端并发如何配合调参前需要先分清两侧的职责服务端--max-num-seqs/--max-num-batched-tokens决定 vllm 服务器并发处理请求的上限是吞吐的主杠杆客户端Surya 发往后端的并发请求数由SURYA_INFERENCE_PARALLEL控制。不设置时vllm 后端取min(服务端 max_num_seqs, 96)见 vllm 后端 中的MAX_AUTO_PARALLEL 96与_client_parallel()。为什么客户端并发要封顶在 96源码注释记录了在 B200max_num_seqs240上测 layout 吞吐的结果——并发从 48 提到 96 提升 28%从 96 提到 240 只提升 5%因为超过约 96 个并发后 GPU 已进入 compute-bound多出来的请求只是在排队。结论是只堆客户端并发不会带来线性收益服务端两个参数才是主路径两侧要配套着看。准备条件NVIDIA GPUvllm 后端需要 Docker 和 NVIDIA Container ToolkitREADME Inference backend prerequisites。安装pip install surya-ocr精度注意VLLM_DTYPE默认bfloat16需要 Ampere 及以上compute capability 8.0的显卡在 T4 / Turing 等旧卡上 vllm 会拒绝以 bf16 启动需把VLLM_DTYPE设为float16settings.py 中的注释说明。路径 A自管 vllm 服务器显式指定两个参数仓库自动拉起服务器时使用的命令在 vllm.py 中拼装。照着这条命令自己起服务器就能把两个参数写成想要提升的值docker run --rm -d --name surya-vllm-self \ --runtime nvidia --gpus device0 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:v0.20.1 \ --model datalab-to/surya-ocr-2 \ --no-enforce-eager \ --max-num-seqs 按显存自行提高的值 \ --dtype bfloat16 \ --max-model-len 18000 \ --max-num-batched-tokens 按显存自行提高的值 \ --gpu-memory-utilization 0.85 \ --enable-prefix-caching \ --mm-processor-kwargs {min_pixels: 3136, max_pixels: 6291456} \ --speculative-config {method: mtp, num_speculative_tokens: 2} \ --served-model-name datalab-to/surya-ocr-2几个必须注意的点除两个待调参数外其余取值都是 settings.py 里的默认值VLLM_DOCKER_IMAGE、SURYA_MODEL_CHECKPOINT、VLLM_MAX_MODEL_LEN、VLLM_GPU_MEMORY_UTILIZATION、VLLM_MTP_TOKENS等两个...占位符由你根据所用 GPU 的显存给出文档没有给出每 GB 显存对应多少的公式只能自行调整并观察服务器是否能正常加载--served-model-name必须保持datalab-to/surya-ocr-2Surya attach 时会探测服务器报告的模型名不一致会抛SpawnErrorModel mismatch见 spawn.py--speculative-config是 MTP 配置VLLM_ENABLE_MTP默认开启不用 MTP 可以删掉这一行如果 8000 端口被占用换其他端口并同步修改下面 attach 的 URL。然后按 README Inference Backends 一节把 Surya 指向这个已运行的服务器export SURYA_INFERENCE_BACKENDvllm export SURYA_INFERENCE_URLhttp://127.0.0.1:8000/v1 # 可选显式指定客户端并发不设置时自动取 min(服务端 max_num_seqs, 96) # export SURYA_INFERENCE_PARALLEL96 surya_ocr DATA_PATHDATA_PATH可以是图片、PDF 或图片/PDF 文件夹。attach 前 Surya 会先探测/health不可达会直接报 not reachable at /health。路径 B自动拉起服务器时默认值是怎么算出来的不自己管服务器时Surya 首次使用会自动docker run一个容器名字surya-vllm-port两个参数没有独立的 settings 键而是由VLLM_GPU_TYPE按公式推算vllm.py 中的_gpu_settings基线24 GB 显存--max-num-batched-tokens 8192、--max-num-seqs 32实际值 基线 ×该卡 VRAM / 24batched-tokens 向下取 2 的幂最小 1024max-num-seqs 向下取 8 的倍数最小 8VRAM 表覆盖b300(270)、b200(180)、h200(141)、h100(80)、a100(80/40)、l40s(48)、a10(24)、l4(24)、5090(32)、4090(24)、3090(24)、t4(16)VLLM_GPU_TYPE默认4090。跑在 5090 上却仍设 4090 的话拿到的就是 8192/32 这组偏小的基线值按代码公式VLLM_GPU_TYPE5090会得到 8192 / 40此为按仓库公式的计算值。所以自动路径下提升的做法是先把VLLM_GPU_TYPE设成真实卡型如需再叠加其他 vllm 启动参数VLLM_EXTRA_ARGS会被逐词追加到 docker 命令末尾。若VLLM_GPU_TYPE不在表内会直接抛SpawnError并列出可用卡型。如何验证生效值自管路径下参数就是你自己写的自动拉起路径下命令输出中 INFO 级别的Spawning:日志行会打印完整的 docker run 命令从中核对实际的--max-num-seqs/--max-num-batched-tokens。功能验证命令完成后打印Wrote results to ...输出目录默认results/surya/文件名/下生成results.json其中blocks含label、html、polygon、confidence等字段可抽样检查识别内容是否完整。吞吐对比改动前后用同一批数据各跑一次比较处理速度。README Throughput 一节给出的官方基准文档示例不是必须复现的数值RTX 509032 GBvllm/vllm-openai:v0.20.196 DPI 全页 OCR平均每页约 2,400 输出 token客户端并发 128 时 5.35 页/s、12,884 tokens/sp50 18,915 ms、p95 42,538 ms。对比测试时建议加--keep_server默认每条命令退出即拆掉服务器连跑多条命令会反复支付启动和 GPU 上的模型加载成本干扰速度对比用完按 README 停止docker stop对应的surya-vllm-*容器或自管容器用docker stop surya-vllm-self。限制与相关项客户端并发的收益有拐点B200 实测从 96 提到 240 仅 5%服务端参数不够时单纯调大SURYA_INFERENCE_PARALLEL意义有限。MTP 也影响延迟/吞吐可在 settings 中调整VLLM_ENABLE_MTP、VLLM_MTP_TOKENS。DPI 对吞吐影响显著OCR 路径默认用 192 DPI 高清输入README 建议尝试从 192 降到 96SURYA_INFERENCE_PARALLEL无关通过环境变量SURYA_IMAGE_DPI_HIGHRES覆盖在精度与速度之间自行取舍。一处文档不一致需要留意README 的设置表把SURYA_INFERENCE_PARALLEL默认值标为 8而当前 settings.py 中默认是未设置None未设置时由 vllm 后端自动选min(服务端 max_num_seqs, 96)。两处描述不一致以代码行为为准。本卡型不在 VRAM 表内、或 attach 的服务器模型名不匹配时启动会直接失败并给出明确报错Unknown VLLM_GPU_TYPE .../Model mismatch ...按提示修正VLLM_GPU_TYPE或服务器上的--served-model-name即可。【免费下载链接】suryaOCR, layout analysis, reading order, table recognition in 90 languages项目地址: https://gitcode.com/GitHub_Trending/su/surya创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考