Run the hf cache verify command for a repository and revision. The huggingface_hub documentation says it checks that cached files match the checksums on the Hub, and reports whether all checksums match. Then record your own hashes. It catches corruption and local tampering, not a malicious file the Hub itself serves.
What the command does
The cache guide for huggingface_hub describes a verification step. You give it a repository id, and optionally a specific revision, and it validates file consistency for that snapshot. The documented example prints that it verified a number of files for the repository and that all checksums match.
The same guide explains how the cache is laid out. Files live in a blobs folder, where the name of each file is its hash. A snapshots folder holds symlinks to those blobs, with one folder per known revision. That layout is why a revision can be checked as a unit.
hf cache verify ORG/MODEL --revision COMMIT_HASH
Use a commit hash, not a branch name, so you verify the snapshot you actually reviewed.
What a pass tells you
| Result | Meaning |
|---|---|
| All checksums match | The files in your cache are the files the Hub lists for that revision |
| A mismatch | A file is corrupt, partial or changed locally. Do not load it |
| Missing files | An incomplete download. Fetch it again |
This is useful in several places: after copying a cache to a new server, after restoring from backup, before a release, and when a service behaves strangely after a disk problem.
What a pass does not tell you
The check compares your copy with the Hub's record. If the Hub's copy is the problem, the files can match and still be unsafe. A match does not mean the file is free of malicious content, that the license suits you or that the publisher is who you think.
So treat verification as one link in a chain.
- Review the model first. Check the publisher, the license and the file formats. Prefer formats that do not execute code on load.
- Pin the revision. Use the commit hash in code and configuration.
- Download and verify. Run the verify command on the build machine.
- Record your own hashes. Compute a hash for each file you plan to ship and store it in your inventory or your software bill of materials.
- Verify again where the model is used. Check the hashes on the serving host before it loads the model.
sha256sum models/ORG__MODEL/* > model.sha256
sha256sum -c model.sha256
Your own recorded hashes matter because they do not depend on the Hub at all. If someone later changes a file on the host or in a bucket, your list catches it.
Make it routine
- Add the verify step to the job that builds your model cache.
- Fail the deployment if verification or your own hash check fails.
- Store the hash file next to the deployment config in version control.
- Re-run the check on a schedule for long-lived hosts.
- Log the revision and hashes at service start, so an investigation can answer exactly which files were loaded.
Related habits
Offline mode, pinned revisions and a read-only mount for the cache all support this. Separate posts on this blog cover offline mode for production inference and pinning a revision to a commit hash. For file formats, see the posts on safetensors and on model file extensions.
Quick check
Does a matching checksum mean the model is safe?
No. It means your copy matches the Hub's record. Safety depends on the publisher, the format and what you test.
Why record my own hashes if the Hub has checksums?
Your list works offline and does not depend on the Hub. It detects changes made after you approved the files.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, so you can keep an inventory of the software around your models, and policies and gates that enforce checks in CI. A free scan is available.
Sources
- huggingface_hub cache guide, read 19 October 2026.
- huggingface_hub download guide, read 19 October 2026.
Last reviewed: 19 October 2026.
