AI NAS ハードウェア要件：CPU、RAM、GPU、ストレージ、ネットワーク

簡単な回答

AI NASのハードウェア要件はワークロードに依存し、AI NASというラベルだけでは決まりません。バックグラウンドOCRや写真インデックス作成を行うシステムは、ローカルLLM、リアルタイムカメラ検出、長文コンテキストRAG、またはマルチユーザー推論を行うシステムとは非常に異なるハードウェア構成が必要です。

多くのストレージ優先のAIワークロードに対する実用的な初期構成は：

• 最新のマルチコアCPU
• 16GBのシステムRAM
• 保護されたソースファイルと大容量用のHDDストレージ
• アプリケーション、データベース、サムネイル、インデックス、モデル用のSSDまたはNVMe層
• ファイルサイズとユーザー数に応じた1GbEまたは2.5GbEネットワーク
• 対象ソフトウェアが対応している場合のオプションのiGPU、NPU、TPU、またはGPUアクセラレーション

より要求の高いシステムでは、32GBから64GB以上のRAM、大容量NVMe、専用GPUまたは大容量統合メモリ、強力な冷却、AI計算が別サーバーで行われる場合は10GbEネットワークが必要になることがあります。

すべてのAI NASに共通の最低仕様はありません。正しい構成は以下に依存します：

• AIタスク
• ファイルライブラリのサイズ
• 処理がリアルタイムかバックグラウンドか
• モデルとコンテキストサイズ
• 同時ユーザー数
• AIがNAS上で直接動作するか、別のローカルマシンで動作するか
• 選択したアクセラレーターをソフトウェアが使用できるかどうか

最も重要なルールはシンプルです：ワークロードから始め、そのワークロードに合わせてCPU、メモリ、アクセラレーション、ストレージ、ネットワーク、冷却を決定します。

AIサーバーの要件は実際に何に依存するのか？

AI NASは同時に二つの異なる役割を果たします。信頼できるストレージシステムでありながら、保存されたデータの処理も行わなければなりません。

従来のNASは主に以下を扱う場合があります：

• ファイル共有
• コンピューターと電話のバックアップ
• スナップショットとバージョン履歴
• メディアストレージとストリーミング
• ユーザー権限
• リモートアクセス

AI対応システムは以下を追加する場合があります：

• OCRとドキュメント解析
• 写真認識
• 物体検出
• 音声文字起こし
• 埋め込み生成
• ベクトル検索とハイブリッド検索
• プライベートRAG
• ローカルLLM推論

これら二つの役割の違いはAI NASハードウェアと従来のNAS要件の比較でさらに説明されています。

ワークロードタイプ

異なるAIタスクはシステムの異なる部分に負荷をかけます。

バックグラウンド処理 vs リアルタイム処理

バックグラウンドワークロードは、夜間やストレージ活動が低い期間に実行できるため、遅いハードウェアでも許容されます。

例としては：

• 新しい写真ライブラリのスキャン
• サムネイルの生成
• 受信スキャンのOCR実行
• 埋め込みの構築
• ドキュメントインデックスの更新

リアルタイムワークロードは低遅延と持続的なパフォーマンスを必要とします。

例としては：

• セキュリティカメラの物体検出
• 対話型ローカルLLMチャット
• ライブ文字起こし
• 複数の同時RAGユーザー
• リアルタイムのマルチモーダル推論

NASは控えめなハードウェアでバックグラウンドインデックス作成を成功させる一方で、対話型LLM推論では満足のいく体験を提供できないことがあります。処理の緊急性はタスク自体と同じくらい重要です。

モデルサイズとライブラリサイズ

ハードウェアの要求は2つの独立した次元で増加します：

1. AIモデルのサイズ
2. インデックス化されるデータライブラリのサイズ

小さなモデルでも、数百万の画像、数十万のドキュメント、または数年分のビデオを処理する必要がある場合は重い負荷を生み出します。

