---
title: "Loading a Model Checkpoint Is a Software Action, Not Just a File Read"
description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/model-checkpoint-deserialization-versus-tensor-data"
last-updated: "2026-10-20"
---

# Loading a Model Checkpoint Is a Software Action, Not Just a File Read

Leviathan Systems — Technical content
Published 2026-10-20; updated 2026-10-20.

Before accepting a model delivery, establish what its loader must do. General object deserialization can invoke software while reconstructing objects; a tensor-only container describes arrays without a pickle program for custom object reconstruction. A restricted unpickler is another distinct arrangement. The buyer still needs separately identified application code, origin evidence, numerical evaluation and permission for the intended use.

## Object reconstruction can invoke software before inference

Python's pickle documentation describes restoring an object hierarchy from a byte stream. Reconstruction can call a function to create an object and invoke behavior to restore its state. Functions and classes are generally referenced by their qualified names rather than having their implementation code copied into the pickle. The corresponding implementation must be available in the loading environment.

This is why opening a serialized object can require a consequential software action before anyone requests inference. Python explicitly warns that malicious pickle data can execute arbitrary code during unpickling. That capability does not establish that every checkpoint contains malicious behavior.

Ask what the supplier means by checkpoint: declared arrays, a saved object requiring reconstruction, or a broader package. The delivery description needs to identify both the stored representation and the software expected to interpret it.

