silicon-layer
0/24 complete

Module 1: Why Run Models Locally · 20 min

Understanding Model Sizes and Quantization in Plain English

// sabak

Turn this lesson into one checked practice output

By the end, you should be able to explain the core idea behind “Understanding Model Sizes and Quantization in Plain English” in your own words, apply it to one small real or sample task, and identify what still needs human review.

  1. 1

    Learn

    Read the 20-minute lesson without copying an output blindly.

  2. 2

    Try

    Use a small, non-sensitive example that you can inspect line by line.

  3. 3

    Review

    Check facts, fit, and risk; save one improvement note for next time.

Model size describes several different things: parameter count, numeric precision, file size, runtime memory, context memory, and temporary workspace. Quantization stores or computes some values with fewer bits to reduce memory and sometimes improve speed. It trades representation precision for efficiency; it does not shrink every workload equally or guarantee acceptable quality.

Parameters and Precision

Parameters are learned numeric weights. A rough weight-only estimate is:

weight bytes ≈ parameter count × bits per weight ÷ 8

A seven-billion-parameter model at 16 bits is roughly 14 GB for weights before format overhead. At a nominal 4 bits it is roughly 3.5 GB before overhead. Real files and runtime use differ because quantization formats store scales/metadata and some tensors may remain at higher precision.

Memory must also hold the KV cache for active context, runtime buffers, tokenizer, operating system, GPU display use, and sometimes multiple requests. A model file fitting on disk or even VRAM does not prove the desired context and concurrency will fit.

Understand the Labels

Formats such as GGUF describe how model data and metadata are packaged for runtimes such as llama.cpp. Quantization names like Q4, Q5, Q8, INT8, GPTQ, AWQ, or bitsandbytes 4-bit are not interchangeable quality grades. Each method, variant, model architecture, backend, and hardware path can behave differently.

Higher precision usually consumes more memory. Lower-bit weights may allow a larger model or longer context on the same hardware, but quality can degrade—especially on sensitive reasoning, exact extraction, multilingual text, code, or structured output. Speed may improve, stay similar, or worsen if the hardware/backend lacks an efficient kernel.

Build a Quality–Performance Matrix

Select one base model and two or three supported quantizations from a trusted source. Keep model revision, prompt template, sampling, context, output limit, and test set fixed. Measure:

  • task score from a human-defined rubric;
  • exact-match/schema validity where applicable;
  • time to first token and generation rate;
  • peak system RAM and VRAM;
  • failures, truncation, and thermal state;
  • file provenance, hash/digest, and license.

Do not compare a 4-bit version of one model with an 8-bit version of another and call the difference a quantization result. That changes two variables.

Worked Example

A support-classification task uses 100 synthetic or authorized redacted tickets and a fixed label set. Full-precision, 8-bit, and 4-bit variants run in randomized order. The report shows accuracy by category, invalid labels, latency percentiles, memory, and uncertainty.

If 4-bit is faster but loses rare Urdu/Roman Urdu categories, the team may keep 8-bit for that workload. If all variants meet the threshold, the smaller one may reduce cost. The decision applies only to the evaluated task and revision.

Failure Cases

  • Equating parameter count with intelligence or suitability.
  • Treating “4-bit” as one universal format.
  • Measuring only tokens per second while ignoring wrong answers.
  • Forgetting context/KV cache and concurrency memory.
  • Downloading community quantizations without provenance or terms.
  • Comparing different prompts, temperatures, or model revisions.
  • Claiming negligible quality loss without a task-specific evaluation.

🇵🇰 Pakistan Angle

Quantization can make useful local inference feasible on older or second-hand hardware, but do not buy from a label alone. Ask for exact GPU/VRAM evidence and test the intended model before purchase where possible. A counterfeit, repaired, thermally damaged, or warranty-less card changes the economics.

Include English, Urdu script, and reviewed Roman Urdu examples only when the application needs them. A model’s global benchmark score does not prove local-language reliability. Record correction rates with a fluent human reviewer.

Hands-On Exercise

Choose one model and at least two quantizations. Create 30 representative prompts, a rubric, and a benchmark sheet. Record versions, hashes, settings, quality, schema validity, latency, tokens/second, RAM/VRAM, temperature, and failures. Recommend one variant or state that none meets the requirement.

Completion Rubric

  • Complete: weight estimates distinguish runtime memory, variants share the same base/revision, and quality is measured beside speed and memory.
  • Needs revision: resource numbers exist but prompts, settings, provenance, or quality rubric are inconsistent.
  • Not complete: the recommendation relies on parameter count, file size, or one vendor benchmark.

Sources

Key takeaway: Quantization is a measured workload trade-off among memory, speed, and output quality; the label alone cannot choose for you.

Self-check

Before you mark Lesson 1.3 complete

  • Can I explain “Understanding Model Sizes and Quantization in Plain English” without reading the lesson back word for word?
  • Did I complete the lesson’s practice step on a real or clearly labelled sample task?
  • Did I check the result for invented facts, private data, unsafe actions, and mismatch with the brief?