ストレージやアプリを壊さずにローカルLLMを展開する方法

ホームNASでのローカルLLMの展開は難しくありません。最初のコマンドが難しいのではなく、モデル、キャッシュ、コンテナ、APIサーバー、バックグラウンドジョブが、NASがすでにファイル、バックアップ、メディア、データベース、アプリに使っている同じストレージとシステムリソースを競合するためです。

最も安全な目標は、初日からLLMをできるだけ速くすることではありません。安全な目標は、既知のストレージパス、厳格なリソース制限、限定的な並列処理、検証ルーチンを与えることです。少し遅いローカルモデルの方が、システムドライブを圧迫したりメモリ圧迫を引き起こしたり、他のセルフホストアプリを不安定にする速いモデルよりも通常は良いです。

ポイント：LLMに専用のスペースと制限を与える

ローカルLLMは、最初のモデルを持つ前に専用のスペースを持つべきです。つまり、モデルファイル、キャッシュ、インデックス、ログ、アプリデータがどこに保存されるかを、モデルのプルやWebUIの接続を行う前に把握しておく必要があります。これらのファイルが隠しDockerパス内や小さなブートドライブ上に置かれると、展開は成功しているように見えても、NAS自体に必要なスペースを静かに消費してしまいます。

また、制限も必要です。LLMのランタイムは、多くのRAM、VRAM、CPUスレッド、コンテキストメモリを使用することがあり、特に複数モデルや並列リクエストが有効な場合は顕著です。Dockerのリソース制約によると、コンテナはカーネルスケジューラの許可によりホストリソースを使用でき、メモリ圧迫は他のプロセスに影響を与えるOOM（メモリ不足）状態を引き起こす可能性があります。

共有NASの場合、ピークベンチマークの数値よりもこちらの方が重要です。Plex、Jellyfin、Home Assistant、データベース、同期ジョブ、バックアップ、ファイル共有が、モデルサーバーが長いプロンプトに答えようとして不安定になってはいけません。安全なローカルLLMの展開は、ストレージのマッピング、リソース制限、モデル選択、検証から始まります。

最初のモデルをプルする前に確認すべきこと

最初のモデルをダウンロードする前に、最初のジョブを定義してください。軽いチャット用のローカルLLMは、RAGアシスタント、埋め込みワーカー、コーディングヘルパー、またはファイルの読み書きができる自動化エージェントとは異なる要件があります。使用例を先に定義しないと、サーバーにとって大きすぎたり遅すぎたり、負荷が高すぎるモデルを引き込んでしまうことがあります。

まずはこれらの確認から始めましょう：

• 使用例：チャット、RAG、埋め込み、要約、自動化、コーディング、または検索支援。
• モデルサイズ：モデルファイルの大きさと複数バリアントを保持するかどうか。
• 量子化：モデルがサーバーに対して十分に圧縮されているかどうか。
• ストレージパス：モデルファイルとキャッシュがホスト上のどこに置かれるか。
• コンテナパス：ホストパスがコンテナ内にどのようにマッピングされているか。
• RAMとVRAM：他のアプリに残るメモリ容量。
• CPU余裕：NASを圧迫せずにモデルが使用できるスレッド数。
• 並列処理：同時に実行可能なリクエストやロード済みモデルの数。
• 既存のワークロード：バックアップ、メディアストリーミング、データベース、同期、ファイル共有。
• 検証計画：その後もNASが健全であることを証明する方法。

この事前確認ステップは単なる作業ではありません。NAS上で最も一般的なローカルLLMデプロイ問題を防ぎます。つまり、モデルは応答するものの、その周辺のシステムが信頼性を失う問題です。

モデルファイルはシステムドライブから分離して管理してください。

モデルファイルは予想以上に急速に増大することがあります。単一モデルは管理可能でも、複数のモデル、量子化バリアント、埋め込み、インデックス、WebUIデータ、ログが加わると、数十ギガバイトから数百ギガバイトに達することもあります。これらのファイルがシステムドライブやDockerルートに置かれると、メインのストレージプールがまだ健全に見えても、NASの重要な空き容量が不足する恐れがあります。

OllamaのFAQには、異なるOSごとのデフォルトモデル保存場所が記載されており、モデル保存ディレクトリはOLLAMA_MODELS環境変数で変更可能と説明されています。NASやホームサーバーでは、この点が重要です。なぜなら、デフォルトパスが長期間保存したいモデルファイルの場所として適切でない場合があるからです。