大きなモデルは、ドキュメントコレクションが小さくても高いメモリ負荷を生み出す可能性があります。

両方を計画してください：

• モデルファイル
• コンテキストとランタイムメモリ
• アプリケーションデータベース
• サムネイルとプレビュー
• OCR出力
• 埋め込みとベクトルインデックス
• 一時処理ファイル
• 元のデータライブラリの成長

ユーザー数と並列リクエスト数

断続的に1人にサービスを提供するシステムは、複数の同時クエリを処理する共有サービスとは異なる要件があります。

公式のOllamaのメモリと同時実行に関するドキュメントでは、同時モデルロードは利用可能なシステムRAMまたはVRAMに依存すると説明しています。また、並列リクエストは有効なコンテキスト割り当てを増加させ、必要なメモリは並列リクエスト数とコンテキスト長に比例して増加すると記載されています。

これは、ローカルモデルのサイズをダウンロードサイズだけで判断するのは不十分であることを意味します。システムは以下のためのメモリも必要です：

• ランタイムオーバーヘッド
• コンテキストとKVキャッシュ
• 並列リクエスト
• 追加のロード済みモデル
• NASサービスとコンテナ

NAS上のAI vs 別のコンピュート

NAS上でAIを直接実行するとデータ移動が減り、ストレージに隣接したワークフローが簡素化される可能性があります。AIコンピュートを分離することで、ユーザーはGPU、メモリ、冷却、モデルランタイムを独立してアップグレードする自由度が高まります。

ワークロードが以下の場合はNAS上で直接実行してください：

• 保存ファイルに密接に関連している
• 軽度または中程度
• 主にバックグラウンド処理
• NASのOSおよびアプリケーションでサポートされている
• バックアップやファイルサービスを妨げる可能性が低い

ワークロードが以下の場合は別のAIサーバーを検討してください：

• GPU集約型
• リアルタイム
• 複数ユーザー対応
• 頻繁に更新されるか実験的
• NASには熱すぎる、騒音が大きい、または消費電力が高すぎる

実用的なAI NASハードウェアの3つの階層

以下の階層は普遍的なベンダー最低要件ではなく計画プロファイルです。実際の要件はアプリケーション、モデル、コンテキスト長、量子化、データ量、ユーザー同時接続数によって異なります。

ティア1：ストレージ優先AIとバックグラウンドインデックス作成

この階層は、ストレージが主な責任であり、AIがバックグラウンドの強化として動作する場合に適しています。

典型的なワークロードには以下が含まれます：

• スキャン文書のOCR
• 基本的なドキュメント分類
• メタデータ抽出
• 軽い写真タグ付け
• 小規模な埋め込みジョブ
• 時折のローカルクエリ

専用GPUは必ずしも必要ありません。ユーザーがバックグラウンドジョブの完了を待てる場合はCPU処理でも許容されます。

重要な優先事項は以下の通りです：

• アプリケーションとデータベースに十分なRAM
• アクティブなアプリデータ用のSSDまたはNVMe階層
• ソースファイル用の信頼できるHDD容量
• 安定したストレージとバックアップ動作

ティア2：統合ローカルAIとプライベートRAG

この階層は、同じシステム上で複数のAI対応アプリケーションを実行するユーザーに適しています。

例としては：

• 写真認識とセマンティックメディア検索
• プライベートドキュメント検索
• ローカルRAG
• ベクターデータベース
• 複数のDockerアプリケーション
• 軽量ローカルLLM

このレベルでは、32GBのRAMがデータベース、インデックス、アプリケーションコンテナ、キャッシュ、ファイルサービス、ローカル生成のための余裕を提供します。

ローカル写真AIとドキュメントRAGワークロードのハードウェアの違いは重要です。なぜなら、ビジュアルインデックス作成とプライベートドキュメント検索はCPU、メモリ、ストレージ、アクセラレーションの要求が異なるためです。

