How do I calculate the VRAM a self-hosted LLM needs?

Three terms. Model weights are parameters multiplied by bytes per parameter — a 70B model at FP16 is about 140GB, at INT8 about 70GB, at INT4 about 35GB. The KV cache is 2 (one key, one value) x layers x KV heads x head dimension x bytes per element, per token, and that whole figure is multiplied again by your context length and by the number of sequences in flight. Then subtract 10-20% for CUDA context, activations, fragmentation and the runtime itself. Weights are a fixed cost you pay once; the KV cache is the term that scales with traffic, and it is the one that decides your concurrency ceiling.

Why does grouped-query attention matter so much for concurrency?

Because the KV cache scales with the number of KV heads, not attention heads. A model with 64 attention heads but only 8 KV heads — standard grouped-query attention in current open-weight models — has an eight-times smaller KV cache than the equivalent multi-head model, which translates almost one-for-one into eight times the concurrent sequences on identical hardware. This is why a modern 70B model can serve more simultaneous users than an older 13B model in some configurations. If you are sizing hardware from a parameter count alone you will get the answer badly wrong; enter the KV head count from the model's config file.

When is self-hosting actually cheaper than paying per token?

Only at high, sustained utilisation. A rented GPU bills every hour whether or not a request arrives, so your effective cost per million tokens is the hourly rate divided by the tokens you actually generate in that hour. At full saturation the economics are often excellent; at 20% duty cycle your real cost per million tokens is five times the headline figure and almost always loses to an API. The break-even throughput shown by this calculator is the number of tokens per second you must sustain, on average and not at peak, for self-hosting to beat the API rate you entered. If your traffic is bursty, compare against that average rather than your peak.

LLM VRAM および同時実行計算ツール | KV キャッシュのサイズを 100 万ドルあたりのトークンに設定

LLM VRAM および同時実行計算ツール

✓ 最終確認日: 2026-07-23· 出典: 公開されたモデル構成 + 公開 GPU レンタル料金· 変更報告→

セルフホスティングの決定はすべて同じ質問から始まりますが、その質問に適切に答える人はほとんどいません。つまり、この GPU は実際に一度に何人にサービスを提供できるのか、ハードウェアを使用するかどうかに関係なく時間単位で請求すると、100 万トークンの実際のコストはいくらになるのかなどです。

ウェイトは簡単な部分です。 モデルのフィッティングは 1 行の計算であり、ほとんど何もわかりません。 8 人のユーザーにサービスを提供できるか、80 人のユーザーにサービスを提供できるかを決定するのは、KV キャッシュ (コンテキストの長さに応じて拡張されるメモリ) です。 そして 飛行中のすべての同時シーケンスで。このツールは両方のサイズを測定し、得られた容量を API 請求に対して保持できる 100 万トークンあたりのコストに変換します。

コンテキスト長ごとの同時実行性とユニットコスト

同じモデル、同じ GPU、同じ金額 - 各リクエストのコンテキストウィンドウのみが変更されます。これは、「max_model_len を上げるだけ」を容量の決定に変える表です。

コンテクスト

KV / リクエスト

同時

トークン/秒の推定値

$ / 100万トークン

利用率の崖

GPU はトークンではなく時間単位で請求されます。本当の単価は、見出しの数字をデューティサイクルで割ったものです。これが、ほとんどのセルフホスティングビジネスケースが静かに崩壊する場所です。

平均使用率

有効トークン/秒

$ / 100万トークン

対 API

モデルをフィッティングすることとモデルを提供することは同じではありません

どこにでもあるアドバイスは、INT4 の 70B モデルには約 35GB が必要なので、1 枚の 80GB カードに余裕を持って収まるということです。それは真実であり、アイドル状態にあるモデルを記述しているため、ほとんど役に立ちません。リクエストが到着すると、実行中のすべてのシーケンスが独自の KV キャッシュを割り当てます。層ごとに 2 つのテンソルがあり、KV ヘッドとヘッドの次元の積でサイズ設定され、そのシーケンスのコンテキスト内のすべてのトークンに対して保持されます。 80 レイヤー、8 KV ヘッド、128 次元、FP16 では、トークンあたり 327,680 バイト (1 メガバイトの 3 分の 1) となり、8K コンテキストでは約 2.7 GB になります。 同時リクエストごと。非常に快適に見える 45GB のヘッドルームには、およそ 12 人のユーザーが収容でき、13 人目はキューに入れられます。推論のためのキャパシティプランニングは KV キャッシュプランニングです。ウェイトはエントリー料金を設定するだけです。

