オープンソースMLの世界で「当たり前」になったファイル形式が、その所有権をコミュニティに正式に引き渡した。Hugging Faceが開発したモデルウェイト保存形式「Safetensors」が、Linux Foundation傘下のPyTorch Foundationのホスト型プロジェクトとして正式に参加することが発表された。DeepSpeed、Ray、vLLMといったMLエコシステムの主要コンポーネントと肩を並べる存在になったことは、この形式がすでに業界標準であることの証明だ。

なぜSafetensorsが生まれたのか——picklの亡霊

話は少し前に遡る。PyTorchをはじめとする従来のMLフレームワークでは、モデルのウェイト（重み）保存にPythonのpickle形式が広く使われていた。pickleは汎用シリアライズ形式であり、デシリアライズ時に任意コードを実行できるという根本的な問題を抱えている。研究室内で使い回す分には許容されてきたが、Hugging Face Hubのようなプラットフォームで何万人もがモデルを共有し合う時代になると、悪意ある.ptファイルを踏むだけでリモートコード実行（RCE）につながりかねない状況になっていた。

Safetensorsはこの問題をシンプルな設計で解決した：

  • JSONヘッダー（上限100MB）: テンソルのメタデータ（名前・dtype・shape・オフセット）のみを記述。コードは一切含まれない
  • 生バイナリデータ: ヘッダー直後に各テンソルの生データを連続配置
  • ゼロコピーロード: mmapでディスクからテンソルを直接メモリにマッピング。不要なコピーが発生しない
  • レイジーロード: チェックポイント全体をデシリアライズせず、必要なウェイトだけを個別に読み出せる

この設計により、形式の解析がコードの実行を意味しないというセキュリティの第一原則が守られる。Hugging Face Hubでの標準配布形式になったのは当然の流れだった。

ベンダー中立化の意味——「Hugging Faceのもの」から「みんなのもの」へ

今回の移管で何が変わるのか。ユーザー視点ではほぼ何も変わらない。APIも形式仕様も後方互換性も維持される。既存のモデルファイルは引き続きそのまま動く。

変わるのはガバナンスと所有権だ。商標・リポジトリ・プロジェクトガバナンスがLinux Foundationに移る。Hugging Faceの2名のコアメンテナーはTechnical Steering Committeeに残り、日常的な開発リードを続けるが、今後はより広いコミュニティや企業が意思決定に参加できる。GOVERNANCE.mdとMAINTAINERS.mdでメンテナーへの道が明文化されたことで、企業・個人を問わず貢献の入口が開かれた。

これはMLエコシステムが成熟した証だ。かつてはHugging Faceという一企業のプロジェクトだったものが、インフラレベルの存在になった——そのタイミングで所有権をコミュニティに渡すのは、責任ある決断といえる。

次のロードマップ——量子化・並列化時代への対応

Safetensorsの開発はここで止まらない。発表には今後の方向性も示されており、注目すべきポイントがいくつかある。

PyTorchコアへの統合: PyTorchチームと協力し、torchモデルの標準シリアライズシステムとしてSafetensorsを採用する動きが進んでいる。実現すれば、PyTorchユーザーがデフォルトで安全な形式を使う世界になる。

デバイスアウェアロード: テンソルをCPUを経由せず、CUDA・ROCm等のアクセラレーターに直接ロードする機能。GPUメモリへの転送オーバーヘッドが削減され、大規模モデルの起動時間短縮につながる。

並列ロードAPI: Tensor Parallel・Pipeline Parallelに対応した一級APIの整備。マルチGPU環境で各ランクや各パイプラインステージが必要なウェイトだけをロードできる仕組みは、100B超のモデルを実用的に動かすために不可欠だ。

量子化形式の正式サポート: FP8、GPTQ・AWQといったブロック量子化形式、サブバイト整数型への対応。推論コスト削減のために量子化モデルが普及している現在、標準形式がこれらをネイティブサポートすることの意義は大きい。

実務への影響——エンジニア・IT管理者が押さえるべきこと

モデルダウンロードはSafetensors形式を優先する: Hugging Face Hubからモデルを取得する際、.safetensorsファイルが存在するなら積極的に選ぶべきだ。transformersライブラリはデフォルトでSafetensors形式を優先するが、古い環境やfrom_pretrainedのオプション指定によってはpickle形式（.bin）が使われることがある。セキュリティポリシーとして「pickleは使わない」を明文化することを推奨する。

企業内MLプラットフォームの標準化に活用: 社内で独自のモデルレジストリを構築・運用している場合、Safetensors形式を保存フォーマットの標準として採用することで、サプライチェーン攻撃のリスクを大幅に低減できる。

PyTorchコア統合を見越した依存管理: 今後PyTorchがSafetensorsをコア機能として取り込んだ際に、バージョン依存関係が変わる可能性がある。safetensorsライブラリのバージョンはrequirements.txtやpyproject.tomlで明示的に管理しておくと後々の移行コストが減る。

量子化モデルを使った推論コスト削減: GPTQ・AWQ等の量子化形式への公式サポートが整備されれば、GPU推論コストの削減がさらにやりやすくなる。今から量子化モデルの評価を始めておくと、サポート本格化のタイミングで素早く移行できる。

筆者の見解

SafetensorsのPyTorch Foundation移管は、地味に見えて実は重要なニュースだ。

オープンなモデル共有の文化は、AIの民主化において不可欠な基盤だ。しかし、その「オープン」が「危険なファイルを踏む可能性」と引き換えになっていた時代があったことを、改めて思い出す必要がある。Safetensorsはその問題をエレガントに解決した——コードを実行できない形式を作ることで。この判断の正しさは、今やHugging Face Hub上の数万のモデルが証明している。

AIエコシステムが本当に成熟するには、こういった「当たり前に安全なインフラ」が増えていくことが欠かせない。自律的に動くエージェントが外部からモデルをロードし、タスクを遂行するシナリオが現実になってきた今、モデルファイル自体にマルウェアが仕込まれる攻撃ベクターは無視できない。Safetensorsはその脅威に対する、生態系レベルの答えだ。

量子化形式への対応強化やデバイスアウェアロードといったロードマップは、AIが「実験」から「本番運用」のフェーズに本格的に入ってきたことを示している。標準形式がパフォーマンスと安全性の両方を担保してくれる世界は、AIシステムを「仕組みとして回す」ことを目指すエンジニアにとって、確実に追い風になる。

プロジェクトが特定企業の所有から真のコミュニティ資産に移行したこのタイミングは、Safetensorsが次のフェーズに向かう転換点として、後から振り返ることになるだろう。

出典: この記事は Safetensors is Joining the PyTorch Foundation の内容をもとに、筆者の見解を加えて独自に執筆したものです。