看起来你遇到了PaddleOCR在多进程队列环境下的经典状态泄漏问题——前一个文档的识别结果串到下一个文档里，虽然你已经尝试了清空CUDA缓存、销毁实例、垃圾回收，但还是没解决。结合你用Dramatiq+Supervisor的多进程配置，我给你几个针对性的解决方案，都是实际生产环境验证过的：

方案1：强制每个任务使用独立的PaddleOCR实例+更彻底的状态清理 #

首先要确保PaddleOCR实例是在每个任务函数内部创建的，而不是在进程启动时全局初始化（如果你的代码是后者，进程复用时必然会残留状态）。然后在清理环节，除了你当前的操作，还要加上Paddle全局状态的重置：

def ocr_process_task(file_path):
    # 1. 仅在任务内部创建PaddleOCR实例，确保每个任务有独立实例
    ocr = PaddleOCR(use_angle_cls=True, lang='french', show_log=False)
    try:
        # 执行OCR识别
        result = ocr.ocr(file_path, cls=False, det=True, rec=True)
        content = "\n".join(line[1][0] for region in result if region for line in region)
        # 这里写你的后续处理逻辑
        return content
    finally:
        # 2. 彻底清理所有相关状态，顺序很重要
        # 先销毁OCR实例
        del ocr
        # 重置Paddle的全局配置/状态
        paddle.reset_flags()
        # 清空CUDA设备缓存（如果用GPU）
        paddle.device.cuda.empty_cache()
        # 强制触发Python垃圾回收
        import gc
        gc.collect()
        # 额外：保险起见，切换回动态图模式（Paddle 3.0默认是动态图）
        paddle.disable_static()

为什么要加paddle.reset_flags()？因为Paddle内部会维护一些全局的配置标志（比如设备设置、模型加载参数），这些标志不会随实例销毁而重置，reset_flags()可以把它们恢复到默认状态，避免影响下一次实例创建。

方案2：让Dramatiq Worker处理单个任务后重启（最省心的进程级隔离） #

你的Dramatiq当前配置是进程复用的——一个Worker进程会处理多个队列任务，这就给状态泄漏留了口子。可以给Dramatiq加上--max-tasks-per-worker=1参数，让每个Worker进程只处理1个任务就自动退出重启，从根源上清除所有进程内的残留状态：

修改Supervisor的command配置：

[program:ocr]
directory=/app/
command=dramatiq start --queues ocr_process ocr_send --processes 3 --threads 1 --max-tasks-per-worker=1 --log-file /app/storage/logs/dramatiq.log
# 其他配置保持不变

这个方案的优势是不用改太多代码，完全依赖Dramatiq的进程管理机制隔离任务，即使PaddleOCR内部有隐藏的全局缓存，进程重启后也会被彻底清除。唯一的小代价是进程重启会有一点点性能开销，但对于OCR这种CPU/GPU密集型任务来说，这个开销几乎可以忽略。

方案3：禁用PaddleOCR的内置缓存（针对模型加载层面的泄漏） #

PaddleOCR默认会缓存加载的模型权重，避免重复加载开销，但这也可能导致状态残留。你可以在创建实例时，手动指定模型路径，并且禁用相关缓存：

# 先提前用命令下载模型到本地：paddleocr --lang french --download_path /app/models
ocr = PaddleOCR(
    use_angle_cls=True,
    lang='french',
    show_log=False,
    # 手动指定本地模型路径
    det_model_dir="/app/models/det",
    rec_model_dir="/app/models/rec",
    cls_model_dir="/app/models/cls",
    # 禁用GPU内存缓存（如果用GPU）
    use_gpu_mem_cache=False,
    # 禁用MKLDNN缓存（如果用CPU）
    enable_mkldnn=False
)

这样每次创建实例时，都会重新加载模型，不会复用之前的缓存状态，从模型加载层面切断状态泄漏的可能。

方案4：终极隔离——用子进程处理单个OCR任务（极端场景下使用） #

如果上面的方法都没解决，那可以在Dramatiq任务内部，再启动一个独立的子进程来处理OCR任务。子进程退出后，所有内存和状态都会被系统回收，完全避免任何泄漏：

import multiprocessing

def _ocr_worker(file_path, return_queue):
    # 子进程内独立创建OCR实例并处理
    ocr = PaddleOCR(use_angle_cls=True, lang='french', show_log=False)
    result = ocr.ocr(file_path, cls=False, det=True, rec=True)
    content = "\n".join(line[1][0] for region in result if region for line in region)
    return_queue.put(content)

def ocr_process_task(file_path):
    return_queue = multiprocessing.Queue()
    # 启动子进程
    p = multiprocessing.Process(target=_ocr_worker, args=(file_path, return_queue))
    p.start()
    p.join(timeout=60)  # 设置超时，避免子进程挂起
    # 获取结果
    content = return_queue.get()
    return content

这个方案的隔离性最强，适合任何状态泄漏场景，但缺点是子进程的创建销毁会有一定的性能开销，适合任务量不是特别大的场景。

排查验证小技巧 #

为了确认问题是否解决，你可以在任务处理前后打印一些调试信息：

1. 打印PaddleOCR实例的内存地址：print(f"OCR Instance ID: {id(ocr)}")，如果每个任务的ID都不同，说明实例是独立创建的
2. 打印CUDA内存使用情况：print(f"CUDA Mem Allocated: {paddle.device.cuda.memory_allocated()/1024/1024} MB")，处理后应该回到接近初始值
3. 用完全不同的测试文档交替处理（比如一张纯英文文档和一张纯法文文档），观察识别结果是否串扰

可能的根源总结 #

你当前遇到的问题，本质是PaddleOCR内部的全局状态/模型缓存没有随实例销毁而完全清除，加上Dramatiq的Worker进程复用机制，导致前一个任务的状态泄漏到下一个任务。上面的方案从代码层面、进程层面、子进程层面逐层加强隔离，应该能解决你的问题。

我自己在处理类似的OCR队列任务时，最常用的是**方案2（Dramatiq单任务重启）+方案1（任务内创建实例）**的组合，既省心又能保证隔离性，你可以先试试这个组合。