Ollamaや他のモデルランナーをDockerで実行する場合、コンテナパスはホストパスとは異なることを覚えておいてください。コンテナ内の/root/.ollamaのようなディレクトリは、予測可能なストレージを望むならホスト上の意図的な場所にマッピングする必要があります。ボリュームマッピングがないと、モデルファイルはDocker管理のストレージ内に残り、容量の増加が見えにくく、クリーンアップも難しくなります。

より安全な方法は、デプロイ前に専用のモデルディレクトリを作成することです。例えば、データプールやアプリストレージボリューム上のAIストレージフォルダなどです。バックアップ対象や重要なデータベース、取り返しのつかないアプリデータとは分けて管理してください。モデルディレクトリは十分な大きさがあり、簡単に確認でき、後で古いモデルを整理できるようにドキュメント化しておくべきです。

関連ファイルの保存場所も決めてください。RAGインデックス、埋め込み、ベクターデータベース、ログ、アップロードされたドキュメントは別のストレージ消費者になる可能性があります。モデルファイルだけを計画していると、AIスタックの他の部分に驚かされることがあります。

メモリ、CPU、並列処理の境界を設定しましょう

メモリ制限

ローカルLLMはメモリを大量に消費します。モデルの重み、コンテキスト、ランタイムオーバーヘッド、場合によっては複数のモデルの読み込みにメモリが必要です。サーバーがデータベース、メディアサービス、ファイル同期、コンテナ、バックアップジョブも実行している場合、LLMに利用可能なメモリをすべて使わせるべきではありません。

Dockerはコンテナのメモリ制限をサポートしており、1つのコンテナがホストを占有するのを防げます。共有NASの場合、これはモデルを速くするためというよりもシステム全体を保護するためです。LLMコンテナが自身の制限に達する方が、サーバー全体がメモリ不足に陥るよりも通常は良いです。

コアサービスのための余裕を残しましょう。NASに32GBのRAMがあり、通常のアプリがピーク時に8GBから12GBを使用する場合、残りすべてをLLMに渡さないでください。ファイルシステムキャッシュ、バックアップジョブ、データベース、短時間のスパイクのためのスペースを残しましょう。何も他に動いていない時だけ動作するモデルは、共有ホームサーバーの安全なデフォルトではありません。

VRAMもGPU推論に関わる場合は重要です。OllamaのFAQによると、CPU推論はシステムメモリを使用し、GPU推論はVRAMを使用し、同時モデル読み込みは利用可能なメモリまたはVRAMに依存します。つまり、GPUは大いに役立ちますが、メモリ計画の必要性はなくなりません。

CPU制限

CPU制限は応答性を保護します。ローカルLLMはプロンプト処理やトークン生成時に多くのスレッドを使用できます。CPUが飽和すると、NASのダッシュボードが遅延したり、メディアストリームがバッファリングしたり、自動化が遅れたり、データベースの応答が遅くなったりします。

Dockerは次のようなCPU制御を提供します --cpus, --cpu-quota、および --cpuset-cpus必ずしも厳しい制限が必要なわけではありませんが、通常のNAS稼働時にLLMがどれだけのCPUを使用できるかを決めるべきです。サーバーの応答性を保ちながら少し時間がかかるモデルの方が、すべてのスレッドを消費するモデルよりも適していることが多いです。

CPUのみの推論は特に制限に敏感です。GPUやNPUがない場合、LLMは他のすべてのCPU依存サービスと直接競合します。NASがすでにメディアのトランスコーディング、インデックス作成、圧縮、バックアップ、またはデータベースを処理している場合、ピーク時間中にLLMを無制限に実行すべきではありません。

モデル数と並列リクエスト

並列処理は見落としがちです。単一モデルが単一プロンプトに答えるだけなら問題ないかもしれませんが、複数ユーザー、WebUI、自動化ワークフロー、RAGツールが積み重なったリクエストをすぐに作り出します。各リクエストはコンテキストメモリとCPU負荷を増加させます。

OllamaのFAQは並列リクエストとロード済みモデルの動作について説明しており、OLLAMA_MAX_LOADED_MODELS、OLLAMA_NUM_PARALLEL、OLLAMA_MAX_QUEUEなどの設定が含まれます。これらの設定は、NASでの同時実行が安定した単一ユーザーの展開をリソーススパイクに変える可能性があるため重要です。

