PackageTrack
Sign in Get early access

safetensors

Provides functions to read and write safetensors which aim to be safer than their PyTorch counterpart. The format is 8 bytes which is an unsized int, being the size of a JSON header, the JSON header refers the `dtype` the `shape` and `data_offsets` which are the offsets for the values in the rest of the file.

0.8.0 22M downloads/mo #1966 most downloaded on crates.io huggingface/safetensors

What this package is like to depend on

Last release 2 months ago

09 Jun 2026

Ships fairly regularly

a new release about every 3 months

Rarely documented

notes for 5 of 22 stable releases

Nothing withdrawn

no release was ever pulled

4 years old

22 releases · first in 2022

2 releases in the last 12 months

see the full history below

Release timeline

22 releases · Dec 2022 to Jun 2026
2023 2024 2025 2026
Release Pre-release

Releases

latest 22
  1. 0.8.0 09 Jun 2026
    Release notes

    News

    safetensors joins the PyTorch foundation!

    Read more on that: https://huggingface.co/blog/safetensors-joins-pytorch-foundation

    What's changed

    Safetensors 0.8.0 brings direct to Metal loading on Apple Silicon, GIL-free serialization, broader hardware and dtype coverage, and a stronger Python API.

    Breaking

    The serialize and serialize_file functions now release the GIL during writes, enabling true multithreaded saves from Python. Their input contract has also changed: tensor metadata is now passed via a TensorSpec class (exported from safetensors) instead of plain dicts, making API more explicit and robust to misinputs. This is a breaking change for anyone calling the low-level serialize / serialize_file API directly; the high-level wrappers (safetensors.torch, safetensors.numpy, safetensors.paddle) are updated internally and their public API is unchanged.

    The minimum supported Python version is now 3.10 (was 3.9). Python 3.9 reached end-of-life in October 2025.

    TensorIndexer::Narrow now carries a step: NonZeroUsize parameter, so a slice is now start:stop:step. This is a fix as this silent error was hidden behind the Storage::Torch variant which offloaded slicing logic to torch directly.

    CI

    On the platform side, this release adds Windows ARM64 wheel builds, riscv64 Linux wheels, and CI has been hardened with pinned GitHub Actions SHAs.

    Also dropped the anaconda CI we had as there's already an automatic tracker via conda-forge.

    New features

    • Direct MPS load on Apple Silicon: tensors are directly loaded in an MTLBuffer and handed to the frameworks that support it (only torch atm) via DLPack, skipping needless copies.
    • New backend parameter introduced, for the addition of the pread backend. We now support loading files via pread(2) syscall instead of just mmap. Useful for specific archs/platforms.
    • get_slice now handles ellipsis [...] and strided slices [:, ::8] wherever safetensors does the slicing itself (pread for any framework, MPS, and mmap outside torch/paddle), which silently dropped the step or rejected ... before.
    • MUSA device support for MooreThreads GPUs.
    • New dtype support includes float8_e4m3fnuz and float8_e5m2fnuz (AMD FNUZ FP8 formats).
    • The reader is now explicitly lenient about leading whitespace in the JSON header, which keeps the door open for future page-aligned writes.

    Improvements/perf

    • File writes on macOS now use F_NOCACHE for direct I/O, yielding roughly 30% faster save_file on Apple Silicon.
    • The packaging dependency has been dropped from the [torch] extra, replaced by a simple hasattr probe for efficiency.

    What's Changed

    New Contributors

    Full Changelog: v0.7.0...v0.8.0

    Open source →
  2. 0.7.0 19 Nov 2025
    Release notes

    What's new

    complex64 support

    This release adds support for storing complex64 tensors.

    What's Changed

    New Contributors

    Full Changelog: v0.6.2...v0.7.0

    Open source →
  3. 0.6.2 08 Aug 2025
    Release notes

    What's Changed

    • Fixing clippy in 1.89 by @Narsil in #644
    • Fixing the version check for uint support in torch. by @Narsil in #643

    Full Changelog: v0.6.1...v0.6.2

    Open source →
  4. 0.6.1 06 Aug 2025
    Release notes

    What's Changed

    New Contributors

    Full Changelog: v0.6.0...v0.6.1

    Open source →
  5. 0.6.0 23 Jun 2025
    Release notes

    Biggest changes

    • Added support for FP4/FP6 https://www.opencompute.org/documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf
      Support is still nascent in most frameworks (will require torch 2.8 which isn't released yet, and that will only support fp4 with caveats), however being an openspec supported by hardware manufacturers (and therefore hardware support most likely), it fits the bill of implementing it in safetensors (rather than all custom quantized formats existing in the wild in various frameworks.

      What FP4/FP6 mean, is that now a element of a tensor may have a non byte-aligned size/access. If you store a single fp4, then there is 4 bit on that byte that is outside of the spec. For now, safetensors library will simply raise MisalignedByte exception whenever an operation leads to unused/unaligned bits within a byte. Since most tensors are larger power of 2s, this shouldn't come up too often in practice. Raising an exception now means we have freedom later to actually implement a behavior which could align with tensor libraries.

      In that regard Dtype.size() is now deprecated, as it returns the size of the dtype in bytes, and we now favor bitsize() and it's up to users for now to handle something like len * bitsize() / 8 (and verifying the division is acceptable)

      On that note, and for Pytorch users specifically, torch doesn't actually implement fp4, it has a dtype called float4_e2m1fn_x2 which actually represents 2 fp4. This is why torch shouldn't have any alignement problems for now (but cannot implement fp6). But that also means that the shape of a [2, 2] tensor for floa4, contains actually 8 values. safetensors will actuallly silently cast a tensor of shape, [x, y, ...z] into [x, y, ..., z/2], using the last dimension to "swallow" , the x2 contained within the types. Again, there is no definite behavior just yet, so this might be subject to change.

    What's Changed

    New Contributors

    Full Changelog: v0.5.3...v0.6.0

    Open source →
  6. 0.5.3 26 Feb 2025

    Nothing published for this version

  7. 0.5.2 08 Jan 2025

    Nothing published for this version

  8. 0.5.1 07 Jan 2025

    Nothing published for this version

  9. 0.5.0 02 Jan 2025

    Nothing published for this version

  10. 0.4.5 05 Sep 2024

    Nothing published for this version

  11. 0.4.4 05 Aug 2024

    Nothing published for this version

  12. 0.4.3 15 Apr 2024

    Nothing published for this version

  13. 0.4.2 23 Jan 2024

    Nothing published for this version

  14. 0.4.1 27 Nov 2023

    Nothing published for this version

  15. 0.4.0 06 Oct 2023

    Nothing published for this version

  16. 0.3.3 23 Aug 2023

    Nothing published for this version

  17. 0.3.2 07 Aug 2023

    Nothing published for this version

  18. 0.3.1 25 Apr 2023

    Nothing published for this version

  19. 0.3.0 05 Mar 2023

    Nothing published for this version

  20. 0.2.8 16 Jan 2023

    Nothing published for this version

  21. 0.2.7 27 Dec 2022

    Nothing published for this version

  22. 0.2.6 13 Dec 2022

    Nothing published for this version

Every package, every release, already written down.

The archive is open and free. Watching your own project is what we are building next.

Browse the archive