ティア3：ヘビーインファレンスとマルチユーザーAI

この階層は、従来の低消費電力NASよりも専用のローカルAIサーバーに近いです。

典型的なワークロードには以下が含まれます：

• より大きなローカル言語モデル
• 長文コンテキストのドキュメント分析
• 複数同時ユーザー
• リアルタイムのマルチカメラ検出
• マルチモーダルモデル
• 画像生成
• 複数モデルの同時読み込み

ユーザーは以下を計画すべきです：

• より多くのシステムRAM
• 十分なVRAMまたは統合メモリ
• 強力な冷却
• より高い消費電力
• 高速NVMeストレージ
• AIコンピュートとコアNASサービスのさらなる分離

中古サーバー、ミニPC、NASのローカルAIワークロード比較は、ストレージ優先の筐体が適切なコンピュートプラットフォームであり続けるかどうかを判断するのに役立ちます。

AI NASにどれだけのメモリが必要か？

AI NASのワークロードは複数の異なるメモリプールを消費するため、メモリはユーザーが最初に直面する制限であることが多いです。

最も役立つ計画式は次のとおりです：

実用的なメモリ要件 = モデル重み + ランタイムオーバーヘッド + コンテキストキャッシュ + 並列リクエスト + データベースとインデックス + NASおよびコンテナの余裕

システムRAM、VRAM、および統合メモリは異なる

推論がGPUで実行される場合でもシステムRAMは必要です。NASのオペレーティングシステム、ファイルサービス、データベース、コンテナ、インデックス、バックグラウンドアプリケーションは引き続きシステムメモリを使用します。

VRAMはモデルのどれだけをGPU上に保持できるか、コンテキストや並列リクエストのためにどれだけの空きがあるかを決定します。

統合メモリはシステムRAMとVRAMの厳密な区分を減らすことができますが、総容量、帯域幅、ソフトウェアサポート、熱挙動によって制限されます。

モデルサイズが出発点に過ぎない理由

利用可能なメモリに収まるように見えるモデルファイルでも、以下のために追加の余裕が必要な場合があります：

• ランタイムライブラリ
• 一時バッファ
• コンテキストとKVキャッシュ
• プロンプト処理
• 並列リクエスト
• 他のロード済みモデル
• オペレーティングシステムとアプリケーション

OllamaはモデルがGPU上に完全にロードされているか、システムメモリ上に完全にあるか、またはCPUとGPU間で分割されているかを報告できます。ドキュメントには、十分なメモリがある場合にのみ複数のモデルを同時にロードできることも説明されています。Ollamaのモデルロードとメモリ動作に関連するランタイムの詳細があります。

コンテキスト長、KVキャッシュ、および同時実行性

コンテキストウィンドウが長くなると、ランタイムがより多くのアテンション状態を保持する必要があるため、メモリ要件が増加します。

並列ユーザー数が増えると要求も増加します。複数の同時リクエストを処理するサーバーは、単一ユーザーシステムよりもはるかに多くのコンテキストメモリを割り当てる場合があります。

ローカルLLMハードウェアを計画する際にテストすること：

• 実際に必要なコンテキスト長
• 同時ユーザー数
• 読み込み状態を維持するモデルの数
• GPU推論に完全なVRAM常駐が必要かどうか
• KVキャッシュの量子化がサポートされているかどうか

16GB、32GB、64GB以上が現実的にサポートできること

これらの範囲は保証ではありません。最適化されたアプリケーションはより少なく使うこともあれば、大規模なライブラリ、長いコンテキスト、複数のサービスやユーザーはより多くを必要とすることもあります。

量子化とCPU–GPUオフロード

量子化は、重みを低精度で保存することでモデルのメモリ要件を削減します。トレードオフとして、モデルや量子化形式によっては精度低下や性能変化が生じることがあります。

