モデルが実際に必要とするVRAMの量

計算式

ここには、2つ目のモデルに直面しても通用する経験則はありません。計算全体はわずか3行なので、係数を鵜呑みにするよりも、実際に計算する価値があります。

# 1. Weights
weights_gb   = parameters_in_billions × bytes_per_parameter

# 2. KV cache, per token — then multiplied by the context you serve
bytes_per_tok = 2 × layers × kv_heads × head_dim × cache_bytes
cache_gb      = bytes_per_tok × context_tokens × batch / 1024³

# 3. Everything else
total_gb      = (weights_gb + cache_gb) × 1.15

2となっているのは、トークンごとにKとVという2つのテンソルがあるためです。bytes_per_parameterはBF16で2、FP8で1、4-bitで0.5です。cache_bytesは別枠の数値であり、この区別を怠ることが誤った答えの最も多い原因です。詳しくは下記をご覧ください。

重み

簡単な半分です。パラメータ数に対して正確に線形であり、決めるべきことは精度だけです。

4-bit量子化は品質を犠牲にしますが、その度合いは手法よりもモデルに大きく左右されます。カード1枚と4枚の違いを生むのであれば理にかなったトレードオフですが、すでに余裕がある状況では割に合いません。

KVキャッシュ

難しい半分であり、あるマシンが4kでは十分でも128kでは全く足りないかを決めるのはこちらです。これはレイヤー数とKVヘッド数に左右され、モデルの大きさには左右されません。

最初の列より先に、最後の列を読んでください。4kコンテキストでは、ここに挙げたどのモデルでもキャッシュは誤差の範囲です。128kになると、4-bitの70Bモデルの重みよりも大きくなります。DeepSeek V3が例外なのは、その潜在アテンションが設計上キャッシュを圧縮するためです。だからこそ、このリストで最大のモデルでありながら長いコンテキストでも使用できるのです。

見積もりが誤る箇所

具体例

8kコンテキスト・1リクエストにおける、重み・キャッシュ・オーバーヘッドを合わせた必要メモリの総量です。これは、コンフィギュレーターがカタログ内のすべての構成に対して実行しているのと同じ計算です。

最後の列は、モデルを4-bit・8kコンテキストで収められる、当社カタログの中で最も安価なノードと、メモリ帯域幅が許す単一ストリームの生成速度です。スループットの数値は意図的に控えめに設定され、公開されている測定値と照らし合わせて調整されています。保証ではなく、下限の目安として扱ってください。

複数のリクエストに同時対応する

デモ向けにサイジングしたマシンが、製品を提供できないマシンになるのはここです。重みは一度だけ必要ですが、キャッシュは同時実行シーケンスごとに必要になります。

Llama 3.3 70Bは4-bitにすると、どうやっても重みが35 GBになります。この表で35 GBを超える分はすべてキャッシュです。だからこそ、「ノートパソコンでは問題なく動いた」のと「本番環境では落ちた」が、同じモデル・同じカードでの出来事になり得るのです。

それが意味するマシン

これまでの内容から導かれる、実践的な3つのルールです。重要な順に並んでいます。

1. 可能な限り、複数枚より1枚が優れています。シャーディングも、レイヤー間の同期も、インターコネクトへの配慮も不要です。使用するコンテキストでモデルが1枚のカードに収まるなら、そのカードを選んでください。
2. モデルの公称最大値ではなく、実際に使うコンテキストと実際の同時実行数でサイジングする。公称最大値は能力であって、要件ではありません。
3. シャーディングが避けられない場合は、NVLinkを選ぶ。PCIeカード4枚への分割も機能しますが、NVLinkカード4枚への分割も機能し、かつ明確に高速です。その差にどれだけの価値があるかは、まさに次のガイドで扱います。

コンフィギュレーターは、この計算を全41構成に対してリアルタイムで実行します。モデル、精度、コンテキスト長を選ぶと、どのノードに収まるか、どのノードが1枚のカードに収められるか、そして月額費用がいくらかを表示します。使われている計算式はこのページと同じものなので、当社の計算に異論があれば、どこが違うのか正確に指摘できます。