从模型仓库下载一个几 GB 的大模型文件，交给工具加载，听起来只是读数据。但老的权重格式有个隐患：文件里可以夹带代码，加载时会被执行。safetensors 这个格式的出发点很单纯——文件里只放数字，不带任何可执行逻辑，把数据和程序完全分开。
老格式的隐患从哪来
早期 Python 生态保存模型普遍走 pickle 这类序列化机制。它有个特性：加载文件时会执行文件里记录的指令。这本是为了方便，副作用是文件来源不干净时，加载一个模型就可能运行了作者塞进去的任意代码。对只想下载来用的人来说，这个风险本不该由用户承担。
safetensors 的存法：头信息加纯数字
它换了一种文件结构：文件头用一段 JSON 描述里面有哪些张量、各是什么形状和类型，后面紧跟着纯粹的数据本体。加载器只读数字，不存在执行环节——想夹带代码，格式上也没有位置可放。这也是它名字里 safety 的由来。附带的好处是加载更快：工具不用先跑反序列化逻辑，直接把数据映射进内存就能用，大模型的启动等待时间能省下不少。
你会在哪里遇见它
如今主流模型仓库的原始权重大多默认提供 .safetensors 文件。在 ModelScope 这类仓库浏览模型文件列表时，一排几 GB 的分片文件多半就是它。分片的名字里带 00001-of-00005 这类编号，只是把大文件切开方便传输，五片合起来才算完整模型。同一个模型常同时挂着多种格式：做训练、微调或在自建框架里推理，safetensors 是常见选择；想在本地用单文件跑起来，GGUF 更对口。两者不冲突，按工具链选就行。
| 文件情形 | 含义 | 建议动作 |
|---|---|---|
| .safetensors 后缀 | 只存数据不存代码 | 同等条件下优先选用 |
| .bin 后缀 | 老格式，可能含执行逻辑 | 来源可信可继续用，否则转格式 |
| 名字带 00001-of-00005 | 分片文件 | 下齐所有分片再合并加载 |
| 来源不明的压缩包 | 内容无法确认 | 不加载，先回官方发布页核对 |
下载与存档的三个习惯
先看来源：只认官方发布页，原作者上传的版本优先，第三方转载的文件多一道核对。再看后缀与大小：同等条件选 .safetensors；下载完对一遍文件体积，与发布页列出的数字对不上就重下。文件名里的 FP16、BF16 这类标记对应权重精度，决定体积和质量的基准线，选档前想清楚用途；要省显存另走量化那条路，和容器格式是两件独立的事。
自己动手训练或微调的话，存档导出同样建议用只存数据的格式，配合定期检查点，安全和进度两不误。训练流程里还有别的细节值得留意，比如为什么要先做 warmup，见什么是 warmup；训练消耗的算力怎么计量，见什么是 FLOPS。
它防住什么，防不住什么
safetensors 堵住的是「加载即执行」这一条路。它防不住的仍然存在：文件来源本身的可信度要靠渠道把关；模型内容层面的偏见与风险，换格式无关痛痒；下载环节的传输劫持，要靠核对体积与校验值来兜底。格式只是防护的一层，渠道选择永远排在格式之前。日常只用 DeepSeek、智谱清言这类在线应用的话，你接触不到这一层——格式与运维由服务方处理，服务可用性由他们的服务等级承诺约束，见什么是 SLA。
还没讲到的三个追问
用了 safetensors 就高枕无忧了吗？它只是移除了加载时执行代码的可能，文件来源仍要挑可信渠道，两层检查缺一不可。
手里的 .bin 文件要立刻处理吗？不必。来源可信、已经验证过的可以继续用；介意的话，主流框架通常一条转换命令就能换成新格式，转完核对体积。
safetensors 和 GGUF 能互转吗？多数场景可以，社区有成熟的转换工具，但转换前后要确认精度和量化档位没有变，体积对不上就别用。
权重文件速查
- 优先 .safetensors：只存数据，加载不执行代码
- 来源只认官方发布页，体积对不上就重下
- 分片要下齐，合起来才是完整模型
- 本地单文件运行选 GGUF，训练推理选 safetensors