llama.cpp CPU–GPUハイブリッド推論は、総VRAM容量を超えるモデルをCPUとGPUで分担して部分的に加速できます。

これは互換性を拡大しますが、完全なモデルを高速GPUメモリにロードするのと同等とは見なすべきではありません。オフロードは、データがメモリやバスの境界を越えて移動するため速度低下を招くことがあります。

AI NASに必要なCPUとは？

AI推論以外のCPUの役割

CPUは、GPU、NPU、iGPU、TPUが推論ワークロードの一部を実行している場合でも、システム全体の調整を行います。

CPUが処理する可能性のあるもの：

• NASファイルサービス
• 暗号化
• コンテナオーケストレーション
• データベース操作
• ドキュメント解析
• 画像前処理
• メディアデコード
• メタデータ抽出
• ネットワークトラフィック
• アクセラレータへのデータ供給

強力なアクセラレータも、CPUがデータを迅速に準備、デコード、または提供できない場合は十分に活用されないことがあります。

混合NASおよびコンテナワークロード

AI NASシステムはしばしば複数のサービスを同時に実行します：

• SMBまたはNFSファイル共有
• バックアップジョブ
• メディアサーバー
• 写真アプリケーション
• ドキュメントデータベース
• ベクトル検索
• モデル実行時間

複数のコアとスレッドは、これらの混合ワークロードに対してより多くのスケジューリング余裕を提供します。ただし、コア数だけでは不十分です。アーキテクチャ、命令サポート、クロック挙動、ビデオエンジン、電力制限、ソフトウェア互換性も重要です。

ハードウェアを選ぶ前に、ストレージとアプリケーションの意図された組み合わせに合わせてオペレーティングシステムを調整してください。NASおよびDockerアプリケーション向けホームサーバーOSの要件では、ストレージ優先、アプリ優先、仮想化優先のシステムがなぜ異なるハードウェアを重視するのかを説明しています。

CPUのみのAIが実用的な場合

CPUのみの処理が実用的な場合：

• ワークロードがバックグラウンドで実行される。
• ファイルライブラリが控えめである。
• モデルが小さいか大幅に量子化されている。
• レイテンシが重要でない。
• 1人のユーザーだけが時折リクエストを実行する。

ユーザーが以下を期待するとCPUのみのセットアップは魅力が薄れます：

• 高速なインタラクティブLLM応答
• 複数の同時ユーザー
• リアルタイムビデオ分析
• 大規模多モーダルモデル
• 大量の埋め込み生成

AI NASにNPU、TPU、iGPU、またはGPUは必要か？

AI NASは自動的にディスクリートGPUを必要としません。ターゲットアプリケーションを改善する場合にのみアクセラレーターが必要です。

ハードウェアビデオデコードとAI検出は異なります

カメラのワークロードは、1つのアクセラレーター仕様だけではシステム全体を説明できない理由を示しています。

カメラAIパイプラインには以下が含まれることがあります：

1. ネットワークストリームの受信
2. ビデオのデコード
3. 動作検出の実行
4. フレームの準備
5. 物体検出の実行
6. 録画とイベントメタデータの書き込み

ビデオデコードはiGPUやメディアエンジンで実行されることがあり、物体検出は別の検出器で行われます。

Frigate検出器とハードウェアサポートマトリックスは複数のアクセラレーションパスを文書化しており、サポートされている検出器が検出遅延とCPU負荷を軽減できることを説明しています。

なぜソフトウェアサポートがTOPSより重要なのか

TOPSは理論上の計算指標です。ユーザーのアプリケーションがハードウェアを利用できることを証明するものではありません。

アクセラレーターを購入する前に確認すること：

• オペレーティングシステムのサポート
• ドライバーの入手可能性
• コンテナのパススルー
• ランタイムの互換性
• サポートされているモデル形式
• アプリケーションレベルの統合
• 実際のワークロードに対する文書化された性能

