Safetensors

3 秒看懂

Safetensors 是一种由 Hugging Face 提出并维护的、安全的张量序列化格式。它的核心设计目标是取代传统 PyTorch 生态中广泛使用的 pickle 格式，从根本上杜绝因加载模型权重文件而可能触发的任意代码执行风险，同时利用内存映射与零拷贝等优化，将大模型的加载速度提升数倍。

3 分钟产业解释

在人工智能工程化链条中，模型文件的保存、分发和加载是高频动作。传统做法通过 Python 的 pickle 协议序列化权重与优化器状态等对象，这虽然方便，却给安全埋下了致命隐患——反序列化时可自动执行内嵌的 Python 字节码，攻击者只需制作一个恶意模型文件，便能在研究人员或生产服务器的环境中远程执行命令，窃取数据或植入后门。随着千亿、万亿参数大模型的资产价值急速攀升，这一风险已从理论探讨变为真实的供应链攻击手段。

Safetensors 的出现标志着 AI 模型分发开始进入“安全原生”时代。它把模型的结构定义与权重数据彻底解耦：权重文件只保存纯粹的二进制张量内容和一份轻量的 JSON 元数据头，加载时仅做数据搬移，完全禁止代码执行。由于格式简洁，还能够直接利用操作系统的内存映射（mmap）机制，实现按需分页加载和多线程并行读取，使得几十 GB 的模型加载可从分钟级压缩到秒级。对云上推理服务的冷启动、大规模训练中的检查点恢复而言，这种速度优势直接转化为 GPU 闲置时间的减少与算力利用效率的提升。

产业层面，Safetensors 已成为 Hugging Face Hub 的事实标准，并被 Meta、Google、Stability AI 等机构的开源模型广泛采用。虽然它不能解决 AI 安全的所有维度，但在模型分发与部署这一最普遍的攻击面上，它给出了一个简洁且可验证的解决方案，并正在被纳入各国 AI 供应链安全合规的推荐工具箱。

技术原理

Safetensors 的设计遵循“数据与逻辑分离”的最小化原则，其文件结构与解析流程极简，从而同时获得安全性与性能。

文件结构 每个 .safetensors 文件由三部分顺序构成：

1. 头部长度（8 字节）：无符号 64 位小端整数，指代后续 JSON 头部的字节数。
2. JSON 头部（可变长度）：UTF-8 编码的 JSON 字符串，描述所有张量的元数据与在数据段中的位置。
3. 张量数据段：连续且无间隔的原始二进制张量值，按 JSON 头部中的偏移量排列。

+--------------------+---------------------+---------------------------+
| 8 bytes            | header_size bytes   | 剩余字节                   |
| 头部长度 (u64 LE)   | JSON 头部            | 张量数据 (raw bytes)       |
+--------------------+---------------------+---------------------------+

JSON 头部包含每个张量的名称、数据类型、形状以及数据在“数据段”中的起止字节偏移量，例如：

{
  "model.layers.0.self_attn.q_proj.weight": {
    "dtype": "BF16",
    "shape": [4096, 4096],
    "data_offsets": [0, 33554432]
  },
  "model.layers.0.self_attn.k_proj.weight": {
    "dtype": "BF16",
    "shape": [4096, 4096],
    "data_offsets": [33554432, 67108864]
  },
  "__metadata__": {
    "format": "pt"
  }
}

data_offsets 中的起止位置是相对于数据段起始字节的偏移量。__metadata__ 为可选字段，用于标记框架来源等信息，但不参与张量解析。

加载流程与安全保证 当程序调用 Safetensors 加载接口时：

1. 读取文件最开始的 8 字节，获得 header_size。
2. 继续读取 header_size 字节，获取 JSON 头部，并使用安全的 JSON 解析器（而非 eval 或 pickle）将其反序列化为字典。
3. 根据每个张量的 data_offsets 和 dtype、shape，通过内存映射或直接读取操作，从数据段提取原始字节并转换为对应类型的数组视图。

整个过程中，不执行任何来自文件内容的可执行代码，不创建任意 Python 对象，不调用可能执行额外逻辑的还原函数。即便攻击者构造了畸形的 JSON 头部，最坏结果也只是解析失败，而不会造成代码执行。

性能来源

