[Bug] Timeout for vLLM plugin #332

New Issue

Closed

opened 2026-02-16 10:19:01 -05:00 by yindo · 4 comments

yindo commented 2026-02-16 10:19:01 -05:00

Owner

Copy Link

Copy Source

Originally created by @sxhysj on GitHub (Jun 1, 2025).

Self Checks

• This is only for bug report, if you would like to ask a question, please head to Discussions.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.4.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

OS:

Max OS 15.5

VLLM startup script:

VLLM_CPU_KVCACHE_SPACE=80 VLLM_USE_MODELSCOPE=true vllm serve deepseek-ai/DeepSeek-R1-0528-Qwen3-8B --enable-reasoning --reasoning-parser deepseek_r1 --max-model-len 32768 --host 192.168.1.12
Dify plugin: vLLM 0.1.5

Problem: Timeout for 300 seconds, no matter how I adjust those parameters in .env file.

[vllm] Error: PluginInvokeError: {"args":{},"error_type":"ConnectionError","message":"HTTPConnectionPool(host='192.168.1.12', port=8000): Read timed out."}

.env file keep as default. The same version of dify works fine on Linux Ubuntu 24.04. Dify to vLLM calls can reach more than 700 seconds without timeout.

✔️ Expected Behavior

Timeout values could be changed in accordance to .env file settings.

❌ Actual Behavior

Always stayed at 300 seconds on Mac OS.

Originally created by @sxhysj on GitHub (Jun 1, 2025). ### Self Checks - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.4.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce OS: ``` Max OS 15.5 ``` VLLM startup script: ``` VLLM_CPU_KVCACHE_SPACE=80 VLLM_USE_MODELSCOPE=true vllm serve deepseek-ai/DeepSeek-R1-0528-Qwen3-8B --enable-reasoning --reasoning-parser deepseek_r1 --max-model-len 32768 --host 192.168.1.12 Dify plugin: vLLM 0.1.5 ``` Problem: Timeout for 300 seconds, no matter how I adjust those parameters in .env file. ``` [vllm] Error: PluginInvokeError: {"args":{},"error_type":"ConnectionError","message":"HTTPConnectionPool(host='192.168.1.12', port=8000): Read timed out."} ``` .env file keep as default. The same version of dify works fine on Linux Ubuntu 24.04. Dify to vLLM calls can reach more than 700 seconds without timeout. ### ✔️ Expected Behavior Timeout values could be changed in accordance to .env file settings. ### ❌ Actual Behavior Always stayed at 300 seconds on Mac OS.

yindo closed this issue 2026-02-16 10:19:01 -05:00

yindo commented 2026-02-16 10:19:02 -05:00

Author

Owner

Copy Link

Copy Source

@dosubot[bot] commented on GitHub (Jun 1, 2025):

Hi @sxhysj! I'm Dosu and I’m helping the dify team.

There are no existing issues or documentation entries directly addressing vLLM plugin timeouts in Dify. However, based on the code and configuration, here are some key points and suggestions:

Timeouts in Dify are controlled by several settings. The GUNICORN_TIMEOUT environment variable (default 200 seconds, recommended 360 seconds) controls the maximum request handling time for the API server, which is important for long-running LLM operations and SSE connections. The TEXT_GENERATION_TIMEOUT_MS setting (default 60000 ms, or 60 seconds) controls the timeout for text generation and workflow processes, but your observed 300-second timeout suggests another layer is involved, possibly at the network or plugin level. See the relevant documentation for these settings here.

The Dify plugin system uses HTTP requests to communicate with the vLLM plugin. The code sets default timeouts for HTTP connections (10s connect, 60s read, 20s write), but if the plugin or network is unresponsive, you may see longer waits or timeouts at the infrastructure level. The error message you shared indicates a read timeout when connecting to the vLLM server at 192.168.1.12:8000, which suggests the vLLM server is either overloaded, slow to respond, or unreachable from the Dify container.

For Docker deployments, ensure you are not using 127.0.0.1 as the plugin host, as this can cause connectivity issues between containers. Always use the host network IP (as you are with 192.168.1.12), but double-check that the vLLM server is accessible from within the Dify container and that no firewall or Docker network misconfiguration is blocking traffic.

