# Ollama pull Error invalid model name **URL:** \ **Category:** Site Feedback\ **Created:** [September 4, 2026, 8:09pm UTC](https://discuss.huggingface.co/t/ollama-pull-error-invalid-model-name/179904 "2026-09-04T20:09:01Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![KottCh](https://avatars.discourse-cdn.com/v4/letter/k/9d8465/32.png) [@KottCh](https://discuss.huggingface.co/u/KottCh)\ **Post date:** [September 4, 2026, 8:09pm UTC](https://discuss.huggingface.co/t/ollama-pull-error-invalid-model-name/179904/1 "2026-09-04T20:09:01Z")
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](http://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: ollama run [hf.co/DavidAU/Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF:Q8\_0](http://hf.co/DavidAU/Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF:Q8_0) other model (example ornith) is pulling ---
**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [September 4, 2026, 11:06pm UTC](https://discuss.huggingface.co/t/ollama-pull-error-invalid-model-name/179904/2 "2026-09-04T23:06:05Z")
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](https://huggingface.co/docs/hub/ollama) explicitly document both: ```bash ollama run hf.co/{username}/{repository}:{quantization} ``` and using the full GGUF filename as the tag. So changing the long filename/tag to: ```bash :Q8_0 ``` was also a sensible thing to try. The interesting part is the repository name: ```plaintext 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](https://github.com/ollama/ollama/blob/main/types/model/name.go) treats a remote reference roughly as: ```plaintext host / namespace / model : tag ``` so your short form is effectively parsed as: ```plaintext 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: ```plaintext 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. ## Probably the cheapest workaround/test 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: ```plaintext your-account/qwen38-fcf-gguf ``` and then: ```bash 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: ```bash 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](https://huggingface.co/docs/huggingface_hub/guides/repository) and [`hf repos duplicate`](https://huggingface.co/docs/huggingface_hub/main/package_reference/cli). There is also the Hugging Face [Repo Duplicator Space](https://huggingface.co/spaces/huggingface-projects/repo_duplicator) if that is more convenient. The nice thing about this test is that it changes essentially **one variable** : ```plaintext same GGUF same quantization same Ollama different/shorter repository identifier ``` So if the error changes from: ```plaintext invalid model name ``` to something like: ```plaintext 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](https://docs.ollama.com/import): ```plaintext FROM /path/to/file.gguf ``` then: ```bash ollama create my-model ollama run my-model ``` That bypasses the Hugging Face remote-model identifier entirely. > **Why I think the 80-character boundary is the relevant one** > > 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: > > ```plaintext > namespace: 1..80 > model: 1..80 > tag: 1..80 > > ``` > > See [`types/model/name.go`](https://github.com/ollama/ollama/blob/main/types/model/name.go). > > For this reference: > > ```plaintext > 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: > > ```plaintext > 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: > > ```bash > ollama pull hf.co/DavidAU/: > > ``` > > and: > > ```bash > ollama pull hf.co/DavidAU/: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](https://github.com/huggingface/huggingface_hub/blob/main/src/huggingface_hub/utils/_validators.py) 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: > > ```plaintext > 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. > **The small boundary test** > > 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: > > ```plaintext > 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: > > ```plaintext > Does Ollama reject the reference locally, > or does it get far enough to try the registry? > > ``` > > The observed split was: > > ```plaintext > 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. > **One additional HF/Ollama edge case you may run into after shortening the name** > > 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: > > ```plaintext > 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](https://github.com/ollama/ollama/issues/15661). > > This is a **different layer** from the 80-character problem. > > Hugging Face’s documentation explicitly says that both: > > ```plaintext > hf.co/... > > ``` > > and: > > ```plaintext > huggingface.co/... > > ``` > > can be used for Ollama references: [HF Ollama docs](https://huggingface.co/docs/hub/ollama). > > 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: > > ```bash > ollama run huggingface.co/your-account/qwen38-fcf-gguf:Q8_0 > > ``` > > rather than: > > ```bash > ollama run hf.co/your-account/qwen38-fcf-gguf:Q8_0 > > ``` > > I would not combine the two errors into one diagnosis: > > ```plaintext > 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. > **A useful way to read whatever error comes next** > > I would roughly separate the path like this: > > ```plaintext > 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](https://huggingface.co/docs/hub/gguf) is useful background here, and the [Ollama/HF integration docs](https://huggingface.co/docs/hub/ollama) 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. ---
**Author:** ![KottCh](https://avatars.discourse-cdn.com/v4/letter/k/9d8465/32.png) [@KottCh](https://discuss.huggingface.co/u/KottCh)\ **Post date:** [September 5, 2026, 7:21am UTC](https://discuss.huggingface.co/t/ollama-pull-error-invalid-model-name/179904/3 "2026-09-05T07:21:37Z")
agree about name problem. error comes instantly without internet connection. I will ask Ollama devs about it. ---
**Author:** ![kamikatze13](https://avatars.discourse-cdn.com/v4/letter/k/9f8e36/32.png) [@kamikatze13](https://discuss.huggingface.co/u/kamikatze13)\ **Post date:** [September 17, 2026, 9:28pm UTC](https://discuss.huggingface.co/t/ollama-pull-error-invalid-model-name/179904/4 "2026-09-17T21:28:59Z")
have the same issue can confirm duplicating the repo works but requires cloning the newly created repo onto a local machine via `GIT_LFS_SKIP_SMUDGE=1 git clone https://huggingface.co/USERNAME/REPO_NAME`, locally renaming the files and pushing that commit. unnecessarily tedious =/ ---
**Author:** ![system](https://us1.discourse-cdn.com/hellohellohello/original/2X/d/de4155eb4aa4108ecb32a1389d7cc37ae69f88b7.png) [@system](https://discuss.huggingface.co/u/system)\ **Post date:** [September 18, 2026, 12:59pm UTC](https://discuss.huggingface.co/t/ollama-pull-error-invalid-model-name/179904/5 "2026-09-18T12:59:20Z")
---
**Author:** ![system](https://us1.discourse-cdn.com/hellohellohello/original/2X/d/de4155eb4aa4108ecb32a1389d7cc37ae69f88b7.png) [@system](https://discuss.huggingface.co/u/system)\ **Post date:** [September 19, 2026, 12:11am UTC](https://discuss.huggingface.co/t/ollama-pull-error-invalid-model-name/179904/6 "2026-09-19T00:11:46Z")