Skip to content

fix(gallery): match mmproj/model quant as a whole token so F16 no longer selects BF16 (#10559)#10564

Merged
mudler merged 1 commit into
masterfrom
fix/mmproj-quant-boundary-match-10559
Jun 27, 2026
Merged

fix(gallery): match mmproj/model quant as a whole token so F16 no longer selects BF16 (#10559)#10564
mudler merged 1 commit into
masterfrom
fix/mmproj-quant-boundary-match-10559

Conversation

@localai-bot

Copy link
Copy Markdown
Collaborator

Description

When importing a multimodal GGUF model from HuggingFace, the importer picks the mmproj/model file whose quant matches the requested preference. pickPreferredGroup matched the preference against the shard base filename with strings.Contains. Since f16 is a substring of bf16, asking for the F16 mmproj quant (mmproj_quantizations: "F16") wrongly satisfied a BF16 file and installed the BF16 variant when its group was ordered first.

The fix makes the match boundary-aware: the preference must appear in the base filename as a whole token, delimited by a non-alphanumeric character (or the string start/end) on both outer edges. So f16 inside bf16 is rejected (preceding b is alphanumeric), while f16 inside ...-F16.gguf is accepted. Separators inside the preference itself (e.g. ud-q4_k_xl) are left untouched, and all occurrences are scanned before rejecting. The rest of the selection behavior (priority order, last-group fallback, empty guard) is unchanged.

Fixes #10559

Notes for Reviewers

  • Added a focused boundary helper (quantTokenMatches + isAlphaNum) in the same file; comments explain the f16bf16 confusion.
  • New table-driven Ginkgo specs drive the public importer with a synthetic HF listing containing both mmproj-...-BF16.gguf and mmproj-...-F16.gguf (and reversed order), plus a normal ud-q4_k_xl regression and a no-match fallback case. The BF16-first case was a functional red before the fix.

Signed commits

  • Yes, I signed my commits.

…ger selects BF16 (#10559)

pickPreferredGroup matched a quant preference against the shard base
filename with strings.Contains. Because `f16` is a substring of `bf16`,
asking for the `F16` mmproj quant would wrongly satisfy a `BF16` file and
select it when its group came first.

Match the preference as a whole token instead: it must be delimited by a
non-alphanumeric character (or the string start/end) on both outer edges.
Separators inside the preference itself (e.g. `ud-q4_k_xl`) are left
untouched, and all occurrences are scanned before rejecting.

Signed-off-by: Ettore Di Giacinto <mudler@localai.io>
Assisted-by: Claude:claude-opus-4-8 [Claude Code]
@mudler
mudler merged commit f1fcafb into master Jun 27, 2026
60 of 61 checks passed
@mudler
mudler deleted the fix/mmproj-quant-boundary-match-10559 branch June 27, 2026 23:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Import from HF (Advanced): Specifying MMProj Quantisations: F16 imports BF16 variant when both F16 and BF16 variants are present on HF

2 participants