Here are the bugs I encountered and the situations where I intentionally triggered the bugs to reproduce them:
I deployed a 72b model on a 64Gb macmini, which, along with system memory usage, occupied approximately 58-60gb of storage space. This is not due to insufficient storage. The known bug relates to the model retention mechanism. It's uncertain whether this is caused by the size of my model.
The current situation is: If, coincidentally, during the time when the model is about to be unloaded or after the countdown for the model has ended, my input request still hasn't received a text response, then the webui will attempt to unload the model. However, ollama refuses to unload a model that's waiting to be exported. Consequently, ollama's backend gets stuck in the "stopping" interface.
and here's when the bug happens.
At this point, any further requests sent through the webUI become ineffective, and ollama remains unresponsive. The only solution is to forcefully close ollama and restart it.
I tested this on both versions 0.5.7 and 0.5.10 of the webui, and the bug persists in both cases.
Originally created by @ILoveWhatILoss on GitHub (Feb 9, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/9698
Here are the bugs I encountered and the situations where I intentionally triggered the bugs to reproduce them:
I deployed a 72b model on a 64Gb macmini, which, along with system memory usage, occupied approximately 58-60gb of storage space. This is not due to insufficient storage. The known bug relates to the model retention mechanism. It's uncertain whether this is caused by the size of my model.
The current situation is: **If, coincidentally, during the time when the model is about to be unloaded or after the countdown for the model has ended, my input request still hasn't received a text response, then the webui will attempt to unload the model.**
**However, ollama refuses to unload a model that's waiting to be exported. Consequently, ollama's backend gets stuck in the "stopping" interface.**
and here's when the bug happens.
At this point, any further requests sent through the webUI become ineffective, and ollama remains unresponsive. The only solution is to forcefully close ollama and restart it.
I tested this on both versions 0.5.7 and 0.5.10 of the webui, and the bug persists in both cases.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @ILoveWhatILoss on GitHub (Feb 9, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/9698
Here are the bugs I encountered and the situations where I intentionally triggered the bugs to reproduce them:
I deployed a 72b model on a 64Gb macmini, which, along with system memory usage, occupied approximately 58-60gb of storage space. This is not due to insufficient storage. The known bug relates to the model retention mechanism. It's uncertain whether this is caused by the size of my model.
The current situation is: If, coincidentally, during the time when the model is about to be unloaded or after the countdown for the model has ended, my input request still hasn't received a text response, then the webui will attempt to unload the model.
However, ollama refuses to unload a model that's waiting to be exported. Consequently, ollama's backend gets stuck in the "stopping" interface.
and here's when the bug happens.
At this point, any further requests sent through the webUI become ineffective, and ollama remains unresponsive. The only solution is to forcefully close ollama and restart it.
I tested this on both versions 0.5.7 and 0.5.10 of the webui, and the bug persists in both cases.