Reading Dtype Like an Archivist

The claim that is not a proof

A repository says the model is BF16. The config says "torch_dtype": "bfloat16". The filename says bfloat16. None of that proves the file holds the maker's native representation — it proves the file holds BF16-encoded numbers. Those are different claims, and the gap between them is where acquisition mistakes live.

Three different artifacts can all honestly wear the BF16 label:

The native representation — the precision the maker actually trained or exported in. Highest information content for this model; the archive's default target.
A real conversion — an FP32 master downcast to BF16 at release. Legitimate, but it is a derivative wearing the same label as the native form.
A padded upcast — a lossy source (a quantized file, an FP8 export) expanded back to 16-bit containers. The label is technically true and practically a trap: the bytes claim more precision than the information they hold. You cannot see this from the label; the information was already gone before the upcast.

Arithmetic is the archivist's instrument

The bytes-per-parameter check is cheap and catches most mislabels. Multiply parameter count by the claimed bytes per element and compare with the actual shard sizes:

7B params at BF16 (2 bytes) ≈ 14 GB of tensors. A repo claiming BF16 at ~28 GB is F32-sized — either a full-precision master (good to know) or an upcast.
The same 7B at ~7 GB is Q8-shaped; at ~4 GB, Q4-shaped. A "BF16" repo whose tensors sum to a quantization-sized footprint is wearing someone else's label.

Then corroborate with provenance, which you will learn to read in the next track: does the maker's own card name the release precision? Does the repo's commit history show a conversion step? Do independent mirrors of the same release agree on sizes? A dtype claim plus consistent arithmetic plus a credible story is a verdict; any leg missing means the label stays evidence.

A dtype label is evidence, not a verdict. It tells you the container's precision. What you are buying is the information's precision — and only arithmetic plus provenance can speak for that.

Why this is the load-bearing skill

Every acquisition policy in this quest — highest-fidelity authoritative representation, one copy per thing — depends on being able to rank candidate artifacts by fidelity. Ranking requires exactly this: reading labels as claims, testing them with size arithmetic, and consulting provenance before anointing a file as the master. The acquisition decision this skill feeds is the difference between an archive and a pile of mislabeled derivatives.

Code

The bytes-per-parameter sanity check·python

def expected_bytes(params: float, dtype: str) -> float:
    per = {"fp32": 4, "fp16": 2, "bf16": 2, "fp8": 1}.get(dtype.lower())
    if per is None:
        raise ValueError(f"unknown dtype {dtype}")
    return params * per

# Candidate repo claims: 7B params, BF16, shards sum to X GB
params = 7.0e9
claimed = sum_shard_bytes  # from the file-tree reconnaissance call

expect_bf16 = expected_bytes(params, "bf16")
expect_fp32 = expected_bytes(params, "fp32")

ratio = claimed / expect_bf16
if 0.9 <= ratio <= 1.1:
    verdict = "size consistent with the BF16 claim"
elif 1.8 <= ratio <= 2.2:
    verdict = "F32-sized: full-precision master OR upcast — provenance decides"
elif ratio <= 0.6:
    verdict = "quantization-sized: the BF16 label is decorative"
else:
    verdict = "neither: investigate before trusting"
print(f"{claimed/1e9:.1f} GB vs BF16 expectation {expect_bf16/1e9:.1f} GB -> {verdict}")

Exercise

Take a model with at least two public variants (e.g., a full-precision release and a smaller re-release claiming the same dtype). Run the reconnaissance arithmetic on both: expected bytes for the claimed dtype vs actual sizes. Write the verdict line for each, and state which artifact you would archive as master and what provenance fact would still need checking.

Hint

If the two variants' ratios differ wildly, at most one of them is what its label says. The maker's release notes or the original announcement usually settle which.

The claim that is not a proof

Arithmetic is the archivist's instrument

Why this is the load-bearing skill

Code

External links

Exercise

Progress

Comments 0