AI開発のSSD・NAS設計 — モデルとデータを速く安全に置く

AI開発用PCを使い始めると、GPU性能より先にストレージの問題へ当たることがあります。複数のモデル、量子化版、展開した画像データ、コンテナイメージ、チェックポイントが積み重なり、「どれを消してよいか」が分からなくなります。

容量を増やすだけでは解決しません。原本データと再生成できるキャッシュが同じ場所にあり、final-v2のような名前でモデルを管理していれば、NASを追加しても混乱が広がります。

この記事では、データを役割で分類し、NVMe SSD、NAS、Git LFS、DVC、バックアップへ配置する設計をまとめます。

先に5種類へ分類する

ストレージ製品を選ぶ前に、保存するものを分類します。

種類	例	消えたとき	主な管理方法
コード・設定	Python、YAML、Dockerfile	Gitから復旧	Git
原本データ	画像、音声、CSV	再取得不能の場合がある	読み取り専用＋バックアップ
派生データ	リサイズ画像、特徴量、索引	再計算できる	パイプラインとキャッシュ
モデル	配布重み、学習チェックポイント	再取得・再学習コスト	モデルID、版、外部ストレージ
実験記録	メトリクス、ログ、図	比較と監査が困難	実験IDと保存期間

最も重要なのは、原本と派生データを分けることです。派生データは処理コードと入力があれば再生成できるため、容量不足時に削除できます。原本は削除できません。

「モデル」も2つに分けます。公開元から再取得できる配布重みはキャッシュに近く、自分の学習結果は再現コストの高い成果物です。同じ.safetensorsや.ggufでも保護の優先度が違います。

NVMe SSDは作業場所にする

内蔵NVMe SSDは、頻繁に読み書きする作業セットへ使います。

• 現在開発中のコードと仮想環境
• よく使うモデル
• 学習中のデータサブセット
• コンテナイメージとビルドキャッシュ
• 一時チェックポイント

速いストレージが効くのは、学習ループ中のデータ読み込みだけではありません。モデルの起動、環境作成、コンテナビルド、ノートブックの復旧も短くなります。

一方、全データを高速SSDへ永続保存する必要はありません。作業セットを定義し、終わった実験は成果物を別層へ移し、再生成可能な一時ファイルを消します。

ディスク使用量をディレクトリ単位で定期確認し、「残り10%になるまで気づかない」状態を避けます。モデルランタイムによって保存先が異なる点にも注意します。OllamaはOSごとの既定保存先と、OLLAMA_MODELSによる変更方法を公開しています[4]。

NASは保管庫であり、常に高速な作業ディスクではない

NASは大容量化、複数端末からの共有、冗長化に向きます。しかし、NAS上の数十万個の小さな画像をネットワーク越しに直接学習すると、GPUがデータ待ちになることがあります。

扱いやすいのは、次の流れです。

1. NASを原本と成果物の保管場所にする
2. 実験に必要な版をローカルSSDへ同期する
3. ローカルで前処理と学習を行う
4. メトリクスと必要なチェックポイントをNASへ戻す
5. 再生成可能なローカルキャッシュを削除する

NASの性能は、ドライブ本数だけでなく、ネットワーク、プロトコル、小ファイル性能、同時利用者で決まります。「10GbE対応」という一項目だけでは実効速度は判断できません。実際のデータセットとファイルサイズでコピー時間を測ります。

また、RAIDは可用性の仕組みであり、バックアップではありません。誤削除、ランサムウェア、NAS本体の故障、同期ミスは複数ディスクへ同時に反映されます。

Gitへ大きなデータを直接入れない

Gitはコードと小さなテキストの履歴に向いています。大きなバイナリは差分が効きにくく、削除しても過去の履歴に残ります。GitHubも大きなバイナリにはGit LFSを使い、プログラム生成物はGit外へ置くことを推奨しています[2]。

Git LFSは、リポジトリには小さなポインタを保存し、実体を別のストレージで管理します[1]。モデルファイルや少数の大きな成果物を、コードと同じコミットに対応づけたい場合に使えます。

ただし、次の点を確認します。

• 利用するホスティングの容量と転送量
• 共同開発者とCIへのGit LFS導入
• 大量ファイルのclone時間
• 公開リポジトリへ置いてよいライセンスとデータか

巨大なデータセット全体をGit LFSへ入れることが常に正解ではありません。アクセス方法、費用、データ保護要件に応じてオブジェクトストレージやDVCを使います。

DVCはデータの版と保存場所を分離する

