4コアCPUでプライベートRAGサーバーは十分？

エヴァ・ウォン

IceWhale author

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

Is a Four-Core CPU Enough for a Private RAG Server? - Zima Store Online

はい。コーパスの範囲が限定され、取り込みが断続的で、アクティブユーザーが1～2人、モデル推論がリモートまたは別のアクセラレーターで実行される場合、最新の4コアCPUでもプライベートRAGサーバーとして十分なことがあります。4コアを超えるのは、解析、OCR、埋め込み生成、再インデックス、同時実行、CPU推論を実測した結果、クエリまたは取り込みのレイテンシーが目標値を超える場合だけにしてください。

4コアで実際に何を実行する必要があるかを定義する

プライベートRAGサーバーは、複数のワークロードが連携して動作するシステムです。ホストは、ファイルの取り込み、テキスト抽出、ドキュメント分割、埋め込み生成、インデックス更新、データベースの実行、文章の検索、検索結果の再ランキング、プロンプトの組み立て、ユーザーインターフェースの提供などを担います。生成モデルは同じCPU、ローカルGPU、別のサーバー、またはリモートAPIで実行できます。これらの選択によって、4コアCPUに求められる役割は大きく変わります。

各処理段階をどこで実行するのかを書き出してください。LLMと埋め込み生成がリモートなら、ローカルCPUの主な役割は、Webサービス、データベース、検索、ファイル処理、オーケストレーションです。埋め込み生成、OCR、再ランキング、生成処理をすべてローカルで行う場合、4コアCPUの負荷は大幅に広がり、継続的なボトルネックになりやすくなります。

したがって、最初に作成すべき購入判断の資料は、ワークロードの対応表です。CPUが範囲の限定されたオーケストレーションと検索処理を担うのであれば、4コアは現実的な選択肢です。一方、「プライベートRAG」が実際には1台のマシンですべてのAI処理とドキュメント処理を同時に行うことを意味するなら、4コアの説得力は大きく下がります。

現在のソフトウェア要件は処理性能の保証ではなく、基準として使う

現在のアプリケーション要件を見ると、4コアは正当なエントリー層になり得ます。たとえばRAGFlowは現在、クイックスタートの前提条件として、4コア以上のx86 CPU、16GBのRAM、50GBのディスクを挙げています。これは4コアシステムが基本スタックを動かすうえで技術的に有効であることを示しますが、インストールの最低要件は、複数ユーザー向けの性能保証とは異なります。

フル機能の検索アプリケーションに必要な具体的な下限を確認するため、購入前に最新のRAGFlowの前提条件を確認してください。4コアという数字は、16GBのメモリ要件やストレージ要件と合わせて解釈する必要があり、どの4コアプロセッサーでも任意のコーパスを処理できるという証拠ではありません。

AnythingLLMは、もう一方の例を示しています。モデル推論を外部で行う場合、セルフホスト型のDockerアプリケーションは大幅に軽量化できます。公式のDocker要件が低いアプリケーション基準を示しているのは、LLMや埋め込みサービスを別の場所で実行できるためです。

この2つの例は、数値を平均するためではなく、範囲を把握するために使ってください。4コアの購入判断は、使用予定のRAGスタック、そのデータベースと検索エンジン、そして負荷の大きいAI処理をローカルで行うのかリモートで行うのかを基準に検証する必要があります。

インタラクティブなクエリのレイテンシーと一括取り込みの時間を分けて考える

質問応答は通常、断続的に発生する処理です。ユーザーがクエリを送信すると、サーバーはインデックスを検索し、フィルターや再ランキングを適用してから、取得したコンテキストをモデルに送ります。一括取り込みは異なります。数百、数千のファイルを処理するには、解析、OCR、チャンク分割、埋め込み生成、データベースへの書き込み、インデックスのメンテナンスに数分から数時間かかることがあります。チャット中は高速に感じるCPUでも、再インデックスには耐え難い時間がかかる可能性があります。

Flowiseの本番運用ガイダンスでは、1つのプロセスですべてのワークロードを処理するのではなく、メインサーバーとワーカーを別々にスケールさせます。キューモードのアーキテクチャは重要なサイジングの目安です。非同期ジョブとインタラクティブなリクエストは、同じAIアプリケーションに属していても、異なる同時実行の負荷を生み出すためです。

自宅や小規模チーム向けのサーバーで、エンタープライズ向けの構成をそのまま再現する必要はありません。ただし、大規模なインポートをピーク時以外にスケジュールし、ワーカー数を制限し、インタラクティブなレイテンシーを測定する際にOCR、埋め込み生成、チャットのテストを同時に行わないことで、同じ原則をローカル環境に適用できます。

取り込みが許容できるメンテナンス時間内に完了し、通常の更新中もクエリの応答性が保たれるなら、4コアで十分です。必要な再インデックスが定期的にユーザークエリを妨げる場合、新しいドキュメントが継続的に追加される場合、または大規模なインポートを決められた運用時間内に完了させる必要がある場合は、CPU性能を上げてください。

Featured

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

ZimaCube2

CPUコア数をモデルのサイジングの代わりに使わない

