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.ggufHermes3.6-35B-A3B-Uncensored-Genesis-V6-Q8_0.gguf
in the same V6-named repository.
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 says that a full GGUF filename can also be used directly as the tag.
For this repository, the unambiguous V6 command is therefore:
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:
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 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 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:
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:
- Generate an exact-filename command whenever the quantization label is not unique.
- Return an ambiguity error when multiple files match the same quantization.
- Show a candidate-selection UI.
- 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:
mediaType = application/vnd.ollama.image.model
The three manifests can be compared with requests like these:
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:
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:
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 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:
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. 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.