より良いハードウェアの選択は、広告されている最大数値ではなく、成熟したアプリケーションサポートを持つアクセラレーターであることが多いです。

AI NASはHDDとNVMeストレージをどのように分割すべきか？

ソースデータと容量用のHDD

HDDは以下に適している：

• 写真およびビデオライブラリ
• ドキュメントアーカイブ
• 防犯カメラの録画
• バックアップ
• 大規模データセット
• 長期保存のソースファイル

テラバイトあたりのコストが低く、AI NASが大容量のプライベートアーカイブをすべてフラッシュストレージプールにすることなく保持できる。

アプリ、モデル、データベース、インデックス用のNVMe

アクティブなAIアプリケーションデータは通常、低遅延の恩恵を受ける。

NVMeストレージは以下に有用：

• コンテナボリューム
• アプリケーションデータベース
• AIモデル
• サムネイル
• OCR出力
• 埋め込みデータベース
• ベクターインデックス
• 一時処理ファイル
• キャッシュ

すべてのアクティブサービスを機械式ドライブアレイから直接実行すると、CPUやGPUリソースがあってもシステムが遅く感じることがある。

AIアプリケーションによるストレージオーバーヘッド

AI対応アプリケーションは元のファイルライブラリ単体よりも多くのデータを生成する。

容量計画のために：

• プレビュー画像
• サムネイル
• 顔データ
• OCRテキスト
• 文字起こし
• インデックス
• 埋め込みデータ
• モデルファイル
• アプリケーションログ

どの派生データをバックアップし、どれを保護されたソースファイルから再生成できるかを判断する。

ネットワークはどれくらい速くあるべきか？

ネットワーク速度はNAS内で実行されるモデルの加速には直接影響しない。ソースファイル、データセット、モデル、結果がストレージ、ユーザー、外部コンピュート間でどれだけ速く移動するかに影響する。

1GbEで十分な場合

1GbEで十分な場合もある：

• AI処理がNAS上で直接実行される
• ほとんどのジョブはバックグラウンドで実行される
• ユーザーは1人か2人のみ
• 大容量のソースファイルは頻繁に移動しない

2.5GbEが有用なアップグレードとなる場合

2.5GbEは以下に余裕を提供：

• 大量の写真インポート
• より高速なローカルバックアップ
• 複数のアクティブユーザー
• 大容量メディアファイル
• モデルファイルの移動

便利な中間層だが、すべてのAI NASの普遍的な最低条件として扱うべきではない

外部AIコンピュートで10GbEが重要な場合

NASが別のマシンに繰り返しデータを供給する場合、10GbEの重要性が増す

例としては：

• プライベートRAGドキュメントを読み取るGPUサーバー
• NASに保存されたビデオを処理するワークステーション
• 複数ユーザーが大容量メディアファイルを編集
• 別のローカルサーバーへの高速バックアップ
• NVMe対応の共有データセット

AIワークロードによるハードウェア要件

OCRとドキュメントインデックス作成

ドキュメントワークフローは通常バッチ処理指向です。最も重要な要件はしばしば以下です：

• 高性能CPU
• 複数のコンテナとデータベース用の十分なRAM
• 高速なアクティブストレージ
• 信頼できるソースファイルストレージ

Paperless-ngxのドキュメント取り込みとOCRワークフローは、ドキュメント処理が消費、OCR、メタデータ、インデックス作成、元ファイルの保存を含むことを示しています。

写真認識

写真AIは初期処理が重いですが、リアルタイム応答は必ずしも必要ありません。CPUとRAMがアプリケーションサービスを処理し、オプションのアクセラレーションで顔、物体、視覚的埋め込みの処理を高速化できます。

Immichスマート検索とメディアインデックス機能は、コンテキスト検索、OCRテキスト、認識された人物、メタデータ、位置情報、日付、カメラ情報が一つの検索システムに統合される様子を示しています。

