LightRAG 怎么自托管 MinerU 解析服务并开启 vLLM 预加载与标题层级修正【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG如果你的文档里包含 PDF、扫描件或需要版面识别与 OCR 的 office / 图片格式LightRAG 的路由规则需要把这类文件交给mineru引擎。mineru是外部服务LightRAG 通过 HTTP 与它通信不在进程内运行它的模型。当你不想使用 MinerU 的云端 API、而是想在本地机器上自建 MinerU API 服务并希望顺手开启两项进阶能力——vLLM 启动预加载容器启动时就把 VLM 模型加载进显存避免首个解析请求承担模型加载延迟和标题层级修正title_aided借助外部 LLM 修正解析输出的标题层级对依赖标题结构的P段落语义分块尤其有帮助——就按本文操作。前提是宿主机有 Docker、可用的 GPU默认后端hybrid-auto-engine是 pipeline VLM需要 GPU 及配套推理引擎以及一个可供title_aided调用的 LLM API。本文依据仓库中 docs/ParserServiceDeployment-zh.md 的 MinerU 章节与 docs/FileProcessingPipeline-zh.md 的 MinerU 引擎章节。注意这两项进阶能力改的都是MinerU 容器侧配置容器内mineru.json与官方compose.yaml不涉及任何 LightRAG 环境变量。准备并构建 MinerU 服务镜像从 MinerU 官方仓库opendatalab/MinerU的docker目录把Dockerfile和compose.yaml两个文件拷到宿主机本地目录。如果使用的是中国供应商的特殊显卡需要选择对应的Dockerfile。镜像构建细节、GPU 驱动准备、模型权重位置等以 MinerU 官方 README 为准LightRAG 文档不重复这些内容。准备好两个文件后构建镜像docker build --tag mineru:latest .镜像构建完成后可以先把下面的进阶配置做完再首次启动也可以先按基础方式启动、做完进阶改动后再重启一次——up -d命令本身相同docker compose -f compose.yaml --profile api up -d--profile api参数表示仅启动 MinerU 的 API 服务服务默认监听 8000 端口。开启 vLLM 预加载与标题层级修正步骤 1导出并修改mineru-lightrag.json从官方镜像中把/root/mineru.json拷到宿主机当前目录的mineru-lightrag.json。下面的命令会用固定容器名temp_mineru创建一个临时容器、拷出文件后删除该临时容器只删除这个刚创建的临时容器不运行它docker create --name temp_mineru mineru:latest docker cp temp_mineru:/root/mineru.json ./mineru-lightrag.json docker rm temp_mineru然后修改mineru-lightrag.json中的llm-aided-config.title_aided填入api_key并把enable改为truellm-aided-config: { title_aided: { api_key: your_api_key, base_url: https://dashscope.aliyuncs.com/compatible-mode/v1, model: qwen3.5-plus, enable_thinking: false, enable: true } }api_key/base_url/model需要替换为你自己可用的 LLM 服务上例使用的是阿里云 DashScope 的 OpenAI 兼容接口仅作为示例值。步骤 2修改官方compose.yaml中的mineru-api服务在mineru-api服务上做三处改动environment增加MINERU_TOOLS_CONFIG_JSON让 MinerU 读改过的配置而非镜像内置mineru.jsonvolumes把宿主机的mineru-lightrag.json挂进容器command追加--enable-vlm-preload true开启 vLLM 预加载。改好后的完整mineru-apiprofile 如下# -- 新增标注了三处增量其余保持官方原样mineru-api: image: mineru:latest container_name: mineru-api restart: always profiles: [api] ports: - 8000:8000 environment: MINERU_MODEL_SOURCE: local MINERU_TOOLS_CONFIG_JSON: /root/mineru-lightrag.json # -- 新增 volumes: - ./mineru-lightrag.json:/root/mineru-lightrag.json # -- 新增 entrypoint: mineru-api command: --host 0.0.0.0 --port 8000 --allow-public-http-client --gpu-memory-utilization 0.45 # 示例值按实际显卡调整 --enable-vlm-preload true # -- 新增 ulimits: memlock: -1 stack: 67108864 ipc: host healthcheck: test: [CMD-SHELL, curl -f http://localhost:8000/health || exit 1] deploy: resources: reservations: devices: - driver: nvidia device_ids: [0] capabilities: [gpu]示例中--gpu-memory-utilization请按实际显卡情况调整device_ids在多卡机器上可以写成[0, 1]。步骤 3重启生效改完后重新启动 API 服务让改动生效docker compose -f compose.yaml --profile api up -d在 LightRAG 侧接入本地 MinerU服务启动后在 LightRAG 的.env文件中添加local模式配置完整变量清单见仓库根目录 env.example 的 MinerU 配置块MINERU_API_MODElocal MINERU_LOCAL_ENDPOINThttp://your_mineru_local_server_ip:8000your_mineru_local_server_ip替换为本地 MinerU 服务所在机器的 IP服务就在 LightRAG 同机时用http://127.0.0.1:8000这也是该变量的缺省值。然后把目标文件路由到mineru引擎。两种方式LIGHTRAG_PARSERpdf:mineru,docx:native-ietP,*:legacy-R或者用文件名 hint 只覆盖单个文件例如paper.[mineru].pdf。规则按文件后缀从左到右匹配第一条可用规则胜出。这里有一个直接决定成败的检查机制通配符规则命中某后缀时外部引擎要同时通过两道可用性检查——能力表支持该后缀、且对应的 endpoint/token 环境变量已配置。如果MINERU_API_MODElocal但未设置MINERU_LOCAL_ENDPOINT所有 PDF 都会跳过mineru规则落到下一条规则不会报错容易误以为路由生效了。如果希望解析结果支撑P段落语义分块优先按标题分割标题层级修正的价值就在这里体现P分块按标题切分标题层级越准确分块语义越好。注意P只能在解析产物sidecar 目录中的lightrag内容存在时生效否则退化为R分块。验证结果服务侧compose.yaml中已内置健康检查curl -f http://localhost:8000/health容器就绪后该地址返回成功。你也可以在宿主机直接对http://服务IP:8000/health发起请求确认 API 服务在监听。LightRAG 路由侧写错的LIGHTRAG_PARSER在服务启动时就会失败。服务起来后GET /documents/supported_file_types返回服务端实际解析出的后缀白名单与引擎-后缀映射不上传任何文件就能确认pdf:mineru这类规则是否真的生效。端到端解析上传一个 PDF 后按以下顺序看状态GET /documents/track_status/{track_id}看本次上传GET /documents/pipeline_status看实时日志GET /documents/status_counts看整批状态阶梯是PENDING → PARSING → ANALYZING → PROCESSING → PROCESSED。解析产物落在INPUT_DIR/__parsed__/下检查*.blocks.jsonl首行是否为meta记录以及内容行的标题结构是否合理——这正是P的切分依据也是判断title_aided是否改善标题层级的直接位置。在GET /documents/paginated的 doc_status 记录里metadata.parse_engine与metadata.process_options表明实际生效的引擎和选项这是发现 hint 被静默判为无效最快的办法。失败时源文件留在INPUT_DIRdoc_status 记录上的error_msg是诊断入口改完配置可以删除文档后重新上传。限制与注意事项两项进阶能力全部落在 MinerU 容器侧不新增任何 LightRAG 环境变量LightRAG 侧只认MINERU_API_MODE、MINERU_LOCAL_ENDPOINT等已列出的变量。title_aided依赖可用的 LLM APIapi_key/base_url/model不可用时标题层级修正无法工作vLLM 预加载则要求容器能拿到 GPU示例 compose 中通过nvidiadriver 预留device_ids。LightRAG 会本地缓存mineru的解析结果重新上传同一文件通常不会触发重新解析。修改MINERU_LOCAL_ENDPOINT或有效的提取参数会使缓存失效若要在同一端点上强制重解析可在删除文档时勾选「同时删除文件」API 参数delete_filetrue或设置LIGHTRAG_FORCE_REPARSE_MINERUtrue绕过原始缓存。local模式的MINERU_PAGE_RANGES只接受单页或一个简单区间逗号列表会在启动期被拒绝page_range多段写法仅在official模式可用。完成上述验证后本地 MinerU 服务就同时承担了 PDF/扫描件的解析、启动期 VLM 预加载和标题层级修正。后续如果要为docx/md走内置的native引擎、或为公式识别再部署 docling-serve属于独立任务见 docs/FileProcessingPipeline-zh.md 与 docs/ParserServiceDeployment-zh.md 对应章节。【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
LightRAG 怎么自托管 MinerU 解析服务并开启 vLLM 预加载与标题层级修正
LightRAG 怎么自托管 MinerU 解析服务并开启 vLLM 预加载与标题层级修正【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG如果你的文档里包含 PDF、扫描件或需要版面识别与 OCR 的 office / 图片格式LightRAG 的路由规则需要把这类文件交给mineru引擎。mineru是外部服务LightRAG 通过 HTTP 与它通信不在进程内运行它的模型。当你不想使用 MinerU 的云端 API、而是想在本地机器上自建 MinerU API 服务并希望顺手开启两项进阶能力——vLLM 启动预加载容器启动时就把 VLM 模型加载进显存避免首个解析请求承担模型加载延迟和标题层级修正title_aided借助外部 LLM 修正解析输出的标题层级对依赖标题结构的P段落语义分块尤其有帮助——就按本文操作。前提是宿主机有 Docker、可用的 GPU默认后端hybrid-auto-engine是 pipeline VLM需要 GPU 及配套推理引擎以及一个可供title_aided调用的 LLM API。本文依据仓库中 docs/ParserServiceDeployment-zh.md 的 MinerU 章节与 docs/FileProcessingPipeline-zh.md 的 MinerU 引擎章节。注意这两项进阶能力改的都是MinerU 容器侧配置容器内mineru.json与官方compose.yaml不涉及任何 LightRAG 环境变量。准备并构建 MinerU 服务镜像从 MinerU 官方仓库opendatalab/MinerU的docker目录把Dockerfile和compose.yaml两个文件拷到宿主机本地目录。如果使用的是中国供应商的特殊显卡需要选择对应的Dockerfile。镜像构建细节、GPU 驱动准备、模型权重位置等以 MinerU 官方 README 为准LightRAG 文档不重复这些内容。准备好两个文件后构建镜像docker build --tag mineru:latest .镜像构建完成后可以先把下面的进阶配置做完再首次启动也可以先按基础方式启动、做完进阶改动后再重启一次——up -d命令本身相同docker compose -f compose.yaml --profile api up -d--profile api参数表示仅启动 MinerU 的 API 服务服务默认监听 8000 端口。开启 vLLM 预加载与标题层级修正步骤 1导出并修改mineru-lightrag.json从官方镜像中把/root/mineru.json拷到宿主机当前目录的mineru-lightrag.json。下面的命令会用固定容器名temp_mineru创建一个临时容器、拷出文件后删除该临时容器只删除这个刚创建的临时容器不运行它docker create --name temp_mineru mineru:latest docker cp temp_mineru:/root/mineru.json ./mineru-lightrag.json docker rm temp_mineru然后修改mineru-lightrag.json中的llm-aided-config.title_aided填入api_key并把enable改为truellm-aided-config: { title_aided: { api_key: your_api_key, base_url: https://dashscope.aliyuncs.com/compatible-mode/v1, model: qwen3.5-plus, enable_thinking: false, enable: true } }api_key/base_url/model需要替换为你自己可用的 LLM 服务上例使用的是阿里云 DashScope 的 OpenAI 兼容接口仅作为示例值。步骤 2修改官方compose.yaml中的mineru-api服务在mineru-api服务上做三处改动environment增加MINERU_TOOLS_CONFIG_JSON让 MinerU 读改过的配置而非镜像内置mineru.jsonvolumes把宿主机的mineru-lightrag.json挂进容器command追加--enable-vlm-preload true开启 vLLM 预加载。改好后的完整mineru-apiprofile 如下# -- 新增标注了三处增量其余保持官方原样mineru-api: image: mineru:latest container_name: mineru-api restart: always profiles: [api] ports: - 8000:8000 environment: MINERU_MODEL_SOURCE: local MINERU_TOOLS_CONFIG_JSON: /root/mineru-lightrag.json # -- 新增 volumes: - ./mineru-lightrag.json:/root/mineru-lightrag.json # -- 新增 entrypoint: mineru-api command: --host 0.0.0.0 --port 8000 --allow-public-http-client --gpu-memory-utilization 0.45 # 示例值按实际显卡调整 --enable-vlm-preload true # -- 新增 ulimits: memlock: -1 stack: 67108864 ipc: host healthcheck: test: [CMD-SHELL, curl -f http://localhost:8000/health || exit 1] deploy: resources: reservations: devices: - driver: nvidia device_ids: [0] capabilities: [gpu]示例中--gpu-memory-utilization请按实际显卡情况调整device_ids在多卡机器上可以写成[0, 1]。步骤 3重启生效改完后重新启动 API 服务让改动生效docker compose -f compose.yaml --profile api up -d在 LightRAG 侧接入本地 MinerU服务启动后在 LightRAG 的.env文件中添加local模式配置完整变量清单见仓库根目录 env.example 的 MinerU 配置块MINERU_API_MODElocal MINERU_LOCAL_ENDPOINThttp://your_mineru_local_server_ip:8000your_mineru_local_server_ip替换为本地 MinerU 服务所在机器的 IP服务就在 LightRAG 同机时用http://127.0.0.1:8000这也是该变量的缺省值。然后把目标文件路由到mineru引擎。两种方式LIGHTRAG_PARSERpdf:mineru,docx:native-ietP,*:legacy-R或者用文件名 hint 只覆盖单个文件例如paper.[mineru].pdf。规则按文件后缀从左到右匹配第一条可用规则胜出。这里有一个直接决定成败的检查机制通配符规则命中某后缀时外部引擎要同时通过两道可用性检查——能力表支持该后缀、且对应的 endpoint/token 环境变量已配置。如果MINERU_API_MODElocal但未设置MINERU_LOCAL_ENDPOINT所有 PDF 都会跳过mineru规则落到下一条规则不会报错容易误以为路由生效了。如果希望解析结果支撑P段落语义分块优先按标题分割标题层级修正的价值就在这里体现P分块按标题切分标题层级越准确分块语义越好。注意P只能在解析产物sidecar 目录中的lightrag内容存在时生效否则退化为R分块。验证结果服务侧compose.yaml中已内置健康检查curl -f http://localhost:8000/health容器就绪后该地址返回成功。你也可以在宿主机直接对http://服务IP:8000/health发起请求确认 API 服务在监听。LightRAG 路由侧写错的LIGHTRAG_PARSER在服务启动时就会失败。服务起来后GET /documents/supported_file_types返回服务端实际解析出的后缀白名单与引擎-后缀映射不上传任何文件就能确认pdf:mineru这类规则是否真的生效。端到端解析上传一个 PDF 后按以下顺序看状态GET /documents/track_status/{track_id}看本次上传GET /documents/pipeline_status看实时日志GET /documents/status_counts看整批状态阶梯是PENDING → PARSING → ANALYZING → PROCESSING → PROCESSED。解析产物落在INPUT_DIR/__parsed__/下检查*.blocks.jsonl首行是否为meta记录以及内容行的标题结构是否合理——这正是P的切分依据也是判断title_aided是否改善标题层级的直接位置。在GET /documents/paginated的 doc_status 记录里metadata.parse_engine与metadata.process_options表明实际生效的引擎和选项这是发现 hint 被静默判为无效最快的办法。失败时源文件留在INPUT_DIRdoc_status 记录上的error_msg是诊断入口改完配置可以删除文档后重新上传。限制与注意事项两项进阶能力全部落在 MinerU 容器侧不新增任何 LightRAG 环境变量LightRAG 侧只认MINERU_API_MODE、MINERU_LOCAL_ENDPOINT等已列出的变量。title_aided依赖可用的 LLM APIapi_key/base_url/model不可用时标题层级修正无法工作vLLM 预加载则要求容器能拿到 GPU示例 compose 中通过nvidiadriver 预留device_ids。LightRAG 会本地缓存mineru的解析结果重新上传同一文件通常不会触发重新解析。修改MINERU_LOCAL_ENDPOINT或有效的提取参数会使缓存失效若要在同一端点上强制重解析可在删除文档时勾选「同时删除文件」API 参数delete_filetrue或设置LIGHTRAG_FORCE_REPARSE_MINERUtrue绕过原始缓存。local模式的MINERU_PAGE_RANGES只接受单页或一个简单区间逗号列表会在启动期被拒绝page_range多段写法仅在official模式可用。完成上述验证后本地 MinerU 服务就同时承担了 PDF/扫描件的解析、启动期 VLM 预加载和标题层级修正。后续如果要为docx/md走内置的native引擎、或为公式识别再部署 docling-serve属于独立任务见 docs/FileProcessingPipeline-zh.md 与 docs/ParserServiceDeployment-zh.md 对应章节。【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考