Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

instrument mechanism / verified-clean

GPU VRAM vs Model Size Ladder mechanism

The inspectable method record for GPU VRAM vs Model Size Ladder, kept separate from implementation and qualification.

Status: VERIFIED_CLEANLifecycle: verified-clean

Model scope

The weight-storage portion is standard under the stated byte and overhead assumptions. The instrument cannot receive a PASS until the KV-cache equation, architecture inputs, KV dtype behavior, overhead semantics, output units, and GPU comparison ladder are made explicit. The honest-label warning is appropriate but should also state that activations and temporary runtime memory may be excluded.

  • The KV-cache term is not defined as an actual formula, so its value is not uniquely computable.
  • The declared inputs omit architecture values required for KV-cache estimation, including layer count, head count or KV-head count, and head dimension.
  • The formula does not specify whether heads means attention heads or KV heads; this materially changes cache size for GQA or MQA models.
  • The formula does not specify whether KV-cache dtype is the same as weight precision. These are often different.
  • The formula does not define the overhead factor, its allowed range, or whether overhead applies only to weights or also to KV cache and runtime buffers.
  • The claimed fits-on-GPU comparison ladder requires a GPU-capacity table and a comparison rule, neither of which is specified in the formula.

Units and conventions

  • Parameter count is a raw count, not millions or billions; values such as 7000000000 mean 7 billion parameters.
  • Bytes per parameter are assumed to be fp32=4, fp16=2, int8=1, and int4=0.5.
  • VRAM outputs are reported in bytes and binary GiB, where 1 GiB=1073741824 bytes.
  • The standard KV-cache formula is assumed to be 2 × batch_size × context_length × layer_count × KV_head_count × head_dimension × KV_bytes_per_element; the factor 2 accounts for keys and values.
  • The test vectors explicitly provide layer count, attention/KV head count, head dimension, and KV-cache dtype because the supplied input list does not.
  • The overhead factor is assumed to multiply weight storage only, as suggested by params × bytes_per_param × overhead_factor + KV cache.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "parameters": 7000000000,
    "precision": "fp16",
    "bytes_per_param": 2,
    "overhead_factor": 1.2,
    "context_length": 4096,
    "batch_size": 1,
    "layers": 32,
    "kv_heads": 32,
    "head_dimension": 128,
    "kv_dtype": "fp16",
    "kv_bytes_per_element": 2
  },
  "expected_outputs": {
    "weight_bytes": 16800000000,
    "kv_cache_bytes": 2147483648,
    "total_vram_bytes": 18947483648,
    "total_vram_gib": 17.646
  },
  "working": "Weights = 7000000000 × 2 × 1.2 = 16800000000 bytes. KV cache = 2 × 1 × 4096 × 32 × 32 × 128 × 2 = 2147483648 bytes. Total = 16800000000 + 2147483648 = 18947483648 bytes. GiB = 18947483648 ÷ 1073741824 = 17.646 GiB."
}

Failure boundary

BREAK_CLAIMED · SELF_FLAGGED

An extreme but numerically representable parameter_count causes the JavaScript arithmetic to overflow to Infinity, so the instrument must reject or explicitly flag non-finite estimates. The specification also leaves int4 packing, metadata overhead, and GB-versus-GiB display conventions ambiguous.

Other records

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

  • VERIFIED_LEDGER.json
  • evidence-tranche4/tranche4-results.json
  • BOUNDARY_HAZARD_CATALOG.json