ローカル文書アシスタントにはどれくらいのVRAMが必要？

エヴァ・ウォン

IceWhale author

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

How Much VRAM Does a Local Document Assistant Need? - Zima Store Online

生成をリモートまたは別の推論サーバーで実行する場合、ローカルのドキュメントアシスタントに専用VRAMは必要ありません。同一マシンで推論する場合、量子化された小規模モデルなら8GBが現実的な出発点です。一方、より大きなモデル、長いコンテキスト、同時実行によって必要量は16～24GBを大きく超えることがあります。RAGアプリケーション自体がVRAM要件を決めるわけではないため、購入前に使用するモデルと作業コンテキストのサイズを正確に見積もってください。

アシスタントに本当にローカルGPUが必要か判断する

ドキュメントアシスタントには、少なくとも2つの層があります。ファイルを保存し、テキストを分割し、文章を検索または取得して回答を表示するアプリケーション層と、生成を行うモデルバックエンド層です。これらを同じハードウェアで動かす必要はありません。コンパクトなサーバーでプライベートなドキュメントライブラリと検索基盤をホストし、モデルへのリクエストを別のローカルGPUマシンやリモートプロバイダーに送ることもできます。

AnythingLLMのセルフホスト向けドキュメントでは、アプリケーションを別の場所にあるモデルサービスや埋め込みサービスへ接続できることが明確に説明されています。そのため、セルフホスト要件は、同一マシンでLLMを動かすために必要なハードウェアよりはるかに低くなります。

要件が「すべてのモデルのトークンをこのサーバー上で生成する」ではなく「ドキュメントを自分のサーバーに置く」であるなら、専用VRAMをゼロにする選択も有効です。ただし、どのテキストがマシン外へ送信されるのか、埋め込みがどこで生成されるのか、リモートモデルがリクエストをどのように処理するのか、そしてプライバシー境界が用途に合っているかを確認する必要があります。

最初に決めるべきなのはアーキテクチャです。リモートまたは別サーバーで推論するなら、検索用のCPU、RAM、ストレージを確保します。同一マシンで推論するなら、VRAMがモデル選定の主要な制約になります。

RAGのオーバーヘッドを加える前にモデルの重みを見積もる

VRAM計画は、正確なモデルと精度から始まります。フル精度の重みは8ビット版や4ビット版よりはるかに大きいため、「7Bモデルを動かしている」と言うユーザー同士でも、必要なメモリ量が大きく異なることがあります。量子化によって、実用的な小型モデルを一般的なハードウェアに収められますが、出力特性が変わる場合もあるため、ドキュメント処理で評価する必要があります。

Hugging Faceのドキュメントでは、量子化によってメモリと計算コストを削減できることが説明されており、一般的な8ビットおよび4ビットの経路に対応しています。つまり、精度はハードウェアを選んだ後に適用する単なるソフトウェア設定ではなく、購入時に考慮すべき要素です。

現在の大まかな計画基準では、4ビットの7～8Bクラスのモデルは6～8GB程度に収まることが多く、13～14Bクラスではおよそ10～12GBに近づき、27～32Bクラスでは追加のコンテキスト用余裕を含める前に20GB台前半が必要になることが多いです。Spheronの2026年版VRAM見積もりガイドでも同様のINT4向け数値が示されており、重みの見積もりに加えて実行時のオーバーヘッドが必要だと明記されています。

ダウンロードしたモデルファイルのサイズぴったりで購入しないでください。ランタイムとコンテキスト状態のための余裕を残し、実際に使用する推論エンジンでモデルを検証してください。短いテストプロンプトで読み込めても、アシスタントが長い検索コンテキストを受け取ると、処理に失敗したり一部がオフロードされたりすることがあります。

モデルが収まった後もコンテキスト長によってVRAMクラスが変わる