• 内存映射（mmap）：加载器将文件映射到进程的虚拟地址空间，但实际不将全部内容读入物理内存。只有在程序访问某个张量时，操作系统才按页将对应磁盘数据加载到内存，这在加载大型模型时既能大幅降低内存占用，也规避了显式 copy 的开销。
• 并行读取：JSON 头部提供了所有张量的准确偏移量，多个线程可同时读取文件不同区域，充分发挥 NVMe SSD 等多队列设备的并行 I/O 能力。
• 零解析计算图：与 ONNX 等格式不同，Safetensors 无需重建计算图或推理节点，仅完成张量级别的映射，解析 CPU 时间几乎可以忽略。

关键参数

决定 Safetensors 文件结构与加载行为的核心参数集中在 JSON 头部，直接决定了张量如何被解释、内存如何分配。

这些参数的精简设计不仅让格式自描述，还使得读取库无需依赖重量级序列化框架，一份几百行的 Rust 或 C 代码即可实现完整解析器，轻易集成到移动端、WebAssembly 等受限环境。

技术路线

从模型存储与交换的角度看，业界曾经或正在演进的路线可归纳为四大类。Safetensors 代表了一种“纯数据 + 元信息头”的路线，相比其他路线，在安全与速度的综合平衡上具备独特优势。

1. “代码即对象”路线（传统 Pickle） 基于 Python 的 pickle 协议，直接将 Python 对象图序列化为字节流。优势在于灵活——几乎任意 Python 对象（包括自定义类、函数、优化器状态）都可保存与恢复。但代价是安全边界彻底消失，反序列化等同于执行不受信任的代码；同时，复杂的对象图重建带来显著的 CPU 开销和内存峰值，难以并行化。

2. “计算图优先”路线（ONNX、TorchScript 等） ONNX 将模型表示为标准化的计算图，包含算子定义、节点连接与初始权重。安全方面，ONNX 使用 Protocol Buffers 与固定算子集，通常不涉及代码执行，安全性较高；但它的重心在于描述计算逻辑，导致文件体积可能膨胀，加载时需要执行图验证、版本转换等额外步骤，且对非标准算子或动态结构的支持有限。更多是推理部署格式而非单纯的权重容器。

3. “推理专用精简二进制”路线（GGML / GGUF） GGML 最初为 llama.cpp 设计，强调在消费级 CPU 上实现高效推理。GGUF 作为其后继格式，将元数据与权重统一在单个文件中，内置量化参数、分词器信息等，极适合边缘设备与个人电脑加载大语言模型。然而，这类格式高度耦合于特定推理引擎和一套预设的模型架构解析方式，通用权重交换能力有限，跨框架兼容性弱。

4. “安全数据容器”路线（Safetensors） 该路线聚焦于一点：只做安全的张量容器，不关心模型结构、计算图或推理逻辑。Safetensors 对张量零依赖、对框架零绑定，任何能够读懂二进制和 JSON 的语言都可以完整读取。这种“做一件事并做到极致”的哲学，使其成为模型分发环节的最小公约数，再配合 Hugging Face 的生态运营，成为连接训练端与多异质推理端的中间格式。

各技术路线的对比可以在以下维度展开：

上游

Safetensors 的上游主要包括模型训练框架与模型生产方、格式转换基础设施。

模型训练框架

• PyTorch：2024 年起官方 torch.load() 已内置对 Safetensors 的读取支持，torch.save() 亦可直接导出该格式。训练过程中保存优化器状态等复杂对象时仍常用 pickle，但官方推荐分发时使用 Safetensors。
• TensorFlow / Keras：通过 tf.saved_model 保存的模型权重可经由转换脚本输出为 Safetensors，社区已提供成熟工具。
• JAX：其基于 flax 或 haiku 的权重可以用 Python dict 形式导出，再由 Safetensors 库直接写入，通常只需两行代码。
• 其他框架：如 PaddlePaddle、MindSpore 等，社区已有第三方适配，部分推理引擎直接集成了 Safetensors 解析器。

模型开发与分发机构

