[feat] Allows the listing and unloading of models via the Ollama Manage Models admin interface

[TravisArmstrong]

Pull Request Checklist

Note to first-time contributors: Please open a discussion post in Discussions and describe your changes before submitting a pull request.

Discussion was posted here and shared in Discord but did not receive much feedback. Code has been slightly improved since then. GitHub Discussion

Before submitting, make sure you've checked the following:

• [x] Target branch: Please verify that the pull request targets the dev branch. Targets DEV
• [x] Description: Provide a concise description of the changes made in this pull request. Allows the listing and unloading of models via the Ollama Manage Models admin interface
• [x] Changelog: Ensure a changelog entry following the format of Keep a Changelog is added at the bottom of the PR description. First version v.1.0 - Allows the listing and unloading of models via the Ollama Manage Models admin interface
• [x] Documentation: Have you updated relevant documentation Open WebUI Docs, or other documentation sources? Glad to add documentation once merged.
• [x] Dependencies: Are there any new dependencies? Have you updated the dependency versions in the documentation? No new dependencies
• [x] Testing: Have you written and run sufficient tests to validate the changes? Testing performed in DEV environment but no automated test sets created yet
• [x] Code review: Have you performed a self-review of your code, addressing any coding standard issues and ensuring adherence to the project's coding standards? Requested code review in Discord and GitHub Discussions but did not receive any feedback
• [x] Prefix: To clearly categorize this pull request, prefix the pull request title:
  • feat: Introduces a new feature or enhancement to the codebase

Changelog Entry

Description

• [Modifies the admin Ollama settings page to allow the listing and unloading of models. Supports multiple Ollama connections.]

Added

• [Dropdowns to list and unload currently loaded Ollama models]

Changed

• [Added backend Ollama APIs getOllamaModelsLoaded() and unloadModel()]
• [Added frontend Admin Ollama settings dropdown to list current loaded Ollama models and the ability to unload]

Additional Information

• [Similar to other user's model unload tools, but built in natively and supports listing and unloading of multiple models accross multiple Ollama connections.]
• https://openwebui.com/f/pkeffect/ollama_model_unload
• https://openwebui.com/f/userx/unload_models_from_vram

Screenshots or Videos

• [Included in the linked GitHub Discussion]

[TravisArmstrong]

Apologies if I wasn't meant to change the status, I'm new here :)

[pkeffect]

The only opinion I have here is location. I don't think anyone wants to or needs to leave the main chat page to run the unloader. Otherwise I think this is great. It would also replace the poorly written function I am currently using for the same purpose. Low vRAM users need to unite in all options that will reduce our overhead and increase our workflow efficiency. :)

[TravisArmstrong]

The only opinion I have here is location. I don't think anyone wants to or needs to leave the main chat page to run the unloader. Otherwise I think this is great. It would also replace the poorly written function I am currently using for the same purpose. Low vRAM users need to unite in all options that will reduce our overhead and increase our workflow efficiency. :)

I feel both use cases are valid. I like your tool's ability to do the same, quickly, in the context of the current chat. This functionality helps to extend and improve upon that by allowing the same, but across multiple Ollama instances/connections, and with each instance potentially having more than one model loaded.

This is more for admin level control and is helpful for environments where there may be GPU resources constraints, typically seen in DEV / UAT environments.

[VooDisss]

The only opinion I have here is location. I don't think anyone wants to or needs to leave the main chat page to run the unloader. Otherwise I think this is great. It would also replace the poorly written function I am currently using for the same purpose. Low vRAM users need to unite in all options that will reduce our overhead and increase our workflow efficiency. :)

I second this, we need something like this:

[tjbck]

Closing in favour of 1cf21d3fa219edefd1599deb11267b36a0be422a, Thanks everyone!