ドキュメントアシスタントは、一般的なチャットボットより多くのコンテキストを必要とすることがあります。取得した文章、引用、システム指示、会話履歴、ユーザーの質問を1つのリクエストにまとめるためです。モデルの重みが一定でも、キー・バリューキャッシュやその他のリクエスト状態はコンテキスト長に応じて増加します。

Ollamaの現在のコンテキストに関するドキュメントでは、このトレードオフが明確に示されています。デフォルトのコンテキスト長は、24GiB未満では4K、24～48GiBでは32K、48GiB以上ではさらに大きくなります。正確なデフォルト値はランタイムの選択によって変わりますが、購入時の教訓は、長いドキュメント処理ではモデルの重み以外にもメモリを消費するということです。

だからといって、コンテキストを無条件に最大化するべきではありません。検索では質問に答えるために必要な最小限の文章だけを選び、生成前にチャンク分割や再ランキングで無関係なテキストを除去すべきです。すべてのドキュメントを1つのプロンプトに詰め込む必要があるなら、検索設計の弱さをVRAMで補っていることになります。

テストしたモデルの精度は十分でも、実際のドキュメントプロンプトでオフロード、メモリ不足エラー、または必要なコンテキスト長で許容できない遅延が発生する場合は、次のVRAMクラスへ移行してください。コンテキストがモデルに届く前から検索品質が低い場合は、まずインデックスとランキングを改善します。

Featured

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

ZimaCube2

埋め込み、再ランキング、OCR、同時実行のための容量を別途確保する

ローカルLLMだけがGPUメモリを使用するコンポーネントではありません。ドキュメントアシスタントによっては、同じGPU上で埋め込み、再ランキング、OCR、音声文字起こし、画像モデルなども高速化します。これらを同時に実行すると、各コンポーネントを単独でテストしたときには収まっていても、生成に使えるVRAMが減少します。

ZimaSpaceの記事モデル全体のメモリフットプリントでは、チェックポイントサイズとともにランタイムバッファやリクエスト状態も考慮する必要がある理由を説明しています。ドキュメントアシスタントでは、取得したコンテキストと並行サービスが共有メモリへの負荷をさらに高めます。

同時実行も答えを変えます。2人のアクティブユーザーが1つの常駐モデルを共有していても、それぞれに別のKVキャッシュ状態が必要になる場合があります。バッチ処理対応のサーバーはアクセラレーターの使用効率を高められますが、リクエストごとのメモリ消費がなくなるわけではありません。想定する同時ユーザー数のもとで、通常発生する最長のドキュメントクエリを測定してください。

GPUワークロードが生成だけなら、テストで確認した作業セットに近い容量で選べます。OCR、埋め込み、再ランキング、生成を重ねて実行する必要がある場合は、より大容量のVRAMを購入するか、負荷の高い処理を順番に実行するか、サービスをCPUとGPUのリソースに分散してください。最も安価なのは、不要なアクセラレーションに費用をかけず、必要な遅延性能を維持できる構成です。

VRAMの階層で候補モデルを絞り込み、品質をテストする

有用な候補リストは、収まる最大モデルではなく、ドキュメントアシスタントに必要な処理内容で整理できます。6～8GB程度のVRAMなら、小型の7～8Bクラスの4ビットモデルと、範囲を制限した検索から始めます。12～16GBあれば、より大きなモデル、高い精度、またはより長いコンテキストを選ぶ余地が広がります。24GB程度では、多くの27～32Bクラスの量子化モデルが、より大きな作業余裕を持って実用的になります。およそ40～48GB以上は、重いオフロードなしで70B規模の4ビットモデルが現実的になり始めるクラスです。

SitePointの2026年版ローカルLLMガイドでは、7BのQ4_K_Mモデルが6GBのVRAMに余裕を持って収まると説明されています。その他の現在の見積もりガイドでは、14Bおよび32Bの量子化モデルはより大きな容量を必要とするとされており、一般的な「AI PC」という名称ではなく、正確なチェックポイントによって必要な階層が決まるという原則を裏付けています。