• Hugging Face：本身即是最大的上游，平台上由社区贡献的数十万个模型仓库，绝大多数已将 Safetensors 作为默认权重格式。
• Meta：在 Llama 2、Llama 3 系列的官方仓库中，除原始 PyTorch 格式外，均提供了 Safetensors 版本的权重，显示其对安全分发的重视。
• Google：Gemma 等开放模型在 Hugging Face 上提供 Safetensors 格式，内部模型对外发布时也开始采用。
• Stability AI：Stable Diffusion 系列模型的权重普遍以 Safetensors 分发，避免了早期单文件 pickle 权重在社区引发的安全争议。
• 其他独立研究机构与个人开发者：由于 Hugging Face Hub 的上传指引强烈建议使用 Safetensors，新增模型大部分为原生 Safetensors 格式。

格式转换与工具体系 上游的关键支撑层是 safetensors Python 库本身，以及集成到 transformers、diffusers、accelerate 等主流库中的自动转换逻辑。用户调用 model.save_pretrained("path", safe_serialization=True) 即可直接写出安全的权重文件，极大降低了切换成本。

下游

Safetensors 的下游几乎覆盖了所有需要加载模型权重的场景，形成了从训练后到服务上线的安全、高效流水线。

推理即服务（Inference-as-a-Service）平台

• 云厂商的模型托管服务（如 AWS SageMaker、Azure AI、Google Vertex AI）在部署开源模型时，底层加载推荐使用 Safetensors，可显著缩短推理节点的冷启动时间。
• 第三方推理服务商（如 Replicate、Together AI、Fireworks AI）的模型容器几乎都优先从 Safetensors 文件加载权重，以在高并发场景下快速扩缩容。

应用开发者

• 在企业内部构建 AI 应用的团队，通过 Hugging Face 的 transformers、diffusers 等库，可以透明地加载 Safetensors 权重，无需关心底层格式差异。
• 对于使用自定义推理栈的团队（如基于 Rust 的 candle、Python 上的 vLLM、llama-cpp-python 等），Safetensors 提供了直接读取张量的 API，允许将权重快速导入自有数据结构，而不依赖 PyTorch 等全家桶。

边缘与端侧部署

• 端侧推理引擎（如 MLX、ExecuTorch、MediaPipe 等）往往希望最小化依赖。Safetensors 的 C/Rust 实现体积小，可嵌入移动应用或 IoT 设备，方便将云端训练好的权重安全转移到设备上。
• 与 GGUF 等格式的关系：通常流程是云端以 Safetensors 保存 FP16/BF16 主干权重，再由工具链进行量化并转为 GGUF 等格式，为不同硬件生成专用文件。Safetensors 充当了“安全源头”的角色。

安全审计与合规工具

• 企业安全团队在接纳外部模型前，可以先用 Safetensors 转换并扫描，确保文件不包含任何可执行代码，降低审计复杂度。
• 一些 AI 供应链安全平台（如 Protect AI 的 modelguard）直接将是否为 Safetensors 格式作为模型风险评分的一个维度。

受益公司

以下公司/机构因 Safetensors 的普及在工程效率、安全合规或生态地位等方面直接或间接受益。此处仅描述事实，不构成任何形式的投资建议。

市场规模

目前没有“Safetensors 市场规模”的直接统计数据，因为该格式本身为开源、免费的技术标准。但可以从模型存储与分发所嵌入的几个相关市场进行推理。

• MLOps 平台市场：据 MarketsandMarkets 2023 年报告，全球 MLOps 市场规模预计从 2023 年的 19 亿美元增长到 2028 年的 93 亿美元，年复合增长率约 37%（口径：含模型注册、部署、监控等软件与服务）。模型格式转换、版本管理、安全分发是 MLOps 的核心组件，Safetensors 作为推荐格式，其采用量将随该市场同向扩张。
• Hugging Face Hub 模型仓库与下载量：Hugging Face 于 2024 年公开分享，Hub 上模型仓库数量已超过 80 万个（口径：含所有公开与私有仓库），且大部分新增模型推荐或默认使用 Safetensors 格式。2024 年 8 月，其官方博文提到，通过 transformers 库加载的模型权重中，Safetensors 格式的调用占比已超过八成。虽然这并非直接财务数字，但反映了该格式在 AI 开发者群体中的支配性份额。
• AI 安全市场：Gartner 在 2023 年的新兴技术雷达中，将 AI 供应链安全标记为高优先级，全球 AI 安全相关支出预计在 2026 年突破 80 亿美元（来源：Gartner 预测，2023 年 10 月）。采用安全模型格式是防范权重投毒、后门植入的基础措施之一，Safetensors 作为该领域的事实标准，其背后隐含的商业价值随合规需求增长而放大。