共有家庭用サーバーの場合は保守的な制限から始めましょう。1つのロード済みモデルと1つのアクティブリクエストが安全な基準です。ストレージ、メモリ、CPU、その他のサービスが安定していることを確認してから増やしてください。

話題に流されず、サーバーに合ったモデルを選ぶ

最適な最初のモデルは、ダウンロード可能な最大のモデルではありません。許容できる品質でタスクを完了できる最小のモデルです。NASでは、モデル選択がシステム保護の一部です。

量子化モデルは実用的な出発点であることが多いです。llama.cppは量子化モデルがモデルの重みの精度をどのように削減するかを説明しています。例えば、高精度のGGUFモデルファイルをより小さなフォーマットに変換します。これによりモデルサイズが小さくなり実用的な推論が向上しますが、品質のトレードオフも伴います。

このトレードオフは、多くの家庭用NASのユースケース、例えばシンプルなチャット、要約、埋め込み、RAG支援、ファイル整理、小規模な自動化ヘルパーには通常許容されます。深い推論、長いコンテキスト、複数ユーザーのパフォーマンス、高いコーディング精度が必要な場合はあまり適していません。

サーバーの状態を出発点として使用する：

安全な展開は小規模から始めることで安定した基準を得られます。その後、大きなモデル、長いコンテキスト、WebUI統合をテストできます。システムが遅くなったら、どの変更が問題を引き起こしたかがわかります。

LLMは重要なアプリやバックアップから離しておきましょう

ローカルLLMは、最も依存するサービスと障害境界を共有すべきではありません。AIモデルのストレージ、バックアップ、アプリデータベース、一時ファイルがすべて同じ計画不足の場所にあると、一つのワークロードが他に問題を引き起こす可能性があります。

モデルキャッシュやAIの一時データはバックアップ対象から離しておきましょう。モデルディレクトリは通常再現可能ですが、バックアップリポジトリはそうではありません。バックアップ先にモデルファイルや一時的なAIデータを詰め込むと、バックアップの失敗、同期ジョブの失敗、混乱した復元ポイントの原因になります。

可能な限りアプリのデータベースは分けておきましょう。Home Assistant、メディアサーバー、写真ライブラリ、パスワードマネージャーなどのセルフホストアプリは、突然のI/O圧力やディスク容量不足を嫌う小さなデータベースに依存していることがあります。大きなモデルのプルやRAGインデックス作成ジョブが同じストレージ領域を占有しないよう計画してください。

時間も考慮してください。バックアップが夜に行われるなら、同じ時間帯に重いインデックス作成をスケジュールしないでください。メディアストリーミングが夕方にあるなら、その時間にCPUのみの長文推論を実行しないでください。NASは複数のジョブを処理できることが多いですが、すべてのピークを同時に処理できるわけではありません。

ファイルを書き込んだりツールを呼び出したりできるLLMワークフローには、ガードレールを追加しましょう。サンドボックス化されたパス、確認ステップ、ログを使います。モデルにアクションを提案させつつ、書き込み、削除、移動、アプリ変更には決定論的なコードやユーザー確認を使いましょう。安全なLLM展開はシステムリソースだけでなく、触れるデータも保護します。

LLMが他のサービスのリソースを奪っている警告サイン

悪い展開は必ずしもすぐに失敗するわけではありません。多くの場合、最初は無関係に見える症状を引き起こします。

警告の一つは突然のディスク増加です。モデルをプルした後にシステムドライブ、Dockerルート、またはアプリストレージが急速に増加する場合、モデルパスが予想した場所にマッピングされていない可能性があります。コンテナパスだけでなく、実際のホストパスを確認してください。

コンテナの再起動も別のサインです。LLMコンテナ、データベース、Home Assistant、メディアサーバー、またはWebUIが繰り返し再起動する場合は、メモリ圧力、OOMログ、CPU飽和度を確認してください。LLMは生きていても他のサービスがリソースを失っているかもしれません。

遅いNASダッシュボードも重要です。プロンプト中にウェブUIが遅くなる場合、ローカルLLMがCPUスレッド、メモリ、またはディスクI/Oを使いすぎている可能性があります。モデルが正しく応答しても、展開が健全であるとは限りません。

