サイジングガイド・10分で読了

# 1台のGPUが実際に対応できる人数。

モデルを収容できるマシンが、そのままユーザーに対応できるマシンとは限りません。重みは一度だけ支払う通行料です。それを差し引いた余りが、人に対応するために使える予算のすべてです。容量を決めるのはカードの大きさではなく、その余りです。そして、その余りはメモリそのものよりもはるかに速く変化します。

簡潔な答え

- **容量を決めるのは余り、カードではない:** **Llama 3.3 70B**は4-bitで、誰か1人に提供する前の時点で**40 GB**を確保します。それ以降は、同時リクエストが1件増えるごとに**2.9 GB**ずつ増えていきます。
- **メモリが二重に効いてくる理由:** 同じカードのまま48 GBから240 GBに増やすと、メモリは5.0×倍になり、席数は**35×**倍になります。重みはすでに支払い済みです。
- **候補の中で最も割に合わない選択:** [NVIDIA L40S](https://gpuserver.io/ja/gpu/l40s)は月額**$714**で2件の同時リクエストを収容します—1席あたり**$357.00**です。
- **最良の選択肢は、費用も安い:** [4 × NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4)は**$564**で19を収容します—1席あたり**$29.68**で、請求書はより安く済みます。

## 要点

あるモデルが*収まるか*どうかを教えてくれるガイドはどれも、リクエスト1件についての問いに答えているにすぎません。製品はリクエスト1件では成り立ちません。2人が同時にエンドポイントを使った瞬間、マシンは会話のコピーをメモリ上にもう1つ必要とします。3人目、40人目となれば、その分だけさらに必要になります。一方で、重みそのものはただ1つだけ保存されていれば済みます。

つまり、対応できる人数を決めるのは、カードの大きさそのものではありません。カードの大きさ*からモデルを引いた値*を、会話1件あたりのコストで割った値です。この2つの数値はどちらも注文前からわかっているため、容量は機械学習の中でも数少ない、紙の上で計算するだけで正しく求められるものの1つです。

**重みは通行料です。**一度、入り口で支払われるだけで、トラフィックの量には左右されません。ユーザー数が増えても増加せず、二度と戻ってくることもありません。

**KVキャッシュが賃料です。**同時リクエストごとに、そのリクエストが開いている間ずっと発生し、会話が長くなるほど増えていきます。

**容量とは、余りを賃料で割った値です。**だからこそ、メモリが2倍のマシンが、単に2倍ではなく10倍の人数に対応できることも珍しくありません。

**そして、収まる最安のマシンがたいてい最も割高になる理由です。**それが収まるのは余りがほとんどないからです。実際にお金を払って買っているのは、その余った部分だけなのです。

以下はすべて、[コンフィギュレーター](https://gpuserver.io/ja/configure)と同じ計算式を、同じカタログに対して、4-bit・8kコンテキストで実行した結果です。メモリの計算式そのものが初めてという方は、[専用のガイド](https://gpuserver.io/ja/guides/vram-sizing)をご覧ください。このページが扱うのは、そこに2人目以降が現れたときに何が起こるか、という話です。

## 重みを差し引いたあとの余り

このサイトの基準モデルを、同じカードで構成されたあらゆるサイズのノードに載せてみます。シリコンも、カードあたりの価格も、その他すべて同じで、変わるのはメモリの量だけです。最後の2つの列が、まったく異なる速度で動く様子に注目してください。

**同一カードで構成された各ノードにおける、Llama 3.3 70Bの4-bit・8kコンテキスト時の同時リクエスト数**

| ノード | メモリ | 重みを差し引いた余り | 同時リクエスト数 | 月額 |
|---|---|---|---|---|
| [NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4) | 24 GB | — | 収容できない | $125 |
| [2 × NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4) | 48 GB | 8 GB | 2 | $285 |
| [4 × NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4) | 96 GB | 56 GB | 19 | $564 |
| [8 × NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4) | 192 GB | 152 GB | 52 | $1,106 |
| [10 × NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4) | 240 GB | 200 GB | 69 | $1,371 |

最初の行がすべてを物語っています。重みすら収容できないカードは、誰にも対応できません。しかもそれは僅差の話ではありません。それ以降の行では、メモリは均等な幅で増えていく一方、席数は加速しながら増えていきます。40 GBの通行料は最初の行で支払われ、その後は二度と発生しないからです。

**計算式を1行で。** `seats = (memory − weights) ÷ cache_per_request`。Llama 3.3 70Bの4-bitでは、これは40 GBの通行料と、開いている会話1件あたり2.9 GBの賃料になります。割る前に引いてください。順序を逆にすると、デモ用に選んだマシンが本番環境で容量不足だと判明する、という事態を招きます。

## ユーザー1人あたりの実際のコスト

続いて、同じモデルを購入者の視点、つまり価格が安い順に並べ替えます。最後の列は、月額価格をそのマシンが同時に収容できる人数で割った値です。デモ以上のものを構築する場合、2台のマシンを公平に比較できるのはこの列だけです。

1つ前提を明示しておきます。これによってすべての数値が変わるからです。各席数は、ノード全体に分割したモデルの*1インスタンス*分です。これは`--tensor-parallel-size`で得られる構成のことです。重みは一度だけ保存され、各カードは自らの余ったメモリをすべて同じ会話用プールに提供します。同じノード上で2つの独立したコピーを実行すると、通行料を2回支払うことになり、合計の席数はかえって少なくなります。

**Llama 3.3 70Bを収容できる最も安い10ノードと、同時ユーザー1人あたりの費用**

| ノード | メモリ | 月額 | 同時リクエスト数 | ユーザーあたり |
|---|---|---|---|---|
| [2 × NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4) カード2枚 · 1枚あたり24 GB | 48 GB | $285 | 2 | $142.50 |
| [NVIDIA RTX A6000](https://gpuserver.io/ja/gpu/rtx-a6000) カード1枚 · 48 GB | 48 GB | $286 | 2 | $143.00 |
| [2 × NVIDIA RTX 4090](https://gpuserver.io/ja/gpu/rtx-4090) カード2枚 · 1枚あたり24 GB | 48 GB | $416 | 2 | $208.00 |
| [4 × NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4) カード4枚 · 1枚あたり24 GB | 96 GB | $564 | 19 | $29.68 |
| [2 × NVIDIA RTX A6000](https://gpuserver.io/ja/gpu/rtx-a6000) カード2枚 · 1枚あたり48 GB | 96 GB | $597 | 19 | $31.42 |
| [2 × NVIDIA RTX 5090](https://gpuserver.io/ja/gpu/rtx-5090) カード2枚 · 1枚あたり32 GB | 64 GB | $692 | 8 | $86.50 |
| [NVIDIA L40S](https://gpuserver.io/ja/gpu/l40s) カード1枚 · 48 GB | 48 GB | $714 | 2 | $357.00 |
| [2 × NVIDIA A100 PCIe](https://gpuserver.io/ja/gpu/a100-40gb) カード2枚 · 1枚あたり40 GB | 80 GB | $802 | 13 | $61.69 |
| [4 × NVIDIA RTX 4090](https://gpuserver.io/ja/gpu/rtx-4090) カード4枚 · 1枚あたり24 GB | 96 GB | $814 | 19 | $42.84 |
| [NVIDIA A100 PCIe](https://gpuserver.io/ja/gpu/a100-80gb) カード1枚 · 80 GB | 80 GB | $1,091 | 13 | $83.92 |

価格の列と合わせて、色のついた2つのセルを見てください。NVIDIA L40Sは月額$714で2を収容し、4 × NVIDIA L4は$564（*より安い金額*）で19を収容します。つまり、0.79×の請求書で10×の席数が得られるということです。それでも多くの候補リストに残るのは高い方です。理由は、そちらの方がモデルを1枚のカードに収められるからです。

**これは、1枚のカードで構成されるマシンに反対する主張ではありません。** 1枚のカードに収まるモデルなら、シャーディングもインターコネクトもテンソル並列のフラグも不要です。4枚のカードに分割した同じモデルよりも、1人のユーザーに対して速く応答します。負荷が一度に1件のリクエストだけ、たとえばバッチジョブや社内向けツール、デモなら、そのマシンを買うのが正解で、ユーザーあたりの列を気にする必要はありません。この列が重要になるのは、複数の人が同時にやって来たときからです。そこから先は非常に重要になります。

最初の10行だけでなくカタログ全体で見ると、このモデルにおける1席あたりの最安価格は、月額$2,239の[8 × NVIDIA RTX A6000](https://gpuserver.io/ja/gpu/rtx-a6000)です。同時リクエストは119件、1件あたり$18.82になります。これは上記の候補よりもはるかに高額な請求書になりますが、それでも、ユーザーを1人収容する最も安い方法という点は変わりません。これが、製品としてサイジングしているのか、それとも試作品としてサイジングしているのかを決める一文です。

## コンテキスト長はもう一つの倍率要因

ここまでの内容はすべて、8kのコンテキストを前提としていました。この前提は、マシン選びそのものよりも大きな影響を及ぼしています。キャッシュはユーザーごとだけでなく、トークンごとにも発生するため、会話をどれだけ長く続けさせるかによって、同じノードでも収容できる人数はまったく違ってきます。

1台のマシン、4つのモデル、4つのコンテキスト長です。使用するノードは月額$1,106の[8 × NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4)です。これは、4つのモデルすべてを同時に収容できる、当社カタログの中で最も安いノードです。以下の数値はすべて、同じメモリを基準に測定されています。

**1ノードあたりの同時リクエスト数（モデル・コンテキスト長別、4-bit）**

| モデル | トークンあたりのキャッシュ | 4k | 8k | 32k | 128k |
|---|---|---|---|---|---|
| Llama 3.1 8B 4 GBの重み | 128 KiB | 325 | 162 | 40 | 10 |
| Qwen 3 32B 16 GBの重み | 256 KiB | 150 | 75 | 18 | 4 |
| Llama 3.3 70B 35 GBの重み | 320 KiB | 105 | 52 | 13 | 3 |
| Qwen 3 235B-A22B (MoE) 118 GBの重み | 188 KiB | 67 | 33 | 8 | 2 |

マシン自体は何も変えていないのに、Llama 3.3 70Bは同時ユーザー数が105から3へ、35×倍に増えます。理由は、コマンドラインで設定する1つの数値だけです。ハードウェアは何も変わっていません。

ここから2つのことが言えます。1つ目は、読むべきコンテキストの列は、モデルカードが謳う値ではなく、実際に提供する値だということです。128kに*対応*しているモデルだからといって、その分を確保しなければならないわけではありません。2つ目は、トークンあたりのキャッシュ量は、パラメータ数が近いモデル同士でも大きく異なるということです。これはパラメータ数ではなく、アテンション設計によって決まるためです。[その表の中で最大のモデルほど、キャッシュは最小クラスに入ることも少なくありません](https://gpuserver.io/ja/guides/mixture-of-experts)。これは、この分野全体の中でも最も直感に反する事実です。

## 容量を買い戻す4つの方法

効果の大きさに対してコストが小さい順に並んでいます。最初の1つはほぼ無料なのに、見落とされていることがほとんどです。

宣言するコンテキストに上限を設ける 無料で、しかも効果は最大 提供用のスタックは、実際に使う長さではなく、宣言した最大長に対してキャッシュを確保します。128kを宣言しておきながら実際には8kしか提供しない場合、必要な量の16倍のメモリを無駄にすることになります。そのメモリこそが、収容できる席数のすべてだったはずです。最初の時点で`--max-model-len`を実際の上限に設定してください。

キャッシュを8-bitに量子化する 席数をおよそ2倍にする *重み*を4-bitに量子化しても、キャッシュには何の影響もありません。一般的などのスタックでも、明示的に指定しない限り16-bitのままです。指定するのはフラグ1つだけで、チャット用途では品質への影響はほとんどの場合見えないほど小さく、その結果を示したのが以下の表です。

重みをさらに量子化する 効果は一度きりで、そこで終わる 重みを半分にすると、その差分がそのままキャッシュに回るため、混み合ったマシンでも席を増やせます。ただし、これは固定された通行料に対する一度きりの効果です。品質という代償も伴います。[どのフォーマットにどれだけの代償があるか](https://gpuserver.io/ja/guides/awq-vs-gptq-vs-fp8)は、それ自体が別の判断になります。

借りているのは余り、カードではない 構造そのものを変える対策 上に挙げた手段はどれも、あくまで限界的な効果しかありません。重みを大きく上回るメモリを持つノードに移行することは、問題の性質そのものを変えます。そしてそれは、4つの手段のうち、成長するほど効果が積み上がっていく唯一のものです。

**同一ノードにおける16-bitキャッシュ時と8-bitキャッシュ時の同時リクエスト数（8kコンテキスト時）**

| モデル | 16-bitキャッシュ | 8-bitキャッシュ | 増加席数 |
|---|---|---|---|
| Llama 3.1 8B | 162 | 325 | +163 |
| Qwen 3 32B | 75 | 150 | +75 |
| Llama 3.3 70B | 52 | 105 | +53 |
| Qwen 3 235B-A22B (MoE) | 33 | 67 | +34 |

同じノード、同じ重み、同じ費用です。変わるのはキャッシュを保存する精度だけですが、それがチームに対応できるマシンと、製品に対応できるマシンとの違いを生みます。

## 席数とサービスの質は別物

上記の数値をもとに何かをサイジングする前に、1つ訂正しておきます。これは、このページの内容を正直なものに保つための訂正です。ここでの数値はすべて、マシンが*開いたまま*保持できる会話の数を数えたものです。そのすべてに速く応答できることを保証するものではありません。

メモリと帯域幅は、それぞれ別の上限です。[8 × NVIDIA L4](https://gpuserver.io/ja/gpu/nvidia-l4)では、Llama 3.3 70Bが52件の同時会話を収容できる一方で、そのマシンを1人だけで使った場合は、およそ17トークン/秒になります。52席をすべて埋めても、各ユーザーが17トークン/秒を得られるわけではありません。生成処理は同じメモリ帯域幅を共有するため、バッチ処理によって合計は増えても、ユーザー1人あたりの速度は下がります。帯域幅の上限は、メモリの上限よりもずっと手前で訪れます。

**席数は上限として使うもの、目標にするものではない。** 最後の1席まで埋まったマシンは、誰もが待たされているマシンです。席数を見れば、そもそもどのハードウェアが必要な同時実行数に対応できるかがわかります。対応できないマシンを除外すると、候補のほとんどが消えることになります。そのうえで、ユーザー1人あたりに本当に必要な速度を測り、上限から余裕を持たせて下げてください。上限ぎりぎりでサイジングすることは、キャッシュを完全に無視することに次いで、マシン選びを誤る2番目に多い原因です。

良い知らせは、この2つの上限がおおむね連動していることです。重みを差し引いたあとの余りが大きいマシンは、一部の例外を除けば、帯域幅も大きいマシンでもあります。余裕を基準に選んでも、速度を犠牲にすることはほとんどありません。最終的に選んだマシンで[提供用スタックを構築する](https://gpuserver.io/ja/guides/serve-llama-70b)方法は別のガイドで扱っており、ここで挙げた数値が実際に生きてくるのは、そこで扱うフラグの設定によってです。

## ユーザー数に応じて選ぶ

順番に並んでいます。該当する負荷を説明している最初の項目で読むのをやめてください。

1. **一度に1件のリクエストしか扱わない場合。**バッチジョブ、社内向けツール、開発者1人での利用です。モデルを1枚のカードに収容できる最も安いマシンを買えば十分で、ここから先を読む必要はありません。このページの各列が答えているのは、この場合には関係のない問いです。
2. **ときどき、少人数が使う場合。**チーム向けツールや、立ち上げたばかりの製品です。見るべきはユーザー登録数ではなく、ピーク時の同時リクエスト数です。登録ユーザーが100人いても、同時に使うのはほんの数人にとどまることがほとんどです。そのピークを余裕を持って上回る席数のマシンの中から、最も安いものを選んでください。
3. **実際のトラフィックがある本番の製品の場合。**カタログを価格ではなく1席あたりの価格で並べ替え、コンテキストは実際に提供する長さに制限し、キャッシュは8-bitまで下げてください。選ばれるのは、月額価格だけを見ていたら候補にすら入らなかったはずのマシンになるはずです。
4. **長い文書や長い会話を扱う場合。**まずコンテキストの表を読み、マシンの表はそのあとで読んでください。32k以上になるとキャッシュの支配力があまりに大きくなり、モデルの選択よりも、その背後にあるアテンション設計の方が重要になります。
5. **急激で予測しづらいトラフィックの場合。**失敗が許されないピークに合わせてサイジングしてください。キャッシュが尽きたときに借りてくることはできず、会話の置き場所がないリクエストはキューで待たされることになります。ピークがまれにしか来ず、しかも非常に大きい場合は、月に2回しか起きないスパイクに合わせてマシンをサイジングするより、[超過分をトークン課金のAPIに任せる](https://gpuserver.io/ja/guides/api-vs-self-hosting)方が安く済みます。

どの項目で読むのをやめたとしても、まず最初に引き算をしてください。マシンのメモリから、実際に提供する精度でのモデルの重みを差し引き、余りを確認します。その余りこそが、実際に借りている対象です。[コンフィギュレーター](https://gpuserver.io/ja/configure)は、当社が運用するすべてのノードに対して同じ計算を実行し、[1か月あたりの費用](https://gpuserver.io/ja/guides/monthly-vs-hourly)は別途算出されます。

## マシンはモデルではなく、ユーザー数を基準にサイジングする。

コンフィギュレーターには、当社が貸し出しているすべてのノードが登録されており、このページと同じメモリ計算を実行し、モデルを読み込んだあとの余りを、支払いの前に示します。

[コンフィギュレーターを開く](https://gpuserver.io/ja/configure) [ガイドを読む](https://gpuserver.io/ja/guides)

## その他のガイド

- [コスト · 6分 月額レンタルが時間貸しに勝つのはどんな時か 実際の数字で算出した損益分岐点、時間単価が請求書が来るまで隠している3つのコスト、そして見積もりを3倍に膨らませるアイドル時間の落とし穴。 ガイドを読む](https://gpuserver.io/ja/guides/monthly-vs-hourly)
- [コスト · 9分 セルフホスティングとトークン課金APIの比較 トークン課金APIとGPUレンタルの損益分岐点を、自社の価格とスループットで算出。そして、その計算が見落としている4つの要素。 ガイドを読む](https://gpuserver.io/ja/guides/api-vs-self-hosting)
- [実践 · 11分 Llama 3.3 70Bを1ノードで提供する 納品されたマシンから、OpenAI互換エンドポイントまで。重要なフラグと、気づかぬうちにスループットを半減させる2つのフラグを解説します。 ガイドを読む](https://gpuserver.io/ja/guides/serve-llama-70b)

---

出典: https://gpuserver.io/ja/guides/concurrent-users/。このファイルはウェブサイトと同じデータから生成されています。ここに記載された数値がページの内容と異なる場合、ページの内容が正となり、このファイルは古い情報です。正式な出典はhttps://gpuserver.io/です。