Lit block = weight in transitDrawers = file sections, disk orderBare board = no memory siteA filing cabinet on a loading dock. The cabinet is the model file. Each drawer is one section. Watch the weight blocks travel to the GPU bay.A runnable model is weights plus a tokenizer, a chat template and an architecture config. GGUF packs all four into one self-describing file: the magic GGUF and version 3, a tensor count, metadata keys such as general.architecture, the context length, tokenizer.ggml.* and tokenizer.chat_template, then one index entry per tensor (name, shape, quant type, offset), zero padding to the alignment (32 bytes by default), then the tensor data. safetensors holds only tensors (an 8-byte little-endian header length, a JSON header of dtype, shape and offsets, then raw bytes); the tokenizer and config sit beside it as JSON files. ONNX is an operator graph plus weights (big ones in an external data file) for ONNX Runtime and Windows ML, and a TensorRT engine is a compiled plan for one GPU type. GGUF and safetensors data is aligned and contiguous, so a loader can memory-map it and the OS pages blocks in from disk (NVMe about 7 GB/s) as they are touched, or from RAM if they are still in the page cache. The hoist lifts pallets from the cabinet (disk) onto the RAM shelf (the page cache); the conveyor (PCIe) carries them to the card, where each block hops onto a memory site. Empty pallets stack on the floor. If the model is too big for the GPU, the bay fills: the blocks that do not fit wait on the RAM shelf (the CPU runs those layers), or go back into the cabinet when RAM cannot hold them either. Drag RAM below the file size and the gauge pegs: there is no warm load.