If you need to support longer inference times, increase GUNICORN_TIMEOUT and verify that your vLLM server is healthy and responsive. If the vLLM server is slow or hangs, Dify will eventually hit a timeout or connection error, regardless of your .env settings.

If you continue to see timeouts at exactly 300 seconds, check for any reverse proxy (nginx, traefik, etc.) or Docker network settings that may enforce their own timeout limits.

In summary: review and increase GUNICORN_TIMEOUT if needed, ensure network connectivity between Dify and vLLM, avoid 127.0.0.1 for inter-container communication, and check for any external network/proxy timeouts. If the vLLM server itself is slow, you may need to optimize its configuration or hardware.

If you need more specific troubleshooting, please share your .env and Docker network setup.

To reply, just mention my name @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

@dosubot[bot] commented on GitHub (Jun 1, 2025): <!-- Greeting --> Hi @sxhysj! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> There are no existing issues or documentation entries directly addressing vLLM plugin timeouts in Dify. However, based on the code and configuration, here are some key points and suggestions: Timeouts in Dify are controlled by several settings. The GUNICORN_TIMEOUT environment variable (default 200 seconds, recommended 360 seconds) controls the maximum request handling time for the API server, which is important for long-running LLM operations and SSE connections. The TEXT_GENERATION_TIMEOUT_MS setting (default 60000 ms, or 60 seconds) controls the timeout for text generation and workflow processes, but your observed 300-second timeout suggests another layer is involved, possibly at the network or plugin level. See the relevant documentation for these settings [here](https://github.com/crazywoola/dify-docs-mintlify/blob/a76e72c5902f8e7b9f3c7d427dad45b7d63a5db1/en/getting-started/install-self-hosted/environments.mdx). The Dify plugin system uses HTTP requests to communicate with the vLLM plugin. The code sets default timeouts for HTTP connections (10s connect, 60s read, 20s write), but if the plugin or network is unresponsive, you may see longer waits or timeouts at the infrastructure level. The error message you shared indicates a read timeout when connecting to the vLLM server at 192.168.1.12:8000, which suggests the vLLM server is either overloaded, slow to respond, or unreachable from the Dify container. For Docker deployments, ensure you are not using 127.0.0.1 as the plugin host, as this can cause connectivity issues between containers. Always use the host network IP (as you are with 192.168.1.12), but double-check that the vLLM server is accessible from within the Dify container and that no firewall or Docker network misconfiguration is blocking traffic. If you need to support longer inference times, increase GUNICORN_TIMEOUT and verify that your vLLM server is healthy and responsive. If the vLLM server is slow or hangs, Dify will eventually hit a timeout or connection error, regardless of your .env settings. If you continue to see timeouts at exactly 300 seconds, check for any reverse proxy (nginx, traefik, etc.) or Docker network settings that may enforce their own timeout limits. In summary: review and increase GUNICORN_TIMEOUT if needed, ensure network connectivity between Dify and vLLM, avoid 127.0.0.1 for inter-container communication, and check for any external network/proxy timeouts. If the vLLM server itself is slow, you may need to optimize its configuration or hardware. If you need more specific troubleshooting, please share your .env and Docker network setup. <!-- Dosu Comment Footer --> *To reply, just mention my name [@dosu](https://go.dosu.dev/dosubot).* --- ^{How did I do? [Good](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=other)}&nbsp;&nbsp;[](https://go.dosu.dev/discord-bot)&nbsp;[](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/20538)

yindo commented 2026-02-16 10:19:02 -05:00

Author

Owner

Copy Link

Copy Source

@sxhysj commented on GitHub (Jun 1, 2025):

Hi @sxhysj! I'm Dosu and I’m helping the dify team.

There are no existing issues or documentation entries directly addressing vLLM plugin timeouts in Dify. However, based on the code and configuration, here are some key points and suggestions:

Timeouts in Dify are controlled by several settings. The GUNICORN_TIMEOUT environment variable (default 200 seconds, recommended 360 seconds) controls the maximum request handling time for the API server, which is important for long-running LLM operations and SSE connections. The TEXT_GENERATION_TIMEOUT_MS setting (default 60000 ms, or 60 seconds) controls the timeout for text generation and workflow processes, but your observed 300-second timeout suggests another layer is involved, possibly at the network or plugin level. See the relevant documentation for these settings here.

The Dify plugin system uses HTTP requests to communicate with the vLLM plugin. The code sets default timeouts for HTTP connections (10s connect, 60s read, 20s write), but if the plugin or network is unresponsive, you may see longer waits or timeouts at the infrastructure level. The error message you shared indicates a read timeout when connecting to the vLLM server at 192.168.1.12:8000, which suggests the vLLM server is either overloaded, slow to respond, or unreachable from the Dify container.

For Docker deployments, ensure you are not using 127.0.0.1 as the plugin host, as this can cause connectivity issues between containers. Always use the host network IP (as you are with 192.168.1.12), but double-check that the vLLM server is accessible from within the Dify container and that no firewall or Docker network misconfiguration is blocking traffic.

If you need to support longer inference times, increase GUNICORN_TIMEOUT and verify that your vLLM server is healthy and responsive. If the vLLM server is slow or hangs, Dify will eventually hit a timeout or connection error, regardless of your .env settings.

If you continue to see timeouts at exactly 300 seconds, check for any reverse proxy (nginx, traefik, etc.) or Docker network settings that may enforce their own timeout limits.

In summary: review and increase GUNICORN_TIMEOUT if needed, ensure network connectivity between Dify and vLLM, avoid 127.0.0.1 for inter-container communication, and check for any external network/proxy timeouts. If the vLLM server itself is slow, you may need to optimize its configuration or hardware.

If you need more specific troubleshooting, please share your .env and Docker network setup.

To reply, just mention my name @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other   

I tried to use Ollama and succeed but vLLM failed.

@sxhysj commented on GitHub (Jun 1, 2025): > Hi [@sxhysj](https://github.com/sxhysj)! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. > > There are no existing issues or documentation entries directly addressing vLLM plugin timeouts in Dify. However, based on the code and configuration, here are some key points and suggestions: > > Timeouts in Dify are controlled by several settings. The GUNICORN_TIMEOUT environment variable (default 200 seconds, recommended 360 seconds) controls the maximum request handling time for the API server, which is important for long-running LLM operations and SSE connections. The TEXT_GENERATION_TIMEOUT_MS setting (default 60000 ms, or 60 seconds) controls the timeout for text generation and workflow processes, but your observed 300-second timeout suggests another layer is involved, possibly at the network or plugin level. See the relevant documentation for these settings [here](https://github.com/crazywoola/dify-docs-mintlify/blob/a76e72c5902f8e7b9f3c7d427dad45b7d63a5db1/en/getting-started/install-self-hosted/environments.mdx). > > The Dify plugin system uses HTTP requests to communicate with the vLLM plugin. The code sets default timeouts for HTTP connections (10s connect, 60s read, 20s write), but if the plugin or network is unresponsive, you may see longer waits or timeouts at the infrastructure level. The error message you shared indicates a read timeout when connecting to the vLLM server at 192.168.1.12:8000, which suggests the vLLM server is either overloaded, slow to respond, or unreachable from the Dify container. > > For Docker deployments, ensure you are not using 127.0.0.1 as the plugin host, as this can cause connectivity issues between containers. Always use the host network IP (as you are with 192.168.1.12), but double-check that the vLLM server is accessible from within the Dify container and that no firewall or Docker network misconfiguration is blocking traffic. > > If you need to support longer inference times, increase GUNICORN_TIMEOUT and verify that your vLLM server is healthy and responsive. If the vLLM server is slow or hangs, Dify will eventually hit a timeout or connection error, regardless of your .env settings. > > If you continue to see timeouts at exactly 300 seconds, check for any reverse proxy (nginx, traefik, etc.) or Docker network settings that may enforce their own timeout limits. > > In summary: review and increase GUNICORN_TIMEOUT if needed, ensure network connectivity between Dify and vLLM, avoid 127.0.0.1 for inter-container communication, and check for any external network/proxy timeouts. If the vLLM server itself is slow, you may need to optimize its configuration or hardware. > > If you need more specific troubleshooting, please share your .env and Docker network setup. > > _To reply, just mention my name [@dosu](https://go.dosu.dev/dosubot)._ > > How did I do? [Good](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=other)  [](https://go.dosu.dev/discord-bot) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/20538) I tried to use Ollama and succeed but vLLM failed.

yindo commented 2026-02-16 10:19:02 -05:00

Author

Owner

Copy Link

Copy Source

@dosubot[bot] commented on GitHub (Aug 19, 2025):

Hi, @sxhysj. I'm Dosu, and I'm helping the dify-official-plugins team manage their backlog and am marking this issue as stale.

Issue Summary:

• You reported that the vLLM plugin times out after 300 seconds on macOS 15.5 despite adjusting timeout settings in the .env file.
• The same setup works correctly on Ubuntu, indicating a possible environment-specific issue.
• I suggested checking multiple timeout settings like GUNICORN_TIMEOUT, Docker network configurations, avoiding 127.0.0.1 for the plugin host, and verifying no external proxies enforce a 300-second limit.
• You noted that Ollama works fine under the same conditions, but vLLM does not.
• I requested further troubleshooting details regarding your .env and Docker setup but have not yet received them.

Next Steps:

• Please let me know if this issue is still relevant with the latest version of the dify-official-plugins repository by commenting here.
• If I do not hear back within 5 days, I will automatically close this issue.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Aug 19, 2025): Hi, @sxhysj. I'm [Dosu](https://dosu.dev), and I'm helping the dify-official-plugins team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported that the vLLM plugin times out after 300 seconds on macOS 15.5 despite adjusting timeout settings in the .env file. - The same setup works correctly on Ubuntu, indicating a possible environment-specific issue. - I suggested checking multiple timeout settings like GUNICORN_TIMEOUT, Docker network configurations, avoiding 127.0.0.1 for the plugin host, and verifying no external proxies enforce a 300-second limit. - You noted that Ollama works fine under the same conditions, but vLLM does not. - I requested further troubleshooting details regarding your .env and Docker setup but have not yet received them. **Next Steps:** - Please let me know if this issue is still relevant with the latest version of the dify-official-plugins repository by commenting here. - If I do not hear back within 5 days, I will automatically close this issue. Thank you for your understanding and contribution!

yindo commented 2026-02-16 10:19:02 -05:00

Author

Owner

Copy Link

Copy Source

@shihuimin1012 commented on GitHub (Sep 11, 2025):

嗨@sxhysj！我是Dosu，我正在帮助dify团队。
目前还没有现成的问题或文档条目直接解决 Dify 中的 vLLM 插件超时问题。但是，根据代码和配置，以下是一些关键点和建议：
Dify 中的超时由多个设置控制。GUNICORN_TIMEOUT 环境变量（默认 200 秒，建议 360 秒）控制 API 服务器的最大请求处理时间，这对于长时间运行的 LLM 操作和 SSE 连接非常重要。TEXT_GENERATION_TIMEOUT_MS 设置（默认 60000 毫秒，即 60 秒）控制文本生成和工作流进程的超时，但您观察到的 300 秒超时表明涉及另一个层级，可能是在网络或插件级别。请参阅此处 中这些设置的相关文档。
Dify 插件系统使用 HTTP 请求与 vLLM 插件通信。代码设置了 HTTP 连接的默认超时时间（连接 10 秒，读取 60 秒，写入 20 秒），但如果插件或网络无响应，您可能会在基础架构层面看到更长的等待时间或超时。您分享的错误消息表明，连接到 192.168.1.12:8000 的 vLLM 服务器时出现读取超时，这表明 vLLM 服务器过载、响应缓慢或无法从 Dify 容器访问。
对于 Docker 部署，请确保您没有使用 127.0.0.1 作为插件主机，因为这可能会导致容器之间的连接问题。请始终使用主机网络 IP（例如 192.168.1.12），但请仔细检查是否可以从 Dify 容器内部访问 vLLM 服务器，并且没有防火墙或 Docker 网络配置错误阻止流量。
如果您需要支持更长的推理时间，请增加 GUNICORN_TIMEOUT 的值，并验证您的 vLLM 服务器是否健康且响应迅速。如果 vLLM 服务器运行缓慢或挂起，无论您的 .env 设置如何，Dify 最终都会出现超时或连接错误。
如果您继续看到恰好 300 秒的超时，请检查任何反向代理（nginx、traefik 等）或 Docker 网络设置是否强制执行其自己的超时限制。
总结：检查 GUNICORN_TIMEOUT 并根据需要增加，确保 Dify 和 vLLM 之间的网络连接，避免使用 127.0.0.1 进行容器间通信，并检查是否存在任何外部网络/代理超时。如果 vLLM 服务器本身速度较慢，则可能需要优化其配置或硬件。
如果您需要更具体的故障排除，请分享您的.env 和 Docker 网络设置。
要回复，只需提及我的名字@dosu。
我做得怎么样？好|不相关|不正确|冗长|幻觉|举报🐛 |其他   

我尝试使用 Ollama 并成功，但 vLLM 失败了。

同样的问题，5分钟一超过就time out 请问最后如何解决的，我用的mac dify使用OpenAI-API-compatible

@shihuimin1012 commented on GitHub (Sep 11, 2025): > > 嗨[@sxhysj](https://github.com/sxhysj)！我是[Dosu](https://go.dosu.dev/dosubot)，我正在帮助dify团队。 > > 目前还没有现成的问题或文档条目直接解决 Dify 中的 vLLM 插件超时问题。但是，根据代码和配置，以下是一些关键点和建议： > > Dify 中的超时由多个设置控制。GUNICORN_TIMEOUT 环境变量（默认 200 秒，建议 360 秒）控制 API 服务器的最大请求处理时间，这对于长时间运行的 LLM 操作和 SSE 连接非常重要。TEXT_GENERATION_TIMEOUT_MS 设置（默认 60000 毫秒，即 60 秒）控制文本生成和工作流进程的超时，但您观察到的 300 秒超时表明涉及另一个层级，可能是在网络或插件级别。请参阅[此处 中](https://github.com/crazywoola/dify-docs-mintlify/blob/a76e72c5902f8e7b9f3c7d427dad45b7d63a5db1/en/getting-started/install-self-hosted/environments.mdx)这些设置的相关文档。 > > Dify 插件系统使用 HTTP 请求与 vLLM 插件通信。代码设置了 HTTP 连接的默认超时时间（连接 10 秒，读取 60 秒，写入 20 秒），但如果插件或网络无响应，您可能会在基础架构层面看到更长的等待时间或超时。您分享的错误消息表明，连接到 192.168.1.12:8000 的 vLLM 服务器时出现读取超时，这表明 vLLM 服务器过载、响应缓慢或无法从 Dify 容器访问。 > > 对于 Docker 部署，请确保您没有使用 127.0.0.1 作为插件主机，因为这可能会导致容器之间的连接问题。请始终使用主机网络 IP（例如 192.168.1.12），但请仔细检查是否可以从 Dify 容器内部访问 vLLM 服务器，并且没有防火墙或 Docker 网络配置错误阻止流量。 > > 如果您需要支持更长的推理时间，请增加 GUNICORN_TIMEOUT 的值，并验证您的 vLLM 服务器是否健康且响应迅速。如果 vLLM 服务器运行缓慢或挂起，无论您的 .env 设置如何，Dify 最终都会出现超时或连接错误。 > > 如果您继续看到恰好 300 秒的超时，请检查任何反向代理（nginx、traefik 等）或 Docker 网络设置是否强制执行其自己的超时限制。 > > 总结：检查 GUNICORN_TIMEOUT 并根据需要增加，确保 Dify 和 vLLM 之间的网络连接，避免使用 127.0.0.1 进行容器间通信，并检查是否存在任何外部网络/代理超时。如果 vLLM 服务器本身速度较慢，则可能需要优化其配置或硬件。 > > 如果您需要更具体的故障排除，请分享您的.env 和 Docker 网络设置。 > > _要回复，只需提及我的名字[@dosu](https://go.dosu.dev/dosubot)。_ > > 我做得怎么样？[好](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=great_response)|[不相关](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=irrelevant_answer)|[不正确](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=incorrect_sources)|[冗长](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=too_verbose)|[幻觉](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=hallucination)|[举报🐛](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=bug_report) |[其他](https://app.dosu.dev/response-feedback/bdd2edb0-d964-4fa0-ba10-790d45978a5b?feedback_type=other)  [](https://go.dosu.dev/discord-bot) [](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/20538) > > 我尝试使用 Ollama 并成功，但 vLLM 失败了。 同样的问题，5分钟一超过就time out 请问最后如何解决的，我用的mac dify使用OpenAI-API-compatible <img width="1788" height="594" alt="Image" src="https://github.com/user-attachments/assets/63c27cc3-4f99-4b33-95a3-bba426f299b8" /> <img width="1788" height="594" alt="Image" src="https://github.com/user-attachments/assets/ad0e3aed-f71f-46f3-a689-927e7c89e7cd" />

yindo referenced this issue 2026-02-16 10:22:33 -05:00

[PR #332] [MERGED] Sync/volcengine mass #1291

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

feat/3479-gemini-flash-models

dependabot/uv/tools/chart/uv-cdf8d38825

feat/moonshot-kimi-k3-k27-code

feat/gemini-system-instruction-semantics

fix/gemini-text-system-parts

dosu/doc-update-3436

feat/openai-gpt-5-6-support

fix/outlook-trigger-readme-permissions

fix/microsoft-oauth-datasource-tenant

fix/byteplus-api-base-url-label

feat/ark-video-generation-custom-models

fix/openai-stream-reasoning-thinking

fix/skip-live-tests-missing-keys

codex/enhance-discord-integrations

codex/harden-trigger-oauth-permissions

update-lemonade-default-port

codex/fix-pr-review-ci

feat/ark-multimodal-polling

copilot/update-mineru-3x-plugin-file-types

feat/action-security-fix

feat/claude-fable5

codex/fix-ollama-model-category

codex/upgrade-ollama-latest

feat/minimax-m3

codex/refine-plugin-readmes

fix/fireworks-model-label-zh-hans

chore/version-bump-plugins-batch-06

chore/version-bump-plugins-batch-05

chore/version-bump-plugins-batch-04

chore/version-bump-plugins-batch-03

chore/version-bump-plugins-batch-02

fix/plugin-sdk-i18n-fields

chore/version-bump-plugins-batch-01

chore/dependencies-high-priority

chore/dependencies-medium-priority

chore/dependencies-low-priority-clean

chore/dependencies-low-priority

fix/tongyi-align-deepseek-model-metadata

codex/update-openrouter-models

codex/azure-ai-studio-cjk-version-bump

feat/ernie-image-tool

claude/cranky-thompson-b6a281

fix/remove-unavailable-volcengine-models

fix/legacy-plugin-daemon-compatibility

copilot/add-deepseek-v4-to-openrouter

codex/merge-tongyi-tts-prs

codex/depot-runners

chore/migrate-selected-plugins-to-uv-lock

fix/repair-failed-plugin-deploys

ci/fix-plugin-change-detection

chore/migrate-aws-s3-storage-to-uv-lock

chore/migrate-somark-dependencies-to-uv-lock

ci/uv-lock-dependency-validation

fix/2911-openai-api-compatible-tool-call-content

chore/remove-deprecated-plugins

copilot/add-more-models-openrouter-provider

copilot/fix-error-connecting-fireworks-ai

fix/openai-compatible-max-completion-tokens-validation

fix/gemini-lockfile

chore/add-React-fallback-desc

feat/add-gemini-embedding-2-preview

copilot/add-claude-sonnet-opus-4-6

codex/update-xai-models-2721

fix/remove-sentence-transformer-for-hubspot

feat/add-gpt-5.4

copilot/fix-ci-errors-and-bump-version

copilot/fix-security-errors-combined

copilot/update-gemini-model-version

fix/anthropic-parallel-tool-call

codex/fix-azure-ai-studio-azure-core-1-38

codex/fix-azure-blob-azure-core-1-38

codex/fix-azure-openai-azure-core-1-38

gitlab-credentials-c

fix/openrouter-validation-model

fix/gemini-null-checks

fix/deepseek-tool-message-ignore

fix/gemini-dependencies

No results found.

Labels

Clear labels

bug

bug

bug

dependencies

documentation

enhancement

good first issue

invalid

pull-request

Mirrored from GitHub Pull Request

question

stale

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

yindo

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: langgenius/dify-official-plugins#332