I have a model I want to host on huggingface and we train it on various resolutions. I’ve seen others host each resolution on a different repo. This seems very inefficient to me compared to having each resolution on a different branch within the same repo. The only problem I can’t find a workaround for though is that the model card appears to only represent the tip of the main branch. I want to be able to point users to the model card (README.md) within each branch without them having to clone and render it locally. Sure, they can read the text of the README.md, but having the same model card showing even when swapping between branches in the “files and versions” tab, seems like it will confuse plenty of people if they are looking for a version not on the main branch.
I guess my only idea for a workaround is to have every resolution on a different branch and just have the README.md on the main branch point this out and maybe even point to this topic
Anyone else consider this before? Wondering what other options exist before spending the time uploading all the versions we already have locally.
Most HF file formats and libraries are designed for one model per repo. Even a small LoRA file, for example, would occupy one repo, and the behavior of multiple models in one repo is unpredictable.
In other words, being able to specify a specific branch does not solve all of the problems.
This is a deep-seated problem.
@Wauplin Can we at least be able to specify in the README.md which model to use? If not specified, keep the current behavior. It looks like something similar is already possible for datasets.
Thanks for your reply. Can you give an example of unpredictable behavior? I’m guessing this won’t affect my workflow, as you mention LoRas and this sounds like we may have very different workflows, but just curious.
I’ll be training some models using a “space” then pushing the model to the respective repo/branch. We may also add a space to implement each model or one space to compare between multiple.
Oh, I thought it was a clear example of the one-model-one-repo principle, but I’m afraid I’ve confused you.
If you upload the LoRA file for the image generation AI or LLM to the repo and specify the base model appropriately in the README.md, the repo will behave as one model.
If multiple LoRA files are uploaded to one repo, one of them will be selected by itself. Basically, it’s the first file found in ls or something, but well, it’s hard to predict.
It would be ostentatious to call it unpredictable behavior, though.
Anyway, whether we want to allow non-main revisions or LoRA files to be specified, we first need to change this fixed behavior.
The YAML portion of the README.md needs to be upgraded and supported on the server side, and the internal code changes to both issues should be very close.
Thanks for clarifying. No, I don’t think what you mentioned would affect our work flow as we don’t have multiple pieces working together like that (LoRA+Model) just an object detection model on its own. The various branches don’t need to interact with each others either.
I think I’ll start with using branches and can always split and push to different repos if something while building the implementation shows some insurmountable hurdles.
Oh I see. I see why I was mistaken. It was a different purpose than this.
As you say, there is currently no way to show the user the version rendered as markdown. A text file is the best we can do. https://huggingface.co/user/repo/resolve/main/README.md
@Wauplin Is this a problem with the HF GUI or is the HF Hub feature not yet supported?
It actually doesn’t look so bad if you go to “files and versions” select a different branch in the drop down and then click the readme. The yaml stuff isn’t rendered anywhere, but at least it is visible with the same info if just organized differently. Thanks for confirming my suspicion though.
Hey there Sorry for the delay to reply. In general on HF we tend to always recommended 1 repo == 1 model as @John6666 mentioned. We tried in the past to do some repos where 1 revision == 1 model but it caused quite some confusion and especially a lack of discoverability. As you’ve noticed, the model card is the README from the main revision. It is this model card that we use to reference the model (tags, library name, etc.) and to build its lineage.
If you have several models, I’d advice to use several repos for them. It’s not necessarily less efficient since files have to be uploaded anyway. If you have 1 main model and several “children models”, you can indicate the base_model in the main model card to create a model tree. You can also create a collection on the Hub to gather all of your models in a single place. All of these can be automated using the huggingface_hub library if you are afraid of having a higher maintenance burden.
We tried in the past to do some repos where 1 revision == 1 model but it caused quite some confusion and especially a lack of discoverability.
I see. So you have experimented in the past and failed…
Indeed, I think it would be confusing to automatically expand all the models by revision.
It would be a lot simpler if there were more things that could be configured from the YAML in the README.md, like setting the default revision to foobar with “revision: foobar”.
I have a relatively fast local connection, so this is not a problem for me, but for those who want to solve things within HF Hub, it is often convenient to just use the YAML settings to somehow solve the problem.
Also, for example, there are cases where there is no LoRA scale setting item when using the PEFT library and it is fixed at 1.0, which we have no control over, even if we have the line speed.
I’m limited in what I can come up with, but I think there are probably a lot of features that are potentially missing or wanted. Maybe once you solicit requests in your Posts or something, we can make progress.
Since HF doesn’t seem to have a feature to announce something to everyone on the top (user home) page, the easiest way for us to notice it from HF’s GUI is currently Posts. It’s often recommended on the top page.
The GUI doesn’t seem to be your area of responsibility, but I think people are often confused because HF can’t force people to be notified of errors or important changes in the current situation.
model tree
That display and quantization display is very cool.
That feature is an incentive to make sure README.md is written properly.
Thanks for both your replies. I’ll have a look at the huggingface_hub api for collections later just to check, but I’m still not sure I need to maintain multiple repos for what I need. I was under the assumption it would be easier to maintain a single key for a single repo rather than managing many. Maybe there is a way to manage a single one with wider scope, but assuming I’ll want to manage other things on here eventually I’d rather keep scopes as finegrained as possible.
One thing catches my eye from your vocab use though. You keep bringing up the idea that it is difficult to manage different models on different “revisions”. I’m relatively new to HF, but long time git user. I’m interpreting your use of “revision” as any given commit on a given branch. I agree that pointing users to a prior commit on a given branch would be sub-optimal also from my perspective.
I’m more aiming for a base model like yolov5, and all the ones I want to host are just finetunes of this for the same specific purpose. (i.e. so no base + children tree like you mention). Each finetune is only different in the fact that it is trained on different resolutions of the same dataset (in an attempt to compare speed vs performance). So eventually we will decide on a given resolution that best suits our purposes and stop updating all others. So we’re not aiming to make great discoverability for all resolutions, just the one. All others can still be accessed via the different branches, but no real need to serve them on the same level as the final chosen resolution one.
Maybe you think I’m being stubborn? … I’ll await your replies if you think I’m ignoring some obvious benefits to the 1 model = 1 repo path.
some obvious benefits to the 1 model = 1 repo path
Basically all HF libraries assume “user/repo” as an argument, so a repo that does not is very disadvantageous for use with HF libraries. The only way to modify this is to make significant modifications to the fundamental parts of the HF library or to insert a conversion process just before use.
If there is no need to use HF’s Inference Serverless API or Inference Endpoint, there is a way to put many files in one repo and let everyone read and use them from the app as they do in their local environment. From the developer or modeler’s point of view, this can be accomplished with the Spaces feature if the HF. Of course, Kaggle and Colab can also be used. If the application is LLM, I would think a $10/month GPU plan would be required…
The above disadvantages are not a problem if the file is uploaded onto HF with the assumption that it will be loaded and used from a non-HF library. Also, even HF libraries may have conversion functions that are designed to load from stand-alone files.
Any number of files up to 50 GB per file and 300 GB total per repo can be uploaded and used externally. There is almost no limit to the number of repos created.
Even HF staff members sometimes use non-HF formats during the experimental phase, and since this is a normal use of HF, there is no need to be concerned about ethics.
This is not limited to HF or AI models, but the more standard the format, the more convenient it is for someone other than you to download and modify.
Thanks for the details! Although I still don’t think I’d be immediately affected by either decision based on what I now know, with the idea of future expandability, I’ll try to follow your recommendations. I had a closer look at how HF handles user/org/repo-specific keys and it looks like my previous worry about managing multiple keys isn’t true, so I now have no real reason not to follow the recommendation other than the somewhat unpleasant naming scheme I’ll have to adopt to identify each resolution
Thanks again for the details. I’ll save this discussion for future reference.
Yeah. We had to convert, write README.md, upload, and do a lot of other work, which is a lot more tedious than uploading a single file. But other than that, there are no problems.
Even old versions of training course models can be valuable historical materials for later researchers.
Sorry for the delay to reply. In general on HF we tend to always recommended 1 repo == 1 model as 
But other than that, there are no problems.