生成モデルをCPUで実行する場合、モデルサイズと量子化が使用感を大きく左右します。4コアプロセッサーでも小型の量子化モデルから回答を生成できる場合がありますが、「動作する」ことと、インタラクティブな応答時間を実現することは別です。CPUが検索ホストだけを担うのか、それとも推論エンジンも兼ねるのかを判断する必要があります。

ZimaSpaceのモデルメモリの割り当てに関するガイドでは、重みはアクティブなワーキングセットの一部にすぎないと説明しています。コンテキスト、ランタイムバッファ、同時リクエストによってメモリ負荷が増加します。また、CPUのみの生成処理では継続的な計算負荷が発生するため、モデルが技術的に収まっていても4コアホストの動作が遅く感じられることがあります。

コンパクトなプライベートRAG構成では、ドキュメントサービスを優先し、予測可能な応答時間を重視するなら、モデル推論をリモートまたは別のGPUノードで実行してください。ローカル生成が必須の場合は、コア数だけで十分だと判断する前に、使用するモデル、量子化方式、コンテキスト長、目標トークン毎秒を実際に測定してください。

アップグレードのきっかけは、「RAGがAIを使うから」ではありません。検索処理とアプリケーション処理を個別に測定した後も、CPU推論または別のCPU負荷の高い処理が目標レイテンシーを満たせないことが根拠になります。

複合ピーク時のCPU飽和度を測定する

有効な購入テストでは、単独のベンチマークではなく、通常発生し得る最悪の重複状態を再現します。RAGインターフェースを動かし、代表的なクエリを複数実行し、少量のドキュメントを取り込むか更新しながら、データベース、ベクトルストア、認証レイヤー、通常のバックグラウンドサービスを有効にしておきます。OCRが通常の用途に含まれるなら、それもテストに含めてください。

CPUの継続的な使用率、ロードアベレージまたは実行キュー、プロセスごとの使用率、クエリレイテンシー、取り込みスループット、メモリ負荷、ストレージレイテンシー、モデルサーバーのレイテンシーを監視してください。目的はCPU使用率を低く保つことではありません。短時間のバッチ処理中にCPU使用率がほぼ最大になっても、インタラクティブな処理の応答性が保たれ、ジョブが時間内に完了するなら、プロセッサーは十分な性能を持っています。

キューが処理能力を上回る速度で増加する、ユーザーリクエストの応答時間が予測できなくなる、取り込みが許容時間を超える、またはメモリ、ストレージ、ネットワークが正常なのに通常のバックグラウンドジョブによって検索が停止する場合、4コアCPUは不足しています。これらの症状は、計算性能が購入時のボトルネックであることを示します。

システムの応答性が保たれ、ジョブが想定時間内に完了するなら、4コアの構成を維持してください。残りの予算は、RAM、SSD容量、バックアップ、または別の推論アクセラレーターに充てたほうが、大きな改善につながる可能性があります。

実証したRAGの範囲にプラットフォームを合わせる

リモートまたは別のモデル推論を使用する範囲の限定されたプライベートRAGサーバーには、ZimaBoard 2 1664が、ZimaBoard 2の中でより適切なモデルです。4コアのIntel N150と16GBメモリが、現在のRAGFlowのCPUおよびRAMの下限に対応しているためです。アプリケーション、インデックス、アップロードしたドキュメント、データベース用にSSDストレージを追加し、内蔵eMMCだけをデータ計画全体と考えないでください。

1664を選ぶ理由を、832よりメモリが多いことだけにしないでください。CPUは同じです。16GBモデルは、複数のサービスで構成されるRAGスタックがメモリ要件を満たすのに役立ちますが、4コアCPUを8コアや10コアのプロセッサーに変えるものではありません。実測した問題が継続的な解析、OCR、埋め込み生成、またはCPU推論にあるなら、RAMを増やすだけでは計算処理のキューは解消しません。

プライベートドキュメントライブラリに、より多くのストレージベイ、より高いCPU余力、複数アプリケーションの同時実行、または将来的な拡張性が必要な場合は、ZimaCube 2へ移行してください。実際のボトルネックがローカルLLMなら、より大きなNAS筐体で推論の問題が解決すると考えず、GPUとVRAMを別途サイジングしてください。

4コアが適切かどうかは条件付きで判断します。制御された検索ホストには十分ですが、オールインワンAIアプライアンスに対する普遍的な上限ではありません。リモート推論、範囲の限定された取り込み、低い同時実行数で目標を満たせるなら、4コアで十分です。ローカルのドキュメント処理または同時クエリ処理を実測し、プロセッサーが継続的な制限要因になった場合にのみ、より高性能なCPUを購入してください。

FAQ

GPUがあれば、4コアCPUでもRAGには自動的に十分ですか？

いいえ。GPUによってローカルのモデル処理や埋め込み生成の負荷を取り除いたり軽減したりできますが、解析、OCR、データベースサービス、ベクトル検索のオーケストレーション、解凍、認証、コンテナのオーバーヘッドはCPUが引き続き担う可能性があります。アクセラレーションを有効にした後のCPU処理経路をテストしてください。