ローカルRAGはGPUなしでも動く？

動きます。埋め込みモデル（nomic-embed-text など）とベクトルDB（Chroma/FAISS）はCPUとRAMだけでも十分実用的で、検索部分はGPUがなくても遅くなりません。ボトルネックは回答を生成するLLM側で、CPU推論だと7Bクラスでも体感が重くなります。RAM16GBあれば3〜7BのLLMで検証は始められますが、快適に使うなら12GB以上のVRAMを持つGPUを足すのが現実解です。

RAGに必要なVRAMはどう見積もる？

「LLM本体 + KVキャッシュ + 埋め込みモデル + ベクトル検索」の合計で考えます。主役はLLMで、8BをQ4_K_Mで動かすなら約5GB、これにコンテキスト長ぶんのKVキャッシュが乗ります。埋め込みモデルは小さく（nomic-embed-textで約300MB）、FAISSのインデックスも100万件×768次元で約3GBと小さいため、配分の主導権は常にLLM側が握ります。12GBは7〜8B級、16GBで余裕、24GBで14B級、48GBで32〜70B級が目安です。

ベクトルDBはChroma・FAISS・Milvusのどれを選ぶ？

件数で決めます。数万件までの個人検証やプロトタイプならChroma（設定不要で即使える）、数十万〜百万件を単一マシンで高速検索するならFAISS（GPUにも載せられる）、百万件超や本番の分散運用ならMilvusです。最初はChromaかFAISSで始め、データ量が増えてからMilvusへ移行して問題ありません。

埋め込みモデルは何を使えばいい？

日本語を含む多言語で精度を最優先するならQwen3-Embedding-8B（MTEB 70.58で首位級、ただしF16で16GB VRAM・Q4で4〜6GB）、軽さと長文対応のバランスならnomic-embed-text（8192トークン対応・約300MB・CPUでも軽快）、英語中心で短いチャンクならmxbai-embed-largeが定番です。迷ったらまずnomic-embed-textで動かし、検索精度に不満が出たらQwen3へ上げるのが省コストです。

ローカルRAG構築向けPC構成ガイド 2026年版：埋め込みモデル + ベクトルDB + LLM を1台で動かすVRAM配分と必要スペック

本記事は Amazon.co.jp および各販売店のアフィリエイトリンクを含む場合があります。推奨は性能・コスパ・実機ベンチマーク基準で編集判断しており、提供記事は受け付けていません。詳細はプライバシーポリシーをご覧ください。

ローカルRAG構築PC構成 2026：埋め込みモデル・ベクトルDB・LLMのVRAM配分

結論：RAGを1台で完結させるVRAMの主役はLLMで、埋め込みモデルとベクトルDBはおまけ程度しか食わない。 12GBなら7〜8B級のLLMで小規模検索、16GBで余裕を持って8B、24GBで14B級、48GB（24GB×2枚）で32〜70B級が現実的な目安です。RAGと聞くと「埋め込みもベクトル検索もGPUを食うのでは」と身構えがちですが、実際にVRAMを圧迫するのはLLM本体とそのKVキャッシュで、埋め込みモデル（数百MB）とFAISSインデックス（百万件でも数GB）は誤差の範囲です。だから構成を決めるときは、まず「動かしたいLLMの規模」から逆算するのが最短になります。

社内ドキュメント検索やナレッジBotをクラウドに出さずローカルで完結させたい、というのがRAGをローカルで組む最大の動機です。この記事は「どのGPUを選ぶか」ではなく「RAGという三層構成（埋め込み＋ベクトルDB＋LLM）を1枚のGPUに同居させたとき、VRAMがどう取り合いになるか」に絞ります。LLM単体の最低スペックはローカルLLMを動かすPCの最低スペック、容量別に何が載るかの早見表はVRAM容量別モデル早見表に分けてあるので、本記事はRAG固有の配分問題に集中します。

RAGの三層構成とVRAMの食い方

ローカルRAGは大きく3つの部品でできています。

