[Ecosystem] safetensors

[LysandreJik]

Contact emails

lysandre@huggingface.co

Project summary

Simple, safe way to store and distribute tensors

Project description

SafeTensors is a secure, fast file format for storing machine learning tensors.

It can be used as a replacement of torch.load and binds itself to underlying torch loading APIs; preventing arbitrary code execution while enabling zero-copy and lazy loading.

Files contain a JSON header with tensor metadata followed by raw data buffers. It speeds up distributed model loading significantly.

Key benefits:

• no code execution risk
• 100MB header limit for DOS protection
• faster multi-GPU loading
• cross-language compatibility via Rust and Python implementations

It is an Open-source under Apache 2.0, developed by Hugging Face.

Are there any other projects in the PyTorch Ecosystem similar to yours? If, yes, what are they?

No comparable library as far as I know

Project repo URL

https://github.com/huggingface/safetensors

Additional repos in scope of the application

No response

Project license

Apache 2.0

GitHub handles of the project maintainer(s)

danieldk,McPatate

Is there a corporate or academic entity backing this project? If so, please provide the name and URL of the entity.

Hugging Face

Website URL

huggingface.co

Documentation

huggingface.co/docs/safetensors

How do you build and test the project today (continuous integration)? Please describe.

on every commit, build rust, run rust tests, audit, code coverage, clippy, fmt on stable release for the following oses:

[ubuntu-latest, windows-latest, macOS-latest]

Performance regression check is run on every commit to main with pytest-benchmarking , we store the results of previous commits in GH actions/cache and add a comment on PR if an issue arises.

Documentation is built every commit to main.

For python, one CI to run tests, clippy, cargo audit of python bindings (py + rust code) on the following platforms:

          - os: ubuntu-latest
            version:
              torch: torch
              python: "3.13"
              numpy: numpy
              arch: "x64-freethreaded"
          - os: macos-15-intel
            version:
              torch: torch==1.10
              numpy: "numpy==1.26"
              python: "3.9"
              arch: "x64"
          - os: macos-latest
            version:
              torch: torch
              python: "3.12"
              numpy: numpy
              arch: "arm64"
          - os: windows-11-arm
            version:
              torch: torch
              python: "3.12"
              numpy: numpy
              arch: "arm64"and bonus separate platform:
  test_s390x_big_endian:
    runs-on: ubuntu-latest
    name: Test bigendian - S390X-> pytorch latest I assume for s390x

and lastly, release CI which builds on every platform - architecture permutation in the world, and when all is built pushes an artifact to pypi. release CI is run on every commit to main but only pushes to pypi when the commit has a tag associated with it.

ubuntu-latest, aarch64
ubuntu-latest, armv7
ubuntu-latest, ppc64le
ubuntu-latest, s390x
ubuntu-latest, x86
ubuntu-latest, x86_64
macos-14, aarch64
macos-15-intel, x86_64
ubuntu-latest, aarch64
ubuntu-latest, armv7
ubuntu-latest, x86
ubuntu-latest, x86_64
windows-11-arm, arm64
windows-latest, x64
windows-latest, x86

Version of PyTorch

1.10 at the moment

Components of PyTorch

Components of pytorch:

• from_file
• Tensor (.to , .narrow )
• UntypedStorage , ByteStorage

How long do you expect to maintain the project?

As long as machine learning is relevant! We're pouring significant resources in the project and consider it still early,

Additional information

No response

[jspisak]

Thanks for submitting @LysandreJik ! I went through the project and I see there are some things I couldn't verify or were missing. Can you take a look and see if we can close these?

✅ 1. PyTorch Support: Project must demonstrate benefit to the pytorch community and be validated with the latest versions of PyTorch.
✅ 2. Working CI: Projects must have a demonstrable working CI workflow for all declared architectures
🔴 3. Governance: Projects must have documented technical governance defined and implemented and it must be represented in their Github or Gitlab repository. Example: Review the LF’s Minimum Viable Governance framework.
✅ 4. User experience: The value proposition should be made clear for the project and documented in the README of the project repository.
✅ 5. Quick start: Project should have a working and demonstrable quick start.
✅ 6. Documentation: Projects must have clear and comprehensive documentation.
✅ 7. Permissive licensing: Users must be able to utilize ecosystem projects without licensing concerns. e.g. BSD-3, Apache-2 and MIT licenses
✅ 8. Functional Testing: Users should have developed tests submitted as a part of their project, and be confident that the project will work well with the latest releases of PyTorch.
✅ 9. Packages: Projects need to have support for binary installation options (pip/Conda).
✅ 10. Ongoing maintenance: Project maintainers must be committed to supporting and maintaining their projects for the next 12 months at a minimum. Projects must commit to updating their projects to the latest two releases of PyTorch (e.g. versions 2.6, 2.5.1).

Measurable Requirements:

🔴 1. Core Maintainers: The project must have a minimum of 2 core maintainers
🔴 2. Contributors: The project should have a minimum of 5 total contributors active in the last 90 days.
✅ 3. Commits: The project must have 30 commits in the last 90 days. This is off by like 15 days: it shouldn't be a deal breaker.
✅ 4. Stars: The project must have a minimum of 200 stars on github

Github Layout Requirements:

✅ 1. LICENSE.md at the root of the repository specifying the terms and conditions for using, distributing, and modifying the software. In addition, you should provide information on the license of any third-party code included in the project.
✅ 2. README.md welcomes new community members to the project and explains why the project is useful and how to get started. Should include information about release methodology, cadence, and criteria in the README.
🔴 3. CONTRIBUTING.md explains how to contribute to the project. The file explains the types of contributions needed and how the development process works.
🔴 4. CODEOWNERS that define individuals or teams responsible for code in a repository; document current project owners and Retired committers.
🔴 5. CODE_OF_CONDUCT.md sets the ground rules for participants’ behavior and helps facilitate a friendly, welcoming environment.

[LysandreJik]

Thank you Joe, I'm handling some of this here: huggingface/safetensors#712

I'll handle governance next.

[jspisak]

Thank you @LysandreJik ! Let me know if/how i can help..

[LysandreJik]

Hey Joe, we just merged two PRs in safetensors:

• Contribution guide security huggingface/safetensors#712
• Project Governance huggingface/safetensors#721

Hopefully this should satisfy the above!

[jspisak]

lgtm - ty @LysandreJik !