PaddleOCR-VL 1.6 serving 并发调用同一静态图预测器触发 tensor 持有器损坏（holder_ should not be null / SIGABRT）

[2HENGYUN]

镜像 / 版本 / 硬件（生产与改造实例）

• 基础镜像：ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/paddleocr-vl:latest-nvidia-gpu-offline
• VLM 服务镜像：ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/paddleocr-genai-vllm-server:latest-nvidia-gpu-offline
• 硬件：NVIDIA GeForce RTX 3090（Compute Capability 8.6，驱动 530.30.02，CUDA 12.6 栈）

---

1. 问题背景

• 在关闭config里的串行设置参数后，使用四份本地文件样本（覆盖单页图文图片、证件类图片、多页 PDF 等不同形态）进行并发压测复现。
• 并发 1：成功率 100%，没有问题；并发提升到 2/4 时开始出现 HTTP 500。
• 实测崩溃形态如下，均为多线程并发进入静态图 predictor 的 ZeroCopyTensor 持有区导致的 tensor 内存损坏：
  • 主错误（sh 脚本参数并发 4，pipeline.py:1179 的 cv worker 线程）：PreconditionNotMetError: Tensor holds no memory. Call Tensor::mutable_data firstly. [Hint: holder_ should not be null.]（dense_tensor_impl.cc:43），同族 Tensor not initialized yet when DenseTensor::place()（:62）。
  • 进程级崩溃（并发 2 复现）：free(): invalid pointer + SIGABRT（FatalError: Process abort signal），伴随 vector<bool>::_M_range_check、(NotFound) Var(...) should not be nullptr 等变体。
• 根因怀疑：Paddle 静态图 predictor 的输入/输出 ZeroCopyTensor 持有器非线程安全；use_queues: True 的 input/cv/vlm 多线程流水线与请求级并发叠加时，多个线程同时 attach/copy_from_cpu/predictor.run() 竞争同一持有器。

2. A/B 测试结果

配置	并发	成功/总数	错误数	平均耗时
原始（SERIAL=true，无锁）	1	8/8	0	3.94s
SERIAL=false	4	21/24	3	6.81s
SERIAL=false	2	0/4	2（余为连接中断，SIGABRT）	15.5s
SERIAL=false + predictor 加锁	1	8/8	0	4.42s
同上	2	8/8	0	4.81s
同上	4	8/8	0	5.39s
同上	8	8/8	0	5.54s

一些问题：

• SERIAL=false（无锁）：多请求真正并发，但触发静态图 predictor tensor 持有器竞态 → HTTP 500（并发 4 为 3 个 500，并发 2 出现过 SIGABRT 进程崩溃）。
• SERIAL=false + predictor 加锁：在本次测试中并发成立且无崩溃，并发 1→8 平均延迟几乎不劣化（4.42→5.54s）。这是因为单次测试的文件较小，8份文件产生的chunk依旧能被vllm服务开的并发数吃下，对于解析出的chunk数更大的文件不会有什么加速效果。

3. 我们尝试的方案

改动均在容器内文件：

