Space Not Able to Pull from Model Library

This space. Is unable to pull from model library. The exact same code in a different space/account works.

1 Like

I think this will probably make it work.
I think it would crash because it doesn’t have enough RAM in the free space…

import spaces
import json
import subprocess

subprocess.run('pip install flash-attn --no-build-isolation', env={'FLASH_ATTENTION_SKIP_CUDA_BUILD': "TRUE"}, shell=True)

cuda_device = 'cuda' if torch.cuda.is_available() else 'cpu'
model_checkpoint = "gokaygokay/Flux-Prompt-Enhance"
enhancer_tokenizer = AutoTokenizer.from_pretrained(model_checkpoint)
enhancer_model = AutoModelForSeq2SeqLM.from_pretrained(model_checkpoint).eval().to(cuda_device)

The error is about repository access, not model performance or dependencies.

1 Like

I think that there is a problem for you authorization.

1 Like

I made no changes to the code or the tokens before it went from working to error’d. I haven’t heard of tokens sporadically going bad.

1 Like

I mean you didn’t select the options.
You should check it now.

1 Like

Hey Alan, I’m not sure what you’re referring to when you say “options”? Are you talking about a call to the gokaygokay/Flux-Prompt-Enhance model? It is using a token in the model call but I added that model locally (gokaygokay/Flux-Prompt-Enhance) and then received the same error for the Janus-Pro-7B model that isn’t using a HF token to call it.

1 Like

After checking the space we’re discussing and then the space that is working I noticed that the gokaygokay model is not using a token in the model call. The code appears to have changed, but the history hasn’t been recorded correctly. Fortunately, I have the local git record available. :eyes:

For the alternate space I copied the code exactly as it was, which included a token in the call to the gokaygokay model, while the Janus call does not. As I said in the previous post, even when adding the gokaygokay model locally to the space that we are discussing I received the same error message for the Janus model.

1 Like

Without proper error logs I’m not sure how we can take Spaces as a serious peice of any infrastructure, maybe that’s the point, just a playpen for us, the internet nerds, not suitable for production workloads. I’ve had a horrible time with docker variants otherwise I’d just fix it and let this incident go. It seems like a deeper problem that could be related to security and it should be reported as an incident. The space went from functional to error’d between ~22:00-~24:00 UTC Jan 29, 2025. Without any intervention from me. Restarting the Space, Factory Reloading had no effect. Loading the model (that is giving the not authorized error) locally in the space doesn’t resolve the error. It is transferred to the Janus-Pro-7B model. The same application code in an alternative account is working.

1 Like

I think what Alan is saying is that it is probably implicitly referring to the HF_TOKEN environment variable (or, to be more precise, the secrets of Spaces in this case). This is a common occurrence in the operation of the HF library…
If the token is None or False, there shouldn’t be a problem, but if the wrong token is entered, something might happen.

In this case, it seems likely that something like a flag that is internally assigned to each space (originally for anti-spam measures, etc.) is malfunctioning…
I also have several spaces that have stopped working, although the symptoms are different.
I can’t find any objective commonality between them. Unlike the libraries, the HF Spaces-related elements are very black box.

1 Like

That sounds reasonable, the problem is completly removing the token has no effect, or if your theory is right, the flag isn’t reset. That would still mean there was an event that corrupted the token or set the flag. Without proper error logging for spaces or a settings change history it leaves us in the dark and Spaces as a tool not meant for production. No big deal, still fun to use and fast to experiment with.

1 Like

That’s right. We like using it because it’s more convenient than being fickle, but basically you can’t rely on it…
Once you’ve started Spaces, it’s very robust and in some cases it’s been running for years, but we can’t let our guard down until it’s running.
From HF’s point of view, the stable production service is probably the paid Endpoint API.

However, it seems that both Spaces and Endpoint are maintained independently, and the specifications can improve or worsen (mainly due to accidents).
Spaces is convenient and there is a free version, so it has been misused, so there is a difficult aspect, but I wish it would be a little easier to give feedback on Spaces…:disappointed:

1 Like

This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.