Downloading AI models from the wrong place is a real supply chain risk that most local AI guides skip entirely. Here is how to acquire, verify, and store models safely - including what to do when a model update breaks your workflow.

Why model provenance matters

A malicious model file can execute code during loading on some inference frameworks. A model with subtle fine-tuning changes can produce outputs that look correct but behave differently in ways that matter for your use case. And a model from an unverified mirror might simply be corrupted.

This is not theoretical. There have been documented cases of malicious models uploaded to Hugging Face (since removed). The ecosystem moves fast enough that verification is not excessive caution.

Where to get models you can trust

Trusted sources, in rough order of reliability:

Official model pages on Hugging Face from the original authors (Meta for Llama, Mistral AI for Mistral, etc.)
Ollama’s model library at ollama.com/library - they curate and verify what they distribute
LM Studio’s model browser - similar curation
Direct from the organization’s GitHub releases for models that distribute that way

Avoid: random mirrors, Discord links, “faster download” alternatives, anything without a clear author trail.

Checksum verification

Many model hosts provide SHA256 hashes for their files. When they do, use them.

# After downloading a model file:
sha256sum your-model-file.gguf

# Compare against the hash published on the model page

Ollama handles verification automatically for models in its library. For manual downloads, the check takes 30 seconds and catches corruption as well as tampering.

When a host does not provide hashes: note that in your version log (see below) and treat that source with extra caution.

Storage recommendations

Models are large. A practical storage setup:

Fast local NVMe SSD for models you are actively using. Inference from a spinning disk or slow SATA SSD creates significant latency.
Larger slower drive for archiving models you use occasionally.
Do not store models in cloud-synced folders. A 7GB model uploading to iCloud will saturate your connection and potentially cost money depending on your plan.

Size planning: assume 4-8GB per 7B parameter model at Q4 quantization, scaling roughly linearly. A modest collection of 10 models is 50-80GB.

The version log

This is the thing most people skip and regret later.

Keep a simple text file or spreadsheet:

Model	Version/Date	Source	Hash verified	Notes
llama3.2:3b	Q4_K_M, Dec 2024	Ollama	Yes	Good for quick tasks
mistral-7b	0.3, Jan 2025	HF official	Yes	Better instruction follow

When a model update changes behavior you depended on, you need this log to roll back. “Pull the old version” is only possible if you know which version you had.

When a model update breaks your workflow

This happens more than people expect. What to do:

Check your version log for the previous version hash or pull tag
Reinstall the previous version (ollama pull modelname:specific-tag for Ollama)
Pin the version in your agent config until you can test the new one properly
File the issue with the model maintainer if you confirm the regression

Keeping models updated (safely)

Updates bring bug fixes and improvements but can change output behavior. A reasonable policy:

Update non-critical models freely
Test updates to models in active workflows against a sample of your real inputs before switching over
Never update a production model and a model config on the same day

What is your current setup for managing local model versions?

Curated by Selendia AI ✈️