opendatalab
能否不处理图片，只让他处理文本内容的解析呢？
Is your feature request related to a problem? Please describe. 您的特性请求是否与某个问题相关？请描述。 A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] 对存在的问题进行清晰且简洁的描述。例如：我一直很困扰的是 [...]
Describe the solution you'd like 描述您期望的解决方案 A clear and concise description of what you want to happen. 清晰且简洁地描述您希望实现的内容。
Describe alternatives you've considered 描述您已考虑的替代方案 A clear and concise description of any alternative solutions or features you've considered. 清晰且简洁地描述您已经考虑过的任何替代解决方案。
Additional context 提供更多细节 Add any other context or screenshots about the feature request here. 请附上任何相关截图、链接或文件，以帮助我们更好地理解您的请求。
可以修改demo中的参数 https://github.com/opendatalab/MinerU/blob/37925f36d9f35d213c8217710e9ab12ace801a8b/demo/demo.py#L34 将这一行改成
md_content = pipe.pipe_mk_markdown(image_dir, drop_mode="none", md_make_mode="nlp_markdown")
来实现nlp格式markdown的输出
```python md_content = pipe.pipe_mk_markdown(image_dir, drop_mode="none", md_make_mode="nlp_markdown")
感谢感谢！！我在magic_pdf_parse_main.py这里面测试，感觉要改动的代码很多，没怎么敢动，上来问问，果然有惊喜~ 不过，大佬，不解析图片和表格，貌似只快了一两秒哇，正常吗？
```python md_content = pipe.pipe_mk_markdown(image_dir, drop_mode="none", md_make_mode="nlp_markdown")感谢感谢！！我在magic_pdf_parse_main.py这里面测试，感觉要改动的代码很多，没怎么敢动，上来问问，果然有惊喜~ 不过，大佬，不解析图片和表格，貌似只快了一两秒哇，正常吗？
不是不解析，只是在最后输出的时候不输出，解析都是要解析的
```python md_content = pipe.pipe_mk_markdown(image_dir, drop_mode="none", md_make_mode="nlp_markdown")感谢感谢！！我在magic_pdf_parse_main.py这里面测试，感觉要改动的代码很多，没怎么敢动，上来问问，果然有惊喜~ 不过，大佬，不解析图片和表格，貌似只快了一两秒哇，正常吗？
不是不解析，只是在最后输出的时候不输出，解析都是要解析的
能否不解析呢，比如说将下面的部分代码注释掉？或者说，能不能并行读取多页的pdf呢，感觉很难，但没办法...boss要求...
@1148330040 你截图的都是后处理pipeline，这个在总时长中占比极小，每页时间平均不到0.1秒，改这个没有意义。 时间消耗的大头在模型解析那块。
并行处理是个可行方案，模型的输入全部都是单张图片，所以只要初始化多个模型并将实例指定在不同的显卡上，是可以通过并行处理的方式提升计算速度的。
大佬小姐姐，能不能指教一下？没办法多卡使用spaw分布处理，只能尝试用Process多进程，但是貌似不支持多进程，还是说我的代码有问题，处理思路有问题。
@1148330040 多进程会爆显存，现在只推荐一张卡一个进程。
嘿，我又来了，开始时显存占用为3000Mib，但是随着后续的使用，逐步上升是怎么回事？已经通过torch进行了显存释放（ torch.cuda.empty_cache()）
我在代码里看到了，有
start_page_id=0,
end_page_id=None,这两个参数，为什么不考虑把他们放出来作为入参使用呢？我在
UNIPipe
TXTPipe
OCRPipe
里面都添加了这两个参数，并且一步步定位到 def pdf_parse_union（）这里面了，貌似...这两个参数还是解析后才用到的，只是用来输出end_page_id页的内容，一顿debug后，解析代码的入口，应该是下面这里对吗？：
如果是的话，是不是意味着我传入pdf的时候，对pdf进行裁剪，就能实现解析并输出指定页数的pdf内容呢？
@1148330040 多进程会爆显存，现在只推荐一张卡一个进程。
嘿，我又来了，开始时显存占用为3000Mib，但是随着后续的使用，逐步上升是怎么回事？已经通过torch进行了显存释放（ torch.cuda.empty_cache()） 我在代码里看到了，有 start_page_id=0, end_page_id=None,这两个参数，为什么不考虑把他们放出来作为入参使用呢？我在 UNIPipe TXTPipe OCRPipe 里面都添加了这两个参数，并且一步步定位到 def pdf_parse_union（）这里面了，貌似...这两个参数还是解析后才用到的，只是用来输出end_page_id页的内容，一顿debug后，解析代码的入口，应该是下面这里对吗？：
如果是的话，是不是意味着我传入pdf的时候，对pdf进行裁剪，就能实现解析并输出指定页数的pdf内容呢？
显存上升是因为遇到比较大的页面或者比较长的公式，自然会占用更多的显存。 start和endpage这个参数设计的时候有考虑到只解析范围内的pdf，但是后面实现的时候没有完全实现该功能，目前只是作为冗余参数存在。
@1148330040 多进程会爆显存，现在只推荐一张卡一个进程。
嘿，我又来了，开始时显存占用为3000Mib，但是随着后续的使用，逐步上升是怎么回事？已经通过torch进行了显存释放（ torch.cuda.empty_cache()） 我在代码里看到了，有 start_page_id=0, end_page_id=None,这两个参数，为什么不考虑把他们放出来作为入参使用呢？我在 UNIPipe TXTPipe OCRPipe 里面都添加了这两个参数，并且一步步定位到 def pdf_parse_union（）这里面了，貌似...这两个参数还是解析后才用到的，只是用来输出end_page_id页的内容，一顿debug后，解析代码的入口，应该是下面这里对吗？：
显存上升是因为遇到比较大的页面或者比较长的公式，自然会占用更多的显存。 start和endpage这个参数设计的时候有考虑到只解析范围内的pdf，但是后面实现的时候没有完全实现该功能，目前只是作为冗余参数存在。
无法释放显存吗？已经释放显存了，还是在占用
pdf是逐页处理的，你释放的是上一页的显存，下一页又进来了还要占用对应的显存的
啊？我的意思是一个流程全部跑完了，生成结果了，然后在使用torch.cuda.empty_cache()，针对同一个pdf，多次运行显存不会上升，但是，有新的pdf（更多的页数）进来了，就会导致显存上升无法释放，这很奇怪呀大佬，如果是这样的话，怎么部署成接口呢？运行着运行着不就 爆显存啦
运行PDF-A，运行结束之后，显存占用为3000mib，结束，在此给传同一个pdf多次，运行结束之后，依旧是3000mib； 现在运行PDF-B，运行结束之后，显存变为了6000mib，结束，无法释放显存了，而且，在此运行PDF-A显存依旧是6000mib占用 我是这个意思
pdf是逐页处理的，你释放的是上一页的显存，下一页又进来了还要占用对应的显存的
啊？我的意思是一个流程全部跑完了，生成结果了，然后在使用torch.cuda.empty_cache()，针对同一个pdf，多次运行显存不会上升，但是，有新的pdf（更多的页数）进来了，就会导致显存上升无法释放，这很奇怪呀大佬，如果是这样的话，怎么部署成接口呢？运行着运行着不就 爆显存啦
部署接口不需要考虑显存释放的问题吧，目前测试来看，在同一批次解析大量pdf时，占用显存的上限和运行单个最吃显存的pdf一致，也就是你的显存只要能运行单个最吃显存的那个，其他的pdf都不会占用更多的额外显存。
pdf是逐页处理的，你释放的是上一页的显存，下一页又进来了还要占用对应的显存的
啊？我的意思是一个流程全部跑完了，生成结果了，然后在使用torch.cuda.empty_cache()，针对同一个pdf，多次运行显存不会上升，但是，有新的pdf（更多的页数）进来了，就会导致显存上升无法释放，这很奇怪呀大佬，如果是这样的话，怎么部署成接口呢？运行着运行着不就 爆显存啦
部署接口不需要考虑显存释放的问题吧，目前测试来看，在同一批次解析大量pdf时，占用显存的上限和运行单个最吃显存的pdf一致，也就是你的显存只要能运行单个最吃显存的那个，其他的pdf都不会占用更多的额外显存。
好吧...果然是这样，虽然很奇怪，但也好解决，辛苦大佬~下班了，拜拜~
因为推理底层是torch和paddle框架，显存的占用与释放应该属于推理框架应该处理的逻辑？本身应用应该不需要太关注这些逻辑。
呦，大佬，俺又来了，咱们这个模型是不是不支持并发？不支持异步？不支持多进程啊？（这三个我也不太区分的清楚），模型一次只接受一个进程运行不能并发访问，除非开两个接口，两套模型才可以呀？
我尝试一下看看可不可以把CustomPEKModel这是哪个加载的模型提出来，放到外面运行，然后作为参数传入到UNIPipe TXTPipe OCRPipe这三个里面，实现并发
因为推理底层是torch和paddle框架，显存的占用与释放应该属于推理框架应该处理的逻辑？本身应用应该不需要太关注这些逻辑。
呦，大佬，俺又来了，咱们这个模型是不是不支持并发？不支持异步？不支持多进程啊？（这三个我也不太区分的清楚），模型一次只接受一个进程运行不能并发访问，除非开两个接口，两套模型才可以呀？
我尝试一下看看可不可以把CustomPEKModel这是哪个加载的模型提出来，放到外面运行，然后作为参数传入到UNIPipe TXTPipe OCRPipe这三个里面，实现并发
测试好了，没问题，相较于原本的并发，需要开多组模型，现在，把模型提前拿出来作为变量传入，传入到多个路由里面（曲线救国，实现并发），就只需要开启一组模型就好
因为推理底层是torch和paddle框架，显存的占用与释放应该属于推理框架应该处理的逻辑？本身应用应该不需要太关注这些逻辑。
呦，大佬，俺又来了，咱们这个模型是不是不支持并发？不支持异步？不支持多进程啊？（这三个我也不太区分的清楚），模型一次只接受一个进程运行不能并发访问，除非开两个接口，两套模型才可以呀？ 我尝试一下看看可不可以把CustomPEKModel这是哪个加载的模型提出来，放到外面运行，然后作为参数传入到UNIPipe TXTPipe OCRPipe这三个里面，实现并发
测试好了，没问题，相较于原本的并发，需要开多组模型，现在，把模型提前拿出来作为变量传入，传入到多个路由里面（曲线救国，实现并发），就只需要开启一组模型就好
而且我还发现，这样子做，结束之后显存是直接释放掉的，不会像之前那样保留最大pdf占用显存的量
因为推理底层是torch和paddle框架，显存的占用与释放应该属于推理框架应该处理的逻辑？本身应用应该不需要太关注这些逻辑。
呦，大佬，俺又来了，咱们这个模型是不是不支持并发？不支持异步？不支持多进程啊？（这三个我也不太区分的清楚），模型一次只接受一个进程运行不能并发访问，除非开两个接口，两套模型才可以呀？ 我尝试一下看看可不可以把CustomPEKModel这是哪个加载的模型提出来，放到外面运行，然后作为参数传入到UNIPipe TXTPipe OCRPipe这三个里面，实现并发
测试好了，没问题，相较于原本的并发，需要开多组模型，现在，把模型提前拿出来作为变量传入，传入到多个路由里面（曲线救国，实现并发），就只需要开启一组模型就好
而且我还发现，这样子做，结束之后显存是直接释放掉的，不会像之前那样保留最大pdf占用显存的量
听起来不错，可以提个pr吗？
因为推理底层是torch和paddle框架，显存的占用与释放应该属于推理框架应该处理的逻辑？本身应用应该不需要太关注这些逻辑。
呦，大佬，俺又来了，咱们这个模型是不是不支持并发？不支持异步？不支持多进程啊？（这三个我也不太区分的清楚），模型一次只接受一个进程运行不能并发访问，除非开两个接口，两套模型才可以呀？ 我尝试一下看看可不可以把CustomPEKModel这是哪个加载的模型提出来，放到外面运行，然后作为参数传入到UNIPipe TXTPipe OCRPipe这三个里面，实现并发
测试好了，没问题，相较于原本的并发，需要开多组模型，现在，把模型提前拿出来作为变量传入，传入到多个路由里面（曲线救国，实现并发），就只需要开启一组模型就好
而且我还发现，这样子做，结束之后显存是直接释放掉的，不会像之前那样保留最大pdf占用显存的量
听起来不错，可以提个pr吗？
嗨呀没那个必要，很简单的，就是移动几块代码就行了，大佬要是需要的话，我截两张图肯定就能看懂啦，不过有个问题，这样做的话，ocr和文字版本的需要区分开来，也就是初始化两组模型，一组ocr处理，一组txt处理，对接口来说比较友善（测试代码大概流程就是这样，当然，可能需要一些逻辑补充进去用来判断）：
