github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-16 23:21:44 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

issue: System switches to specific model after current conversation ends, interrupting workflow #4282

New Issue
Closed
opened 2025-11-11 15:50:32 -06:00 by GiteaMirror · 3 comments
GiteaMirror commented 2025-11-11 15:50:32 -06:00
Owner
Copy Link

Originally created by @Yoikllong on GitHub (Mar 6, 2025).

Check Existing Issues

  • I have searched the existing issues and discussions.

Installation Method

Pip Install

Open WebUI Version

v0.5.20

Ollama Version (if applicable)

0.5.13

Operating System

Ubuntu 22.04

Browser (if applicable)

No response

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have checked the browser console logs.
  • I have checked the Docker container logs.
  • I have listed steps to reproduce the bug in detail.

Expected Behavior

The system should retain the user-selected model (qwq:latest) for subsequent interactions after completing a conversation or task, unless explicitly changed by the user. Background processes (e.g., resource cleanup) should not terminate active models or force unintended switches to other models like deepseek-r1:32b.

Actual Behavior

While the frontend interface does not explicitly show a model switch, interactions experience significant lag and interruptions due to Ollama's backend repeatedly terminating the active qwq:latest instance and restarting it alongside deepseek-r1:32b. This constant switching forces time-consuming reinitialization of models (e.g., GPU/CPU memory allocation), breaking the conversation flow. Users must wait for each model reload, disrupting real-time continuity and creating delays that worsen with frequent context switches between instances.

Steps to Reproduce

  1. Launch Open-WebUI with Ollama and ensure both models (qwq:latest, deepseek-r1:32b) are installed.

  2. Start a conversation using the qwq:latest model:

    $ ollama ps  # Verify "qwq:latest" is running

  3. Complete the conversation or task (e.g., exit the chat session).

  4. Immediately run $ ollama ps again to observe:

    • qwq:latest shows a "Stopping..." state and terminates.
    • deepseek-r1:32b starts automatically without user input.

Logs & Screenshots

Include logs from Ollama or Docker showing the model termination/switch. Example outputs:

# Before ending the conversation:
$ ollama ps
NAME          ID              SIZE     PROCESSOR    UNTIL
qwq:latest    cc1091b0e2      23 GB    100% GPU     Stopping...

# After termination/switch:
$ ollama ps
NAME               ID              SIZE     PROCESSOR    UNTIL
deepseek-r1:32b    38056bbc8d      23 GB    100% GPU     4 minutes from now

Attach screenshots of the model switch in Open-WebUI's interface (if applicable).

Additional Information

  • Open-WebUI Version: v0.5.20
  • Ollama Version: v0.5.13
  • OS: Ubuntu 22.04
  • Docker Usage?: No

The issue likely arises from Open-WebUI invoking specific models like deepseek-r1:32b during conversation summarization or dialogue tagging functionality, which inadvertently triggers an unintended switch after task completion.

