mudler / LocalAI

:robot: The free, Open Source OpenAI alternative. Self-hosted, community-driven and local-first. Drop-in replacement for OpenAI running on consumer-grade hardware. No GPU required. Runs gguf, transformers, diffusers and many more models architectures. It allows to generate Text, Audio, Video, Images. Also with voice cloning capabilities.
https://localai.io
MIT License
21.75k stars 1.66k forks source link

Model Gallery Page on Site needs some love #1343

Closed lunamidori5 closed 5 months ago

lunamidori5 commented 7 months ago

I am opening this issue to get some help remaking the Model Gallery page on the site, if you would like to help. Please comment you input here!

dave-gray101 commented 7 months ago

Hey Luna!

While there will probably still be a few changes to the files themselves still (especially for automatic templating with openAI 1.0) - I've been giving some thought to a small interactive component I'd like to put on the eventual docs page:

As a part of my new HuggingFace scraper, I've started generating a super-simple index file. It's literally just an array of the file names for now...

https://github.com/dave-gray101/model-gallery/blob/main/huggingface_index.json

I'd like to put together a quick "programmer art" web ui for the docs page with two inputs:

Originally, I was going to leave this over in the messier automated generation gallery, but if you're going to be cleaning up the docs page on galleries, it might be worth prototyping it over there, and eventually integrating it here.

In general, the automated generation galleries seem to work pretty well at this point, so it's probably worth mentioning that they exist, and the slight difference in how they are used. Essentially, rather than add a single "huggingface" gallery that is very large, the user should add the gallery file specific to the model repository on HF.

The files ending in a long hash dot yaml are not quite "immutable" at this stage of development, but they do correspond to a specific commit id of the got repo on HF. The files ending in dot ref are "gallery links" - they associate the name of the model repo on HF to the latest gallery file. This way, the user could add the ref file, and remain able to install models even if the repo was updated. While this may prove helpful, it turns out TheBloke and many others tend to create whole new repositories rather than update the existing ones... so the dot ref files may end up being more often used as human readable aliases.

There's nothing else to really worry about from the perspective of a user - LocalAI should already support the ref files, and once the gallery is added via environment variable or the endpoint, installation is exactly the same as before - with perhaps the mild note that since a user will perhaps be expected to have more galleries "loaded" at the same time, the "name" property continues to be used to select the right one.

I've got more notes on how to improve the gallery and submit contributions, but I think this comment is long enough and that those would belong on a separate docs page anyway!

Thanks for spearheading the docs pages, Luna!

localai-bot commented 7 months ago

:warning::warning::warning::warning::warning:

Hi! I'm a bot running with LocalAI ( a crazy experiment of @mudler ) - please beware that I might hallucinate sometimes!

_but.... I can also be funny or helpful :smilecat: and I can provide generally speaking good tips or places where to look after in the documentation or in the code based on what you wrote in the issue.

Don't engage in conversation with me, I don't support (yet) replying!

:warning::warning::warning::warning::warning:

Sure, I can definitely help with that! Let's start by breaking down the requirements for the Model Gallery page:

  1. Display a list of available models in the gallery
  2. Provide information on how to install and use each model
  3. Include links to relevant resources and documentation
  4. Make sure the page is visually appealing and easy to navigate Here are some ideas for how we can achieve these requirements:
  5. We can create a table or list of available models, with columns for the model name, description, and version. This will allow users to quickly scan through the available options and find the right model for their use case.
  6. For each model, we can provide a brief overview of how to install and use it, along with any relevant configuration options or dependencies. We can also include links to the model's GitHub repository and documentation.
  7. We can include additional resources such as tutorials, examples, and benchmarks to help users get started with each model.
  8. To make the page visually appealing and easy to navigate, we can use a clean and consistent layout, with clear headings and subheadings to organize the information. We can also use images and icons to break up the text and make the page more engaging. Let me know if you have any other ideas or suggestions for the Model Gallery page!

Sources: