VRAM計算機

速度はシングルストリームデコード時の帯域幅制限推定値であり、ベンチマークではありません。プロンプト処理は計算量依存で、動作が異なります。

3部構成の内訳の読み方

インターネット上のほぼすべての「will it fit」議論は、実際には誰かが忘れた3つの数のうちどれかという議論です。モデルカード上のダウンロードサイズはそのうちの1つです。残りの2つはモデルがロードされ回答を開始したときにのみ存在し、そのときにメモリ不足になると問題が発生します。

Llama 3.1 8B を Q4_K_M で 8K コンテキスト、1 リクエストずつ、F16 キャッシュで実行すると、これが最も一般的なローカル セットアップになります。ここでそのバイト数をすべて示します：

weights  = 8.03e9 params x 4.85 bits / 8      = 4.87e9 bytes = 4.53 GB
kv       = 2 x 32 layers x 8 kv-heads x 128 dim
           x 8192 tokens x 2 bytes             = 1.07e9 bytes = 1.00 GB
overhead = 0.65 + 0.08 x (4.53 + 1.00)                        = 1.09 GB
                                                                -------
total                                                            6.63 GB

重みは参照できる唯一の部分です。これは純粋な算術です：パラメータ数 × 重みあたりのビット数 ÷ 8。あなたのワークロードにかかわらずこれらは変わりません。他の2つの数に触れなければ、8B モデルを 4 ビットで使うと 4.5 GB 必要で、6 GB のカードに快適に収まると考えるでしょう。実際にはそうではありません。

KV キャッシュは移動する部分です。コンテキスト内の各トークンは、各レイヤーごとにキーとバリュー ベクトルが保存されており、これによりモデルは過去に注意を向ける際に再計算する必要がありません。これが生成を高速にし、キャッシュがオプションでない理由です。KV キャッシュはコンテキストに対して線形に、同時リクエスト数に対して線形にスケールし、パラメータ数ではなく注意のレイアウトによって決まります。ここでのコストは正確に 1024 トークンあたり 0.125 GB で、これは Llama 3.1 が 32 個のクエリ ヘッドに対して 8 個のキー・バリュー ヘッドを使用しているため小さいです。

ランタイムオーバーヘッドは、誰も予算に組み込まないが誰もが直面する部分です。コンパイル済みカーネル、CUDAまたはMetalコンテキスト、活性化とロジットバッファー、ブロックを完全にパックできないアロケーター、およびサンプラーのワークセット。この計算機はこれを固定0.65 GBにその他の8％を加えたものとしてモデル化します。これは意図的な近似ですが、形は正しいです：オーバーヘッドは小さなモデルでは消えず、大きなモデルでは一定ではありません。

単位の注意点です。なぜならこれが実際の混乱を招くからです。このページでのすべてのGBは、1024の3乗で割ることで計算され、したがって技術的にはギビバイトです。これはあなたのGPUドライバーが報告する単位と同じであり、これが24 GBと販売されているカードが約24564 MiBと表示される理由です。Hugging Face上的モデルファイルは通常、10進ギガバイトで表記されるため、5.0 GBのダウンロードはここで約4.65 GBと表示されます。この差は約7％で、あなたに有利に働き、不利にはなりません。

量子化レベルの選択

量子化は各重みをより少ないビットで保存します。BF16でリリースされたモデルはパラメータあたり2バイトを消費し、4ビット量子化は半バイトを少し超える量を消費します。モデルの他の部分は変更されず、これが量子化が何かが収まるかどうかを左右する単一の最大のレバーである理由です。

ここで紹介するモデルは、この計算機が提供するすべてのレベルでのLlama 3.3 70Bです。重みはディスク上のファイルであり、他の2列はF16キャッシュを持つ単一ストリームにおけるキャッシュとオーバーヘッドを含む完全なロードフットプリントです。

この表で注目すべき点が3つあります。第一に、公称ビット数はユーザーにとって有利でもあり不利でもあるという点です。Q4_K_Mは重みあたり4ビットではなく4.85ビットです。これは、K-quantフォーマットが、精度低下の影響が最も大きいattentionおよびembeddingテンソルを高精度に保つためです。Q2_Kも同様の理由で平均3.35ビットとなります。モデルサイズを「パラメータ数 × 4 / 8」で計算すると、約5分の1ほど過小評価することになります。

第二に、量子化を進めるほど効果は急激に減少します。BF16からQ8_0への移行はモデルサイズを半減させますが、品質への影響は測定不能なほど軽微です。Q8_0からQ4_K_Mへの移行でも再びほぼ半減しますが、通常の利用で品質低下を感じる人はほとんどいません。Q4_K_MからQ3_K_Mへ下げると7.8 GB節約できますが、指示追従能力の低下、コード生成の弱体化、計算ミスといった影響が出始めます。それ以下に下げると、容量と引き換えに能力を明確に損なうことになります。

第三に、過度な量子化によるダメージはモデルサイズによって均一ではありません。70BモデルをQ2_Kにしても、冗長性が非常に高いため実用可能です。一方、3BモデルをQ2_Kにすると、出力が破綻することが頻繁にあります。実践的な経験則として、約4ビットまでは「より大きなモデルを低い量子化で」使い、それ以下では「より小さなモデルを4ビット以上で」使うのが推奨されます。70BのQ4_K_Mは、ほとんどのタスクで32BのQ8_0を上回りますが、70BのIQ2_XXSでは通常そうはなりません。

知っておくべき特殊なケースがあります。一部のモデルは、後から量子化するのではなく、最初から低ビットフォーマットで公開されています。gpt-ossはMXFP4（重みあたり4.25ビット）で提供されており、学習段階でそれが考慮されているため、BF16モデルを後から4ビットに圧縮したものとは品質が比較になりません。そのため、この計算機では実際にそのフォーマットで提供されているモデルにのみMXFP4を選択できるようにしています。また、gpt-oss 120Bがフル精度で117Bモデルが必要とする250 GBではなく、63.4 GBに収まるのもこのためです。

コンテキスト長がハードウェアの決定事項である理由

コンテキスト長を単なる機能フラグのように扱う人がいますが、モデルカードに128Kと書かれているからといって128Kに設定すべきではありません。これは機能フラグではなくメモリ割り当てであり、アーキテクチャによっては予算内で最大の項目となります。以下は、Q4_K_M、シングルストリーム、F16キャッシュにおける4つのモデルの、4つのコンテキスト長ごとの合計ロードフットプリントです。

Llama 3.1 8Bは2Kから128Kの間でサイズが4倍（5.8 GBから22.8 GB）に増加します。これは、ほぼあらゆる環境で動作するか、24 GBのカードに収まらないかという違いを生みます。Command R 35Bは極端な例で、2KではQwen3 32Bより小さいものの、128Kでは約4倍のサイズになります。これは64個のkey-valueヘッドを持つフルマルチヘッドattentionを使用しており、1024トークンごとに1.25 GBのキャッシュを消費するためです。一方、Gemma 3 27Bはほとんど変化しません。6層のうち5層が1024トークンのウィンドウのみを参照するため、メモリ消費がすぐに頭打ちになるからです。

実用上の結論として、設定するコンテキスト長はモデルがサポートする最大値ではなく、実際に使用する長さにすべきです。プロンプトが3000トークン、回答が800トークンであれば、32Kに設定するのはメモリの無駄であり、その分をより良い量子化に充てるべきです。24 GBカード上のLlama 3.1 8B（Q4_K_M）は64Kコンテキストまで保持できますが、128Kは不可能です。128Kには22.8 GB必要ですが、ディスプレイやドライバが使用する分を引くと、カードの空きは約22.3 GBしかないためです。キャッシュをQ8に下げれば収まります。他の設定を変更する必要はありません。

使用するランタイムも重要です。llama.cppは指定したコンテキストサイズ分のみキャッシュを割り当てるため、小さなコンテキストを設定すればメモリが解放されます。一方、vLLMはカードの一定割合を事前に確保し、その内部でページングプールを管理するため、設定値に関わらずnvidia-smi上ではカードがほぼ満杯に見えます。この計算機が示す数値は必要なワーキングセットであり、llama.cppの挙動およびvLLMが確保すべきプールサイズに直接対応しています。

キャッシュはサイズではなくアーキテクチャで決まる

KVキャッシュについて最も重要な事実は、パラメータ数からはほとんど予測できないということです。予測の決め手となるのは、モデルが保持するkey-valueヘッドの数、各ヘッドの幅、層の数、そして特殊な工夫がなされているかどうかです。以下に、パラメータ数が3桁異なるモデルの1024トークンあたりのキャッシュコストを示します。

一番上と一番下の行を比較してください。671Bモデルのキャッシュは35Bモデルより小さく、3.8Bモデルのキャッシュは27Bモデルの4.5倍もあります。Phi-3.5 miniは128Kコンテキストで合計54.8 GB必要ですが、そのうち重みはわずか2.2 GBです。つまり、「極小」と評されるモデルが、32Bモデルよりも多くのメモリを必要とするケースがあるということです。

表の全容は4つのメカニズムで説明できます。Grouped-query attentionは1つのkey-valueヘッドを複数のクエリヘッドで共有する現在の業界標準であり、キャッシュを通常4〜8倍削減します。Sliding-window attentionはほとんどの層に固定ウィンドウを持たせることでキャッシュの増加を抑えており、これがGemma 3やgpt-ossでメモリ消費が頭打ちになる理由です。DeepSeekが採用するMulti-head latent attentionは、キーと値をフルで保存する代わりに、トークン・層ごとに576要素のベクトルに圧縮します。一方、Command RやPhi-3.5などの古いリリースで使われている単純なMulti-head attentionは、これらの工夫を行わず、すべてのヘッド分のコストを支払います。

この議論の詳細と導出過程については、以下で個別に解説しています。 なぜパラメータ数がVRAMの予測に適さないのか.

KVキャッシュ量子化が有効な場合

キャッシュは重みと同様に量子化可能です。F16は要素あたり2バイト消費しますが、Q8オプションは平均1.06バイト、Q4は0.56バイトとなります（オーバーヘッドはブロックごとのスケールによるものです）。主要なランタイムはすべてこれをサポートしており、llama.cppではcache-type-kおよびcache-type-v、vLLMではkv-cache-dtypeフラグとして提供されています。

問題は「メモリが節約できるか」ではなく、「節約分が重要か」という点にあります。それは、フットプリント全体のうちキャッシュがどれだけを占めているかに完全に依存します。Q4_K_Mの重みで32Kコンテキストの場合：

Command Rは1つのフラグで20.3 GB節約でき、これは48 GBカードが2枚必要か1枚で済むかの違いになります。Llama 3.3 70Bは同じフラグで5.1 GBの節約にとどまります。これはGrouped-query attentionにより元々キャッシュが小さいためです。この傾向は一般的で、KV量子化は長コンテキストのマルチヘッドモデルでは劇的な効果がありますが、短コンテキストのグループクエリモデルでは効果が限定的です。適用前に上記の分解図でKVキャッシュの項目を確認してください。そのバーが非常に細い場合、このフラグによる恩恵はほとんどありません。

コストは確かに存在しますが、限定的です。Q8キャッシュは品質面でほぼ無料であり、長コンテキストのワークロードではデフォルトで有効にする価値があります。Q4キャッシュは、長コンテキストの目的である「入力の深層にある特定の事実の正確な想起」を損なう可能性があります。要約や自由形式のチャットには適していますが、長文からの検索、needle-in-haystack（干し草の中の針探し）、複数ファイルにまたがるコード推論には向きません。また、キーは値よりも量子化の影響を受けやすいため、ランタイムで個別に設定できる場合は、両方Q4にするよりも「キーをQ8、値をQ4」にする方が通常は良い結果が得られます。

失敗しないための原則は、「まず重みを量子化し、次にキャッシュを量子化する」ことです。重みの量子化はキャッシュの量子化よりもはるかに深く研究・調整されているため、合計サイズが同じであれば、ほぼすべての場合において「Q4_K_Mの重み ＋ F16キャッシュ」の方が「Q6_Kの重み ＋ Q4キャッシュ」よりも優れた結果を出します。

24 GBカード2枚は48 GBカード1枚ではない

モデルを複数のGPUに分割することは有効であり、大規模モデルにおいては唯一の現実的な選択肢です。しかし、単純な加算とはならず、その差は「利用可能な容量」と「デコード速度」の2点に現れます。

容量について、シングルカードではドライバー、ディスプレイ出力、アロケーターの断片化によって一部が消費されます。この計算機では、コンシューマー向けカードで約93%、ディスプレイ未接続のワークステーション/データセンター向けカードで約95%が利用可能と想定しています。マルチカード構成では、各カードが独自のランタイムコンテキストとアクティベーションバッファのコピーを持ち、レイヤー分割も均等にならないことが多いため、損失が大きく約90%となります。そのため、2枚のRTX 4090では約43.2 GBの作業領域となりますが、同じ公称48 GBのRTX 6000 Ada単体では45.6 GBを利用できます。

この2.4 GBの差が実用上の分かれ目となります。Llama 3.3 70B（Q4_K_M、8Kコンテキスト）は46.4 GBを必要とするため、どちらの構成でも収まりません。キャッシュをQ8に変更すると45.1 GBとなり、48 GBのシングルカードには収まりますが、2枚構成では依然として不足します。2枚のRTX 4090で動作させるには、ウェイトをQ4_0まで落として42.5 GBにする必要があります。公称メモリは同じでも、2つの追加の妥協が必要になります。

速度について、一般的には2枚で2倍の速さになると期待されますが、シングルストリームのデコードではそうはならず、モデルが1枚に収まる場合よりも遅くなることがよくあります。llama.cppや多くのシングルノード設定におけるデフォルトの分割はパイプライン並列化です。つまり、レイヤー0～39を1枚目、40～79を2枚目に配置します。トークン生成は80層すべてを順に処理するため、常に1枚のGPUのみが動作し、もう1枚は待機状態となります。さらに境界でのPCIe経由の隠れ状態転送も発生します。購入したのは容量であり、スループットではありません。この計算機では、これを帯域幅効率の低下としてモデル化しており、シングルカードの0.75から分割時は0.6に低下します。その結果、70Bモデルにおいて2枚のRTX 4090は約13 tokens per second、単体のRTX 6000 Adaは約16 tokens per secondとなり、ペアの方がカードあたりの生帯域幅が高いにもかかわらず逆転します。

vLLMやTensorRT-LLMが採用するテンソル並列化が代替案です。すべてのレイヤーを全カードに分割し、同時に処理します。これはデコード速度を確実に向上させますが、レイヤーごとにカード間でのall-reduceが必要となるため、NVLinkまたは各カードへのフルx16 PCIeレーンが推奨されます。2枚目のカードがx4で動作するコンシューマー向けマザーボードでは、テンソル並列化はパイプライン並列化よりも遅くなる可能性があります。また、アテンションヘッドの数がカードの数で割り切れる必要があり、3枚構成が扱いにくいのはこのためです。

実用上のまとめ：カードの追加は、単体では実行できないモデルを動かすために行うべきであり、すでに動くモデルを高速化するために行うべきではありません。同じ価格で1枚の大型カードと2枚の小型カードを選ぶなら、シンプルさ、消費電力、利用可能容量、シングルストリームのレイテンシの面でシングルカードが勝ります。マルチカードが有利なのは、同時リクエストを処理する場合であり、バッチ処理によってすべてのカードが稼働し続けるためです。

システムRAMにオフロードするとどうなるか

モデルが収まらない場合、llama.cppやOllamaは一部のレイヤーをシステムRAMに保持し、CPUで実行します。動作はしますが、速度が緩やかに低下するのではなく急激に悪化するため、ハードウェアが故障したと誤解される原因にもなります。

その理由は、デコードが計算能力ではなくメモリ帯域幅に依存しているためです。1つのトークンを生成するために、ランタイムはすべての有効なウェイトとキャッシュ全体を一度読み込みます。Llama 3.3 70B（Q4_K_M、8Kコンテキスト）の場合、トークンあたり約45.5 GBの読み込みが発生します。これをメモリの帯域幅で割れば、計算が始まる前の理論上の上限速度が算出されます。

RTX 4090の読み込み速度は1008 GB/sですが、一般的なデスクトップのデュアルチャネルDDR5は約90 GB/sです。この11倍の差がすべてを物語っています。もし70Bモデルが4090に完全に収まれば、約17 tokens per secondでデコードできます。しかし収まらない場合、46.4 GBのうち22.3 GBのみがGPU上にあり、トークン読み込みの52%がシステムRAMから行われるため、速度は9分の1になります。結果として約2.6 tokens per secondまで低下します。モデルの48%を高速なデバイスに残しても、速度の84%を失うことになります。

同様の傾向はあらゆるスケールで当てはまります。Llama 3.1 8Bはトークンあたり5.9 GBを読み込みます。4090では約127 tokens per secondですが、90 GB/sのRAMを用いたCPUのみの環境では約11 tokens per secondになります。Qwen3 32B（Q4_K_M）は22.8 GBを必要とするため、16 GBのRTX 5080では約65%がGPU上に残り、推定速度は約33 tokens per secondから約8 tokens per secondに低下します。

2つの詳細が、実際の体験をこれらの数値以上に悪化させます。CPUレイヤーでのプロンプト処理は帯域幅ではなく計算能力に依存するため、ストリーミング速度が許容範囲内であっても、長いプロンプトでは最初のトークンが表示されるまでに数分かかることがあります。また、GPU側でもオフロードは無料ではなく、ホストしているレイヤーのためにランタイムが作業用バッファを必要とします。

オフロードが適切なケース：待機する必要のないバッチジョブ、数 tokens per secondで十分なモデル、わずかなレイヤーのみが溢れる場合。10%のオフロードは50%のオフロードよりもコストがはるかに低くなります。不適切なケース：インタラクティブな用途。DIMMを低速で読み込む大型モデルよりも、適切な量子化を施した小型モデルの方がほぼ確実に優れたパフォーマンスを発揮します。大型モデルの能力が必要な場合は、デスクトップで無理に動かすよりもAPI経由で呼び出す方が高速かつ安価です。

Apple Siliconとユニファイドメモリ

Apple Siliconには独立したVRAMがありません。CPUとGPUが同じパッケージ上のLPDDRプールを共有するため、128 GBメモリを搭載したMacは、市場のどのコンシューマー向けGPUにも収まらないモデルをロードできます。これは大きな利点であり、ローカル推論の界隈でMacが普及している理由です。ただし、後から気づく2つの注意点があります。

1つ目は、全容量を使えるわけではないことです。macOSは他の処理のためにメモリを予約し、GPUが確保できる量を制限します。この計算機では約75%がモデルに利用可能と想定しており、128 GBのユニファイドメモリは約96 GBの予算となり、16 GBのMac miniは約12 GBとなります。iogpu wired limit設定で上限を上げることは可能ですが、物理的な合計値に近づけるとシステムスワップのリスクがあり、モデルのスワップはロードできないことよりも悪影響を及ぼします。

2つ目は帯域幅です。ユニファイドメモリは広帯域ですが、GDDRには及びません。M4 Maxの読み込み速度は約546 GB/sで、RTX 4090の1008 GB/sやRTX 5090の1792 GB/sと比較されます。Mac miniのベースM4は約120 GB/sで、5年前のRTX 3060の3分の1程度です。Llama 3.1 8B（Q4_K_M）では、M4 Maxで約60 tokens per second、ベースM4のMac miniで約13 tokens per second、RTX 3060で約45 tokens per secondとなります。容量と速度は別々の購入対象であり、Appleはコストあたりの容量は多く提供しますが、速度は比較的控えめです。

プロンプト処理はより顕著な課題です。デコードは帯域幅に依存し、Appleは単に後れを取っている状態ですが、プリフィル（事前処理）は計算能力に依存するため、専用のテンソルコアを持つ最新のNVIDIAカードとの差はさらに広がります。Macのチャットに30,000トークンのドキュメントを貼り付けると、ストリーミング自体は問題なくても、開始までにかなりの時間がかかることがあります。長いプロンプトと短い回答が中心のワークロードであれば、購入前にこの数値をテストすべきです。

Macが圧倒的に有利なのは、ディスクリートGPUでは現実的な価格で到達できない中間領域です。Llama 3.3 70B（Q4_K_M）は128 GBのM4 Maxに余裕を持って収まり、約8 tokens per secondで動作します。192 GBのM2 Ultraなら約11 tokens per secondで動作し、100 GBを超えるモデルも保持可能です。NVIDIAハードウェアでこれを実現するには、複数のカード、それらを駆動するレーンを持つマザーボード、そして相応の電源ユニットが必要です。可能な限り汎用バックエンドではなくMLXを使用してください。このメモリモデル向けに書かれており、同じマシン上の代替手段よりも一貫して優れたパフォーマンスを発揮します。

複数人を同時に処理する場合

上記はすべて1回のリクエストを前提としています。モデルを他人が使用するエンドポイントに配置した瞬間、ウェイトは共有されますが、同時リクエストごとに独自のKVキャッシュが必要になります。これにより、キャッシュは副次的な要素から主要なコストへと変わります。Llama 3.1 8B（Q4_K_M、8Kコンテキスト）における同時実行数増加の影響：