公开资料未见关于 Safetensors 的直接市场收入、产能或财务数字，因其以开源基础设施的形态存在，商业价值通过平台生态、推理成本和合规成本节约的方式间接体现。

玩家对比

在“安全模型权重容器”这一细分赛道上，Safetensors 已占据主导地位，但仍有少量替代方案或并存格式，各自由不同背景的玩家推动。

整体格局显示，Safetensors 并非要取代所有格式，而是作为“安全、高速的权重交换层”被广泛配置在各生态的上游和下游之间，成为一个各方共识的中间表示。

风险

尽管 Safetensors 优势突出，其发展与应用仍面临若干值得关注的风险。

• 格式演进与生态碎片化风险：Safetensors 规范目前由 Hugging Face 主导，虽然开源，但核心贡献者集中。若未来不同参与方因定制需求而产生不兼容的分叉（fork），可能导致生态碎片化，削弱其作为通用交换格式的价值。
• 竞争对手的替代格式风险：PyTorch 社区正在探索更安全的默认序列化后端（例如将安全特性直接嵌入 torch.save），如果未来 PyTorch 官方推出具有同等安全性和极致性能的新格式，Safetensors 的必要性可能被稀释。此外，ONNX 若在后续版本中大幅简化纯权重加载并内置 mmap 支持，也可能形成竞争。
• 过分依赖 Hugging Face 平台：目前 Safetensors 几乎与 Hugging Face Hub 强绑定。若未来平台因商业策略变化而调整格式策略，或者开发者大规模迁移至其他模型共享平台（如 ModelScope、自建仓库），Safetensors 的普及速度可能受到冲击。
• 安全认知的单一维度依赖：Safetensors 消除了加载阶段的代码执行攻击面，但可能使用户放松对其他攻击向量的警惕。例如，恶意架构代码、篡改的元数据字段（若下游有不安全的 JSON 使用方式）、或在训练阶段植入的后门权重，都可以绕开 Safetensors 的安全屏障。过度宣传可能形成“安全即 Safetensors”的错觉，反而增加系统性风险。
• 量化与压缩场景的兼容性：Safetensors 本身不定义量化参数，需要在元数据中扩展或依赖外部配置。在 GGUF 这样高度集成的格式面前，对于量化模型的“开箱即用”体验较弱，可能在端侧极端性能追求的场景下被跳过。
• 大文件管理的工程挑战：对于 TB 级别的多文件权重，基于 mmap 的加载虽然高效，但仍要面对文件系统页缓存策略、网络存储延迟等问题。跨节点、跨云的权重分发方案尚需与对象存储等基础设施更好磨合，这部分工程复杂度较高。

上述风险并不意味着 Safetensors 会被轻易替代，但它们显示了在快速演进的 AI 基础设施中，任何单一格式都需持续演进以保持其定位。

误读纠偏

• 误读 1：“Safetensors 是一种模型压缩格式，能让模型文件显著变小。” 纠偏：错误。Safetensors 不做量化、不进行熵编码。它与存储相同精度权重的 pickle 文件体积几乎完全一致。它的速度来自高效的 I/O 和零拷贝内存映射，而非文件缩小。如果需要更小体积，需额外使用量化工具，再将量化后的张量存入 Safetensors 文件。
• 误读 2：“一旦使用 Safetensors，就再也不用担心模型安全问题。” 纠偏：不全面。Safetensors 消除了“加载权重文件即触发恶意代码执行”这一严重的攻击向量，但不等于模型本身值得信赖。恶意微调的后门模型、带有有害生成倾向的权重、或者在模型结构代码中包含恶意逻辑，依然可以构成威胁。应将 Safetensors 视为多层供应链防御中必要但不充分的一环。
• 误读 3：“所有场景都应立即切换至 Safetensors，抛弃 pickle。” 纠偏：需根据场景权衡。在模型分发、共享、部署和推理环节，切换到 Safetensors 是强烈推荐的最佳实践。但在训练循环内部，频繁保存包含优化器状态、学习率调度器、随机数状态等复杂 Python 对象的检查点时，pickle 或其他框架原生方案仍是更成熟、兼容性更广的选择。通行做法是训练时保留框架原生检查点，最终发布权重时转为 Safetensors。
• 误读 4：“Safetensors 只能用于 Hugging Face 的 transformers 库。” 纠偏：错误。Safetensors 是完全独立于 Hugging Face 生态的开放格式，拥有 Python、Rust、C++、Go 等多语言实现，可以直接读取任何符合规范的张量文件。许多不使用 transformers 的推理框架（如 vLLM、candle、llama.cpp 的 Python 绑定）都提供了基于 Safetensors 的加载路径。Hugging Face 只是其最大的生态推动者，并非唯一使用者。

