issue: /api/models endpoint slow & very heavy with larger instances #6840

New Issue

GiteaMirror · 2025-11-11T17:07:08-06:00

GiteaMirror commented

2025-11-11 17:07:08 -06:00

Originally created by @taylorwilsdon on GitHub (Nov 5, 2025).

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

v0.6.34

Ollama Version (if applicable)

No response

Operating System

Ubuntu

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 included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

Loading the base route ({yourowuihost.com/}) should load quickly and the necessary metadata for the models picker should just be ID, display name, link etc

Actual Behavior

An enormous payload (in my case, 4.3mb) is returned that includes the entire system prompt for all 350+ models, base64 encoded images for every single one etc.

Interestingly, we have gotten reports from users who aren't admins and can't see all models that their load times are even slower even though the payload is smaller. Potentially due to filtering before it responds?

Steps to Reproduce

Load your OWUI instance with 300 models configured

Logs & Screenshots

Additional Information

No response

Originally created by @taylorwilsdon on GitHub (Nov 5, 2025). ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version v0.6.34 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu ### 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 included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior Loading the base route ({yourowuihost.com/}) should load quickly and the necessary metadata for the models picker should just be ID, display name, link etc ### Actual Behavior An enormous payload (in my case, 4.3mb) is returned that includes the entire system prompt for all 350+ models, base64 encoded images for every single one etc. Interestingly, we have gotten reports from users who aren't admins and can't see all models that their load times are even slower even though the payload is smaller. Potentially due to filtering before it responds? ### Steps to Reproduce Load your OWUI instance with 300 models configured ### Logs & Screenshots <img width="2836" height="1710" alt="Image" src="https://github.com/user-attachments/assets/4759a99b-2770-499e-b5b5-a696e0a054fc" /> ### Additional Information _No response_

GiteaMirror added the bug label 2025-11-11 17:07:08 -06:00

GiteaMirror commented

2025-11-11 17:07:11 -06:00

@silentoplayz commented on GitHub (Nov 6, 2025):

Related - https://github.com/open-webui/open-webui/issues/17266

@silentoplayz commented on GitHub (Nov 6, 2025): Related - https://github.com/open-webui/open-webui/issues/17266

GiteaMirror commented

2025-11-11 17:07:11 -06:00

@tjbck commented on GitHub (Nov 10, 2025):

I believe we can just drop profile_image_urls and that should reduce the size of the response significantly

@tjbck commented on GitHub (Nov 10, 2025): I believe we can just drop profile_image_urls and that should reduce the size of the response significantly

GiteaMirror commented

2025-11-11 17:07:11 -06:00

@adam-skalicky commented on GitHub (Nov 11, 2025):

I believe the issue is the lack of optimization of the get_filtered_models function in utils/models.py which is invoked as part of /api/models for non-admin users when bypass is not enabled.
https://github.com/open-webui/open-webui/blob/main/backend/open_webui/utils/models.py#L352C5-L352C24

It is invoking has_access for every model without providing the group_id list causing a DB hit to get a group list for the user for each model.

If you examine the get_models_by_user_id function in models/models.py it preloads the user group IDs prior to looping through the models.
https://github.com/open-webui/open-webui/blob/main/backend/open_webui/models/models.py#L206

Testing the runtime out locally with stubbed responses, I see a ~4.7s response time in our environment with 400+ models with a simulated 10ms delay on the group fetch, but preloading the group IDs brings this to ~0.2s.

I think /api/models should either move to using the get_models_by_user_id function or get_filtered_models should be updated to preload the group IDs.

@adam-skalicky commented on GitHub (Nov 11, 2025): I believe the issue is the lack of optimization of the `get_filtered_models` function in `utils/models.py` which is invoked as part of /api/models for non-admin users when bypass is not enabled. https://github.com/open-webui/open-webui/blob/main/backend/open_webui/utils/models.py#L352C5-L352C24 It is invoking `has_access` for every model without providing the `group_id` list causing a DB hit to get a group list for the user for each model. If you examine the `get_models_by_user_id` function in `models/models.py` it preloads the user group IDs prior to looping through the models. https://github.com/open-webui/open-webui/blob/main/backend/open_webui/models/models.py#L206 Testing the runtime out locally with stubbed responses, I see a ~4.7s response time in our environment with 400+ models with a simulated 10ms delay on the group fetch, but preloading the group IDs brings this to ~0.2s. I think /`api/models` should either move to using the `get_models_by_user_id` function or `get_filtered_models` should be updated to preload the group IDs.

GiteaMirror commented

2025-11-11 17:07:11 -06:00

@adam-skalicky commented on GitHub (Nov 11, 2025):

I see get_filtered_models has additional logic that get_models_by_user_id would not have without a bit of refactoring. I will create a PR to suggest the group pre-seed for has_access like get_models_by_user_id

@adam-skalicky commented on GitHub (Nov 11, 2025): I see `get_filtered_models` has additional logic that `get_models_by_user_id` would not have without a bit of refactoring. I will create a PR to suggest the group pre-seed for has_access like `get_models_by_user_id`

GiteaMirror commented

2025-11-11 17:07:11 -06:00

@adam-skalicky commented on GitHub (Nov 11, 2025):

See https://github.com/open-webui/open-webui/pull/19097 for the improvement

@adam-skalicky commented on GitHub (Nov 11, 2025): See https://github.com/open-webui/open-webui/pull/19097 for the improvement