#1045·llmfit

[Bug]: pre-quantized AWQ/GPTQ/INT4 repos report packed element count as parameters — 6x memory understatement, rated 'Perfect'

Author: JarnDevCreated Sep 15, 2026Updated Sep 15, 2026
Labelsbug

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:

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:

python
# 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_params

estimate_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_raw is wrong with nothing able to catch it

Reproduction

bash
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:

bash
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:

  1. In _build_discovered_model(), fetch config.json when detect_quant_format() returns a pre-quantized format, so the existing line-1031 correction can fire.
  2. Fall back to the repo's actual .safetensors blob 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