trying to pull this model, but error appears:
ollama run hf.co/DavidAU/Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF:Qwen3.8-27B-TurboFCFusion-735-882-Here-Uncen-NEO-CODER-MAX-Q8_0.gguf
Error: invalid model name
also not pulls in following format:
other model (example ornith) is pulling
Hmm… after looking into it, this might be a case where the repository name + filename is too long for Ollama:
More precisely, I think the repository/model-name part alone may already be long enough to hit Ollama’s model-name validator, before Ollama gets as far as resolving or downloading the GGUF.
Your command syntax itself looks reasonable. Hugging Face’s Ollama integration docs explicitly document both:
ollama run hf.co/{username}/{repository}:{quantization}
and using the full GGUF filename as the tag. So changing the long filename/tag to:
:Q8_0
was also a sensible thing to try.
The interesting part is the repository name:
Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF
That part is 85 characters long.
Ollama’s current model-name parser treats a remote reference roughly as:
host / namespace / model : tag
so your short form is effectively parsed as:
host = hf.co
namespace = DavidAU
model = Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF
tag = Q8_0
and Ollama currently limits that model component to 80 characters.
So shortening only the tag from a full .gguf filename to Q8_0 would not change the part that appears to be failing.
I did a small CPU-only sanity check against Ollama rather than downloading the actual large model. Using otherwise equivalent synthetic Hugging Face model references, the boundary came out cleanly:
model part length 79 -> passed model-name validation
model part length 80 -> passed model-name validation
model part length 81 -> "invalid model name"
model part length 85 -> "invalid model name"
The actual 85-character repository name also produced the same local invalid model name behavior.
So I would currently treat the name-length mismatch as the first blocker, rather than assuming that the GGUF itself or Q8_0 is invalid.
If you have enough Hub storage, I think a useful test would be to duplicate the same repository under a much shorter name and leave the actual GGUF unchanged.
For example, something conceptually like:
your-account/qwen38-fcf-gguf
and then:
ollama run huggingface.co/your-account/qwen38-fcf-gguf:Q8_0
Hugging Face now has a server-side repository duplication API/CLI, so this does not necessarily require manually downloading and re-uploading the whole repository:
hf repos duplicate \
DavidAU/Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF \
your-account/qwen38-fcf-gguf
See the repository duplication docs and hf repos duplicate.
There is also the Hugging Face Repo Duplicator Space if that is more convenient.
The nice thing about this test is that it changes essentially one variable:
same GGUF
same quantization
same Ollama
different/shorter repository identifier
So if the error changes from:
invalid model name
to something like:
pulling manifest
then even if a different error appears afterward, that would be useful evidence that the name-validation problem was indeed the first blocker.
If you do not want to duplicate a Hub repository at all, the other fairly standard route is to download the GGUF directly and import it locally with a short Ollama name. Ollama documents that route in its GGUF import guide:
FROM /path/to/file.gguf
then:
ollama create my-model
ollama run my-model
That bypasses the Hugging Face remote-model identifier entirely.
The important distinction here is that the complete command being long is not, by itself, the issue.
Ollama parses the reference into individual components. Its source currently documents these limits:
namespace: 1..80
model: 1..80
tag: 1..80
See types/model/name.go.
For this reference:
hf.co/DavidAU/Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF:Q8_0
the relevant component is:
Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF
which is 85 characters.
That also explains why these two attempts can fail identically:
ollama pull hf.co/DavidAU/<long-repo>:<very-long-full-filename.gguf>
and:
ollama pull hf.co/DavidAU/<long-repo>:Q8_0
The second command makes the tag short, but the parsed model part is still 85 characters.
This looks like an interoperability boundary more than a malformed Hugging Face repository. Hugging Face accepts this repository ID, while huggingface_hub’s own repository-ID validator permits repository names up to 96 characters.
So there is a small range of repository names that can be valid on the Hub but too long for Ollama’s model field:
HF-valid repository name
|
| 81..96 characters
v
Ollama remote model reference rejects it
I would describe that as a naming/interop edge case rather than saying either the model or GGUF is inherently broken.
I used Ollama v0.33.3 for the runtime check and deliberately did not download this 27B Q8 GGUF.
The test generated fake Hugging Face references with model components of controlled length:
79
80
81
85
The synthetic Hub namespace was intentionally nonexistent, so references that passed local validation were expected to fail later while trying to resolve a manifest.
That is useful here because the question was simply:
Does Ollama reject the reference locally,
or does it get far enough to try the registry?
The observed split was:
79 -> no "invalid model name"
80 -> no "invalid model name"
81 -> HTTP 400 "invalid model name"
85 -> HTTP 400 "invalid model name"
That is why I think the 85-character repository name is a fairly strong explanation for this particular first error.
It still does not prove that the same GGUF will load and run correctly after the name problem is bypassed. Those are later layers.
There is another currently open Ollama/Hugging Face integration issue that is worth separating from this one.
In the <=80-character test cases, Ollama got past local name validation but then hit:
pull model manifest:
realm host "huggingface.co" does not match original host "hf.co"
There is an open Ollama report for that behavior: ollama/ollama#15661.
This is a different layer from the 80-character problem.
Hugging Face’s documentation explicitly says that both:
hf.co/...
and:
huggingface.co/...
can be used for Ollama references: HF Ollama docs.
So if a short repository name gets past invalid model name but then hits that particular realm-host error, I would try the full hostname:
ollama run huggingface.co/your-account/qwen38-fcf-gguf:Q8_0
rather than:
ollama run hf.co/your-account/qwen38-fcf-gguf:Q8_0
I would not combine the two errors into one diagnosis:
85-character model component
|
v
"invalid model name"
|
| shorten repository name
v
manifest/auth stage
|
+--> possibly a separate hf.co / huggingface.co realm issue
Seeing a new error after shortening the name can therefore actually mean that you successfully got past the first problem.
I would roughly separate the path like this:
1. model-reference parsing
|
+-- "invalid model name"
|
v
2. manifest / tag resolution
|
+-- manifest/tag/auth/realm error
|
v
3. GGUF download
|
v
4. GGUF loading / architecture support
|
v
5. template / renderer / runtime behavior
So:
If it still immediately says invalid model name
The reference itself is still being rejected. Check the actual parsed namespace, model, and tag lengths/characters first.
If it starts saying pulling manifest
That is useful progress: the name/reference layer appears to have been passed. Any error after that should be investigated as a registry, tag, authentication, or manifest problem instead.
If the GGUF begins downloading
Then the identifier/manifest path has gone substantially further, and any later failure is more likely to belong to GGUF loading or architecture support.
If it loads but behaves incorrectly
That becomes a separate runtime/template/renderer question. Hugging Face’s GGUF documentation is useful background here, and the Ollama/HF integration docs describe how the Hub can provide quantization selection, chat templates, parameters, etc.
In other words, I would avoid changing the model, quantization, template, and repository structure all at once. The short-repository test is attractive because it isolates the naming layer first.
So, at least from the error shown here, I don’t think you were simply using the Hugging Face Ollama syntax incorrectly. The most economical next step seems to be keeping the same GGUF and giving the remote repository a short name, or bypassing the remote naming layer with a local GGUF import.
If that changes the failure from invalid model name to a later-stage error, that would narrow the remaining problem quite a lot.
agree about name problem. error comes instantly without internet connection. I will ask Ollama devs about it.