1. 给 paddle_static/runner.py 的 reshape / copy_from_cpu / run / copy_to_cpu 加进程级锁

   • 文件：/usr/local/lib/python3.10/site-packages/paddlex/inference/models/runners/paddle_static/runner.py
   • 新增模块级 threading.Lock，并用 with 包住 PaddleRunnerChainLegacy.__call__ 里真正碰 GPU tensor holder 的那一段，最小化锁粒度。
   • 这是针对「多线程共享同一静态图 predictor non-thread-safe」的串行化 workaround，与社区「Triton 动态批处理 / 多实例隔离」是不同路线。

   具体修改（diff）如下：

   --- a/paddlex/inference/models/runners/paddle_static/runner.py
   +++ b/paddlex/inference/models/runners/paddle_static/runner.py
   @@ -19,6 +19,7 @@ from typing import Any, Dict, List, Optional, Sequence, Union
    
    import numpy as np
   +import threading
    from pydantic import BaseModel, ConfigDict
    
    from paddlex.inference.models.runners.utils import sort_inputs
   @@ -34,6 +35,14 @@ from paddlex.utils.flags import (
    )
    from paddlex.utils.import_guard import import_paddle, import_paddle_module
    
   +# PATCH(CONCURRENCY): process-wide lock serializing entry to the shared
   +# static-graph predictor. Paddle Inference's input/output ZeroCopyTensor
   +# holders are NOT thread-safe; concurrent run() from multiple serving
   +# threads corrupts holder state -> 'Tensor holds no memory / holder_ should
   +# not be null'. This serializes only the actual run(), so layout-detection
   +# for concurrent documents avoids the tensor holder race.
   +_STATIC_PREDICTOR_LOCK = threading.Lock()
   +
    from ..inference_runner import InferenceRunner
    from .config import (
        DISABLE_TRT_HALF_OPS_CONFIG,
   @@ -259,11 +268,12 @@ class PaddleRunnerChainLegacy:
                self.output_handles.append(output_handle)
    
        def __call__(self, x):
   -        for input_, input_handle in zip(x, self.input_handles):
   -            input_handle.reshape(input_.shape)
   -            input_handle.copy_from_cpu(input_)
   -        self.predictor.run()
   -        outputs = [o.copy_to_cpu() for o in self.output_handles]
   +        with _STATIC_PREDICTOR_LOCK:
   +            for input_, input_handle in zip(x, self.input_handles):
   +                input_handle.reshape(input_.shape)
   +                input_handle.copy_from_cpu(input_)
   +            self.predictor.run()
   +            outputs = [o.copy_to_cpu() for o in self.output_handles]
            return outputs

2. 关闭文档级串行：PADDLE_PDX_SERVING_SERIAL_PIPELINE_CALLS=false，让多请求并发进 predict()，各自 layout → vLLM，交给 vLLM 自身的 continuous batching 排队批处理。

重要说明：以上是我们为应对线上故障而做的 workaround，不确定是否符合社区推荐用法，也没有覆盖到多实例/多进程的社区方案，故提交此 issue 请社区确认。

4. 希望社区确认的问题

1. 目前我们出现的并发方面的问题，是设计上刻意设计成这样的吗，是否进行实际并发时会出现某些预料外的问题，导致没有去做并发
2. 我们目前的实现方案是合理的吗，会不会有什么隐患，能否用于实际生产场景

附录. 服务端崩溃日志（无锁 + SERIAL=false）

1. 主错误：holder_ should not be null（sh 参数并发 4，logs/paddle-holder.log）

RuntimeError: Exception from the 'cv' worker: In user code:
    PreconditionNotMetError: Tensor holds no memory. Call Tensor::mutable_data firstly.
      [Hint: holder_ should not be null.] (at /paddle/paddle/phi/core/dense_tensor_impl.cc:43)

同族变体：Tensor not initialized yet when DenseTensor::place() ... holder_ should not be null（dense_tensor_impl.cc:62）。
触发入口（paddleocr_vl/pipeline.py 的 cv worker 线程）：

paddlex/inference/pipelines/paddleocr_vl/pipeline.py:1179  raise RuntimeError("Exception from the 'cv' worker: ...")

2. 进程级崩溃：SIGABRT（并发 2，logs/paddle-error.log）

free(): invalid pointer
--------------------------------------
C++ Traceback (most recent call last):
--------------------------------------
0   paddle::AnalysisPredictor::ZeroCopyRun(bool)
1   paddle::framework::NaiveExecutor::RunInterpreterCore(...)
2   paddle::framework::InterpreterCore::Run(...)
3   paddle::framework::PirInterpreter::Run(...)
--------------------------------------
FatalError: `Process abort signal` is detected by the operating system.
  [SignalInfo: *** SIGABRT (@0x1) received by PID 1 ... ***]

崩溃前后的业务层 tensor 内存损坏变体：

RuntimeError: Exception from the 'cv' worker: vector<bool>::_M_range_check: __n (1337) >= this->size() (1107)
RuntimeError: Exception from the 'cv' worker: (NotFound) Var(id=...) should not be nullptr.

[dev-jinwoohong]

The serving code does serialize calls by default: the flag defaults to True, and PipelineWrapper queues them through a worker thread. Setting it to false bypasses that queue.

Your lock covers the full shared-handle sequence: reshape, input copy, run, and output copy. Locking only run() would still allow interleaving. However, a module-level lock also serializes otherwise independent PaddleRunnerChainLegacy instances in the same process.

It doesn't protect shared pipeline state outside that function. For the production check, compare request-tagged outputs against the serialized baseline using mixed image dimensions and multi-page PDFs. Successful HTTP responses alone won't catch results accidentally crossing between requests. Your short tests don't establish that the entire pipeline is safe to call concurrently.

For parallel predictor execution, the Paddle Inference example gives each worker its own cloned predictor or PredictorPool entry. Adapting that to PaddleOCR-VL also requires isolating any shared pipeline state. Until that is checked, keeping the default serialization preserves the upstream execution behavior.