部品	役割	VRAM/メモリの食い方
埋め込みモデル	文章をベクトル（数値の列）に変換	小さい（300MB〜、大きくても16GB）
ベクトルDB	ベクトルを保存し、近いものを高速検索	非常に小さい（百万件で数GB、CPU/RAMでも可）
LLM	検索した文書を読んで回答を生成	大きい（主役。8BでQ4約5GB＋KVキャッシュ）

ポイントは、検索パイプライン（埋め込み＋ベクトルDB）はフットプリントが小さく、回答生成のLLMだけが大きく重いという非対称性です。RAGの体感品質を決めるのは「検索の精度」と「回答の賢さ」ですが、ハードを圧迫するのは後者だけ。だからVRAM配分は「LLMにいくら割けるか」で決まり、埋め込みとベクトルDBは常に共有GPUに常駐させても困りません。

埋め込みモデルの選び方

埋め込みモデルは「文章を意味のベクトルに変換する」係です。RAGの検索精度はここで8割決まりますが、サイズは小さく、選択の自由度が高い部品です。

モデル	MTEBスコア	最大トークン	サイズ目安	向き
nomic-embed-text	約62.4	8192	約300MB	長文・CPUでも軽快・万能の入門
mxbai-embed-large	約64.7	512	約700MB	英語中心・短いチャンク
Qwen3-Embedding-8B	約70.6	32K	F16で16GB / Q4で4〜6GB	多言語・日本語・精度最優先

実務的な選び方はこうです。まずnomic-embed-textで組みます。8192トークンの長文に対応し、CPUでも軽く動き、VRAMをほぼ食わないので「とりあえず検索が回る状態」を最短で作れます。日本語の検索精度に不満が出たらQwen3-Embedding-8Bへ上げます。MTEB 70.58は現行OpenAIの埋め込みすら上回る水準で、多言語・長文に強い一方、F16では16GB VRAMを要求するので、GPUが厳しければQ4量子化（4〜6GB）で載せます。英語ドキュメントしか扱わず、チャンクが512トークンに収まるならmxbai-embed-largeが軽くて速い選択肢です。

注意点として、埋め込みモデルは後から変えると全文書をベクトル化し直す（再インデックス）必要があるため、本番運用に入る前に決めきるのが安全です。検証段階で複数試し、日本語精度で当たりを付けてから固定しましょう。

ベクトルDBの選び方

ベクトルDBは「埋め込んだベクトルを保存して、質問に近い文書を高速に引っ張る」係です。ここは件数で機械的に選べます。

ベクトルDB	得意な規模	特徴
Chroma	〜数万件	設定不要・pip一発・個人検証/プロトタイプの定番
FAISS	数十万〜百万件	単一マシンで高速・GPUにも載せられる・ライブラリ型
Milvus	百万件超	本番分散・スケール前提・運用は重め

FAISSのインデックスがどれだけVRAM（またはRAM）を食うかは単純な掛け算で見積もれます。ベクトル数 × 次元数 × 4バイト（float32） が素のサイズで、たとえば100万件 × 768次元なら 1,000,000 × 768 × 4 ≒ 3GB です。768次元の埋め込みなら百万件でも3GB程度で、LLMの隣に置いても邪魔にならないのが分かります。量子化インデックス（IVF-PQなど）を使えばさらに圧縮できます。

最初はChromaで組んで動作を確認し、件数が数十万を超えて検索が遅くなってきたらFAISSへ、百万件超で複数マシンに分散したくなったらMilvusへ、という段階移行が無駄がありません。個人・小規模チームのナレッジBotなら、Chroma/FAISSの範囲で完結するケースがほとんどです。

VRAM配分：12 / 16 / 24 / 48GBで何が回るか

ここが本記事の核心です。RAGの合計VRAMは次の足し算で考えます。

LLM本体 + KVキャッシュ（コンテキスト長ぶん）+ 埋め込みモデル + ベクトル検索

埋め込み（〜数百MB）とベクトル検索（百万件で〜3GB）は小さいので、実質は「LLMにいくら残せるか」の勝負です。

