fix: DocVLMPredictor device use error

[gouzil]

fix

• 在使用 PaddleOCR 时遇到的 PaddleX DocVLMPredictor 显存分配异常情况

复现代码

from paddleocr import PPStructureV3

pipeline = PPStructureV3(device="gpu:1") # device 指定为任意，非默认 device 即可

表现形式

当使用 PPStructureV3(device="cpu"), 同时有 gpu 时，DocVLMPredictor 下的几个模型会被加载到 gpu:0 上，并占用大约 2034MiB 显存

修复方案

• 修改 device 设置策略，优先加载 kwargs 传入，当 device 为 None 时加载 pp_option 中的 device。（paddlex 框架内居然有两种 device 加载选项挺奇怪的）

TODO

• 现有的 paddlex/inference/models/common/vlm/flash_attn_utils.py 下的 is_flash_attn_available 函数也有类似问题，需要换一种形式确认是否支持 flash_attention

[paddle-bot]

Thanks for your contribution!

[gouzil]

@luotao1 能帮忙看看 cla 为啥过不了嘛，还有应该找谁 review

[BluebirdStory]

哈喽，感谢PR。

1. 先来说一下为什么会有两套的device设置：因为目前doc_vlm之下的vlm模型只支持动态图的推理，和PaddleX下其他使用静态图的模型不太一样，所以在设计最初避开了对pp_option的使用，做了隔离，直接通过传入的device来在指定设备上推理。
2. 再来说一下为什么pp structure会有相关问题：因为对于PPStructureV3(device="cpu")这里传入的device参数，PaddleOCR内部会直接封装出pp_option，并不会再单独传入device参数给doc_vlm的predictor，所以这导致在structure产线下，doc_vlm模块收到的device参数永远是None，从而导致在有gpu的情况下，会加载部分模型参数到0号线卡上。
3. 这个PR中，先对device检查，之后再检查pp_option，确实是个解决这个问题的很好的方法，但是依然存在一些问题：
   • self.pp_option.device_type != "cpu"如果设置device为cpu，那self.device依然是None，依然会加载模型到gpu:0上。

方便的话，辛苦更正上述问题重新PR。

[gouzil]

• self.pp_option.device_type != "cpu"如果设置device为cpu，那self.device依然是None，依然会加载模型到gpu:0上。

done，我这没有权限能查看 ci 日志，能帮忙看看 ci 挂了是啥原因嘛

[BluebirdStory]

哈喽，感谢PR。

依然存在一些小问题哈，在你的逻辑里：

                self.device = constr_device(
                    self.pp_option.device_type,
                    (
                        str(self.pp_option.device_id)
                        if self.pp_option.device_type != "cpu"
                        else None
                    ),
                )

如果设置self.pp_option.device_type为gpu，但是self.pp_option.device_id如果为默认参数None，那么会导致str(self.pp_option.device_id)为"None"，进而输入给constr_device导致错误的device_id形式。

方便的话，辛苦更正上述问题重新PR。

感谢您的共享精神，besides，代码的修改所涉及的所有变量，辛苦考虑到每一种可能的情况。

[gouzil]

方便的话，辛苦更正上述问题重新PR。

Done