DVCは、Gitで追跡するメタデータと、データ・モデルの実体を置くremote storageを分けます。公式ドキュメントでは、S3、Azure Blob Storage、Google Cloud Storage、SSH、NASなどをremoteとして利用できます[3]。

たとえば、コードのコミットAがデータ版AとモデルAを参照し、コミットBがデータ版Bを参照する形を作れます。チームメンバーは必要な版だけを取得でき、すべてをGit履歴へ入れずに済みます。

DVCが向くのは、次の条件です。

• データセットの版とコードを対応づけたい
• 前処理結果やモデルを複数人で共有したい
• NASとクラウドストレージを同じ操作で扱いたい
• 実験の入力を後から復元したい

一方、単に写真を保管するだけなら、DVCを入れる前に明確なディレクトリ名とバックアップを整える方が先です。ツールは、どれが原本かという運用ルールを自動では決めてくれません。

モデル名ではなく識別情報を保存する

model-final.ggufだけでは、数か月後に同じものを取得できません。最低限、次の情報をメタデータとして残します。

source: 配布元のリポジトリまたはURL
revision: コミットまたは公開版
filename: 元のファイル名
sha256: ファイルのハッシュ
license: 利用条件
quantization: 量子化方式
created_by: 変換コマンドまたは学習ジョブ

ハッシュは、名前が同じファイルの中身が一致するかを確認するために使えます。量子化した場合は、元モデル、量子化ツールの版、オプションを残します。

自分で学習したチェックポイントには、データ版、コードコミット、ハイパーパラメータ、評価結果も紐づけます。保存容量を抑えるために全ステップを残すのではなく、「最新」「最良評価」「節目」の保持ルールを決めます。

バックアップは復元テストまで含める

AI開発で失いたくないものは、容量の大きさと一致しません。公開モデルは数十GBあっても再取得できますが、手作業で付けた100MBのラベルは再現できません。

優先順位は次のように決めます。

1. 再取得できない原本とアノテーション
2. 再学習コストが高いモデル
3. 実験記録と設定
4. 公開元から再取得できるモデル
5. 再生成できるキャッシュ

バックアップは別ディスクにコピーした時点では完成しません。定期的に別の場所へ復元し、ファイル数、ハッシュ、アプリからの読み込みを確認します。暗号化して保存するなら、復号鍵の保管と復旧手順もテストします。

個人情報や顧客データでは、バックアップ先も同じアクセス制御と削除ポリシーの対象です。増分バックアップに残る過去版を含め、いつ完全削除されるかを把握します。

容量不足を自動で検知する

モデル取得や学習中にディスクが満杯になると、壊れたチェックポイントや中途半端なキャッシュが残ることがあります。次を監視します。

• ファイルシステムの使用率
• ディレクトリ別の増加量
• inodeまたはファイル数
• バックアップの最終成功時刻
• 未参照のチェックポイント
• コンテナとモデルキャッシュの容量

削除は自動化しすぎない方が安全です。最初は候補を一覧にし、人が原本でないことを確認してから消します。自動削除するのは、有効期限と再生成手順が明確なキャッシュに限定します。

古いPCを自宅AIラボへ再利用する場合も、サービスより先にデータ配置とディスク監視を決めると、サーバー停止の原因を減らせます。

小規模環境の現実的な配置例

保存先	置くもの
Git	コード、設定、データ定義、実験マニフェスト
内蔵NVMe SSD	現在の作業セット、仮想環境、キャッシュ
NASまたは大容量SSD	原本、過去成果物、共有モデル
DVC remote	コードと対応づけるデータ・モデルの版
別拠点・クラウド	復旧が必要な原本と成果物のバックアップ

この構成は、すべての人がNASを買うべきという意味ではありません。データが小さければ、外付けSSDと暗号化クラウドバックアップから始められます。AI開発用PCの選び方では、ストレージもGPUと同じく用途から逆算します。

まとめ

• コード、原本、派生データ、モデル、実験記録を先に分類する
• 内蔵NVMeは作業場所、NASは原本と成果物の保管場所として使い分ける
• RAIDをバックアップの代わりにしない
• 大きなバイナリを通常のGit履歴へ直接入れない
• Git LFSは大きなファイル、DVCはデータ・モデルの版管理に向く
• 再取得不能な小さなアノテーションを、大きな公開モデルより優先して守る
• バックアップは実際に復元できることを定期確認する

最初の改善は、容量追加ではなく「消して再生成できるもの」と「二度と作れないもの」を別ディレクトリへ分けることです。それだけで、ストレージ購入の必要量も明確になります。