多言語の家族向けRAGインデックスにはどれくらいのRAMが必要ですか？

エヴァ・ウォン

IceWhale author

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

How Much RAM Is Needed for a Multilingual Family RAG Index? - Zima Store Online

多言語ファミリー向けRAGインデックスは、多くの場合16～32GBのRAMに収まりますが、言語数だけでなくチャンク数とインデックス設計のほうが重要です。

50万チャンクのホームアーカイブでは、言語ごとに1つずつではなく、チャンクごとに1つの多言語埋め込みを使用できます。ただし、ベクトルの次元数、グラフリンク、メタデータ、キャッシュ、リランカー、生成モデルによってメモリ使用量は増加します。そのため、目標とすべきなのは、ピーク負荷時の「言語ごとのギガバイト数」というルールではなく、余裕を含めて測定したピーク時のワーキングセットです。

まずベクトルを計算し、その後に検索構造を加える

生のベクトルメモリは、チャンク数に次元数と1値あたりのバイト数を掛けて算出します。float32の場合、次元数768のベクトル50万個には、座標データだけで約1.54GBが含まれます。float16ならこの座標データ量は半分になりますが、データベースの対応状況と精度への影響を確認する必要があります。

HNSWグラフインデックスの概要では、高速な近似検索のためにHNSWが近傍接続のグラフを保持する仕組みを説明しています。これらの接続、ID、アライメント、アロケーターのオーバーヘッドは、生のベクトル計算に上乗せされます。

メタデータフィルター、ドキュメントID、テキストキャッシュ、ビルド時に複製される構造体によって、予想以上にメモリを消費することがあります。ディスクバックアップ型のデータベースでも、ホットなグラフページはメモリに保持される場合があります。一方、インメモリエンジンではインデックスのほぼ全体が保持されることがあります。生のベクトル量は最低限の目安であり、最終的なRAM要件ではありません。

多言語対応では、計算量よりもチャンク数が変わる

多言語埋め込みモデルは複数の言語を1つのベクトル空間にマッピングするため、言語を追加しても、すべてのベクトルが自動的に複製されるわけではありません。RAMが増加するのは、翻訳済みコピーを別々にチャンク化する場合、言語別のインデックスを維持する場合、または同じ文書でもトークン化によってチャンク数が増える場合です。

多言語埋め込みに関する研究では、多数の言語にわたる共有表現を評価しており、選択したモデルが各言語を十分に整合させられる場合には、1つのインデックスで設計できることを示しています。ただし、メモリ使用量が変わらなくても、言語によってカバレッジの品質は異なる可能性があります。

生成モデルとリランカーもシステムメモリを奪い合います。16GBのサーバーなら中規模のインデックスを保持できる場合がありますが、LLM、OCR処理、データベースキャッシュを同時に実行すると、頻繁にページングが発生する可能性があります。RAMを増やしても、多言語検索の品質が低い問題は解決しません。メモリ圧迫によってテスト結果が歪むのを防ぐだけです。

16～32GBの範囲が当てはまらなくなる場合

16GBは、数十万件のコンパクトなベクトル、ディスク上のテキスト、小規模なローカルモデルを組み合わせる場合には現実的です。次元数768のベクトルが約100万件あり、複数のサービスを稼働させる場合、32GBのほうが安全な出発点です。次元数が大きい場合、複数のレプリカ、言語別のインデックス、または常駐する大型LLMを使用する場合は、64GB以上が妥当になる可能性があります。

HNSWインデックスのメモリ使用量に関する解説では、グラフ構造を含めると、生のベクトルバイト数がHNSW全体のメモリ使用量の一部にすぎない場合があることを示しています。実装上の選択肢があるため、普遍的な比率を前提にするのは危険です。

データベースが圧縮、メモリマッピング、積量子化を使用している場合や、グラフの設定が大きく異なる場合、これらの範囲は当てはまりません。インデックス構築中に古いコピーと新しいコピーを一時的に同時保持する場合も同様です。通常の検索時と再構築時のピークを分けて測定してください。

Featured

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

ZimaCube2

測定したワーキングセットからRAM容量を決める

まず生のベクトル量を計算し、最終的な次元数、メタデータ、インデックスパラメーターを使って、想定するコーパスの10％を取り込みます。ウォームアップ済みの検索、同時実行クエリ、1回の再構築後に、常駐メモリを測定します。線形に増加するコンポーネントだけを拡大計算し、そのうえで少なくとも25％の運用上の余裕を確保してください。

モデルとデータベースのピークが重なる可能性があるため、計画しているホームベクトルデータベースのワークロードと並行してプロトタイプを実行してください。スワップの発生状況とページフォールト率も記録しておきます。

外挿したピークが約12GB未満に収まる場合に限り16GBを選び、約24GB未満に収まる場合は32GBを選びます。再構築や同時推論がその境界を超える場合は、より大容量へ移行してください。チャンク化や埋め込みの次元数を変更した後は、再計算してください。