ホーム AI・LLM ベクトルDBサイズの計算 作成日: 2026年7月20日 21:33 ベクトルDBサイズの計算 入力 ベクトル件数1,000,000次元数1,5361値あたりのバイト数4インデックスのオーバーヘッド25 % AI・LLM ベクトルDBサイズの計算 ベクトル件数、ベクトルの次元数、1値あたりのバイト数、そして近似最近傍構造が加えるインデックスのオーバーヘッドから、埋め込みインデックスの保管容量を概算します。RAGやベクトル検索の容量設計に利用できます。 入力 ベクトル ベクトル件数 保管する埋め込みベクトルの件数で、通常は文書チャンク1件につき1つです。大規模なナレッジベースでは数百万件のベクトルを抱えることも珍しくありません。 次元数 ≥ 1 各ベクトルの長さで、埋め込みモデルによって決まります。よく使われる値は384、768、1,536です。次元が大きいほどニュアンスをとらえられますが、容量も増えます。 1値あたりのバイト数 ≥ 1 ベクトル内の各数値の保管サイズです。完全精度（float32）は4バイト、半精度（float16）は2バイト、8ビット量子化（int8）は1バイトで、わずかな精度と引き換えに容量を4分の1にできます。 インデックス インデックスのオーバーヘッド % 0 – 400 % 素のベクトルに加えて検索インデックスが要する追加の容量です。HNSWなどのグラフインデックスはベクトルごとに近傍リンクを保持し、一般的に20〜50パーセントを上乗せします。 結果 値を入力すると計算結果が表示されます。 合計容量 GB 素のベクトル ... に、インデックスのオーバーヘッド 25 % を加えると、保管容量は ... になります。 詳細 素のベクトル容量 GB ベクトルだけの容量です。1,536 個の値を持つベクトル 1,000,000 件を1値あたり 4 バイトで保管すると、インデックス構造を含まない素の容量は ... です。 共有 レポートを印刷 リセット 埋め込み この計算機を埋め込む プレビュー このコードをページに貼り付けると計算機を表示できます。 コードをコピー この計算を共有 このリンクを開くと、入力した値がそのまま表示されます。 リンクをコピー 共有する XFacebookLINE メール 最終更新: 2026-06-22 ベクトルデータベースのサイズとは ベクトルデータベースのサイズとは、埋め込みベクトルの集合と、その上に構築された検索インデックスを保持するために必要な保管容量のことです。検索システムが文書群を埋め込むと、各文書チャンクはベクトル、すなわち固定長の数値列になります。これらのベクトルはすべて、高速な類似検索を支えられる場所に置かれる必要があります。容量を左右するのは3つの要素です。ベクトルが何件あるか、各ベクトルがどれだけ長いか、そして各値が何バイトを占めるかです。 容量の積み上がり方 1つのベクトルは dimensions 個の数値からなる配列です。各数値は選んだ精度で保管されます。32ビット浮動小数点数なら4バイト、16ビット浮動小数点数なら2バイト、8ビット量子化整数なら1バイトです。1値のバイト数に次元数を掛けると1ベクトルのサイズになり、それにベクトル件数を掛けると素のペイロードになります。 素のベクトルの上にはインデックスが載ります。クエリを保管済みのすべてのベクトルと比較する方法は正確ですが、件数が数百万に達すると遅くなります。そのためベクトルデータベースは近似最近傍構造、最も一般的にはHNSWグラフを構築し、検索がベクトルのごく一部だけをたどればよいようにします。このグラフはベクトルごとに近傍リンクを保持し、それらのリンクは追加データとなって、通常は素の容量の5分の1から2分の1ほどを上乗せします。 計算式 次元 dd のベクトルが NN 件あり、各値が bb バイトを占めるとき、素の保管容量は次のとおりです。 Sraw=N⋅d⋅bS_{raw} = N \cdot d \cdot bSraw=N⋅d⋅b そして、割合で表したインデックスのオーバーヘッド oo を加えると合計は次のようになります。 S=Sraw⋅(1+o)S = S_{raw} \cdot (1 + o)S=Sraw⋅(1+o) 計算例 次元768のモデルから得たベクトルが2,400,000件あり、完全精度で保管して各値が4バイトを占め、35パーセントのオーバーヘッドを加えるHNSWインデックスを用いるとします。素の容量は次のとおりです。 Sraw=2,400,000×768×4=7,372,800,000 bytes≈7.37 GB\begin{aligned} S_{raw} &= 2{,}400{,}000 \times 768 \times 4 \\ &= 7{,}372{,}800{,}000 \text{ bytes} \\ &\approx 7.37 \text{ GB} \end{aligned}Sraw=2,400,000×768×4=7,372,800,000 bytes≈7.37 GB インデックスを加えると次のようになります。 S=7.37 GB×1.35≈9.95 GB\begin{aligned} S &= 7.37 \text{ GB} \times 1.35 \\ &\approx 9.95 \text{ GB} \end{aligned}S=7.37 GB×1.35≈9.95 GB 同じベクトルを8ビット量子化に切り替えて1値あたり1バイトにすると、素の容量はおよそ 1.84 GB、合計はおよそ 2.49 GB まで下がり、距離計算における精度のわずかな低下と引き換えに4分の1になります。 注意点と派生 この概算が対象とするのはベクトルとインデックスだけです。ほとんどのデータベースは、各ベクトルのそばに元のテキストチャンクとメタデータも保管します。短いチャンクではこの付随データがベクトル本体に匹敵することもあるため、ディスク容量全体を見積もる際は別途加算してください。インデックスを縮小する主な手立ては、次元削減と量子化の2つです。次元を半分にする、あるいはint8へ量子化すると、それぞれインデックスのオーバーヘッドを適用する前の素の容量を大きく削減できます。 活用の場面 保管容量はホスティングコストの入力となります。インデックスが何ギガバイトを占めるかが分かれば、ベクトルDBコストの計算 がそれを月額の請求へ変換します。ここでサイズを見積もるベクトルは、埋め込みコストの計算 で料金を計算する埋め込みのステップで生成されます。また、ベクトル件数は通常、元の文書をどう分割するかによって決まります。 よくある質問 (FAQ)インデックスがオーバーヘッドを加えるのはなぜですか素のベクトルを保管しておけば、クエリをすべてのベクトルと比較できますが、その全件走査は規模が大きくなると遅くなります。HNSWなどの近似最近傍インデックスは、検索がベクトルのごく一部だけをたどればよいように、たどりやすいグラフを構築します。このグラフはベクトルごとに近傍リンクを保持するため、ベクトル本体に上乗せされる追加データとなります。グラフの結びつきの密度にもよりますが、一般的に20〜50パーセントの増加になります。 量子化でどれくらい容量を節約できますか埋め込みの値は32ビット浮動小数点数、すなわち1値あたり4バイトで生成されます。これを16ビット浮動小数点数で保管すると容量は半分になり、8ビット整数への量子化では4分の1まで減ります。量子化は距離計算にわずかな丸め誤差を持ち込みますが、検索における順位の品質低下は通常ささいなものです。そのため、大きなインデックスを縮小する手段としてint8がよく使われます。1値あたりのバイト数の欄で、3つの選択肢を直接比べられます。 メタデータやテキストも含まれますかいいえ。この概算が対象とするのはベクトルと検索インデックスだけです。ほとんどのベクトルデータベースは、各ベクトルとともに元のテキストチャンクや、文書ID、タイトル、タグといったメタデータも保管します。短いチャンクではこの付随データがベクトルの容量に匹敵したり上回ったりすることもあるため、ディスク使用量全体を見積もる際は別途加算してください。 免責事項 これはベクトルとインデックスのおおよその容量を示す参考情報です。実際のデータベースは元のテキスト、メタデータ、内部の管理情報も保管し、特定のインデックスのオーバーヘッドはその設定によって変わります。結果は計画上の概算とみなし、正確なディスク容量とは扱わないでください。 次のおすすめ ベクトルDBコストの計算 保管容量、1ギガバイト月あたりの単価、そして定額のプラットフォーム料金から、マネージドサービス上でベクトルインデックスをホスティングする月額および年額のコストを概算します。RAGやベクトル検索の運用予算に利用できます。 詳しく解説埋め込みコストの計算 文書数、1文書あたりのトークン数、埋め込みモデルの100万トークン単価から、検索用に文書群をベクトル化する初回コストを概算します。RAGや埋め込み、ベクトル検索の予算見積もりに利用できます。 詳しく解説 200+ ツール · 10 言語対応 · 完全無料 コスト・料金の他の計算 1ドルあたりトークン数の計算GPU クラウド費用を計算GPU利用率コストの計算LLMファインチューニング費用の計算LLMレート制限の計画ベクトルDBサイズの計算 +20 more Show less LLM学習のカーボンフットプリントの計算LLM学習時間とコストの計算LLM月額コストの計算エージェントコストの計算コンテキストコストの増加の計算コンテキスト長の判定システムプロンプトの償却コストトークンから単語数への変換トークンコスト計算バッチAPIの節約額の計算プロンプトキャッシュの節約額の計算ベクトルDBコストの計算音声合成コストの計算音声文字起こしコストの計算画像生成コストの計算関数呼び出しのトークンオーバーヘッド構造化出力のトークンオーバーヘッド自己ホストとAPIの損益分岐の計算推論エネルギーコストの計算埋め込みコストの計算 AI・LLMの他のカテゴリ 推論・サービング トークンあたりFLOPsの計算バッチ推論スループットの計算モデルFLOPs利用率の計算画像入力トークン数の計算実効トークン毎秒の計算推論スループットの計算推論レイテンシの計算投機的デコーディングの高速化の計算学習・スケーリング Chinchilla最適トークン数LLMトレーニングVRAMの計算LoRA の学習パラメータ数を計算データセットのトークン数の計算データ並列スケーリングの計算パイプライン並列のバブルの計算学習FLOPsの計算学習率ウォームアップの計算計算最適なモデルサイズ計算予算から求めるエポック数勾配累積のメモリ計算実効バッチサイズの計算ハードウェア・メモリ KVキャッシュサイズの計算LLM推論のVRAM計算MoE のアクティブパラメータ数を計算Transformerのパラメータ数の計算アテンションメモリの計算モデルに必要なGPU台数の計算モデルのダウンロード時間の計算量子化によるモデルサイズの計算RAG・埋め込み RAGチャンク分割の設計評価 A/Bテスト有意性の計算LLM評価のサンプルサイズの計算pass@k の計算パープレキシティの計算すべてのツール コサイン類似度の計算 この計算機は役に立ちましたか？ 役に立った 改善が必要 改善が必要 どのような点が改善されると良いですか？ フィードバックを送信 Powered by OneCalc ↗
最終更新: 2026-06-22 ベクトルデータベースのサイズとは ベクトルデータベースのサイズとは、埋め込みベクトルの集合と、その上に構築された検索インデックスを保持するために必要な保管容量のことです。検索システムが文書群を埋め込むと、各文書チャンクはベクトル、すなわち固定長の数値列になります。これらのベクトルはすべて、高速な類似検索を支えられる場所に置かれる必要があります。容量を左右するのは3つの要素です。ベクトルが何件あるか、各ベクトルがどれだけ長いか、そして各値が何バイトを占めるかです。 容量の積み上がり方 1つのベクトルは dimensions 個の数値からなる配列です。各数値は選んだ精度で保管されます。32ビット浮動小数点数なら4バイト、16ビット浮動小数点数なら2バイト、8ビット量子化整数なら1バイトです。1値のバイト数に次元数を掛けると1ベクトルのサイズになり、それにベクトル件数を掛けると素のペイロードになります。 素のベクトルの上にはインデックスが載ります。クエリを保管済みのすべてのベクトルと比較する方法は正確ですが、件数が数百万に達すると遅くなります。そのためベクトルデータベースは近似最近傍構造、最も一般的にはHNSWグラフを構築し、検索がベクトルのごく一部だけをたどればよいようにします。このグラフはベクトルごとに近傍リンクを保持し、それらのリンクは追加データとなって、通常は素の容量の5分の1から2分の1ほどを上乗せします。 計算式 次元 dd のベクトルが NN 件あり、各値が bb バイトを占めるとき、素の保管容量は次のとおりです。 Sraw=N⋅d⋅bS_{raw} = N \cdot d \cdot bSraw=N⋅d⋅b そして、割合で表したインデックスのオーバーヘッド oo を加えると合計は次のようになります。 S=Sraw⋅(1+o)S = S_{raw} \cdot (1 + o)S=Sraw⋅(1+o) 計算例 次元768のモデルから得たベクトルが2,400,000件あり、完全精度で保管して各値が4バイトを占め、35パーセントのオーバーヘッドを加えるHNSWインデックスを用いるとします。素の容量は次のとおりです。 Sraw=2,400,000×768×4=7,372,800,000 bytes≈7.37 GB\begin{aligned} S_{raw} &= 2{,}400{,}000 \times 768 \times 4 \\ &= 7{,}372{,}800{,}000 \text{ bytes} \\ &\approx 7.37 \text{ GB} \end{aligned}Sraw=2,400,000×768×4=7,372,800,000 bytes≈7.37 GB インデックスを加えると次のようになります。 S=7.37 GB×1.35≈9.95 GB\begin{aligned} S &= 7.37 \text{ GB} \times 1.35 \\ &\approx 9.95 \text{ GB} \end{aligned}S=7.37 GB×1.35≈9.95 GB 同じベクトルを8ビット量子化に切り替えて1値あたり1バイトにすると、素の容量はおよそ 1.84 GB、合計はおよそ 2.49 GB まで下がり、距離計算における精度のわずかな低下と引き換えに4分の1になります。 注意点と派生 この概算が対象とするのはベクトルとインデックスだけです。ほとんどのデータベースは、各ベクトルのそばに元のテキストチャンクとメタデータも保管します。短いチャンクではこの付随データがベクトル本体に匹敵することもあるため、ディスク容量全体を見積もる際は別途加算してください。インデックスを縮小する主な手立ては、次元削減と量子化の2つです。次元を半分にする、あるいはint8へ量子化すると、それぞれインデックスのオーバーヘッドを適用する前の素の容量を大きく削減できます。 活用の場面 保管容量はホスティングコストの入力となります。インデックスが何ギガバイトを占めるかが分かれば、ベクトルDBコストの計算 がそれを月額の請求へ変換します。ここでサイズを見積もるベクトルは、埋め込みコストの計算 で料金を計算する埋め込みのステップで生成されます。また、ベクトル件数は通常、元の文書をどう分割するかによって決まります。 よくある質問 (FAQ)インデックスがオーバーヘッドを加えるのはなぜですか素のベクトルを保管しておけば、クエリをすべてのベクトルと比較できますが、その全件走査は規模が大きくなると遅くなります。HNSWなどの近似最近傍インデックスは、検索がベクトルのごく一部だけをたどればよいように、たどりやすいグラフを構築します。このグラフはベクトルごとに近傍リンクを保持するため、ベクトル本体に上乗せされる追加データとなります。グラフの結びつきの密度にもよりますが、一般的に20〜50パーセントの増加になります。 量子化でどれくらい容量を節約できますか埋め込みの値は32ビット浮動小数点数、すなわち1値あたり4バイトで生成されます。これを16ビット浮動小数点数で保管すると容量は半分になり、8ビット整数への量子化では4分の1まで減ります。量子化は距離計算にわずかな丸め誤差を持ち込みますが、検索における順位の品質低下は通常ささいなものです。そのため、大きなインデックスを縮小する手段としてint8がよく使われます。1値あたりのバイト数の欄で、3つの選択肢を直接比べられます。 メタデータやテキストも含まれますかいいえ。この概算が対象とするのはベクトルと検索インデックスだけです。ほとんどのベクトルデータベースは、各ベクトルとともに元のテキストチャンクや、文書ID、タイトル、タグといったメタデータも保管します。短いチャンクではこの付随データがベクトルの容量に匹敵したり上回ったりすることもあるため、ディスク使用量全体を見積もる際は別途加算してください。 免責事項 これはベクトルとインデックスのおおよその容量を示す参考情報です。実際のデータベースは元のテキスト、メタデータ、内部の管理情報も保管し、特定のインデックスのオーバーヘッドはその設定によって変わります。結果は計画上の概算とみなし、正確なディスク容量とは扱わないでください。
