ワークステーションのSSDを圧迫せずにローカルLLMモデルを保存する方法

小規模なホットセットはワークステーションのNVMeに置き、より大きなモデルライブラリは共有ストレージに保存し、すべての実行環境でパスを明示的に指定します。

この構成は、モデルの重みが主に起動時に読み込まれ、ネットワーク経由でも許容できる読み込み時間を確保でき、代替不可のファインチューニング済みモデルをダウンロード可能なファイルとは別に保護している場合に有効です。各キャッシュが気付かないうちに起動用SSDへフォールバックしたり、NASが利用できないと推論サービスがモデルを新しいローカルディレクトリへ再ダウンロードしたりすると、問題が起こります。

モデルファイルを作業セットと再構築コストで分類する

巨大なキャッシュディレクトリを丸ごと移動するのではなく、まずインベントリを作成しましょう。ベースウェイトや量子化されたバリエーションは再ダウンロードできる場合がありますが、アダプター、ファインチューニング済みモデル、プロンプトテンプレート、マニフェスト、評価結果、ローカルで変換したファイルは固有のものかもしれません。各項目をホット、ウォーム、コールド、または代替不可に分類し、どのアプリケーションがそのパスを使用するかを記録します。

ホットセットには毎日使うモデルを置き、決められたワークステーションの容量内に収めます。ウォームモデルはNASに保存し、プロジェクト開始前にローカルへコピーできます。コールドな実験用モデルは共有ライブラリのみに保存できます。元のモデルを再ダウンロードできる場合でも、代替できない出力はバージョン管理してバックアップする必要があります。

この分類により、よくある2つの間違いを防げます。再作成が容易な数百GBのデータをバックアップすることと、低コストで再作成できない小さなアダプターやマニフェストを削除してしまうことです。また、最初の容量の目安も得られます。すべてのモデルを試す場合の容量ではなく、ホットセットのサイズに、次のモデルを1つ追加できる空き容量を加えた値です。

ローカルNVMe、共有ストレージ、アーカイブの役割を割り当てる

実際のローカルAIクラスターで、モデルファイルをNASに保存し、10GbE経由で読み込んだところ、大容量の読み込みに適したネットワークとストレージ経路を設計すれば、この構成が実用的であることが示されました。このNASを利用したモデルサービングのワークフローから得られる重要な教訓は、役割を分けることです。共有ライブラリをソースとし、計算処理とメモリは推論ノードに置きます。

すべてのランタイムを同じ書き込み可能なネットワークフォルダーに向けないでください。変換の失敗、クリーンアップジョブ、バージョン変更によって、別のツールが使っているファイルまで変更されるおそれがあります。正規のライブラリは読み取り中心に保ち、変更は一時領域で行い、検証してから完成した成果物を意図的に反映します。

予測可能なモデルパスとキャッシュポリシーを構築する

Linuxでは/srv/models、Windowsでは固定のドライブ文字など、正規のマウント先を1つ決め、Ollama、vLLM、LM Studio、開発用コンテナの起動前に利用できる状態にします。各ツールのモデル設定とキャッシュ設定を明示的に指定します。シンボリックリンクを使う場合は、マウントの確認を先に実行し、再起動のたびにリンク先が変わらないようにしてください。

独立したNASの導入を検討するコミュニティの運用者は、モデルの読み込み時間が分かれ目になると繰り返し指摘しています。あるAIワークステーションとNASに関するディスカッションでは、大容量の重みは低速なリンク経由だと読み込みに数分かかることがあるため、よく使うモデルはローカルのNVMeに保存するよう提案されていました。

NAS全体をミラーリングするのではなく、ローカルのホットキャッシュには許可リストを使います。読み込みまたはコピーが成功したら、ファイルサイズかチェックサムを検証し、current/model-nameのようなアトミックなエイリアスを更新します。実行中でもピン留めされてもいないモデルだけを削除します。更新中にブートボリュームが満杯にならないよう、空き容量は15%か、想定される最大モデルのダウンロードサイズのどちらか大きい方を常に確保します。

Featured

ZimaCube 2 パーソナルクラウド ホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

すべてのダウンロードではなく、マニフェストとファインチューンを保護

ライブラリの再構築に必要な情報をバックアップします。ソースURLまたはリポジトリID、正確なリビジョン、ファイル名、量子化方式、チェックサム、ライセンスに関するメモ、ランタイム設定、本番環境で使用したパスを記録します。このマニフェストは小さく、検索しやすく、名前が曖昧なファイルが並ぶディレクトリより、復旧時に役立ちます。

独自のアダプター、マージ済みモデル、キャリブレーションデータ、評価結果は、通常の世代管理付きバックアップで保護します。公開されているベースウェイトについては、復旧時間を考慮して別のコピーを用意する価値があるか判断します。インターネット接続が遅い場合や、モデルが入手できなくなる可能性がある場合は、一部のウェイトを保護する価値がありますが、すべての実験をミラーリングすると、通常はバックアップ容量の無駄になります。

AIファイル向けの広範なファイルレイヤーがまだ決まっていない場合は、ZimaSpaceのAIファイル向けパーソナルクラウドとローカルPCストレージの比較が次の検討ステップです。永続的なソースデータやインデックスと、推論を実行するマシンを切り分けられます。

読み込み時間、オフライン時の動作、拡張の判断基準を検証する

モデルサービスを停止した状態で、ローカルのホットロード、NASからのコールドロード、NAS停止の3つの経路をテストします。最初に利用可能な応答が返るまでの時間、ネットワークのピークスループット、ワークステーションの実行前後の空き容量、ツールがブートディスク上にフォールバック用ディレクトリを作成するかどうかを記録します。マウント順序を想定ではなく実際に検証できるよう、再起動後にもテストを繰り返します。

日常的に使うモデルが想定時間内にローカルから読み込まれ、コールドモデルを手動でパスを編集せずにステージングでき、固有の成果物をバックアップから復元でき、NASが見つからない場合には、サイレントに再ダウンロードするのではなく明確なエラーが発生すれば、セットアップは合格です。実測したコールドロードの遅延が作業を妨げる場合に限り、ネットワークを高速化するか、より大容量のローカルストレージ層を追加します。正規ライブラリの空き容量が定めた下限に近づいた場合は、NASの容量を増やします。

モデルのシャード間を頻繁にシークする、起動時の低レイテンシを安定して確保する必要がある、またはNASがオフラインでも動作させる必要があるワークロードでは、ネットワークから直接読み込む方法をやめましょう。その場合もNASはライブラリとして維持し、起動前にモデル全体を、より大容量の専用ローカルSSDにコピーします。

最終セットアップのルール

正規モデルライブラリは共有ストレージに置き、日常的に使うモデルはローカルNVMeに固定し、使い捨てのキャッシュは分離し、再作成できない成果物とマニフェストだけを保護します。実測した読み込み時間または容量が、文書化したしきい値を超えた場合に拡張します。