次の階層を購入する前に、自分のドキュメントで評価セットを作成してください。正確な抽出、複数文章の統合、情報源にない場合の拒否、必要に応じて表や構造化テキスト、想定する最長コンテキストを含めます。回答品質、引用の挙動、最初のトークンが出るまでの遅延、生成速度、ピークVRAMを比較してください。

小さいモデルが、モデルの能力またはコンテキスト容量の不足によって実際に失敗する場合は、より大きなVRAMを購入してください。より大きなチェックポイントが存在するという理由だけでアップグレードする必要はありません。限定されたプライベートナレッジベースでは、検索によって小型で高速なモデルのほうが、根拠付けの弱い低速モデルより有用になることがあります。

ストレージ・検索ホストとVRAMの判断を分ける

ドキュメントアシスタントには、元ファイル、抽出テキスト、インデックス、アプリケーションデータベース、ログ、バックアップを保存する永続ストレージも必要です。これらの資産は通常、GPUのVRAMではなく、システムRAMとディスク容量を消費します。すべてのリソースを1つの「AIメモリ」という数値にまとめると、ハードウェア選びを誤る原因になります。

ZimaSpaceのNAS上のプライベートAIアシスタントに関する概要では、ローカルファイルを中心とした検索優先の役割が説明されています。この構成なら、後から推論ハードウェアを変更しても、ストレージシステムを安定して運用できます。

ZimaBoard 2 1664は、コンパクトなサーバーでドキュメントストレージ、インデックス作成、アプリケーション、オーケストレーションを担い、LLMをリモートまたは別のGPUマシンで実行する場合に適しています。内蔵Intelグラフィックスを、LLM専用VRAMとして扱わないでください。

ストレージホストは、ドキュメント量、バックアップ、アプリケーションメモリ、ネットワーク要件から選びます。アクセラレーターは、正確なモデル、量子化方式、コンテキスト、同時実行数から選びます。これらの判断を分けておけば、信頼できるドキュメントストアを再構築せずにGPUだけをアップグレードできます。

同一筐体のGPU構成は購入前に検証する

ストレージ、検索、ローカル生成を1つの筐体にまとめたい場合、最後に確認すべきなのは、ランタイムが実際に利用できるGPUメモリ容量です。「AI」「クリエイター」「RTX」といった製品名だけでは、選択したローカルモデルが収まるかどうかは分かりません。VRAM、ドライバー対応、コンテナからのアクセス、電源、冷却、物理的な拡張性をすべて確認する必要があります。

現在のZimaCube 2 Creator Packは、複数ベイのストレージと専用NVIDIA GPUを同じシステムに搭載したい場合に検討できるZima製品です。現行の商品ページではGPUファミリーが示されていますが、主な仕様欄にVRAM容量は記載されていません。そのため、搭載GPUの正確なメモリ容量を確認するまで、8GB、16GB、24GB、48GBのどのモデル階層に該当するか判断しないでください。

購入前には、可能な限り代表的なモデルでテストを実行するか、テスト結果を提供してもらってください。通常の量子化方式とコンテキストでピークVRAMを記録し、その後、アシスタントの埋め込み、再ランキング、OCR、その他のGPUサービスを有効にして再測定します。ランタイムが意図したGPUを実際に使用しており、レイヤーをシステムメモリへ静かにオフロードしていないことも確認してください。

最終的なルールは、マーケティング上のカテゴリではなく、検証済みの作業セットに合わせてVRAMを購入することです。推論を別の場所で実行できるなら専用VRAMはゼロにし、小型の量子化ローカルモデルには6～8GB程度から始めます。より大きなモデルや余裕が必要なら12～16GBへ移行し、モデルサイズ、コンテキスト、同時実行数によって必要だとテストで確認できた場合にのみ、24GB以上を検討してください。