ローカルRAGとセマンティック検索

ローカルRAGは単一モデルではなくパイプラインです。ハードウェアは以下のために必要になることがあります：

• ドキュメント抽出
• チャンク分割
• 埋め込み生成
• ベクトルストレージ
• 検索
• 再ランキング
• ローカル回答生成

埋め込みとインデックス作成はバックグラウンドで実行でき、回答生成はインタラクティブです。ユーザーはローカルで検索を実行し、必要に応じて重い生成段階だけを別のマシンに移すことができます。

セキュリティカメラ検出

カメラAIは、以下を組み合わせるため、最も負荷の高い常時稼働ワークロードの一つです：

• 複数の継続的なネットワークストリーム
• ビデオデコード
• 動作解析
• 物体検出
• イベントメタデータ
• 継続的なストレージ書き込み

カメラの台数、解像度、フレームレート、サブストリーム構成、モデルタイプ、保持期間は、一般的なGPU仕様よりも重要な場合があります。

ローカルLLMとマルチユーザー推論

インタラクティブなローカルLLMワークロードは主に以下に制約されます：

• モデルメモリ
• コンテキスト長
• メモリ帯域幅
• 並列リクエスト
• GPUまたは統合メモリ容量

1ユーザー向けの小さなモデルは中程度のハードウェアで動作可能です。複数ユーザーにサービスを提供する大きなモデルは、はるかに強力な計算ノードを必要とする場合があります。

AIはNAS上で実行すべきか、それとも別のAIサーバーで実行すべきか？

NASでストレージに隣接したバックグラウンドタスクを実行する

保存データの近くに自然に属するタスクには以下が含まれます：

• バックアップ後の写真インデックス作成
• 新しいスキャンファイルのOCR
• メタデータ抽出
• ドキュメント埋め込みの更新
• サムネイル生成
• 軽い分類

これらのワークロードは直接ファイルアクセスの恩恵を受け、ワークステーションクラスのハードウェアなしでバックグラウンドで実行できることが多いです。

重く、熱く、頻繁に更新されるワークロードを分離する

別のAIサーバーがより適しているのは：

• より大きなローカルLLM
• 画像生成
• 複数のカメラストリーム
• マルチユーザー推論
• 頻繁に変わるモデルとドライバー
• 大量の熱と騒音を発生させるハードウェア

ワークロード配置の決定はNAS外でホームAIワークロードを実行すべき時で詳しく説明されています。

AIサービスが失敗してもストレージの信頼性を維持する

分割設計により、実験的なモデルランタイムやGPUドライバーの更新が主要ストレージに影響を与えるのを防げます。

NASは以下の責任を持ち続けることができます：

• 元のファイル
• ユーザー権限
• スナップショット
• バックアップ
• アプリケーションデータベースのコピー

AIサーバーは以下の責任を持ち続けることができます：

• モデル推論
• GPUドライバー
• 埋め込みジョブ
• 実験的なコンテナ
• 重いカメラ検出

ハードウェア仕様が教えてくれないこと

アクセラレータのサポートはソフトウェアに依存します

仕様書ではアプリケーションが以下をサポートしているか確認できません：

• 選択されたドライバー
• オペレーティングシステム
• コンテナランタイム
• モデルフォーマット
• アクセラレータAPI
• 正確なハードウェア世代

GPU、NPU、TPUが使用されると仮定する前に、アプリケーションの現在の互換性ドキュメントを確認してください。

TOPSは完全なワークフローを測定しません

TOPSは以下を示しません：

• 利用可能なメモリ
• メモリ帯域幅
• モデルの互換性
• データベースのパフォーマンス
• ビデオデコード
• ストレージのレイテンシ
• ネットワークスループット
• アプリケーションの品質

サポートされているソフトウェアを備えたバランスの取れたシステムは、必要なワークロードを効率的に実行できないより高いTOPSのデバイスよりも優れる場合があります。