KVヘッド数は実際に移動する数です

グループ化されたクエリへの注目こそが、現代のオープンウェイトモデルがそもそも提供可能である理由であり、パラメーター数からハードウェアのサイジングを行う人は、この注目を常に見逃しています。 64 個のアテンションヘッドと 8 個の KV ヘッドを備えたモデルは、同等のマルチヘッド設計の 8 分の 1 のキャッシュを保存します。これは、同じカード上でほぼ直線的に 8 倍の同時実行性に変換されます。上記の 13B マルチヘッドプリセットを 70B プリセットと比較してみてください。多くの場合、小さいモデルの方が最初にメモリが不足しますが、バイトがどこに行くのかを確認するまでは直感的ではありません。 KV 精度を FP8 に半分にすると、適度な精度コストで同時実行性が再び 2 倍になります。これら 2 つのスイッチは、より大きなカードを購入するよりもはるかに多くの容量を移動でき、費用はかかりません。

ハードウェアではなく、使用率が経済性を決定します

最後のテーブルは、ほとんどの自己ホスティングプロジェクトを正直に終了するテーブルです。 H100 のレンタル料金は、交通量のない午前 3 時にピーク時と同じ 1 時間あたり 2.50 ドルであるため、100 万トークンあたりの実際のコストは、ヘッドラインの数値を平均デューティサイクルで割ったものとなります。使用率 20% でサービスを提供すると、計算ツールの楽観的な数字が示す金額の 5 倍の料金を支払うことになります。また、小型モデルの汎用 API レートと比較すると、それに近い金額ではありません。セルフホスティングは、持続的で飽和した予測可能なボリューム、API が満たせないデータ常駐やレイテンシの制約があるワークロード、および誰もトークンごとに販売していないモデルで勝利を収めます。突発的なトラフィックで損失が発生することもあれば、請求書がフラットで無駄な容量が品目として表示されないため、静かに損失が発生することもあります。結論をクロスチェックします。セルフホスト型 LLM と API の計算ツール、ハードウェア自体の価格を GPU推論コスト計算ツール答えが限界に達している場合は、小型化されたモデルまたはプロンプトキャッシュラックを購入する前に。

この計算機の仕組み

重みはパラメータ×パラメータごとのバイト数です。トークンあたりの KV キャッシュは 2 × レイヤー × KV ヘッド × ヘッドの寸法 × KV バイトです。各同時シーケンスが保持するメモリを与えるコンテキスト長を乗算します。使用可能なメモリは、GPU 全体の VRAM の合計からランタイムオーバーヘッドの割合を差し引いたもので、重みをシーケンスごとの数値で割って同時実行の上限を求めた後に残ったものになります。 100 万トークンあたりのコストは、1 時間あたりの GPU 請求額を 1 時間で実際に生成するトークンで割ったものです。そのため、使用率の表がメモリの表と同じくらい重要になります。

よくある質問

セルフホステッド LLM に必要な VRAM はどのように計算すればよいですか?

3 つの用語: モデルの重み (パラメーター × パラメーターごとのバイト数)、KV キャッシュ (2 × レイヤー × KV ヘッド × ヘッドの寸法 × バイト、トークンごと、コンテキスト長の倍、同時シーケンスの倍)、CUDA コンテキスト、アクティベーション、フラグメンテーションの 10 ～ 20% のオーバーヘッド。ウェイトは固定の参加費です。 KV キャッシュは、トラフィックに応じて拡張し、同時実行の上限を設定する用語です。

グループ化されたクエリの注意が同時実行にとってそれほど重要なのはなぜでしょうか?

KV キャッシュはアテンションヘッドではなく KV ヘッドに応じて拡張されるためです。 64 個のアテンションヘッドと 8 KV ヘッドを備えたモデルは、同等のマルチヘッドよりもキャッシュが 8 倍小さく、同じカード上のほぼ 1 対 1 を 8 倍の同時シーケンスに変換します。パラメーター数からではなく、モデルの構成ファイルからのサイズ。

セルフホスティングがトークンごとに支払うよりも実際に安くなるのはどのような場合ですか?

継続的な使用率が高い場合のみ。レンタルされた GPU は、リクエストが到着するかどうかに関係なく 1 時間ごとに請求されるため、20% のデューティサイクルでは、100 万トークンあたりの実際のコストは見出しの数字の 5 倍になります。上記の損益分岐点スループットは、セルフホスティングが入力した API レートを上回るために、ピーク時ではなく平均して維持する必要がある 1 秒あたりのトークンです。