paddlex高稳定服务化部署后性能问题 #5221

Activity

1. duxiao19931008 commented on Oct 22, 2026

   

   duxiao19931008

   on Oct 22, 2026

   More actions

   #4484
   我们遇到的问题和这个应该也是一致的， 实际测试发现server的docker显存利用率没有拉满， pipline的利用率也上不来，我是两张L20, 一个部署server, 一个pipline, 实例数是5， 实例开1和开5竟然提升只有25%， cpu也没有很高， 所以问题就很奇怪， 初步怀疑是调度逻辑有问题， 你可以顺着这个方向查， 我正在努力解决这个问题， 就看官方有什么解决办法了
2. duxiao19931008 commented on Oct 26, 2026

   

   duxiao19931008

   on Oct 26, 2026

   More actions

   1. EOF 通知修复：输入结束时立即唤醒后续阶段(历史 100 请求/c10 前后对照：吞吐 1.554→1.904 页/秒，约 +22.48%):
      原问题**：输入线程结束时只设置结束事件，CV 线程可能仍阻塞在 queue_input.get(timeout=0.5)；短批 VLM 聚合又要等 CV 结束。数据已经没有了，却还可能等待一次轮询超时。

   修改文件：

   /paddlex/py310/lib/python3.10/site-packages/paddlex/inference/pipelines/paddleocr_vl/pipeline.py
   

   核心改法：

   # 示意，完整实现以发布快照为准。
   # 输入结束：不只设置 event，还向队列发送 EOF。
   event_data_loading_done.set()
   while not event_shutdown.is_set():
       try:
           queue_input.put(None, timeout=0.05)
           break
       except queue.Full:
           continue
   
   # CV 消费到 EOF：向下游转发，不再等轮询。
   if item is None:
       event_cv_processing_done.set()
       queue_cv.put(None)
       break

   2. 长块优先：让可能耗时长的块尽早进入 vLLM(吞吐 1.489→1.675 页/秒，约 +12.48%)
      原问题：整页要等所有块返回；一个大表格或长 OCR 块若排到最后提交，会拖住整批。引擎队列等待很小，并不代表客户端侧没有晚提交或批尾等待。

   最终实现文件：

   /app/model_repo/pvl-crossbatch-cv/1/common.py
   

   在 make_front() 中包装 VLM 客户端的 _genai_client_process：

   1. 表格块优先。
   2. 同类按裁剪图像面积从大到小稳定排序。
   3. 调用原客户端。
   4. 按原索引放回结果，保持阅读顺序和块对应关系。

   # 实际优先级：表格标记 + 图像面积，不偷看未来输出 token 数。
   priority = (query == "Table Recognition:", crop_height * crop_width)
   # 完成后：restored[original_index] = value
   
   
   3 同步 BLS 跨批：一份 GPU CV 模型，多个 CPU 协调器
   涉及文件：
   
   ```text
   /app/model_repo/layout-parsing/1/model.py
   /app/model_repo/layout-parsing/config_gpu.pbtxt
   /app/model_repo/pvl-crossbatch-cv/1/model.py
   /app/model_repo/pvl-crossbatch-cv/1/common.py
   /app/model_repo/pvl-crossbatch-cv/config.pbtxt

   实现方式：

   • 前端模型继续复用原 HPS 输入/输出、参数分组、预处理与结果组装逻辑，但 _create_pipeline() 改为创建不持有 CV GPU 模型的协调器。
   • CV 子模型持有一份方向分类/UVDoc/Layout，运行原 Pipeline 的 CV 阶段。
   • 通过 pb.InferenceRequest(...).exec() 同步 BLS 传递图像和中间状态。
   • 保留原预测参数、页路径、页索引、结果类型；内部 token 校验防止响应错配。
   • 使用类型化 JSON + 非 object NPZ，读取 allow_pickle=False；设置 512MiB payload、16MiB metadata 等保护。它们是当前边界，不等于已验证任意超长图/PDF。
   • 不让多个线程并发调用同一份不明线程安全性的 Paddle/ORT predictor。

   4. CPU 协调器 2→3：补足批尾期间的供给

   跨批方案先使用 2 个 CPU 协调器。后续保持 GPU CV count=1、VLM client=32、模型和输入策略不变，只把前端 CPU count 改为 3。

   最终前端配置关键部分：

   backend: "python"
   max_batch_size: 16
   # input/output 定义见完整发布文件，不要只复制此节覆盖整个文件。
   instance_group [ { count: 3 kind: KIND_CPU } ]
   dynamic_batching { }

   为什么保留：ABBA 吞吐 1.849→2.285 页/秒，+23.59%；各轮 P95 均值 6.289→5.257 秒，-16.42%；
   代价：多一个协调进程和图像缓冲，潜在 VLM 在途块从 2×32 增为 3×32；不是零成本增加线程，也不能外推 4 个或更多更好。

   5 Layout HPIP/ORT：保留的后端选择，不冒充所有模型加速(测试L20单卡下未收益， 跳过， 不代表无收益)
   测试配置

   SubModules:
     LayoutDetection:
       use_hpip: True
       hpi_config:
         backend: onnxruntime
         auto_paddle2onnx: False
       model_name: PP-DocLayoutV3
       batch_size: 16
3. jiangshengguo commented on Oct 30, 2026

   

   jiangshengguo

   on Oct 30, 2026

   Author

   More actions

   我暂时没试过 我目前用的是cpu+4NPU 并且关闭了板式校验，目前实测 200+/分，单张卡也就是50 上下 和官方标称的1.25张/s 差不多 这个应该就是极限了