強力なAIサーバーでも優れたNASとは限らない

ゲーミングPCやワークステーションは優れた推論性能を提供するかもしれませんが、以下が不足していることがあります：

• 効率的な常時稼働
• 便利なドライブ拡張
• ストレージプール管理
• 静かな冷却
• バックアップ統合
• 予測可能なファイル権限

逆に、低消費電力のNASはストレージには優れていても、重いローカルAIには不向きな場合があります。

実際のワークフローを制限しているシステムの部分を特定するために、計算、メモリ、ストレージ、ネットワークのボトルネックチェックリストを使用してください。

AI NAS ハードウェア購入チェックリスト

1. 正確なワークロードを定義します。

   システムがOCR、写真のインデックス作成、カメラ検出、RAG、チャットボット、画像生成、またはその他のタスクを実行するかを指定します。

2. 処理がバックグラウンドかリアルタイムかを決定します。

   バックグラウンドジョブは遅いハードウェアを許容できます。リアルタイムサービスはより持続的な性能を必要とします。

3. データライブラリのサイズを見積もってください。

   元ファイル、サムネイル、OCR出力、データベース、インデックス、モデル、将来の成長を含めてください。

4. モデルのメモリとコンテキストを見積もってください。

   ランタイムオーバーヘッド、KVキャッシュ、並列ユーザー、その他のアプリケーションを含めてください。

5. アクセラレーターのソフトウェアサポートを検証してください。

   ドライバー、コンテナパススルー、ランタイムサポート、モデルフォーマットを確認してください。

6. HDD容量をアクティブなNVMeストレージから分離してください。

   容量層のソースデータを保護し、アクティブなデータベースとモデルを高速ストレージに配置してください。

7. アーキテクチャに合わせてネットワークを選択してください。

   ローカル処理には1GbEで十分な場合があります。AI計算が分離される場合は10GbEがより重要になります。

8. NASの信頼性を保護してください。

   インデックス作成と推論がバックアップ、録画、ファイルアクセス、ストレージの健全性を妨げないことを確認してください。

9. 電力、冷却、騒音を計画してください。

   アイドル時の効率と持続的なAI負荷の両方を評価してください。

10. 外部計算ノードの方がアップグレードしやすいかどうかを判断してください。

    分割アーキテクチャの方が実用的な場合は、重い推論を無理にNASに押し込まないでください。

結論

AI NASのハードウェア要件は、1つの最小CPU、1つのRAM容量、1つのGPU推奨に単純化できません。

適切なシステムはワークロードによって異なります：

• OCRと軽いインデックス作成は、16GB RAMと高速アプリケーションストレージを備えた有能なCPUで実行可能です。
• 写真認識、ドキュメントRAG、複数のコンテナは、より多くのRAMとNVMe作業層の恩恵を受けます。
• ローカルLLM、多数のカメラAI、長いコンテキスト、複数ユーザーは、専用GPU、より多くのメモリ、強力な冷却、別の計算リソースを必要とする場合があります。

システムRAM、VRAM、統合メモリは異なる問題を解決します。モデルの重みはメモリ需要の一部に過ぎず、コンテキスト、同時実行、データベース、インデックス、NASサービスも容量を必要とします。

HDDは保護されたソースデータに有用であり、NVMeはアクティブなアプリケーション、モデル、キャッシュ、インデックスに適しています。ネットワーク速度はNASと外部AIサーバー間で移動するデータ量に合わせるべきです。

最高のAI NASは、最大のGPUや最高のTOPS評価を持つシステムではありません。ストレージ、バックアップ、電力効率、保守性を損なうことなく、意図したワークロードを安定して実行できるシステムです。

よくある質問

AI NASの実用的な初期構成は何ですか？

最新のマルチコアCPU、16GBのRAM、ソースファイル用のHDDストレージ、アプリケーションとインデックス用のSSDまたはNVMe層、そして1GbEまたは2.5GbEのネットワークは、軽いバックグラウンドワークロードの実用的な出発点となります。