最新事件

（本节主要基于截至 2025 年 4 月的公开信息，无法穷尽所有变动。）

• 2024 年上半年：Meta 发布 Llama 3 系列模型，在其官方仓库同时提供原始 PyTorch 格式和 Safetensors 格式权重，社区反馈积极，进一步巩固了 Safetensors 作为大模型分发标配的地位。
• 2024 年第二季度：Hugging Face 更新 Hub 上传指引，明确推荐优先使用 Safetensors，并将新模型仓库默认模板改为该格式。同年，Hugging Face 博客披露，通过 transformers 库下载的权重中 Safetensors 调用占比已超过 85%（来源：Hugging Face 博客，2024 年 7 月）。
• 2024 年第三季度：PyTorch 2.4 版本增强了 torch.load 的安全模式，当检测到权重文件为未知来源时，会提示用户优先使用 Safetensors 并给出转换建议。Stability AI 在其 Stable Diffusion 3 模型发布时，彻底弃用 pickle 权重，仅提供 Safetensors 版本。
• 2024 年第四季度：AI 供应链安全公司 Protect AI 发布报告，指出模型仓库中使用 pickle 格式的新增恶意模型数量环比上升，但成功感染的概率因自动扫描与 Safetensors 的推广而下降，称 Safetensors 作为“最低安全基线”作用显著。
• 2025 年初：部分公有云厂商（AWS、Azure）在各自的 AI 服务最佳实践文档中，将“采用 Safetensors 等安全格式”列为模型入驻和分发的正式安全建议。个别开源许可证合规工具也开始标记仅提供 pickle 格式的模型为“需额外审查”。
• 持续演进：Safetensors 规范仓库的 issue 和 PR 活跃，社区正讨论增加可扩展的量化参数元数据字段，以更好衔接 GGUF 等格式，但暂无正式发布。公开资料未见 Safetensors 被任何主要机构宣布弃用或出现重大安全漏洞。

跟踪指标

为持续观察 Safetensors 的产业渗透与健康状况，可跟踪以下量化或定性指标：

信源

1. Safetensors 官方仓库与规范：Hugging Face, “Safetensors”，GitHub，https://github.com/huggingface/safetensors （含格式规范、参考实现与变更日志）。
2. Hugging Face 官方博客：多篇文章关于 Safetensors 发布、安全加载、Hub 推荐策略。例如 2023 年 3 月“Safetensors: a simple, safe way to store and distribute neural network weights”。
3. Meta Llama 官方仓库：Meta Llama 3 模型卡及 Hugging Face 仓库，体现 Safetensors 权重的提供。
4. PyTorch 官方文档：torch.load 安全模式与 Safetensors 集成说明，PyTorch 2.4 Release Notes。
5. Stability AI 官方 Hugging Face 仓库：Stable Diffusion 3 权重格式说明。
6. AI 安全公司报告：Protect AI, “MLSecOps Landscape” 及季度威胁报告；HiddenLayer 相关威胁情报。
7. 云厂商最佳实践文档：AWS “Security in Amazon SageMaker AI” 中关于模型格式的建议；Azure AI 安全文档相关章节。
8. 市场研究：MarketsandMarkets, “MLOps Market – Global Forecast to 2028”, 2023。Gartner, “Emerging Tech Impact Radar: AI”, 2023。
9. 框架集成：vLLM、candle、llama.cpp 等项目文档中 Safetensors 加载的相关代码与说明。
10. 监管动向：欧盟 AI 法案 (EU AI Act) 关于供应链安全的相关条款讨论；NIST AI RMF Playbook 更新草案。
11. 公开新闻与分析师报告：TechCrunch、VentureBeat 等科技媒体对 Hugging Face 融资及 Safetensors 生态的报道，2023—2025 年。