# Ollama pull Error invalid model name > Source: > Published: 2026-09-17 21:28:59+00:00 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: ``` 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](https://github.com/ollama/ollama/blob/main/types/model/name.go) 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: ``` php 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](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**: ``` 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](https://docs.ollama.com/import): ``` FROM /path/to/file.gguf ``` then: ``` 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: ``` 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: ``` 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/: ``` and: ``` 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: ``` 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: ``` 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: ``` php 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: ``` 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: ``` hf.co/... ``` and: ``` 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: ``` 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. ## A useful way to read whatever error comes next 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](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.