LightRAG 实体提取卡在 0% 不走了这份 Ollama 排障指南一次讲透【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG进度条停在 Extracting entities from chunks 已经超过十分钟CPU 占用飙红你以为 LightRAG 进程死了其实它还在硬扛——只是 Ollama 后端在 CPU 上跑大模型的速度慢得让人误以为程序挂了。故障现场还原进度条卡死不是你的错觉 ️如果你正在用 lightrag_ollama_demo.py 往 LightRAG 里灌文档大概率会撞上下面这组症状插入流程走到实体提取阶段后进度条长时间停在 0%没有任何增量任务队列里的 chunk 数量不少但已完成数纹丝不动top/htop里 CPU 占用接近 100%内存也居高不下换个硬件环境CPU 或 GPU表现不一但卡住的体感完全一样它不是崩溃也不是死锁而是**慢到看起来像死了**。这种假死最坑的地方在于前端没有任何报错你唯一能依赖的信号就是那个不动的百分比。排查路径四步从表象走到根源 下面这套顺序可以照抄核心思想是从最外层的表象一路往下钻每一层都只回答一个问题。第一步确认进程真的活着。先看 Python 进程是否还在、状态是否是R运行中而不是D不可中断睡眠。这一步排除进程真死了的可能。活着的进程卡进度说明它在等某个耗时操作返回。第二步判断瓶颈在谁身上。LightRAG 的实体提取本质是把每个 chunk 丢给 LLM让模型吐出实体和关系。所以关键问题是是 LightRAG 自己卡了还是它调用的 Ollama 慢了方法很简单——直接对 Ollama 发一个最小请求比如ollama run 模型 hi如果连你好都要等几十秒瓶颈就不在 LightRAG而在模型推理侧。第三步看后端日志别只看前端。前端进度条只反映完成了多少不反映为什么没完成。打开 Ollama 容器的日志重点找超时、context length、显存/内存不足这类报错。日志里的一句错误信息往往比前端十分钟的空白更有价值。第四步算一笔并发账。LightRAG 默认会并发地对多个 chunk 发起 LLM 请求见 env.example 里的MAX_ASYNC_LLM4和MAX_PARALLEL_INSERT3。如果单请求在 CPU 上要 30 秒4 路并发就是同时压 4 个大模型推理进 Ollama——CPU 环境根本吃不下这个并发队列只会越积越长。走到这一步你手里就有完整因果链了前端不动 ← 实体提取慢 ← LLM 单请求慢 ← 模型在 CPU 上跑 并发放大负载根因拆解三层叠加每层都能单独拖垮你 ⚙️把上面的排查结论按层拆开你会看到三个独立的瓶颈任何一个不达标都会让整体卡 0%硬件层CPU 跑 LLM 本身就是慢车道。实体提取阶段每个 chunk 都要过一次完整的 LLM 推理像 Intel Xeon Gold 这类服务器 CPU 虽然核心多但单核 AI 推理能力有限跑 7B 级别模型一个请求要几十秒很正常。类比一下这相当于用一台拖拉机去拉货车车没坏就是拉不动。服务层Ollama 过载后前端完全无感。Ollama 内部是串行队列请求挤进去后就排队等待前端 LightRAG 只看到请求还没回来于是进度条原地踏步。Ollama 容器日志里的高负载报错才是这个假死的直接证据。配置层并发参数是放大器不是救命稻草。MAX_ASYNC_LLM默认 4 路并发对 GPU 环境是合理值对 CPU 环境则相当于同时派 4 辆车堵在同一条单车道里。很多人遇到问题第一反应是加并发方向恰恰反了。分场景解决方案按你的处境选一条路 ️有 GPU 可用直接搬走一劳永逸把 Ollama 部署到带 NVIDIA 显卡的机器上RTX A6000 级别实测有效演示脚本里通过LLM_BINDING_HOST把host指过去即可LightRAG 侧代码不用动部署细节参考 Docker 部署文档GPU 环境下再恢复默认的MAX_ASYNC_LLM4并观察显存占用必要时给模型显式设置num_ctx演示脚本默认 8192只有 CPU降并发 缩块让它走得动把MAX_ASYNC_LLM从 4 降到 1~2MAX_PARALLEL_INSERT同步降到 1先让单条链路跑通缩小单块体量参考 env.example 中的CHUNK_SIZE默认 1200 token调小单请求耗时随之下降进度条的跳动频率会肉眼可见地变快换更小参数量的模型如 3B/4B 级别并调大TIMEOUT演示脚本默认 300 秒CPU 上大文档建议再放宽给复杂请求留足时间模型选择与配置参考 LLM Provider 选项文档临时应急先保进度再谈优化文档按业务逻辑拆成多个小批次分批插入每批跑完再投下一批避免一次性积压开着top和 Ollama 日志两个窗口盯只要单请求还在陆续返回就别 CtrlC让队列自然消化把MAX_PARALLEL_INSERT临时调到 1把并发风暴降级为串行慢跑进度条至少会动预防清单开工前对照这 5 条就不踩坑 ✅先跑通最小链路插入前先手动发一个单 chunk 请求测 Ollama 延迟单请求超过 30 秒就不要直接灌大文档并发参数按硬件分级CPU 环境MAX_ASYNC_LLM设 1~2GPU 环境再用默认 4参数说明见 env.example前后端各开一个监控窗口前端看进度条后端盯top和 Ollama 日志两边信号对不上时立刻怀疑假死chunk 大小与硬件匹配CPU 环境把CHUNK_SIZE往小调牺牲单块信息量换整体吞吐大文档分批投喂把一次插入拆成多次每批之间有间隔避免 Ollama 队列被一次性打满下次再遇到进度条卡 0%别再对着终端干等——先测单请求、再翻后端日志、最后算并发账这套顺序走完假死还是真卡、该降并发还是该上 GPU自然就有答案了。【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LightRAG 实体提取卡在 0% 不走了？这份 Ollama 排障指南一次讲透
LightRAG 实体提取卡在 0% 不走了这份 Ollama 排障指南一次讲透【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG进度条停在 Extracting entities from chunks 已经超过十分钟CPU 占用飙红你以为 LightRAG 进程死了其实它还在硬扛——只是 Ollama 后端在 CPU 上跑大模型的速度慢得让人误以为程序挂了。故障现场还原进度条卡死不是你的错觉 ️如果你正在用 lightrag_ollama_demo.py 往 LightRAG 里灌文档大概率会撞上下面这组症状插入流程走到实体提取阶段后进度条长时间停在 0%没有任何增量任务队列里的 chunk 数量不少但已完成数纹丝不动top/htop里 CPU 占用接近 100%内存也居高不下换个硬件环境CPU 或 GPU表现不一但卡住的体感完全一样它不是崩溃也不是死锁而是**慢到看起来像死了**。这种假死最坑的地方在于前端没有任何报错你唯一能依赖的信号就是那个不动的百分比。排查路径四步从表象走到根源 下面这套顺序可以照抄核心思想是从最外层的表象一路往下钻每一层都只回答一个问题。第一步确认进程真的活着。先看 Python 进程是否还在、状态是否是R运行中而不是D不可中断睡眠。这一步排除进程真死了的可能。活着的进程卡进度说明它在等某个耗时操作返回。第二步判断瓶颈在谁身上。LightRAG 的实体提取本质是把每个 chunk 丢给 LLM让模型吐出实体和关系。所以关键问题是是 LightRAG 自己卡了还是它调用的 Ollama 慢了方法很简单——直接对 Ollama 发一个最小请求比如ollama run 模型 hi如果连你好都要等几十秒瓶颈就不在 LightRAG而在模型推理侧。第三步看后端日志别只看前端。前端进度条只反映完成了多少不反映为什么没完成。打开 Ollama 容器的日志重点找超时、context length、显存/内存不足这类报错。日志里的一句错误信息往往比前端十分钟的空白更有价值。第四步算一笔并发账。LightRAG 默认会并发地对多个 chunk 发起 LLM 请求见 env.example 里的MAX_ASYNC_LLM4和MAX_PARALLEL_INSERT3。如果单请求在 CPU 上要 30 秒4 路并发就是同时压 4 个大模型推理进 Ollama——CPU 环境根本吃不下这个并发队列只会越积越长。走到这一步你手里就有完整因果链了前端不动 ← 实体提取慢 ← LLM 单请求慢 ← 模型在 CPU 上跑 并发放大负载根因拆解三层叠加每层都能单独拖垮你 ⚙️把上面的排查结论按层拆开你会看到三个独立的瓶颈任何一个不达标都会让整体卡 0%硬件层CPU 跑 LLM 本身就是慢车道。实体提取阶段每个 chunk 都要过一次完整的 LLM 推理像 Intel Xeon Gold 这类服务器 CPU 虽然核心多但单核 AI 推理能力有限跑 7B 级别模型一个请求要几十秒很正常。类比一下这相当于用一台拖拉机去拉货车车没坏就是拉不动。服务层Ollama 过载后前端完全无感。Ollama 内部是串行队列请求挤进去后就排队等待前端 LightRAG 只看到请求还没回来于是进度条原地踏步。Ollama 容器日志里的高负载报错才是这个假死的直接证据。配置层并发参数是放大器不是救命稻草。MAX_ASYNC_LLM默认 4 路并发对 GPU 环境是合理值对 CPU 环境则相当于同时派 4 辆车堵在同一条单车道里。很多人遇到问题第一反应是加并发方向恰恰反了。分场景解决方案按你的处境选一条路 ️有 GPU 可用直接搬走一劳永逸把 Ollama 部署到带 NVIDIA 显卡的机器上RTX A6000 级别实测有效演示脚本里通过LLM_BINDING_HOST把host指过去即可LightRAG 侧代码不用动部署细节参考 Docker 部署文档GPU 环境下再恢复默认的MAX_ASYNC_LLM4并观察显存占用必要时给模型显式设置num_ctx演示脚本默认 8192只有 CPU降并发 缩块让它走得动把MAX_ASYNC_LLM从 4 降到 1~2MAX_PARALLEL_INSERT同步降到 1先让单条链路跑通缩小单块体量参考 env.example 中的CHUNK_SIZE默认 1200 token调小单请求耗时随之下降进度条的跳动频率会肉眼可见地变快换更小参数量的模型如 3B/4B 级别并调大TIMEOUT演示脚本默认 300 秒CPU 上大文档建议再放宽给复杂请求留足时间模型选择与配置参考 LLM Provider 选项文档临时应急先保进度再谈优化文档按业务逻辑拆成多个小批次分批插入每批跑完再投下一批避免一次性积压开着top和 Ollama 日志两个窗口盯只要单请求还在陆续返回就别 CtrlC让队列自然消化把MAX_PARALLEL_INSERT临时调到 1把并发风暴降级为串行慢跑进度条至少会动预防清单开工前对照这 5 条就不踩坑 ✅先跑通最小链路插入前先手动发一个单 chunk 请求测 Ollama 延迟单请求超过 30 秒就不要直接灌大文档并发参数按硬件分级CPU 环境MAX_ASYNC_LLM设 1~2GPU 环境再用默认 4参数说明见 env.example前后端各开一个监控窗口前端看进度条后端盯top和 Ollama 日志两边信号对不上时立刻怀疑假死chunk 大小与硬件匹配CPU 环境把CHUNK_SIZE往小调牺牲单块信息量换整体吞吐大文档分批投喂把一次插入拆成多次每批之间有间隔避免 Ollama 队列被一次性打满下次再遇到进度条卡 0%别再对着终端干等——先测单请求、再翻后端日志、最后算并发账这套顺序走完假死还是真卡、该降并发还是该上 GPU自然就有答案了。【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考