Originally created by @Yoikllong on GitHub (Mar 6, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Installation Method Pip Install ### Open WebUI Version v0.5.20 ### Ollama Version (if applicable) 0.5.13 ### Operating System Ubuntu 22.04 ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have checked the browser console logs. - [x] I have checked the Docker container logs. - [x] I have listed steps to reproduce the bug in detail. ### Expected Behavior The system should retain the user-selected model (`qwq:latest`) for subsequent interactions after completing a conversation or task, unless explicitly changed by the user. Background processes (e.g., resource cleanup) should not terminate active models or force unintended switches to other models like `deepseek-r1:32b`. ### Actual Behavior While the frontend interface does not explicitly show a model switch, interactions experience significant lag and interruptions due to Ollama's backend repeatedly terminating the active `qwq:latest` instance and restarting it alongside `deepseek-r1:32b`. This constant switching forces time-consuming reinitialization of models (e.g., GPU/CPU memory allocation), breaking the conversation flow. Users must wait for each model reload, disrupting real-time continuity and creating delays that worsen with frequent context switches between instances. ### Steps to Reproduce 1. Launch Open-WebUI with Ollama and ensure both models (`qwq:latest`, `deepseek-r1:32b`) are installed. 2. Start a conversation using the `qwq:latest` model: ```bash $ ollama ps # Verify "qwq:latest" is running ``` 3. Complete the conversation or task (e.g., exit the chat session). 4. Immediately run `$ ollama ps` again to observe: - `qwq:latest` shows a "Stopping..." state and terminates. - `deepseek-r1:32b` starts automatically without user input. ### Logs & Screenshots Include logs from Ollama or Docker showing the model termination/switch. Example outputs: ```bash # Before ending the conversation: $ ollama ps NAME ID SIZE PROCESSOR UNTIL qwq:latest cc1091b0e2 23 GB 100% GPU Stopping... # After termination/switch: $ ollama ps NAME ID SIZE PROCESSOR UNTIL deepseek-r1:32b 38056bbc8d 23 GB 100% GPU 4 minutes from now ``` Attach screenshots of the model switch in Open-WebUI's interface (if applicable). ### Additional Information - **Open-WebUI Version**: v0.5.20 - **Ollama Version**: v0.5.13 - **OS**: Ubuntu 22.04 - **Docker Usage?**: No The issue likely arises from Open-WebUI invoking specific models like deepseek-r1:32b during conversation summarization or dialogue tagging functionality, which inadvertently triggers an unintended switch after task completion.
GiteaMirror added the bug label 2025-11-11 15:50:32 -06:00
GiteaMirror commented 2025-11-11 15:50:34 -06:00
Author
Owner
Copy Link

@rgaricano commented on GitHub (Mar 6, 2025):

What is your settings in interface, models for tasks (local & external) , title & tag generation,..., are you tried swithing there?

Are you tried to choose a small model for local tasks and keep it permantly loaded in mem? (with ollama env variables)

For reference:
https://github.com/ollama/ollama/blob/main/docs/faq.md#how-can-i-preload-a-model-into-ollama-to-get-faster-response-times
https://github.com/ollama/ollama/blob/main/docs/faq.md#how-do-i-keep-a-model-loaded-in-memory-or-make-it-unload-immediately

@rgaricano commented on GitHub (Mar 6, 2025): What is your settings in interface, models for tasks (local & external) , title & tag generation,..., are you tried swithing there? Are you tried to choose a small model for local tasks and keep it permantly loaded in mem? (with ollama env variables) For reference: https://github.com/ollama/ollama/blob/main/docs/faq.md#how-can-i-preload-a-model-into-ollama-to-get-faster-response-times https://github.com/ollama/ollama/blob/main/docs/faq.md#how-do-i-keep-a-model-loaded-in-memory-or-make-it-unload-immediately
GiteaMirror commented 2025-11-11 15:50:34 -06:00
Author
Owner
Copy Link

@Yoikllong commented on GitHub (Mar 7, 2025):

What is your settings in interface, models for tasks (local & external) , title & tag generation,..., are you tried swithing there?

Are you tried to choose a small model for local tasks and keep it permantly loaded in mem? (with ollama env variables)

For reference: https://github.com/ollama/ollama/blob/main/docs/faq.md#how-can-i-preload-a-model-into-ollama-to-get-faster-response-times https://github.com/ollama/ollama/blob/main/docs/faq.md#how-do-i-keep-a-model-loaded-in-memory-or-make-it-unload-immediately

Thank you for your response! I appreciate the suggestions, and I wanted to clarify a few points to help narrow down the issue.

I am already familiar with Ollama's configuration options for persisting models (e.g., OLLAMA_KEEPALIVE, environment variables) and have explicitly tested them. For instance:

  • I ran ollama run --keepalive 5h qwq directly to ensure the model remains loaded.
  • Verified that Ollama’s default unload behavior is not the root cause, as the issue persists even with manual persistence.

The problem appears specific to Open WebUI’s interaction with Ollama. After completing a conversation (e.g., closing a chat session), Open WebUI automatically triggers the termination of qwq:latest and initiates deepseek-r1:32b, even though no user action selects the latter model. This is evident from Ollama’s logs showing the abrupt state transitions (attached earlier).

Key Observations

  1. Task Configuration: I confirmed that only qwq:latest is selected in the frontend for conversations. No other models are explicitly assigned to tasks like summarization or tagging.
  2. Logs & Behavior: The switch occurs after task completion, suggesting Open WebUI might be invoking another model (e.g., for post-processing) without user intent.

Would it be possible to investigate whether Open WebUI’s background processes (e.g., title generation, tags generation) inadvertently call deepseek-r1:32b? The issue does not arise when using Ollama standalone or with other interfaces, which isolates the problem to this repository’s integration logic.

Thank you again for your help in troubleshooting! Let me know if additional logs or testing steps would assist.

Additional Context:

  • Steps to reproduce are consistent and clearly documented above.
  • The behavior is reproducible across multiple sessions and Ollama versions (tested with 0.5.12 and 0.5.13).

Looking forward to your insights!

Image
Here is my UI setting. I do have Title and Tag Generation enabled.

@Yoikllong commented on GitHub (Mar 7, 2025): > What is your settings in interface, models for tasks (local & external) , title & tag generation,..., are you tried swithing there? > > Are you tried to choose a small model for local tasks and keep it permantly loaded in mem? (with ollama env variables) > > For reference: https://github.com/ollama/ollama/blob/main/docs/faq.md#how-can-i-preload-a-model-into-ollama-to-get-faster-response-times https://github.com/ollama/ollama/blob/main/docs/faq.md#how-do-i-keep-a-model-loaded-in-memory-or-make-it-unload-immediately Thank you for your response! I appreciate the suggestions, and I wanted to clarify a few points to help narrow down the issue. I am already familiar with Ollama's configuration options for persisting models (e.g., `OLLAMA_KEEPALIVE`, environment variables) and have explicitly tested them. For instance: - I ran `ollama run --keepalive 5h qwq` directly to ensure the model remains loaded. - Verified that Ollama’s default unload behavior is not the root cause, as the issue persists even with manual persistence. The problem appears specific to **Open WebUI**’s interaction with Ollama. After completing a conversation (e.g., closing a chat session), Open WebUI *automatically triggers* the termination of `qwq:latest` and initiates `deepseek-r1:32b`, even though no user action selects the latter model. This is evident from Ollama’s logs showing the abrupt state transitions (attached earlier). ### Key Observations 1. **Task Configuration**: I confirmed that only `qwq:latest` is selected in the frontend for conversations. No other models are explicitly assigned to tasks like summarization or tagging. 2. **Logs & Behavior**: The switch occurs *after* task completion, suggesting Open WebUI might be invoking another model (e.g., for post-processing) without user intent. Would it be possible to investigate whether Open WebUI’s background processes (e.g., title generation, tags generation) inadvertently call `deepseek-r1:32b`? The issue does not arise when using Ollama standalone or with other interfaces, which isolates the problem to this repository’s integration logic. Thank you again for your help in troubleshooting! Let me know if additional logs or testing steps would assist. --- **Additional Context**: - Steps to reproduce are consistent and clearly documented above. - The behavior is reproducible across multiple sessions and Ollama versions (tested with `0.5.12` and `0.5.13`). Looking forward to your insights! ![Image](https://github.com/user-attachments/assets/9669a52a-fc38-49ac-95eb-ec42b39396d7) Here is my UI setting. I do have Title and Tag Generation enabled.
GiteaMirror commented 2025-11-11 15:50:34 -06:00
Author
Owner
Copy Link

@Yoikllong commented on GitHub (Mar 7, 2025):

Image

Oops – turns out this was entirely my fault! 😅
After double-checking my Open WebUI settings, I realized I accidentally set deepseek-r1:32b as the default model for background tasks in the interface configuration. This caused Ollama to trigger it automatically after conversations without any UI indication. Talk about a classic "user error" moment!

Thank you so much for your prompt response – even though it turned out to be a false alarm, your questions helped me catch this oversight.

Apologies again for the confusion and wasting your time on my misconfiguration! Huge thanks to the Open WebUI team for building such awesome tools.

@Yoikllong commented on GitHub (Mar 7, 2025): ![Image](https://github.com/user-attachments/assets/903f1756-7cfb-40a8-889a-3eece7e1cf63) **Oops – turns out this was entirely my fault! 😅** After double-checking my Open WebUI settings, I realized I accidentally set `deepseek-r1:32b` as the default model for **background tasks** in the interface configuration. This caused Ollama to trigger it automatically after conversations without any UI indication. Talk about a classic "user error" moment! Thank you so much for your prompt response – even though it turned out to be a false alarm, your questions helped me catch this oversight. Apologies again for the confusion and wasting your time on my misconfiguration! Huge thanks to the Open WebUI team for building such awesome tools.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#4282
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?