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 ✈️
