模型層 開放閱讀

Safetensors

Safetensors

概念 ID
safetensors
更新時間
2026-05-29
來源數量
待補

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 頭部，直接決定了張量如何被解釋、記憶體如何分配。

引數型別/取值說明
dtype字串，如 "F16", "BF16", "F32", "F64", "I8", "I16", "I32", "I64", "U8", "BOOL" 等張量的數值精度型別。不同 dtype 決定了每個元素佔用的位元組數與算術特性。BF16 在大型模型權重中極為常見，可在保持與 FP32 相近的動態範圍的同時節省一半空間。
shape整數列表，如 [4096, 4096]張量的維度，長度與張量階數相同。載入時依據 shape 與 dtype 計算出該張量的總元素數。
data_offsets[start, end] 兩個整數張量在資料段中的位元組級起止偏移量。end - start 必須嚴格等於 shape 各維度乘積 × dtype 位元組數，否則為格式錯誤。支援零間隔排列，實現緊湊儲存。
__metadata__可選物件鍵值對，可由生成方填入架構標識、量化方案名、自定義版本號等，不參與張量反序列化，僅用於輔助工具鏈識別。
header_size (二進位制頭)64 位無符號整數本身不屬於 JSON，而是檔案的前 8 位元組。它告訴載入器需要讀取多長的 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 的生態運營，成為連線訓練端與多異質推論端的中間格式。

各技術路線的對比可以在以下維度展開：

維度SafetensorsPickle (.pt, .bin)ONNXGGUF
程式碼執行安全性極高（禁止任何程式碼執行）極低（任意程式碼執行）高（無程式碼執行）高（二進位制解析）
載入速度極快（mmap，並行 I/O）慢（物件圖重建）中等（圖解析、版本轉換）快（針對引擎最佳化）
跨架構通用性極強（語言、架構無關）弱（深度繫結架構）強（標準化運算元集）弱（專用引擎）
檔案體積與同精度原始權重等大基準可能更大（含圖結構）更小（支援內建量化）
主要用途安全權重分發、訓練-推論橋接訓練檢查點、快速原型推論部署、跨架構交換邊緣/桌面推論
生態成熟度高（Hugging Face Hub 事實標準）極高（PyTorch 原生）極高（行業標準）中（快速成長的開源社群）

上游

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 的普及在工程效率、安全合規或生態地位等方面直接或間接受益。此處僅描述事實，不構成任何形式的投資建議。

公司/機構受益邏輯上市情況
Hugging FaceSafetensors 作為其平台預設權重格式，鞏固了開放性 AI 基礎設施的領先地位，增強了開發者粘性，併為其企業版服務（如推論端點、企業 Hub）提供安全賣點。未上市，2023 年完成融資後估值約 45 億美元（來源：Hugging Face 官方揭露，2023 年 8 月）
Meta Platforms, Inc.通過在其開源模型（Llama 系列）中提供 Safetensors 版本，降低了社群使用其模型的安全顧慮，促進生態繁榮，間接鞏固其在開源大型模型領域的話語權。上市 (NASDAQ: META)
Stability AI早期因模型分發使用 pickle 格式引發安全爭議，全面轉向 Safetensors 後顯著改善了社群信任度，使其模型更易被商業使用者和安全敏感行業採納。未上市
Google (Alphabet Inc.)其 Gemma 等開放模型提供 Safetensors 權重，符合 Google 自身提倡的安全 AI 原則，減少了安全漏洞相關公關風險。同時，其雲端平台 Vertex AI 在服務開源模型時受益於更快的載入速度。上市 (NASDAQ: GOOGL)
Amazon (AWS), Microsoft (Azure)兩家公有雲端的 AI 服務需要安全、快速地部署海量開源模型，Safetensors 幫助降低因惡意模型導致的租戶間風險，並提升 GPU 例項週轉效率。上市 (NASDAQ: AMZN, MSFT)
AI 推論服務初創公司如 Replicate、Together AI、Fireworks AI 等，它們依賴極低延遲的模型載入以實現彈性伸縮；Safetensors 減少了冷啟動時間，直接降低執行成本。多未上市
AI 安全公司Protect AI、HiddenLayer 等將 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 已佔據主導地位，但仍有少量替代方案或並存格式，各自由不同背景的玩家推動。