これは普遍的な最小要件ではありません。より重いアプリケーションでは、より多くのRAM、アクセラレーション、ストレージ性能、または別の計算リソースが必要になる場合があります。

専用GPUなしでNAS上でAIを実行できますか？

はい。OCR、ドキュメントのインデックス作成、メタデータ抽出、小規模な埋め込み、およびバックグラウンド写真処理はCPUハードウェアで実行できます。

GPUはローカルLLM、マルチモーダルモデル、画像生成、高負荷推論、複数同時ユーザーにより有用になります。

AI NASに16GB RAMは十分ですか？

16GBは数個のコンテナ、軽いOCR、メタデータ抽出、バックグラウンドインデックスには十分なことがあります。

大きな写真ライブラリ、ドキュメントRAG、ベクターデータベース、仮想化、ローカルモデル、複数同時サービスも動かす場合は制限になることがあります。

いつ32GB RAMを選ぶべきですか？

32GBは複数のAI対応アプリケーション、大きなインデックス、プライベートRAG、写真認識、データベース、軽いローカル生成を同じシステムで動かす場合により適しています。

64GB以上のRAMはいつ意味がありますか？

64GB以上は大きなインデックス、仮想化、複数ユーザー、長いコンテキストワークフロー、CPUまたは統合メモリ推論、複数のAIサービスに関連します。

ローカルLLMにはどれくらいのVRAMが必要ですか？

VRAMの必要量はモデルアーキテクチャ、量子化、コンテキスト長、KVキャッシュ、ランタイムオーバーヘッド、同時実行数に依存します。

パラメーター数やモデルのダウンロードサイズだけでなく、ターゲットランタイムを使って総メモリを見積もってください。

ローカルLLMにNPUは十分ですか？

通常、重い汎用ローカルLLMワークロードには向きません。NPUは効率的な対応推論、ビジョン、分類、バックグラウンドタスクに適していることが多いです。

ソフトウェアの互換性がNPUの実用的価値を決定します。

AI NASアプリケーションはHDDかNVMeのどちらで動かすべきですか？

元のメディア、ドキュメント、録音、バックアップはHDDストレージに残せます。モデル、コンテナ、データベース、サムネイル、キャッシュ、埋め込み、インデックスは通常SSDまたはNVMeストレージに置く方が良いです。

AI NASに10GbEは必要ですか？

いいえ。AIが直接NAS上で動作し、大きなファイルが頻繁に移動しない場合は1GbEで十分なことがあります。

10GbEは外部AIサーバー、NVMe対応の共有データ、大規模メディアワークフロー、複数のアクティブユーザーにより有用になります。

高速ネットワークはローカルLLM推論を速くしますか？

モデルとデータがすでに同じマシン上にある場合はそうではありません。ネットワークは主にNAS、ユーザー、ワークステーション、外部計算ノード間のデータ移動に影響します。

重いAI推論はNASの外で実行すべきですか？

多くの場合、はい。大きなモデル、画像生成、マルチユーザー推論、継続的なカメラAIは別のサーバーでアップグレードや冷却がしやすい場合があります。

NASは信頼性の高いストレージ、権限、スナップショット、バックアップの管理を担当し続けることができます。

最大のAI NASハードウェアのミスは何ですか？

最も一般的なミスは、他のパイプラインを確認せずに印象的なコンポーネントだけを購入することです。

強力なGPUでも、RAM不足、遅いアクティブストレージ、非対応ソフトウェア、弱い冷却、信頼性の低いストレージ設計は補えません。

参考文献

• よくある質問 - Ollama
• ggml-org/llama.cpp - C/C++でのLLM推論
• 推奨ハードウェア - Frigate
• 基本的な使い方 - Paperless-ngx
• 検索中 - Immich