CPUのみのホームサーバーで、家族のドキュメントライブラリに役立つRAGを実行できますか？

はい、CPUのみのホームサーバーでも、検索対象をコンパクトに保ち、生成に小型の量子化モデルを使えば、家族向けの実用的なドキュメントRAGを実行できます。

マニュアル、領収書、学校からのお知らせ、保証書、スキャンしたPDFで構成される家庭の文書ライブラリには、データセンター並みのスループットはほとんど必要ありません。必要なのは、プライベートな検索、出典を追跡できる抜粋、そして1〜2人で使う際に許容できる応答時間です。CPUは文書の埋め込み、ベクトル検索、検索結果テキストの処理、回答生成をすべて担う必要があるため、実用性はモデルサイズ、コンテキスト長、同時実行数、文書のクリーニングエラーをどれだけ抑えられるかに左右されます。

結論を左右するのはGPUの有無ではなく、RAGパイプライン

RAGでは、タスクを取り込み、検索、生成に分けます。取り込みではテキストを抽出して埋め込みを作成し、検索では関連性の高いチャンクを少数見つけ、生成ではそれらのチャンクを回答に変換します。CPUはすべての段階を実行できますが、それぞれボトルネックが異なります。ベクトル検索がすぐに終わっても、プロンプトの評価やトークン生成が待ち時間の大部分を占めることがあります。

CPUのみのオフラインRAGは、制約のあるハードウェア上でも安全に動作します。ただし、すべてのモデルや文書量で対話的に使えるという意味ではありません。より正確には、適切なモデル、制御されたコンテキスト、待ち時間を許容する1ユーザー向けの運用であれば、専用GPUやクラウドのエンドポイントなしに、根拠のある質問への回答が可能だということです。

家庭のライブラリにおける「実用的」とは、正しい文書が検索され、回答に該当箇所が引用され、よくある質問が合意した待ち時間内に完了することを意味すべきです。即時のマルチユーザーチャットや、数百ページにまたがる完璧な推論を意味するものではありません。CPUのみのサーバーは、プライバシーと既存ハードウェアの再利用では優れていますが、レイテンシーや同時利用の需要が最優先になると不利になります。

検索は通常手頃で、速度を決めるのは生成

ローカルのベクトルインデックスは、すべてのファイルを読み直すのではなく、コンパクトな数値表現を検索します。数千から数万チャンク規模の家庭用コレクションなら、インデックスをRAM上に保持して候補をすばやく返せることが多いでしょう。OCRと埋め込み作成は初回の取り込み時に負荷が高くなりますが、これらの処理はバックグラウンドで実行でき、変更された文書に対してのみ再実行すれば済みます。

検索にも測定可能なレイテンシーがあり、設計によっては最初のトークンが出るまでの時間の大部分を占めることがあります。測定されたRAGシステムのトレードオフからは、統合方法によって精度とエンドツーエンドの遅延が変わることも分かります。家庭用CPUでは、top-kを小さく保ち、生成中の検索を繰り返さないことで、控えめな検索処理が何度も負担になるのを防げます。

生成は逐次的です。モデルはプロンプトのトークンを処理し、回答トークンを一度に1つずつ出力します。そのため、長い検索結果の抜粋には、プロンプト評価の負荷が増えることと、無関係な根拠が混ざる機会が増えることの二重のコストがかかります。適切にチャンク分割した短いコンテキストを使えば、大型のCPUモデルに文書全体を渡すよりも、小型モデルのほうが速く、正確に感じられる場合があります。コンテキストを増やせば、検索結果が自動的に良くなるわけではありません。

量子化した小型モデルでメモリ予算を確保する

量子化では、モデルの重みを低い精度で保存し、RAM使用量と生成トークンあたりのメモリ帯域幅を削減します。これにより、通常のシステムメモリを搭載したマシンでも、30億〜80億パラメータのモデルが現実的になります。ただし、コンテキスト用バッファ、OS、ベクトルデータベース、OCRサービスにも余裕が必要です。かろうじて収まるモデルはディスクへのページングが発生し、実用にならないほど遅くなる可能性があります。

量子化されたローカルモデルは、小型コンピューターやランタイムによってスループット、メモリ、電力の挙動が異なります。したがって、パラメータ数だけでは使用感を予測できません。量子化レベル、メモリ帯域幅、ランタイム、プロンプト長、モデルアーキテクチャのすべてが、1秒あたりのトークン数と最初の応答までの時間に影響します。

まずは、スタックの他の部分に少なくとも数GBを残せるモデルから始め、実際に使用するCPUで測定してください。4ビットモデルで十分な引用付き回答を許容できる速度で生成できるなら、より大型のモデルへ移行すると、家庭文書の検索精度が向上する以上に応答性が低下する可能性があります。モデルサイズを大きくする前に、検索品質、OCR精度、チャンクの境界を見直す価値があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

CPUのみのRAGは長いコンテキストと同時実行で限界に達する

複数のユーザーが長い質問を送信する場合、すべての回答に多数の検索チャンクを含める場合、または大規模な契約書や医療記録を横断して統合する必要がある場合、設計は快適ではなくなります。同時に実行される生成処理は、メモリ帯域幅とCPUコアを奪い合います。リクエストがキューに並び、コンテキストキャッシュが拡大し、サーバーがスワップを始めると、レイテンシーは非線形に増大します。

RAGを使う小型言語モデルでは、モデル、ベクトルデータベース、検索設計を1つのデプロイ問題として扱う必要があります。そのため、CPUのみの家庭用サーバーでクラウドのようなサービスレベルをうたうべきではありません。たまに行う検索や短い要約には適していますが、低レイテンシーの音声アシスタント、大量の文書分析、多数の同時セッションには向いていません。

限界は計算能力だけでなく、情報面にもあります。ZimaSpaceのNAS上のプライベートAIアシスタントに関する解説では、CPUのみのシステムには重い推論よりも軽量な検索と要約が適していると説明されています。誤ったOCRテキストから返される速い回答は、依然として誤答です。そのため、確認できるように、インターフェースには出典ファイル名と引用箇所を表示すべきです。

実用的と判断する前に20問の受け入れテストを行う

実際の家庭内の作業からテストセットを作成します。家電の保証期間を探す、保険の条項を見つける、学校の締切を確認する、正しい回答が文書内に存在しない質問に答える、といった内容を含めてください。スキャンPDFとテキストベースのPDFの両方を対象にします。各クエリについて、検索成功率、引用の正確性、最初のトークンまでの時間、回答全体の所要時間、ピークRAM使用量、根拠が不足している場合にモデルがそれを認めるかを記録します。

クエリごとにインデックスの検索範囲を絞ることで、検索処理を削減できます。TeleRAGはクラスタ化検索を使って、アクティブな検索空間を制限します。家庭でのテストにこのアーキテクチャをそのまま採用する必要はありませんが、同じ原則を検証すべきです。検索では、ライブラリ全体をプロンプトに転送するのではなく、関連性の高いチャンクを少数返すようにします。

20問中少なくとも18問で正しい出典が検索され、事実に関する回答すべてに確認可能な引用箇所が示され、通常のクエリが家庭で定めたレイテンシー目標を満たし、ピークRAM使用量が80％未満に収まるなら、CPUのみの設計を採用してよいでしょう。検索に失敗するならOCRまたはチャンク分割を修正し、検索は成功するものの生成が遅すぎるなら、コンテキストまたはモデルを小さくします。GPUを追加するのは、測定によってボトルネックが明確になってからにしてください。