Ollama pull Error invalid model name

Ollama's model-name parser rejects remote Hugging Face references whose model component exceeds 80 characters, according to a technical analysis of the parser in Ollama's types/model/name.go file. A CPU-only test using synthetic Hugging Face references found that model names of 79 and 80 characters passed validation while 81 and 85 characters returned "invalid model name," matching the failure seen with the 85-character repository name Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF. The analysis recommends duplicating the repository under a shorter name via the hf repos duplicate CLI or importing the GGUF locally with ollama create to bypass the Hugging Face remote identifier.

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/<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 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.