メディアのバッファリング、遅延する自動化、遅いファイル共有、バックアップウィンドウの逸失はより強い兆候です。これらはNASの基本的な役割です。LLM導入後にこれらが劣化する場合は、より小さいモデル、厳しい制限、より良いスケジューリング、または別の計算ホストが必要です。

APIの挙動も監視してください。WebUI、RAGツール、自動化システムが接続したときにLLM APIがハングしたり、無限にキューイングしたり、信頼性が低下する場合は、サーバーに対して並列処理が多すぎます。統合を増やす前に、読み込むモデル数、アクティブなリクエスト数、キューの長さを制限してください。

NAS上のローカルLLMのより安全な展開順序

すべてのAIツールを一度にインストールして始めないでください。ローカルLLMサービス1つ、モデル1つ、ストレージパス1つ、テストユースケース1つから始めます。これにより展開が理解しやすく、デバッグも安全になります。

より安全な展開順序は次のようになります：

1. 軽いチャット、埋め込み、RAGテストなど1つのユースケースを選びます。
2. 仕事をこなせる最小のモデルを選びます。
3. 既知のストレージパスに専用のモデルディレクトリを作成します。
4. そのディレクトリをコンテナにマッピングするか、ランナーに使用するよう設定します。
5. メモリとCPUの制限を設定します。
6. 並列リクエストと読み込むモデル数を制限します。
7. まずは1つのテストプロンプトか1つの小さなRAGインデックスから始めます。
8. 実行中はディスク、RAM、CPU、GPU、ログ、応答時間を監視します。
9. 既存のアプリやバックアップが正常に動作し続けていることを確認します。
10. その後でOpen WebUI、RAGツール、自動化ワークフローなどの統合を追加します。

この順序はクイックインストールガイドより遅く感じるかもしれませんが、予期せぬ問題を減らします。何かが壊れた場合、問題がモデル、パス、リソース制限、WebUI、RAGインデックス、または他の統合のどこから来たのかがわかります。

ストレージとアプリがまだ安全であることを確認する方法

検証は「モデルが応答した」だけで終わってはいけません。ローカルLLMはプロンプトに答えながらも、誤ったディスクにデータを書き込み、他のコンテナのリソースを枯渇させたり、バックアップジョブを遅延させたりすることがあります。

まずはストレージの検証から始めます。モデルファイルが期待したホストパスに配置されていることを確認してください。システムドライブにまだ空き容量があるか確認します。Dockerのルートが予期せず増加していないかチェックします。モデルのキャッシュ、ログ、インデックス、アプリデータが重要なバックアップやデータベースと混ざっていないことを確認してください。

次にリソースを確認します。CPUはプロンプトやインデックス作成後に正常に戻るべきです。メモリは計画した制限以下に保つべきです。通常使用時にスワップが増加してはいけません。GPU推論が有効な場合は、モデルが実際にGPUを使用しているか、VRAMの負荷が許容範囲内かを確認してください。

次にアプリの安定性を確認します。ファイル共有を開き、メディアをストリーミングし、Home Assistantの自動化をトリガーし、NASのダッシュボードを閲覧し、データベースやアプリのダッシュボードがまだ応答していることを確認してください。これらのサービスがLLMがアクティブな間だけ遅延する場合は、CPU、メモリ、またはスケジューリングの制限を厳しくする必要があります。

ログを確認してください。再起動ループ、OOMメッセージ、モデルロード失敗、権限エラー、GPUアクセス欠如、ボリュームマウント失敗、繰り返されるAPIタイムアウトを探します。ログは「動作している」展開がかろうじて安定していることを示すことが多いです。

最後にエンドポイント境界を確認してください。モデルサーバーがAPIを公開している場合、それがどこでアクセス可能かを知っておくこと。ローカルLLMエンドポイントは誤って公開されるべきではありません。認証、リバースプロキシルール、VPNアクセス、または他の制御された境界の背後に意図的に配置しない限り、内部に保ってください。

ZimaOS AI検索が示す制御されたAI展開パターン

制御されたNAS AIワークフローは、定義されたモデルパス、リソース要件、実行期待値、検証パスを持つべきです。モデルをダウンロードし、GPU時間を消費し、好きな場所にデータを書き込む無制限のバックグラウンドサービスのように振る舞ってはいけません。