16人の同時ユーザーでキャッシュはモデルサイズを超えます。32人では、8Bモデルがシングルユーザーの70Bモデルよりも多くのメモリを必要とします。これは、ラップトップでプロトタイプを作成し、8人でサーバーがダウンした理由に驚くチームが直面する数値です。

利点は、同時実行によってGPUの無駄がなくなることです。シングルストリームのデコードではメモリ待ちで計算リソースの大部分がアイドル状態になりますが、バッチ処理は1回のウェイト読み込みを多くのシーケンスで共有するため、メモリ使用量よりもはるかに速くスループットが向上します。これはページ化キャッシュが真価を発揮する場面でもあります。vLLMは最悪のケースを全スロットに予約するのではなく、シーケンスの成長に合わせてキャッシュをブロック単位で割り当てるためです。サーバーのサイジングを行う際は、最大コンテキスト×最大ユーザー数ではなく、実際の同時実行数と中央値のプロンプト長に基づいてキャッシュを計算してください。

GPUサイジングにおける一般的な間違い

実際に寄せられる質問

7Bまたは8Bモデルの実行にはどれくらいのVRAMが必要ですか？

8KコンテキストのQ4_K_Mで約6.6 GBであり、8 GBのカードに少し余裕を持って収まります。BF16では同じモデルで17.9 GB必要となり、24 GBのカードが推奨されます。128Kのフルコンテキストを求める場合は22.8 GBまで増加するため、ここではコンテキストが精度と同じくらい重要になります。

8 GBのモデルが8 GBのカードで読み込めないのはなぜですか？

3つの理由が重なっています。ドライバーとデスクトップ環境でカードの約7%が既に使用されており、KV cacheがウェイトの上に割り当てられ、さらにランタイムが動作を開始する前に約0.65 GBのコンテキストおよびカーネル領域を必要とします。ファイルサイズは、これらを含まない単なる数値に過ぎません。

24 GBのカードで70Bモデルを実行できますか？

VRAM単体では不可能です。Llama 3.3 70BはQ4_K_Mかつ8Kで46.4 GB必要であり、IQ2_XXSかつ2Kコンテキストであっても、利用可能な約22.3 GBに対して22.5 GB必要となります。システムRAMにオフロードして毎秒数tokenを得るか、代わりに32Bを実行して毎秒30 tokenを得るかの選択になります。

Q4_K_Mで十分と言えますか？

ほぼすべての用途において十分であり、デフォルトであるのには理由があります。ウェイトあたり4ビットではなく4.85ビットを保持し、attentionとembeddingテンソルをより高い精度で維持します。Q8_0との測定可能な差は小さく、メモリ節約効果はほぼ半分です。これより低い精度にするのは、モデルが全く動作しない場合の代替手段としてのみ検討してください。

低精度の大きなモデルは、高精度の小さなモデルより優れていますか？

約4ビットまではイエスです。Q4_K_Mの70Bは、同程度のフットプリントであれば、ほとんどのタスクでQ8_0の32Bを上回ります。3ビットを下回ると、小さなモデルや中規模モデルでは冗長性が少なくなるため、順位が逆転します。非常に大きなモデルは、小さなモデルよりも2ビットフォーマットへの耐性がはるかに高いです。

3.8BモデルのKV cacheが27Bモデルより大きいのはなぜですか？

Phi-3.5 miniは32個のkey-valueヘッドを持つフルマルチヘッドattentionを使用しており、1024 tokenあたり0.375 GBを消費する一方、Gemma 3 27Bは6層中5層に1024 tokenのsliding windowを採用しているためです。128Kでは48 GB対10.4 GBとなります。キャッシュサイズはパラメータ数ではなく、attentionのレイアウトに従います。

KV cacheを量子化すべきですか？

コンテキストが長い場合は常にQ8を有効にしてください。コストはほぼゼロです。キャッシュがフットプリントの大部分を占め、かつワークロードがリコール（想起）を重視しない場合にのみQ4を検討してください。Command R 35Bの32KではQ8で20.3 GB節約できます。Llama 3.3 70Bの同じコンテキストでは、grouped-query attentionが既に最適化されているため、節約分は5.1 GBとなります。

24 GBカード2枚は48 GBカード1枚と同等ですか？