玩家 / 格式立場與策略格式特色生態滲透程度
Hugging Face (Safetensors)以中立平台身份推廣安全標準，降低自身 Hub 的安全維護成本，提升開發者體驗。純資料容器、mmap、跨架構、禁止程式碼執行已成為 Hugging Face Hub 實際標準，PyTorch 官方支援，多架構適配
Meta / PyTorch 社群 (Pickle)Pickle 是 PyTorch 的原生序列化方式，短期內仍將繼續存在，用於訓練檢查點。但同時積極擁抱 Safetensors 作為分發終點。極為靈活，能序列化幾乎任意 Python 物件在訓練過程內部仍不可替代；社群正推動 default 安全載入，並推薦分發用 Safetensors
Linux Foundation AI / ONNX 社群 (ONNX)ONNX 主攻模型交換與部署標準化，權重安全只是其副產品。其格式基於 Protobuf，天然安全但對張量載入的最佳化不如 Safetensors。攜帶計算圖，可直接用於推論在跨架構推論部署中佔據穩固地位，尤其是邊緣和資料中心推論最佳化工具鏈中
llama.cpp 社群 (GGUF)GGUF 專為 LLM 推論極致最佳化，優先考慮 CPU/記憶體效率與量化方案，不追求通用權重容器定位。單檔案、內建量化等推論引數，零依賴在消費級 LLM 推論領域接近壟斷，但與其他生態介面有限
TensorFlow 生態 (SavedModel / HDF5)TF 的官方模型格式主要用於 TF Serving 和 TF Lite 管線，安全係數相對較高但封閉性強。與 Safetensors 不直接競爭，更多通過轉換橋接共存。架構原生，最佳化 TF 執行時在純 TF 生產管線中仍為主流，但跨架構影響力趨於減弱
Apple (Core ML / MLX)Apple 提供從 PyTorch/TensorFlow 到 Core ML 的轉換工具鏈，其 MLX 架構可直接讀取 Safetensors，並據此建置生態以吸引開源模型向 Apple 硬體遷移。深度繫結 Apple 硬體生態受益於 Safetensors 的無縫接入，快速擴充 Silicon Mac 上的可用模型庫

整體格局顯示，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 的產業滲透與健康狀況，可追蹤以下量化或定性指標：

指標說明資料來源建議
Hugging Face Hub 格式佔比Hub 上新增模型倉庫中，提供 .safetensors 權重的比例，以及平台預設下載格式的採用率。Hugging Face 年度/季度平台報告、官方部落格
主流架構原生支援程度PyTorch、TensorFlow、JAX、PaddlePaddle 等架構版本釋出說明中關於 Safetensors 匯入/匯出的更新。各架構官方 Release Notes
主要開源模型格式分佈追蹤 Llama、Mistral、Gemma、Falcon、Stable Diffusion 等頭部開源模型的官方權重格式。各模型官方倉庫與 Hugging Face Hub
模型載入速度基準測試社群或雲端廠商釋出的相同模型、相同硬體上，Safetensors 與 pickle 的載入延遲對比（GB/s）。技術部落格、雲端廠商文件、MLPerf 推論相關專案
安全事件關聯報告的涉及惡意模型權重的事件中，Safetensors 與 pickle 的各自出現頻率與影響程度。安全公司白皮書（如 Protect AI、HiddenLayer）、CVE 資料庫
工具鏈轉換活躍度safetensors 庫的 GitHub star 數、下載量、PR 合併頻率，以及下游專案（如 vLLM、candle）的整合度。GitHub 倉庫指標、PyPI 下載統計
監管/標準引用各主要經濟體 AI 安全法規、行業標準、雲端安全指南中是否明確提及或推薦使用安全序列化格式。法規文本、NIST AI 風險管理架構更新、ISO/IEC 相關標準草案

信源

  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 年。

相關推薦

同產業鏈：cloud

同產業鏈 · 相關公司

阿里巴巴BABA / 9988.HK百度BIDU / 9888.HKGoogle AlphabetGOOGL騰訊0700.HK亞馬遜 AWSAMZN字節跳動未上市Anthropic未上市CoreWeaveCRWV

相關概念

3D 高斯潑濺3D 生成Adapter TuningAgent 通訊協議Ahead-of-Time 編譯 (AOT)Attention With Linear Biases音訊 TokenAutogen
source: 公開揭露與公開資料整理 本頁僅用於產業鏈學習、資訊檢索和研究輔助；不構成投資建議，不預測漲跌，不提供買賣、部位或目標價建議。
完整概念頁 複盤 13 節結構 公司投研頁 沿產業鏈找到受益公司 投資課 把概念轉成可跟蹤模型