ZimaOS-AIはこの制御されたパターンの有用な例です。ZimaSpaceのAI検索ガイドは、このモジュールがローカルLLMを使って画像、音声、動画から特徴を抽出しZimaOS検索にサービスを提供するよう設計されていると説明しています。この枠組みが重要です：AIワークロードは検索と特徴抽出をサポートし、NASを無制限のチャットサーバーに変えるものではありません。

同じガイドはリソース境界を可視化します。NVIDIA専用GPUシステムとIntel統合GPUシステムの別々のインストールパスを説明しています。NVIDIAパスはCUDA対応GPUサポートに依存し、Intel統合GPUパスは最低8GBの空きRAMを必要とし、i5-1235U以上の統合グラフィックスCPUを推奨します。また少なくとも20GBの空きシステムスペースが必要で、モデルファイルはAppDataが移行されていなければ/media/ZimaOS-HD/AppData/.modelsに保存されると記載されています。

安全なLLM展開が開始される前に必要な情報はこれです。ZimaCube 2 AI NASのようなプライベートクラウドデバイスは、モデルパス、GPUまたはiGPUのサポート、RAM、ストレージ容量、スケジューリングがワークロードに合致すると、より豊かなローカルAIワークフローをサポートできます。しかし重要なのはブランド名ではなく境界線です：モデルがどこにあるか、どのハードウェアパスを使うか、いつリソースを消費してよいかを知ることです。

トラブルシューティングの詳細は展開検証の例も示しています。AI検索がAI関連の結果を返さない場合、モデルがまだダウンロード中、特徴抽出が進行中、Hugging Faceへのアクセス不可、またはVRAM不足でCPU/メモリフォールバックが発生している可能性があります。ガイドはまた、Call-History、ネットワークトラフィック、journalctl -xef -u zimaos-aiでの状態確認も案内しています。

これはNAS上のローカルLLM展開に役立つパターンです：パスを定義し、リソースを定義し、ログを監視し、機能が実際に動作することを確認し、重い処理はNASが使いやすい時間にスケジュールします。

よくある質問

NAS上のローカルLLMモデルファイルはどこに保存すべきですか？

モデルファイルは、十分な容量のあるデータボリュームやアプリストレージの専用かつ文書化されたモデルディレクトリに保存してください。モデルがブートドライブ、Dockerルート、バックアップ対象に無断で置かれるのは避けてください。パスは簡単に検査、整理、移行できるものであるべきです。

Ollamaは直接実行すべきですか、それともDockerで実行すべきですか？

どちらも可能です。Dockerは分離と展開を簡単にしますが、モデルストレージのマッピングとリソース制限の設定が必要です。直接インストールは一部のシステムで簡単かもしれませんが、モデルディレクトリ、権限、メモリ使用量、サービスの境界を確認する必要があります。

他のアプリ用にどれくらいのRAMを確保すべきですか？

NASのOS、ファイルシステムキャッシュ、データベース、メディアサービス、バックアップ、通常のコンテナ用に十分なRAMを確保してから、LLMにメモリを割り当ててください。モデルのサイズは総RAMに対してではなく、コアサービスに余裕がある後の利用可能RAMに対して決めてください。

ローカルLLMは他のDockerコンテナを壊す可能性がありますか？

LLMが過剰にメモリ、CPU、ディスクI/O、またはストレージ容量を消費すると、他のコンテナに影響を与える可能性があります。直接「壊す」わけではありませんが、制限なしに展開すると、動作の遅延、再起動ループ、OOMイベント、バックアップの失敗、データベース操作の失敗を引き起こすことがあります。

LLMを別のマシンに移すべきタイミングはいつですか？

より大きなモデル、長いコンテキスト、複数ユーザー、GPU負荷の高い作業、またはNASの動作を遅くする高速応答が必要な場合は、LLMを別のマシンに移動してください。その構成では、NASはストレージとデータソースとして残り、GPU対応のデスクトップ、ミニPC、またはAIサーバーが推論を担当します。

NAS上で安全なローカルLLMの展開は、境界設定から始まります。モデルの話題に流されず、モデルに既知のパスを与え、コンテナにリソース制限を設定し、重要なアプリやバックアップを保護し、最初のプロンプト後にサーバー全体を検証します。LLMが正常に動作し、NASが信頼できるNASとして機能し続けるときにのみ、展開は成功です。