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

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Store Local LLM Models Without Filling the Workstation SSD - Zima Store Online

ワークステーションのNVMeには小さなホットセットを置き、より大きなモデルライブラリは共有ストレージに配置し、すべてのランタイムで明示的なパスを使用します。

この構成は、モデルの重みが主に起動時に読み込まれ、ネットワークで許容できるロード時間を実現でき、再取得可能なファイルとは別に、代替の利かないファインチューンを保護できる場合に機能します。一方、すべてのキャッシュが気付かないうちにブートSSDへフォールバックしたり、NASが見つからないと推論サービスがモデルを新しいローカルディレクトリへ再ダウンロードしたりする場合は破綻します。

モデルファイルをワーキングセットと再構築コストで分類する

巨大なキャッシュディレクトリを一度に移動するのではなく、まずインベントリを作成します。ベースウェイトや量子化バリアントは再ダウンロードできますが、アダプター、ファインチューン、プロンプトテンプレート、マニフェスト、評価結果、ローカルで変換したファイルは固有の場合があります。各項目をホット、ウォーム、コールド、または代替不能に分類し、そのパスをどのアプリケーションが所有しているかを記録します。

ホットセットには毎日使用するモデルを含め、固定したワークステーションの容量内に収めます。ウォームモデルはNASに置き、プロジェクトの前にローカルへコピーできます。コールドな実験用モデルは共有ライブラリだけに残せます。親モデルを再ダウンロードできる場合でも、代替不能な出力にはバージョン管理されたバックアップが必要です。

この分類により、再作成が容易な数百GBをバックアップすることと、安価には再作成できない小さなアダプターやマニフェストを削除することという、よくある2つのミスを防げます。また、最初の容量の目安も得られます。必要なのは、これまでにテストする可能性のあるすべてのモデルの容量ではなく、ホットセットのサイズに、受け入れるモデル1つ分の空き容量を加えた値です。

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

実際のローカルAIクラスターでは、モデルファイルをNASに保存し、10GbE経由で読み込んでいました。この例は、大容量の読み込みに合わせてネットワークとストレージ経路を設計すれば、この方式が実用になることを示しています。このNASを利用したモデル提供ワークフローから得られる有用な教訓は、役割を分離することです。共有ライブラリがソースとなり、計算処理とメモリは推論ノードに残します。

ストレージの役割	推奨コンテンツ	障害時の動作	制御方法
ワークステーションのNVMeホットティア	現在使用中のモデル、トークナイザーファイル、アクティブなランタイムキャッシュ	NASが利用できなくても推論を継続	厳格なサイズ上限と最終使用時刻が古いものからの削除
NASモデルライブラリ	承認済みのウェイト、量子化版、共有リビジョン	新規ロードは一時停止、メモリ上で稼働中のモデルは継続できる場合がある	読み取り中心の共有とチェックサム
保護されたプロジェクトストア	ファインチューン、アダプター、マニフェスト、評価結果	再構築の可否はバックアップに依存	スナップショットと独立したバックアップ
スクラッチ領域	不完全なダウンロード、変換中のファイル、一時的なシャード	安全に削除可能	自動期限切れの別パス

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

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

Linuxでは/srv/modelsのような正規マウントポイントを、Windowsでは安定したドライブレターを1つ選び、Ollama、vLLM、LM Studio、または開発用コンテナが起動する前に利用可能にします。各ツールのモデル設定とキャッシュ設定を明示的に指定します。シンボリックリンクを使用しても構いませんが、最初にマウント確認を実行し、再起動のたびに宛先が変わらないことが条件です。

独立したNASを検討するコミュニティの運用者は、モデルのロード時間を繰り返し判断基準として挙げています。あるAIワークステーションとNASに関する議論では、大きなウェイトは低速なリンク経由だと読み込みに数分かかることがあるため、頻繁に使用するモデルをローカルNVMeに置くよう推奨されていました。

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

Featured

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

ZimaCube2

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

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

固有のアダプター、マージ済みモデル、キャリブレーションデータ、評価結果は、通常のバージョン管理された保持ポリシーでバックアップします。公開されているベースウェイトについては、復旧時間に見合う別コピーが必要か判断します。インターネット接続が遅い場合や、モデルが入手できなくなる可能性がある場合は、選択したウェイトを保護する価値がありますが、すべての実験をミラーリングすると、通常はバックアップ容量を浪費します。

AIファイル層全体の方針がまだ決まっていない場合は、AIファイル向けのパーソナルクラウドとローカルPCストレージに関するZimaSpaceの比較が、次の計画段階になります。これは、永続的なソースデータとインデックスを、推論を実行するマシンから分離します。

ロード時間、オフライン動作、拡張のきっかけを検証する

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

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

モデルのシャード間を繰り返しシークするワークロード、予測可能で短い起動遅延が必要なワークロード、またはNASがオフラインでも動作しなければならないワークロードでは、ネットワークからの直接読み込みをやめます。その場合はNASをライブラリとして維持し、起動前に完全なモデルを大容量の専用ローカルSSDへコピーします。