VRAM	推奨LLM	同居構成の現実
12GB	7〜8B（Q4_K_M、約5GB）	チャットモデル常駐中の大量インデックス作成は競合。検証〜小規模なら可、両方フルスピードは不可
16GB	8B（余裕）/ 一部14B	LLM 8B + 埋め込み + FAISSを同時常駐しても余裕。個人ナレッジBotの実用ライン
24GB	14B級	14BのQ4＋長めのコンテキスト＋検索を快適に同居。回答品質を一段上げたい人向け
48GB（24GB×2）	32〜70B級	70B級の高品質回答とRAGを両立。社内向けの本格運用

12GBの落とし穴を具体的に言うと、8BのチャットモデルがQ4で約5GBを占有している状態で、大量の新規文書を一括ベクトル化（インデックス作成）しようとすると、埋め込み処理とLLMがGPUを取り合い、どちらもフルスピードが出ません。「初回の大量インデックスはCPUで回す→検索・回答だけGPU」のように時間軸で分ける運用なら12GBでも実用になりますが、常時両方を高速で、を求めるなら16GB以上が安心です。

16GBが個人RAGの実用ラインと考えてよいでしょう。8BのLLMを常駐させたまま埋め込みモデルとFAISSを同居させても余裕があり、RTX 5060 Ti 16GBクラスで十分組めます。回答品質を14B級へ引き上げたいなら24GB、70B級の本格運用なら48GB（24GBを2枚）という階段です。複数GPUでVRAMを束ねる場合のハード前提はワークステーションPC構築ガイドのマルチGPUの項も参考になります。

最短で動かす構成（ソフト導線）

ハードが決まったら、ソフトは「全部入りで迷わない」組み合わせから始めるのが速いです。

Ollama 一本：埋め込みもLLMもOllamaで動かせます（ollama pull nomic-embed-text と ollama run llama3.3）。最小の手数でRAGの両輪を揃えられる入門ルート。
LM Studio + LangChain + Chroma：GUIでモデルを管理しつつ、LangChainでRAGパイプラインを組み、Chromaに保存する定番構成。コードを書きながら仕組みを把握したい人向け。

実行ツールそのものの比較（Ollama / LM Studio / llama.cpp / vLLM）はローカルLLM実行ツール比較に詳しくまとめてあります。RAGを本番でチームに提供し、並列リクエストを捌くフェーズに入ったら、回答LLMをvLLMでサービングする構成へ移ると並列スループットが伸びます。

GPUなし・RAM16GBでも、3〜7BのLLM＋nomic-embed-text＋Chromaで「RAGとは何か」を体感する検証は十分可能です。まずCPUで仕組みを掴み、回答の遅さが気になったらGPUを足す。この順番が、無駄な買い物を避ける現実解になります。

まとめ：LLMから逆算してVRAMを決める

ローカルRAGの構成は、三層のうちLLMだけがVRAMの主役という非対称性さえ掴めば一気に簡単になります。

埋め込みモデルは小さい（nomic-embed-textで約300MB）。まず軽いもので始め、日本語精度が欲しくなったらQwen3へ
ベクトルDBは件数で選ぶ（Chroma→FAISS→Milvus）。FAISSは「件数×次元×4バイト」で見積もれて百万件でも数GB
VRAMは「動かしたいLLMの規模」から逆算。16GBが個人RAGの実用ライン、24GBで14B、48GBで70B級

「RAGは重そう」という先入観でオーバースペックなGPUを買う必要はありません。動かすLLMを8Bに決めるなら16GBで快適に回り、検索パイプラインはその隙間に余裕で同居します。

入手先・関連商品

当サイトは Amazon.co.jp アソシエイト・プログラムに参加予定です。下記リンク経由で購入された場合、紹介料を受け取ることがあります。読者の負担は増えません。リンクは記事評価とは独立しており、編集判断には影響しません。

本記事で前提とした「ローカルRAGを動かすGPU」の例です。埋め込みモデルとベクトルDBは無料のオープンソースで、ハード側の用意だけで始められます。

GPU（VRAM別の目安）

あなたに合うPCを診断する

用途や予算をもう少し細かく入力すると、3つの候補構成を提案します。

→ 診断スタート