# Site problem for ollama pull **URL:** \ **Category:** Site Feedback\ **Created:** [July 31, 2026, 8:59am UTC](https://discuss.huggingface.co/t/site-problem-for-ollama-pull/178339 "2026-07-31T08:59:10Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![KottCh](https://avatars.discourse-cdn.com/v4/letter/k/9d8465/32.png) [@KottCh](https://discuss.huggingface.co/u/KottCh)\ **Post date:** [July 31, 2026, 8:59am UTC](https://discuss.huggingface.co/t/site-problem-for-ollama-pull/178339/1 "2026-07-31T08:59:10Z")
> **[LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V6-GGUF · Hugging Face](https://huggingface.co/LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V6-GGUF)** > > We’re on a journey to advance and democratize artificial intelligence through open source and open science. problem with ollama pulling case: 1. no choose for model, only one string ollama run [hf.co/LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V6-GGUF:Q8\_0](http://hf.co/LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V6-GGUF:Q8_0) 2. and manifest of this contains other variant of model: Hermes3.6-35B-A3B-Uncensored-Genesis-V5-Q8\_0.gguf | digest | “sha256:1ce77d0d9ff484ce1995242dff8824d3c9881cc9f3b68e418789777985a15910” | | --- | --- | | mediaType | “application/vnd.ollama.image.model” | | size | 36903139456 | ..huggingface.co/v2/LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V6-GGUF/manifests/Q8\_0 sorry, newbie here, if in wrong place posted. can’t see problem reporting future on site. is there any? ---
**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:** [July 31, 2026, 11:54pm UTC](https://discuss.huggingface.co/t/site-problem-for-ollama-pull/178339/2 "2026-07-31T23:54:58Z")
Hmm… this probably is not quite a bug, but rather something like **a behavior or specification that may still have some room for improvement** : * * * Your command does not look like a simple user mistake, and posting this under **Site Feedback** seems reasonable. The repository currently contains both: - `Hermes3.6-35B-A3B-Uncensored-Genesis-V5-Q8_0.gguf` - `Hermes3.6-35B-A3B-Uncensored-Genesis-V6-Q8_0.gguf` in the same [V6-named repository](https://huggingface.co/LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V6-GGUF/tree/main). That means `Q8_0` is a valid quantization name, but it is **not a unique file selector in this particular repository**. The important part is that this is not only a filename shown incorrectly in the UI. I compared the three registry manifests directly, without downloading the 36.9 GB model files: | Requested tag | Returned model digest | Resolved file | | --- | --- | --- | | `Q8_0` | `sha256:1ce77d0d9ff484ce1995242dff8824d3c9881cc9f3b68e418789777985a15910` | V5 | | exact V5 filename | `sha256:1ce77d0d9ff484ce1995242dff8824d3c9881cc9f3b68e418789777985a15910` | V5 | | exact V6 filename | `sha256:927d6b575cf31f0de0d3988ce24aeeec027253fe1160e85f50c4874e028bcf94` | V6 | So your observation is correct: > `:Q8_0` currently returns the same manifest as explicitly requesting the V5 file. ## Practical workaround Hugging Face’s [Ollama documentation](https://huggingface.co/docs/hub/ollama) says that a full GGUF filename can also be used directly as the tag. For this repository, the unambiguous V6 command is therefore: ```bash ollama run hf.co/LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V6-GGUF:Hermes3.6-35B-A3B-Uncensored-Genesis-V6-Q8_0.gguf ``` I verified that this exact filename resolves to the V6 model-layer digest shown above. I only checked manifest resolution, not the complete 36.9 GB download and subsequent model loading, so this confirms that the correct V6 blob is selected rather than guaranteeing that every later Ollama runtime step will succeed. ## What appears to be happening The current path seems to be: ```plaintext The repository contains both V5-Q8_0 and V6-Q8_0 ↓ Q8_0 alone does not identify one unique file ↓ the generated command retains only the quantization name ↓ the manifest endpoint silently resolves Q8_0 to V5 ``` There are therefore two related parts. ### Repository layout The repository contains several revisions—V3, V5 and V6—and two of them use the same `Q8_0` quantization label. I did not find a rule saying that this is invalid as generic Hub file storage. It is, however, ambiguous for any integration that tries to identify a GGUF using only its quantization label. Hugging Face’s current [model release checklist](https://huggingface.co/docs/hub/model-release-checklist) recommends using separate repositories for different model weights or variants, and using Collections and metadata to preserve their relationships. Separating V3, V5 and V6 would therefore be one possible repository-side way to avoid this ambiguity, but it should be understood as an organizational improvement rather than necessarily a repository-format violation. ### Generated command and manifest resolution The more surprising part is the user-facing flow. The [official Ollama instructions](https://huggingface.co/docs/hub/ollama#custom-quantization) tell users to open a particular GGUF file under **Files and versions** , then choose Ollama from **Use this model**. However, the resulting command is reduced to: ```plaintext repository:Q8_0 ``` rather than preserving the exact file that the user opened. That works when a repository contains only one `Q8_0`, but here the file-level choice is lost. The manifest resolver then returns one candidate—currently V5—without reporting that another `Q8_0` candidate exists. Whether Hugging Face would classify that internally as a bug, an unsupported repository layout, or underspecified selection behavior is probably for Hugging Face to decide. From a user’s perspective, though, the current behavior can silently download a different revision from the one whose file page was selected. A more defensive behavior could be any of the following: 1. Generate an exact-filename command whenever the quantization label is not unique. 2. Return an ambiguity error when multiple files match the same quantization. 3. Show a candidate-selection UI. 4. At least display the actual filename or digest selected by the generated command. I would not recommend simply choosing the “newest” matching file automatically, because that would replace one hidden selection rule with another. > **Manifest comparison and reproduction** > > The relevant model layer has: > > ```plaintext > mediaType = application/vnd.ollama.image.model > > ``` > > The three manifests can be compared with requests like these: > > ```bash > REPO="LuffyTheFox/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V6-GGUF" > > curl -sSfL \ > -H "Accept: application/vnd.docker.distribution.manifest.v2+json" \ > "https://huggingface.co/v2/${REPO}/manifests/Q8_0" | > jq . > > curl -sSfL \ > -H "Accept: application/vnd.docker.distribution.manifest.v2+json" \ > "https://huggingface.co/v2/${REPO}/manifests/Hermes3.6-35B-A3B-Uncensored-Genesis-V5-Q8_0.gguf" | > jq . > > curl -sSfL \ > -H "Accept: application/vnd.docker.distribution.manifest.v2+json" \ > "https://huggingface.co/v2/${REPO}/manifests/Hermes3.6-35B-A3B-Uncensored-Genesis-V6-Q8_0.gguf" | > jq . > > ``` > > The observed model-layer results were: > > ```plaintext > Q8_0: > sha256:1ce77d0d9ff484ce1995242dff8824d3c9881cc9f3b68e418789777985a15910 > > Hermes3.6-35B-A3B-Uncensored-Genesis-V5-Q8_0.gguf: > sha256:1ce77d0d9ff484ce1995242dff8824d3c9881cc9f3b68e418789777985a15910 > > Hermes3.6-35B-A3B-Uncensored-Genesis-V6-Q8_0.gguf: > sha256:927d6b575cf31f0de0d3988ce24aeeec027253fe1160e85f50c4874e028bcf94 > > ``` > > `Q8_0` and the exact V5 filename returned the same complete manifest—not merely the same display name or model-layer digest. They also shared the same manifest ETag and associated layers. > > The exact V5 and V6 file endpoints returned corresponding `X-Linked-ETag` values: > > ```plaintext > V5: > 1ce77d0d9ff484ce1995242dff8824d3c9881cc9f3b68e418789777985a15910 > > V6: > 927d6b575cf31f0de0d3988ce24aeeec027253fe1160e85f50c4874e028bcf94 > > ``` > > The comparison was repeated twice through both `huggingface.co` and `hf.co`. `hf.co` redirected to the same Hugging Face registry endpoint, and the results remained stable across the observation window. > > Hugging Face also has a public [Debug Ollama Manifest Space](https://huggingface.co/spaces/ngxson/debug_ollama_manifest) whose source uses the same `/v2/{model_id}/manifests/{tag}` endpoint, so inspecting this generated manifest separately from the original GGUF files appears to be the appropriate layer for this kind of problem. > **Where the mismatch occurs, and what remains unknown** > > It helps to separate the stages: > > ```plaintext > tag/file selection > → remote manifest generation > → model blob download > → local Ollama registration > → model loading > → inference > > ``` > > In this case, the V5 selection is already present in the **remote Hugging Face manifest** , before the 36.9 GB blob is downloaded and before Ollama attempts to load the model. > > That makes GPU memory, Qwen runtime support and model loading behavior unlikely to explain this particular V5/V6 mismatch. Those could still cause separate problems later, but they do not explain why the remote manifest already identifies the V5 blob. > > There have been other, technically different cases where the original GGUF and Hugging Face’s generated Ollama manifest needed to be examined as separate artifacts—for example, this [chat-template manifest report](https://discuss.huggingface.co/t/ollama-model-registry-provides-wrong-chat-template/176139). That is not evidence of the same root cause here; it is just a useful example of why the generated registry manifest should be checked independently. > > What cannot be determined externally is **why** the ambiguous tag currently selects V5. > > There is not enough evidence to say that Hugging Face chooses: > > - the oldest file, > - the first file returned by an index, > - the first file alphabetically, > - a cached historical candidate, > - or some other ordering. > > The externally verifiable statement is only: > > > In this repository, at the time tested, `Q8_0` resolved to V5, while the exact V6 filename resolved correctly to V6. So, for the immediate problem: - your manifest diagnosis appears correct; - **Site Feedback** is a reasonable place to report the generated-command and silent-resolution behavior; - the exact V6 filename is the currently verified way to select V6 unambiguously; - and the repository owner could separately reduce the ambiguity by separating revisions or documenting the exact-file commands. The main improvement opportunity seems to be ensuring that when a user opens one specific GGUF file, the generated command cannot silently resolve to another file carrying the same quantization label. ---
**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/site-problem-for-ollama-pull/178339/3 "2026-09-18T12:59:21Z")
---
**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:12am UTC](https://discuss.huggingface.co/t/site-problem-for-ollama-pull/178339/4 "2026-09-19T00:12:22Z")