いいえ。各カードが独自のランタイムコンテキストを持ち、レイヤー分割が不均一になるため、45.6 GBではなく約43.2 GBしか使用できません。パイプライン並列処理では片方のカードが計算している間にもう片方が待機するため、シングルストリームの速度も向上しません。2枚のカードは容量を確保し、並行処理時にはスループットを向上させます。

実際にはどのくらいの速度で動作しますか？

メモリ帯域幅をtokenあたりの読み込みバイト数で割ってください。Llama 3.1 8BのQ4_K_Mはtokenあたり5.9 GBを読み込むため、1008 GB/sのRTX 4090では効率損失を考慮して毎秒約127 tokenとなります。この見積もりはデコードのみに適用されます。プロンプト処理は計算負荷が高く、異なる曲線に従います。

システムRAMにオフロードすると実際には何が起こりますか？

速度は緩やかに低下するのではなく、崖から落ちるように急落します。Llama 3.3 70Bのレイヤーの48%をRTX 4090に、残りをDDR5に配置した場合、完全にVRAMに収まる場合の17 token/sに対し、毎秒約2.6 tokenまで低下します。わずかなオーバーフローなら許容範囲ですが、モデルの半分をオフロードするのは現実的ではありません。

Macはローカル推論に適したマシンですか？

コストあたりの容量という点ではイエスです。128 GBのM4 Maxは約96 GBの予算を提供し、70Bモデルを毎秒約8 tokenで実行できます。純粋な速度という点ではノーです。RTX 5090の1792 GB/sに対し546 GB/sの帯域幅であり、プロンプト処理はさらに遅延します。大きなモデルの実行や静音性を求めるなら購入すべきですが、低遅延を求めるなら適していません。

Mixture-of-expertsモデルはメモリを節約しますか？

メモリではなく時間を節約します。Qwen3 30B-A3Bはすべてのエキスパートを常駐させる必要があるため20.1 GB必要ですが、tokenあたり約3.3Bのパラメータしか読み込まないため、同じフットプリントのdenseな32Bモデルよりも数倍速くデコードできます。MoEモデルは、収容能力については合計サイズで、速度についてはアクティブパラメータ数で判断してください。

Flash attentionはVRAMを削減しますか？

大きな中間attention行列を削除するため、長いプロンプトのプリフィル時に実質的な節約となり、プロンプト処理を高速化します。コンテキストに応じて増加するKV cache自体を縮小するわけではありません。常に有効にすべきですが、このページの合計値が変化するとは期待しないでください。

小さなコンテキストを設定してもnvidia-smiでカードが満杯と表示されるのはなぜですか？

おそらくvLLMを実行しており、起動時にカードの固定割合を確保し、内部でページ化されたキャッシュプールを管理しているためです。llama.cppは要求されたコンテキストに必要な分だけを割り当てます。ここでの数値はワーキングセットを表しており、これはvLLMが割り当て可能でなければならない量であり、llama.cppが直接報告する値です。

モデルの実行ではなくファインチューニングにはどれくらいのVRAMが必要ですか？

はるかに多くのVRAMが必要であり、この計算機ではモデル化していません。フルファインチューニングではウェイト、勾配、オプティマイザの状態をパラメータあたり約16バイト保持するため、8Bモデルでは活性化関数（アクティベーション）を除いても約130 GBに達します。4ビットベースでのQLoRAは、推論フットプリントにアクティベーションメモリを加えたものに近いため、単一のコンシューマー向けカードで唯一現実的な選択肢となります。

ビジョンモデルは計算に影響しますか？

ビジョンエンコーダーはここに記載されているマルチモーダルモデルのパラメータ数に含まれているため、ウェイトの数値は正確です。合計値に含まれていないのは、画像が言語モデルに到達する前に多数のtokenに展開されるという点です。そのため、数枚の高解像度画像が1ページのテキストよりも多くのコンテキストを消費し、結果としてキャッシュを多く消費する可能性があります。

何も収まらない場合はどうすればよいですか？

まずはコンテキストを減らしてください。これが最もコストのかからない妥協案です。次にキャッシュをQ8に量子化し、それでも足りなければウェイトを一段階下げてください。それでも不足する場合は、システムRAMに溢れて動作が遅くなる大きなモデルよりも、適切な量子化を施した小さなモデルの方が優れています。または 無料のAPI経由で同じオープンウェイトモデルを呼び出し ハードウェアの管理を他社に任せてください。