Medium
Single Scan
GGUF
Structural
The embedding table doesn't match its own metadata
See the real report
This isn't a mockup — the screenshot above is cropped from a real, cached scan report.
This isn't a mockup — the screenshot above is cropped from a real, cached scan report.
Every GGUF file carries the vocabulary size in two places: implicitly, as a dimension of the token_embd.weight tensor, and explicitly, as the tokenizer.ggml.vocab_size metadata field. In a correctly produced file these always agree — they describe the same vocabulary.
We left the embedding tensor at its real 32 rows and patched the metadata field to claim 999. Nothing crashes on load in most runtimes; the mismatch is silent until something downstream (detokenization, logit indexing) trusts the wrong number.
This is exactly the kind of tamper — or, just as often, honest corruption from a broken conversion or a mismatched tokenizer/model pairing — that a naive "does it load" check can't see. The scanner cross-checks the two fields against each other and flags the disagreement directly, without needing a reference model to compare against.