Graphiti 摄取时遇到 LLM Provider 429 限流错误怎么调整 SEMAPHORE_LIMIT【免费下载链接】graphitiBuild Real-Time Knowledge Graphs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/grap/graphiti用 Graphiti 构建实时知识图谱时episodeepisode 文本、结构化 JSON 等摄取过程会并发调用 LLM 完成实体抽取、去重、摘要等任务。如果并发过高LLM Provider 会返回429限流错误导致摄取失败。Graphiti 用环境变量SEMAPHORE_LIMIT控制并发上限遇到 429 时应当调低这个值如果你的 Provider 配额更高也可以反向调高它来提升摄取速度。本文基于仓库 README.md 和 mcp_server/README.md 的说明给出定位、调整与验证的完整操作路径。确认 429 来自并发过高而不是其他问题先确认你遇到的确实是 Provider 限流摄取或 MCP server 运行日志中出现429rate limit 错误。Graphiti 的 OpenAI 系客户端见 graphiti_core/llm_client/openai_base_client.py会把 OpenAI 的RateLimitError转成RateLimitError直接抛出不会重试所以 429 一旦触发对应该 episode 的处理就会失败。症状对照来自 mcp_server/README.md值太高429 限流错误且并行处理带来的 API 成本上升值太低episode 吞吐变慢API 配额没有被充分利用。如果你只是觉得 Graphiti 慢、但没有 429不要动这个值先按文档建议把并发调高见下文的调高路径。调整 SEMAPHORE_LIMITSEMAPHORE_LIMIT决定同时处理多少个 episode。注意每个 episode 会触发多次 LLM 调用实际并发 LLM 请求数会达到它的数倍。方式一设置环境变量主路径文档默认值为SEMAPHORE_LIMIT10适合 OpenAI Tier 3、中等档位的 Anthropic 账号。# 遇到 429按你的 Provider 档位把值调低例如 SEMAPHORE_LIMIT2按 Provider 档位选择值的对照表来自 mcp_server/README.mdOpenAI档位请求配额建议 SEMAPHORE_LIMITTier 1免费3 RPM1-2Tier 260 RPM5-8Tier 3500 RPM10-15Tier 45,000 RPM20-50Anthropic档位请求配额建议 SEMAPHORE_LIMIT默认档50 RPM5-8高档1,000 RPM15-30Azure OpenAI文档建议查询 Azure Portal 中的配额后再设置先保守起步、逐步上调。Ollama本地取决于硬件建议SEMAPHORE_LIMIT1-5并监控 CPU/GPU 占用。环境变量可以在进程启动前export也可以写入.env文件——mcp_server/README.md 明确支持在项目目录放.env设置这些变量Docker 部署时则在 compose 目录的.env中写入SEMAPHORE_LIMIT10示例值按档位替换见 mcp_server/docker/README.md。各 Docker Compose 文件均已声明该变量如 mcp_server/docker/docker-compose.yml未设置时回退为10。方式二MCP server 部署时确认配置生效如果你运行的是 MCP server环境变量会直接传入容器例如 mcp_server/docker/docker-compose.yml 中- SEMAPHORE_LIMIT${SEMAPHORE_LIMIT:-10}修改.env中的SEMAPHORE_LIMIT后重启容器即可生效。mcp_server/docker/README.md 的故障排查章节也把「调整SEMAPHORE_LIMIT」列为性能问题的首选手段之一。方式三代码中用 max_coroutines 覆盖库调用场景如果你直接以 Python 库方式使用 Graphiti构造函数提供max_coroutines参数用于覆盖环境变量SEMAPHORE_LIMIT见 graphiti_core/graphiti.pygraphiti Graphiti( uribolt://localhost:7687, userneo4j, passwordyour_password, max_coroutines2, # 仅用于说明遇到 429 时把并发压到 Provider 档位允许的范围内 )并发最终通过 graphiti_core/helpers.py 中的semaphore_gather落实它用一个asyncio.Semaphore给所有并发的摄取操作实体抽取、去重、摘要等限流上限就是max_coroutines or SEMAPHORE_LIMIT。一点需要留意的冲突graphiti_core/helpers.py 中核心库读取环境变量的回退值写作20而 README.md 与 mcp_server/README.md 均称默认值为10。也就是说如果你从未显式设置过SEMAPHORE_LIMIT实际生效值可能是 20 而非文档宣称的 10——遇到 429 时显式设置一个确定值如SEMAPHORE_LIMIT2比依赖默认值更可靠。验证调整是否生效文档给出的监控与判断手段mcp_server/README.md观察日志中是否还有429rate limit 错误——调整后重新摄取之前失败的 episode日志中不再出现 429 即说明并发已压到 Provider 限额之内。监控 server 日志中的 episode 处理耗时如果耗时明显变长但吞吐极低说明值调得过低配额未用满可回调。到 LLM Provider 的控制台核对实际请求速率是否低于配额。跟踪 token 用量与成本避免并发过高带来的额外开销。Docker 部署下还可以用 mcp_server/docker/README.md 给出的命令观察资源占用docker stats graphiti-falkordb docker compose exec graphiti-falkordb redis-cli info memory边界与限制SEMAPHORE_LIMIT只控制 Graphiti 侧的并发上限不能突破 Provider 的真实配额档位对照表是文档给出的建议区间实际配额以你账号为准。429 在 OpenAI 系客户端中不会重试失败的 episode 需要在调整并发后重新摄取。本项目的 OpenAI 兼容/本地 ProviderDeepSeek、Together、OpenRouter、Ollama、vLLM 等通过其 OpenAI-compatible 端点接入README.md 明确建议本地部署时保持SEMAPHORE_LIMIT处于低位。调低或按档位上调SEMAPHORE_LIMIT并确认日志中 429 消失、episode 处理耗时稳定即完成本次排查。若调整后仍然间歇性 429继续对照 Provider 控制台的实际速率与配额进一步降低该值。【免费下载链接】graphitiBuild Real-Time Knowledge Graphs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/grap/graphiti创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Graphiti 摄取时遇到 LLM Provider 429 限流错误怎么调整 SEMAPHORE_LIMIT？
Graphiti 摄取时遇到 LLM Provider 429 限流错误怎么调整 SEMAPHORE_LIMIT【免费下载链接】graphitiBuild Real-Time Knowledge Graphs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/grap/graphiti用 Graphiti 构建实时知识图谱时episodeepisode 文本、结构化 JSON 等摄取过程会并发调用 LLM 完成实体抽取、去重、摘要等任务。如果并发过高LLM Provider 会返回429限流错误导致摄取失败。Graphiti 用环境变量SEMAPHORE_LIMIT控制并发上限遇到 429 时应当调低这个值如果你的 Provider 配额更高也可以反向调高它来提升摄取速度。本文基于仓库 README.md 和 mcp_server/README.md 的说明给出定位、调整与验证的完整操作路径。确认 429 来自并发过高而不是其他问题先确认你遇到的确实是 Provider 限流摄取或 MCP server 运行日志中出现429rate limit 错误。Graphiti 的 OpenAI 系客户端见 graphiti_core/llm_client/openai_base_client.py会把 OpenAI 的RateLimitError转成RateLimitError直接抛出不会重试所以 429 一旦触发对应该 episode 的处理就会失败。症状对照来自 mcp_server/README.md值太高429 限流错误且并行处理带来的 API 成本上升值太低episode 吞吐变慢API 配额没有被充分利用。如果你只是觉得 Graphiti 慢、但没有 429不要动这个值先按文档建议把并发调高见下文的调高路径。调整 SEMAPHORE_LIMITSEMAPHORE_LIMIT决定同时处理多少个 episode。注意每个 episode 会触发多次 LLM 调用实际并发 LLM 请求数会达到它的数倍。方式一设置环境变量主路径文档默认值为SEMAPHORE_LIMIT10适合 OpenAI Tier 3、中等档位的 Anthropic 账号。# 遇到 429按你的 Provider 档位把值调低例如 SEMAPHORE_LIMIT2按 Provider 档位选择值的对照表来自 mcp_server/README.mdOpenAI档位请求配额建议 SEMAPHORE_LIMITTier 1免费3 RPM1-2Tier 260 RPM5-8Tier 3500 RPM10-15Tier 45,000 RPM20-50Anthropic档位请求配额建议 SEMAPHORE_LIMIT默认档50 RPM5-8高档1,000 RPM15-30Azure OpenAI文档建议查询 Azure Portal 中的配额后再设置先保守起步、逐步上调。Ollama本地取决于硬件建议SEMAPHORE_LIMIT1-5并监控 CPU/GPU 占用。环境变量可以在进程启动前export也可以写入.env文件——mcp_server/README.md 明确支持在项目目录放.env设置这些变量Docker 部署时则在 compose 目录的.env中写入SEMAPHORE_LIMIT10示例值按档位替换见 mcp_server/docker/README.md。各 Docker Compose 文件均已声明该变量如 mcp_server/docker/docker-compose.yml未设置时回退为10。方式二MCP server 部署时确认配置生效如果你运行的是 MCP server环境变量会直接传入容器例如 mcp_server/docker/docker-compose.yml 中- SEMAPHORE_LIMIT${SEMAPHORE_LIMIT:-10}修改.env中的SEMAPHORE_LIMIT后重启容器即可生效。mcp_server/docker/README.md 的故障排查章节也把「调整SEMAPHORE_LIMIT」列为性能问题的首选手段之一。方式三代码中用 max_coroutines 覆盖库调用场景如果你直接以 Python 库方式使用 Graphiti构造函数提供max_coroutines参数用于覆盖环境变量SEMAPHORE_LIMIT见 graphiti_core/graphiti.pygraphiti Graphiti( uribolt://localhost:7687, userneo4j, passwordyour_password, max_coroutines2, # 仅用于说明遇到 429 时把并发压到 Provider 档位允许的范围内 )并发最终通过 graphiti_core/helpers.py 中的semaphore_gather落实它用一个asyncio.Semaphore给所有并发的摄取操作实体抽取、去重、摘要等限流上限就是max_coroutines or SEMAPHORE_LIMIT。一点需要留意的冲突graphiti_core/helpers.py 中核心库读取环境变量的回退值写作20而 README.md 与 mcp_server/README.md 均称默认值为10。也就是说如果你从未显式设置过SEMAPHORE_LIMIT实际生效值可能是 20 而非文档宣称的 10——遇到 429 时显式设置一个确定值如SEMAPHORE_LIMIT2比依赖默认值更可靠。验证调整是否生效文档给出的监控与判断手段mcp_server/README.md观察日志中是否还有429rate limit 错误——调整后重新摄取之前失败的 episode日志中不再出现 429 即说明并发已压到 Provider 限额之内。监控 server 日志中的 episode 处理耗时如果耗时明显变长但吞吐极低说明值调得过低配额未用满可回调。到 LLM Provider 的控制台核对实际请求速率是否低于配额。跟踪 token 用量与成本避免并发过高带来的额外开销。Docker 部署下还可以用 mcp_server/docker/README.md 给出的命令观察资源占用docker stats graphiti-falkordb docker compose exec graphiti-falkordb redis-cli info memory边界与限制SEMAPHORE_LIMIT只控制 Graphiti 侧的并发上限不能突破 Provider 的真实配额档位对照表是文档给出的建议区间实际配额以你账号为准。429 在 OpenAI 系客户端中不会重试失败的 episode 需要在调整并发后重新摄取。本项目的 OpenAI 兼容/本地 ProviderDeepSeek、Together、OpenRouter、Ollama、vLLM 等通过其 OpenAI-compatible 端点接入README.md 明确建议本地部署时保持SEMAPHORE_LIMIT处于低位。调低或按档位上调SEMAPHORE_LIMIT并确认日志中 429 消失、episode 处理耗时稳定即完成本次排查。若调整后仍然间歇性 429继续对照 Provider 控制台的实际速率与配额进一步降低该值。【免费下载链接】graphitiBuild Real-Time Knowledge Graphs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/grap/graphiti创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考