[Bug]: pre-quantized AWQ/GPTQ/INT4 repos report packed element count as parameters — 6x memory understatement, rated 'Perfect'
Summary
Pre-quantized safetensors repos (AWQ / GPTQ / INT4 / W4A16 / AutoRound / compressed-tensors) report a parameters_raw that is the packed int32 element count, not the true parameter count. llmfit then derives disk/VRAM from that already-deflated number and applies the quantization discount a second time, understating memory by roughly 3-6x. The affected models score as Perfect / Good and, because a smaller apparent size raises the fit score, they are promoted to the top of the ranking.
This is the same class of bug as #622 (GGUF repos, 29.6B instead of 671B), but on a different code path, so the fix there doesn't cover it.
Evidence
Four repos, comparing what llmfit reports against the actual weight files on HF:
| Repo | llmfit params_b |
HF safetensors.total |
Real .safetensors on disk |
|---|---|---|---|
TelperionAI/Huihui-Qwen3.8-27B-abliterated-INT4-AWQ-GPTQ |
7.84B | 7,839,289,360 | 25.1 GB |
TelperionAI/Qwen3.8-27B-INT4-AWQ-GPTQ |
7.84B | 7,839,289,360 | 25.1 GB |
Minachist/Qwen3.8-27B-INT8-AutoRound |
9.12B | 9,116,380,400 | 30.9 GB |
RedHatAI/NVIDIA-Nemotron-Nano-9B-v2-quantized.w4a16 |
2.26B | 2,261,053,168 | 6.5 GB |
llmfit's value matches HF's safetensors.total exactly in every case — the bad number is inherited from the API, not invented.
For the first repo, HF reports:
safetensors.total: 7839289360
parameters by dtype: {'I32': 16840130560, 'BF16': 3454464752}The I32 tensors are packed 4-bit weights. The real model is 27B-class: config.json gives architectures: ["Qwen3_5ForConditionalGeneration"], text_config.hidden_size: 5120, num_hidden_layers: 64, vocab_size: 248320, quantization_config.quant_method: "compressed-tensors".
The catalog entry in llmfit-core/data/hf_models.json:
{
"name": "TelperionAI/Huihui-Qwen3.8-27B-abliterated-INT4-AWQ-GPTQ",
"parameter_count": "7.8B",
"parameters_raw": 7839289360,
"min_ram_gb": 4.4,
"recommended_ram_gb": 7.3,
"min_vram_gb": 4.0,
"quantization": "AWQ-4bit",
"format": "awq",
"num_hidden_layers": null,
"hidden_size": null,
"vocab_size": null,
"_discovered": true
}llmfit fit --json on a 10 GB RTX 3080 then yields disk_size_gb: 3.92, memory_required_gb: 4.48, fit_label: "Perfect", utilization_pct: 44.8 — for a model whose weights alone are 25.1 GB. It cannot load on this card at all.
Root cause
The correction already exists, at scripts/scrape_hf_models.py:1031:
# Correct parameters_raw when safetensors reports quantized element counts
# instead of true parameter count (common in FP8/INT4/INT8 repos).
arch_params = estimate_params_from_arch(full_config)
if arch_params and arch_params > total_params * 2:
total_params = arch_paramsestimate_params_from_arch handles multimodal wrappers correctly (it falls back to text_config, line 658), and for this repo text_config carries hidden_size, num_hidden_layers and vocab_size — so it would have estimated ~27B, seen 27B > 7.84B * 2, and corrected the value.
It never runs. The entry is "_discovered": true, built by _build_discovered_model() (scrape_hf_models.py:1710), a lightweight path that never calls fetch_config_json(). With full_config absent, estimate_params_from_arch returns None and the guard is unreachable. That is also why every architecture field on the entry is null.
Scale in the shipped catalog
Counted directly in llmfit-core/data/hf_models.json @ v1.1.15:
- 12,937 entries total
- 12,748 are
_discovered(98.5%) - 5,450 have
hidden_size: null(no architecture metadata, so the correction can never fire) - 143 are both null-arch and a pre-quantized format — the population where
parameters_rawis wrong with nothing able to catch it
Reproduction
llmfit fit --json -n 12200 \
| jq '.models[] | select(.name=="TelperionAI/Huihui-Qwen3.8-27B-abliterated-INT4-AWQ-GPTQ")
| {name, params_b, disk_size_gb, memory_required_gb, fit_label, utilization_pct}'Compare against the real repo size:
curl -s "https://huggingface.co/api/models/TelperionAI/Huihui-Qwen3.8-27B-abliterated-INT4-AWQ-GPTQ?blobs=true" \
| jq '[.siblings[] | select(.rfilename|endswith(".safetensors")) | .size] | add / 1e9'On a 10 GB card the model is also in the top 4 rows of a plain llmfit fit, alongside three sibling repos with the same defect.
Suggested fix
Either would close the gap:
- In
_build_discovered_model(), fetchconfig.jsonwhendetect_quant_format()returns a pre-quantized format, so the existing line-1031 correction can fire. - Fall back to the repo's actual
.safetensorsblob sizes (already available from the HF API via?blobs=true) when architecture metadata is unavailable and the format is pre-quantized. This also avoids double-applying the quantization discount, since those bytes are the quantized size.
A regression guard worth adding either way: assert that a pre-quantized entry's derived disk_size_gb is not wildly below the sum of its repo blob sizes.
Environment
- llmfit version: 1.1.15 (built from source at
58e29bb) - OS: Linux 6.8.0 x86_64 (Ubuntu)
- CPU: AMD Ryzen 9 5900X, 31.28 GB RAM
- GPU: NVIDIA GeForce RTX 3080, 10 GB VRAM, CUDA backend
Source: AlexsJones/llmfit