Model serialization is the process of converting a trained model's in-memory state into a portable file format that can be saved, transferred, and reloaded elsewhere — the first concrete step of the deployment pipeline previewed in DL Deployment Lifecycle.
What Actually Gets Serialized
| Component | Description |
|---|---|
| Parameters (weights and biases) | The learned numerical values themselves |
| Architecture definition | Either the code that builds the model, or (for formats like ONNX) a serialized computational graph describing the operations |
| Buffers | Non-trainable state that still matters for correctness — e.g. BatchNorm's running mean/variance (see Batch Normalization) |
PyTorch's Native Serialization
import torch
# Recommended: save only the state_dict (weights), not the full model object
torch.save(model.state_dict(), "model_weights.pt")
# Reloading requires re-creating the exact same architecture first
model = MyModelClass(*args)
model.load_state_dict(torch.load("model_weights.pt"))
model.eval()Saving just the state_dict (a plain Python dictionary of tensor weights) rather than the entire model object is the generally recommended approach — it's more portable across code changes and doesn't depend on Python's pickle format being able to reconstruct arbitrary class definitions exactly as they existed at save time.
Why Native Format Isn't Always Deployment-Ready
A native state_dict still requires the original Python model class and a live PyTorch environment to reload — fine for another PyTorch script, but often not ideal for a production serving environment that may want to avoid a full Python dependency, run on different hardware, or be language-agnostic. This is exactly the gap that TorchScript and ONNX address, covered next.
Common Mistakes
- Saving the entire model object (
torch.save(model, ...)) rather than just itsstate_dict— this pickles the exact class definition too, which can break if the model class's code changes even slightly between saving and loading. - Forgetting to call
model.eval()after reloading a model for inference — without it, layers like Dropout and BatchNorm remain in training mode, producing incorrect, non-deterministic outputs.
Interview Relevance
Q: "Why is saving a model's state_dict generally preferred over saving the entire model object in PyTorch?" Saving the full object pickles the exact class definition at save time; if that class's code changes at all before reloading (even a minor refactor), loading can silently break or produce incorrect results. Saving only the state_dict — the weights as a plain dictionary — decouples the saved weights from the exact code structure, requiring only that the class be re-instantiated correctly before loading the weights into it, making it more robust to code evolution over time.
Practice Question
Why must model.eval() be called after loading a saved model's weights, before running inference?