References: [PY1](https://docs.python.org/3.14/library/pickle.html)

## Weights-only changes the unpickler's scope

The PyTorch 2.14 serialization note, dated May 8, 2026, describes weights_only=True as restricting reconstruction to functions and classes needed for plain-tensor state dictionaries and certain primitive types. It disallows dynamic imports during unpickling. This is a restricted unpickler, not a conversion to a tensor-only file format.

The note says this narrows remote-code-execution exposure but does not guard against denial of service. Memory corruption may remain possible, including through downstream handling of loaded objects.

A supplier's supported loader version and mode therefore belong in the delivery description. If its artifact requires reconstruction beyond that declared scope, return the mismatch to the appointed application and security owners. A loading failure supplies no approval to broaden the permitted behavior.

References: [PT1](https://docs.pytorch.org/docs/2.14/notes/serialization.html)

## A tensor container describes arrays and their locations

The safetensors v0.6.2 format uses an eight-byte little-endian unsigned integer to give the header length, followed by a UTF-8 JSON header and the tensor byte buffer. Named entries describe data types, shapes and byte offsets. Those offsets are relative to the tensor buffer; their end positions are exclusive.

This represents arrays without a pickle program for reconstructing custom Python objects. Parser software still interprets the container, and application software still decides how to use the arrays. Separating those responsibilities makes the supplied code easier to identify; it does not certify that code or the application.

References: [ST1](https://raw.githubusercontent.com/safetensors/safetensors/v0.6.2/README.md)

## MD-249: account for 360 bytes without inventing a network

Consider fictional delivery MD-249 with two float32 arrays. W has shape 4 by 4: 16 values at four bytes each, totaling 64 bytes. B has shape 2 by 4: eight values at four bytes each, totaling 32 bytes. Together they require 96 bytes of tensor data.

Stipulate a valid safetensors-format header of 256 bytes, including permitted padding. Its entries declare W as F32 with shape [4,4] and range [0,64), and B as F32 with shape [2,4] and range [64,96). The ranges refer to the start of the tensor buffer. W ends where B begins, and together they cover that buffer.

The complete size is 8 + 256 + 96 = 360 bytes. The tensor buffer begins at absolute file offset 264. W occupies file offsets [264,328), and B occupies [328,360). Header length and data length account for different parts of the file.

MD-249 is an invented format-reading example; no file or model was created or tested. Its arithmetic describes storage positions and scalar counts. It establishes no network architecture, checkpoint accuracy, loading result or runtime-memory fit.

References: [ST1](https://raw.githubusercontent.com/safetensors/safetensors/v0.6.2/README.md)

## A valid shape leaves the values' meaning unresolved

The names W and B do not supply the Python implementation that will interpret MD-249 as a network. Their dimensions do not specify input preparation, the sequence of operations or the meaning of an output. Those decisions belong in the separately identified application code and configuration.

The pinned safetensors description explicitly says tensor values are not checked and may include NaN or positive or negative infinity. A structurally valid container therefore need not contain numerically acceptable values.

Even finite values with the expected dimensions can be unsuitable for a task. The application owner needs evaluation evidence for the intended computation and use. Locating all 24 scalar values in MD-249 answers a storage question; it cannot answer whether those values produce an acceptable result.

References: [ST1](https://raw.githubusercontent.com/safetensors/safetensors/v0.6.2/README.md)

## Compare the required software action in two offers

Suppose fictional Offer A requires general reconstruction of a supplier-defined Python object. The buyer needs the supplier to identify the necessary implementation, dependencies and reconstruction behavior for assessment. Possession of the checkpoint alone does not describe that software responsibility.

Offer B delivers the MD-249 arrays alongside separately identified application code and configuration. Its description separates parsing the arrays from implementing the computation. That separation is useful when the buyer wants the application team to assess the program independently of the stored parameters.

B still requires software. If its supplier also provides a preparation helper, that helper's behavior belongs in the comparison. The array container's format does not describe everything a surrounding program might do.

For either offer, request the actual format, supported loader and version, required loading mode, supplementary processing, application code identity and named assessment owner. A proposal that merely promises to open the model leaves the consequential action undefined. Neither fictional offer has been assessed as trusted or suitable.

The related LoRA delivery guide answers a separate completeness question: whether an adapter delivery leaves base parameters to be supplied. Completing the weight population would not resolve the loader behavior compared here.

References: [PY1](https://docs.python.org/3.14/library/pickle.html)

## Keep origin evidence and permission attached to their own questions

The related SBOM and build-provenance guide explains evidence about component populations and software production. Use that guide for the origin question, while keeping evidence connected to the particular weights and separately supplied application code. A favorable origin assessment cannot explain away an undefined reconstruction requirement.

Permission is another substantive decision. The appointed owners must establish whether the intended use of the model and software is permitted and whether the proposed software action is authorized in their environment. A container's format supplies neither decision. Conversely, an authorized application still needs evidence that its numerical behavior meets the intended purpose.

The purchasing decision is whether the supplier has described a usable delivery with an assessment owner for each responsibility. Format explains representation and interpretation; origin evidence concerns where the identified artifacts came from; numerical evidence concerns the intended result; permission concerns the allowed use and action. Receiving one favorable answer leaves the others to their responsible owners.

## Connect selected equipment to a separate physical deployment

If the project also needs GPU equipment physically deployed, Leviathan's Complete Physical Deployment service connects agreed receiving, rack integration, hardware QA, onsite installation and cabling stages. Use the related service and project inquiry with a nonconfidential equipment list, destination, target window and required physical handoff.

Artifact loading, model security or malware assessment, software installation or conversion, and model serving remain with separately appointed software providers. Identify the application team receiving the equipment so the physical handoff and the software responsibilities meet at a defined interface.

## Primary sources

- [PY1 — Python 3.14 documentation — pickle: object serialization and reconstruction](https://docs.python.org/3.14/library/pickle.html). Checked 2026-10-20. Explains reconstruction behavior, qualified-name references and the arbitrary-code warning. Supports the distinction between stored object data and the implementation invoked to restore it.
- [PT1 — PyTorch 2.14 — Serialization semantics: weights-only security](https://docs.pytorch.org/docs/2.14/notes/serialization.html). Checked 2026-10-20. May 8, 2026 note describes the restricted unpickler, dynamic-import restriction and denial-of-service and memory-corruption limits. These limits concern the documented loader mode, not a finding about a particular artifact.
- [ST1 — safetensors v0.6.2 — Format and tensor-value limitations](https://raw.githubusercontent.com/safetensors/safetensors/v0.6.2/README.md). Checked 2026-10-20. Pinned format description supports header-length, shape and byte-range interpretation and the NaN/Inf limitation. MD-249 uses original stipulated dimensions and arithmetic; no actual loading or application result is reported.

## Related Leviathan resources

- [Software inventories and build provenance answer the origin question](/articles/gpu-software-sbom-versus-build-provenance)
- [LoRA adapters and merged models: identify the supplied parameters](/articles/lora-adapter-versus-merged-model-delivery)
- [Complete physical infrastructure deployment](/services/turnkey-gpu-deployment)
- [Discuss the physical deployment around the selected equipment](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Fmodel-checkpoint-deserialization-versus-tensor-data)
- [GPU Rack Floor Loading: Read the Rating Before Comparing the Weight](/articles/floor-loading-nvl72-rack)

## Discuss a separate physical GPU deployment

Share a nonconfidential equipment outline, destination, target window and physical handoff needs to discuss the receiving, rack integration, hardware QA, installation and cabling stages required.

[Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/model-checkpoint-deserialization-versus-tensor-data)