ローカルRAGはなぜ重い？CPU・GPU・NPUで見るPDF読み込みと検索の負荷

RAGが重い理由を工程ごとに分ける

PDF抽出が遅いのにLLMを小さくしても改善しません。逆に、検索結果が正しいのに回答生成だけ遅い場合は、embeddingやvector DBを入れ替えるより、context長、モデル、VRAM、選択されたExecution Providerを確認します。

「遅い」を一つの数字にしない

RAGの体感時間は、初回のindex作成、質問ごとの検索、最初のtoken、回答の最後のtokenで別です。最低限、`parse_ms`、`index_ms`、`retrieve_ms`、`rerank_ms`、`time_to_first_token`、`generation_ms`を分け、同じ文書・同じ質問・同じ出力上限で比較します。

Task ManagerのGPU/NPU使用率だけでは、どのRAG工程がどのproviderで動いたか分かりません。runtimeのmodel ID・EP・device表示と、工程別の時間を同じ測定記録へ残します。

CPU・GPU・NPU・外部APIはRAG全体に同じようには効かない

MicrosoftのWindows AI比較では、Windows AI APIsはready-to-useの機能、Foundry Localはready-to-useのLLM・音声モデル、Windows MLは自分で用意するONNXモデルの実行基盤として整理されています。RAGでembeddingやrerankingを自作する場合は、生成モデルの選択だけでなく、その工程をどのruntime・形式・providerへ載せるかを確認します。

Foundry LocalのFAQはhardwareを検出してproviderを選び、CPU fallbackを持つと説明していますが、これはFoundry Localのruntimeの挙動です。すべてのRAGアプリが同じprovider選択をする、またはNPU搭載だけで全工程がNPUへ移る、という意味ではありません。

Windowsの実行基盤をRAGの役割へ割り当てる

• Foundry Localのcache・loaded状態 - local model・EP・cache・offlineの状態を分ける
• Windows ML custom ONNX - embedding・rerankingを含むONNXのEP・配布条件を見る
• 文書チャットのlocal/cloud境界 - 推論、保存、同期、exportの経路を分ける

embedding・chunk・retrievalの設定変更は新しい基準で測る

Open WebUIの公式RAG説明では、質問を設定済みembedding modelでvector化して検索し、top matchesをpromptへ入れます。embedding modelが変わるとvector spaceが一致しなくなるため、古いindexとの速度・検索品質をそのまま比較しません。

LM Studioもembedding modelをRAGの構成要素として説明しています。embeddingをlocalで動かすか外部APIへ出すかは、LLM生成の場所とは別に記録します。検索が外れた時に、いきなり大きい生成モデルやNPUへ移るのではなく、embedding model・chunk・index・top-kの順に確認します。

• chunking・retrievalの検索漏れ - 分割・top-k・検索結果の品質へ進む
• PDF抽出・Doclingの出力 - 抽出構造と再parseの境界を見る
• RAG引用の証拠ID - retrieval結果をpage・source・claimへ戻す

NPUは「RAG全体の速度」ではなく工程別に評価する

NPUはembeddingやrerankingのような繰り返し処理を省電力にする候補ですが、RAG全体の改善は、モデル形式、compiler、入力/出力長、provider、アプリ実装に依存します。NPUの存在、TOPS、Windows AI APIの対応表だけから、LM Studio・Ollama・Open WebUIのRAG速度を推定しません。

Quant.npuのような静的量子化研究は、NPUに合う量子化形式が重要であることを示します。LENSのようなレイテンシ予測研究は、入力長、出力長、compiler、bucketingで速度が変わることを示します。RAGでは検索でcontextが増えやすいため、短文チャットだけで購入判断をしないでください。

Snapdragon X Elite / Hexagon NPU上のオンデバイスRAG研究も、特定hardware・実装・測定条件の研究として読みます。全Windows PC、全embedding model、全RAGアプリへ一般化せず、対象PCとruntimeで同じpipelineを測ります。

• オンデバイスRAG/NPU研究 - 研究の条件と一般化の限界を確認する
• NPU向け静的量子化 - GGUFのQ4/Q5/Q8とNPU形式を分ける
• NPUレイテンシ予測 - 入力・出力長と実測の関係を見る

初心者の切り分け手順

1. Windows build、driver、RAM、GPU/VRAM、NPU、runtime、model ID・revisionを記録する。
2. モデル単体で短い質問を行い、generationだけのTTFT・生成時間・providerを保存する。
3. 公開PDFを1つだけ入れ、抽出ページ数・文字数・parse時間を測る。
4. 同じ文書をindexし、embedding model、chunk数、index時間、indexサイズを記録する。
5. 同じqueryでretrieve・rerank・context tokenを測り、検索結果とscoreを保存する。
6. 最後に固定max outputで回答を生成し、CPU fallback・対象GPU/NPU・cloudを一度に一つだけ比較する。

一度にモデル、chunk、top-k、providerを全部変えると原因が分からなくなります。まず「どの工程が遅いか」を特定し、その工程を担当する資源だけを変えます。

症状から最初の確認箇所を選ぶ

関連記事と次の判断

• ローカルAI用PCスペック - RAM・GPU/VRAM・CPU・SSDを購入判断へ戻す
• GPUなしPCの現実ライン - CPU fallbackで試す用途を分ける
• Open WebUIのRAG - File Context・embedding・provider設定を確認する
• RAGの引用faithfulness - 検索結果と回答の根拠を照合する