Cost, Billing, and Ops2026年10月14日Flatkey Team

32Bおよび70BモデルのVRAMガイド：単一GPUとマルチGPUの選択肢

4bit、8bit、FP16/BF16推論、Ollama、QLoRAファインチューニング、マルチGPU構成における32Bおよび70Bモデルの実用的なVRAM要件を解説します。

32Bおよび70BモデルのVRAMガイド：単一GPUとマルチGPUの選択肢

70b model vram requirementsに対する実用的な答えは、70Bモデルは一般的な4-bit量子化ならおよそ35GBから45GB、8-bit量子化と実行時オーバーヘッド込みで約70GBから90GB、FP16またはBF16ではオーバーヘッド前でも140GB超になるということです。32Bモデルのほうが扱いやすいですが、それでも計画は必要です。4-bit推論で約18GBから24GB、8-bit推論で32GBから45GB、FP16またはBF16ではオーバーヘッド前でも64GB超が必要です。

これらの数値はあくまで下限です。実際の70b model vram requirementsは、コンテキスト長、バッチサイズ、KVキャッシュ、サービングエンジン、テンソル並列、LoRAアダプター、オプティマイザ状態、そして本番トラフィックがメモリ不足エラーで失敗し始める前にどれだけ安全余裕が必要かによって変わります。

このガイドは、32Bまたは70Bのワークロードが1枚のGPUに収まるのか、複数GPUが必要なのか、あるいはレンタルGPU容量の代わりにモデルAPIで提供すべきかを判断するAIエンジニア、プラットフォームチーム、技術購買担当者向けです。

2026年10月13日時点で確認済み。

70b model vram requirements: すぐに分かる答え

まずはこの表を一次見積もりとして使い、その後、実際のモデル、コンテキストウィンドウ、サービングスタックでベンチマークしてください。

ワークロード	32Bの出発点	70Bの出発点	実務上の注意
4-bitローカル推論	24GBで動作可能、48GBのほうが快適	48GBで一部の量子化モデルを読み込める、80GBのほうが安全	開発、デモ、社内ツール、低同時実行のサービングに適しています。
8-bit推論	48GBまたは80GB	最低80GB、96GBまたは141GBのほうが安全	実行時オーバーヘッドとKVキャッシュが、エンドポイントの安定性を左右することが多いです。
FP16/BF16推論	80GB	2x80GB、141GB、180GB、またはそれ以上のマルチGPUシステム	重みメモリだけで、1パラメータあたり約2バイトです。
Ollama風の単一ユーザー向けローカルサービング	24GBから48GB	48GBから80GB	ollama 70b model vram requirementsの問題は、主に量子化モデルサイズとコンテキストの合計です。
本番環境のvLLMまたはSGLangサービング	48GBから80GB	80GB、96GB、141GB、またはマルチGPU	KVキャッシュ、バッチ処理、失敗リクエストの復旧のための余裕を確保してください。
QLoRAファインチューニング	制約付き実行なら48GB、80GBのほうが安全	48GBは研究上の下限、80GBまたはマルチGPUのほうが安全	qlora 70b model vram requirementsは、シーケンス長とバッチ戦略に大きく依存します。

購入の近道:

32Bの量子化実験、または非常に制約の強い70BのCPU/GPU分割ワークフローに限るなら、24GBを選びます。
32Bを快適に使う、70Bの4-bitローカル推論、または厳密に調整したQLoRA実験には、48GBを選びます。
本格的な70B推論、より大きいコンテキストウィンドウ、またはより信頼性の高いQLoRAには、80GBを選びます。
本番向けの余裕、より長いコンテキスト、高い同時実行数、またはFP16/BF16が必要なら、96GB、141GB、180GB、またはマルチGPUを選びます。

製品が必要とするのがモデル出力だけで、ハードウェアの直接制御ではない場合は、GPU契約を結ぶ前にモデル/API経路を比較してください。Flatkeyは、1つのキー、1つの残高、1つの請求書、そして数百の公式モデルとツールにまたがる利用台帳をチームに提供します。利用率が不確かな場合、こちらのほうがよりきれいな基準になります。

なぜモデル重みだけではVRAM要件の全体にならないのか

最も単純なメモリ見積もりは次のとおりです。

model_weight_memory = parameter_count x bytes_per_parameter

これで有用な下限が得られます。

モデルサイズ	FP16/BF16の下限	8-bitの下限	4-bitの下限
32B	約64GB	約32GB	約16GB
70B	約140GB	約70GB	約35GB

しかし、稼働中のLLMには重み以外にも必要なものがあります。

メモリ要素	重要な理由
量子化メタデータ	4-bitおよび8-bit形式では、スケール、グループメタデータ、フレームワークのバッファが必要です。
KVキャッシュ	より長いコンテキストウィンドウとより多い同時リクエストは、追加のメモリを消費します。
ランタイムバッファ	vLLM、SGLang、TensorRT-LLM、llama.cpp、Ollamaはそれぞれ異なる方法でメモリを確保します。
CUDAグラフとカーネル	サービングエンジンは、速度と安定性のためにワークスペースを確保することがあります。
LoRAアダプター	ファインチューニング済みアダプターはフル重みより必要メモリは少ないですが、それでも予算確保が必要です。
安全余裕	本番エンドポイントには、プロンプトの変動、再試行、デプロイの差分に対応する余地が必要です。

そのため、70b model vram requirements quantizedは「4-bitファイルが35GB」で終わる話ではありません。35GBから45GBの量子化された70Bモデルは48GBのGPUに載るかもしれませんが、コンテキストが長い、バッチが大きい、またはランタイムが重いと、やはり失敗することがあります。

32Bおよび70Bモデルの単一GPU विकल्प

24GB GPU

24GBカードは、4-bit形式の32Bモデル、CPUへの部分オフロードを伴う小規模な70Bテスト、そしてレイテンシが主目的ではない開発者向け実験に有用です。

70b model vram requirementsに対して、24GBを快適な答えだと考えないでください。強い量子化、短めのコンテキスト、CPUオフロード、またはllama.cpp風のローカルテストでは役立つことがありますが、通常は本番向けの70Bサービング階層ではありません。

最適な用途:

32Bの4ビット推論。
小さなコンテキストウィンドウ。
単一ユーザーによるローカルテスト。
より大きなGPUをレンタルする前のプロトタイプ評価。

注意点:

70BではCPUオフロードが必要になることが多く、かなり厳しい設定が必要です。
長いプロンプトはKVキャッシュをすぐに使い切る可能性があります。
スループットは制限されます。

48GB GPU

48GBは、70Bの量子化ワークロードにおける本格的な単一GPU階層の最初の段階です。コンテキストと同時実行数を管理できれば、多くの70B 4ビット推論ワークロードを実行できます。また、元のQLoRA結果で示された、単一の48GB GPUでの大規模な65B級ファインチューニングとも整合する、実用的な最低ラインでもあります。

最適な用途:

70Bの4ビットローカル推論。
32Bの8ビット推論。
アダプターと長めのコンテキストのための余裕を持たせた32Bファインチューニング。
厳しめのqlora fine-tuning 70b model vram requirementsの実験。

注意点:

70Bの8ビットでは、通常ヘッドルームが十分ではありません。
長コンテキストのサービングでは、70B 4ビットモデルでも限界を超えることがあります。
バッチサイズは制限されます。

80GB GPU

80GBは、本格的な70B作業に対する最も一般的な実用解です。A100 80GBやH100 80GBクラスのGPUは、48GBよりもコンテキストの余裕が大きく、多くの70B量子化推論ワークロードを処理できます。また、QLoRAの出発点としてもはるかに快適です。

最適な用途:

本番に近いコンテキスト条件での70B 4ビット推論。
実行環境とコンテキストが収まるなら70B 8ビット推論。
オーバーヘッド込みの32B FP16/BF16推論。
制約はあるものの現実的な設定での70B QLoRA。

注意点:

FP16/BF16の70Bには通常、1枚以上の80GB GPUが必要です。
高い同時実行数には、依然として慎重なKVキャッシュ計画が必要です。
プロバイダー固有のノード形状と価格は、VRAMと同じくらい重要になることがあります。

96GB、141GB、180GBのGPU

新しい大容量メモリのアクセラレーターは、単一GPUの議論を変えます。96GBカードなら、70B 8ビットやより大きな量子化コンテキストにさらに余裕が生まれます。H200クラスの141GBメモリがあれば、多くの70Bワークロードをはるかに大きなヘッドルームで収められます。B200クラスの180GB構成は、特にサービングスタックが新しい低精度パスを使える場合に、単一GPUまたは単一ノードの上限をさらに押し上げます。

最適な用途:

長いコンテキストでの70B推論。
より大きなバッチサイズと同時実行数。
8ビットまたは混合精度のサービング。
大規模モデルのシャーディング複雑さの削減。

注意点:

在庫状況とレンタル価格は、理論上の適合性より重要になることがあります。
ソフトウェアの成熟度はGPU世代ごとに異なります。
それでも、受理された出力あたりのコストをベンチマークする必要があります。

関連するハードウェア比較については、B200 vs H200、H200 vs H100、およびLLM推論に最適なGPUを参照してください。

70Bモデル向けのマルチGPU विकल्प

マルチGPUサービングは、単に「VRAMが増える」だけではありません。通信オーバーヘッド、トポロジーの考慮、配置リスク、ソフトウェアの複雑さも加わります。

マルチGPUを使う場面:

必要な精度ではモデルが1枚のGPUに収まらない場合。
長いコンテキストや高い同時実行数のために、より多くのKVキャッシュ領域が必要な場合。
FP16/BF16の70Bサービングが必要な場合。
1枚のGPUでは出せないスループットが必要な場合。
テンソル並列と相互接続性能を検証できる場合。

オプション	適している場面	確認すべき点
2x48GB	単一の48GBカードよりも余裕のある70B量子化サービング	相互接続、テンソル並列対応、障害時の挙動。
2x80GB	70B FP16/BF16の実験、または高いヘッドルームを持つ量子化サービング	シャーディングが、レイテンシとコストでより大きな1枚GPUより優れるかどうか。
4x80GB	より重い70Bサービング、より大きなコンテキスト、複数レプリカ、またはファインチューニング	NVLink/NVSwitch、バッチポリシー、利用率、チェックポイント戦略。
8x80GB以上	共有本番クラスタ、複数エンドポイント、または70B超のモデル	スケジューラ、ストレージ、可観測性、コスト配分。

マルチノード展開では、クラスタ設計が重要です。容量を購入する前に、GPUクラスタアーキテクチャガイドで、計算、ネットワーク、ストレージ、制御プレーンの要件を確認してください。

Ollama 70BモデルのVRAM要件

ollama 70b model vram requirementsの答えは、モデルタグと量子化に依存します。Ollamaのモデルページでは、70Bアーティファクトが140GBではなく数十GBとして記載されることがよくあります。これは、デフォルトのローカルサービング経路が通常FP16ではなく量子化であるためです。

実用的な目安:

48GBあれば、いくつかの70B量子化モデルを読み込んでテストできます。
64GBから80GBあれば、コンテキストの余裕が増え、OOMの驚きも減ります。
24GBでは、通常はより小さなモデル、短いコンテキスト、重いオフロード、または遅い実験になります。
本番レイテンシや複数ユーザーが必要なら、ダウンロードしたモデルサイズだけでなく、サービングのヘッドルームを基準に容量を見積もってください。

ローカルテストでは、正確なモデルタグ、量子化、コンテキスト長、GPUレイヤー、実測のメモリ使用量を記録してください。「70Bが自分のGPUで動いた」と、これらの詳細なしに書いてはいけません。同じ70B系でも、メモリ挙動の異なる複数の量子化バリエーションがあります。

QLoRAによる70Bモデルのファインチューニングに必要なVRAM

qlora fine-tuning 70b model vram requirementsという問いには、2つの答えがあります:

研究段階では、QLoRA がベースモデルを凍結し、量子化して、小さな低ランクアダプターだけを学習するため、必要メモリの下限が驚くほど低くなることがあります。
本番運用では、シーケンス長、バッチサイズ、勾配チェックポイント、データパイプライン、評価頻度、アダプター管理などが実用上のメモリ圧迫要因になるため、快適に動かせる領域はより高くなります。

次の計画表を使ってください:

ファインチューニング構成	32Bの出発点	70Bの出発点	注記
最小限のQLoRA実験	24GB〜48GB	48GB	シーケンス長とバッチサイズは控えめに保つ。
実用的なQLoRA実行	48GB〜80GB	80GB	データ、評価、再起動回数のための余裕が増える。
より長いシーケンス、またはより大きい有効バッチ	80GBまたはマルチGPU	2x80GB以上	メモリ使用量はシーケンス長と学習戦略に応じて増加する。
フルファインチューニング	マルチGPU	マルチGPUクラスター	オプティマイザ状態のため、フルファインチューニングは別問題になる。

検索クエリが qlora fine-tune 70b model vram requirements なら、まずは48GBまたは80GBで1つの制約付き実行が成功することを確認し、その後で実際のピークメモリを記録しながらシーケンス長と有効バッチを拡大してください。本番のファインチューニングワークフローでは、80GBまたはマルチGPU容量のほうが、場当たり的な最小メモリ構成よりも運用しやすいのが普通です。

KVキャッシュとコンテキスト長で答えが変わることがある

4Kコンテキストでは収まる70Bモデルでも、32Kコンテキストでは収まらないことがあります。KVキャッシュは次の要素に応じて増加します:

層の数。
KVヘッド数とヘッド次元。
コンテキスト長。
バッチサイズまたはアクティブなシーケンス数。
KVキャッシュ要素あたりのバイト数。

サービングエンジンはこれをそれぞれ異なる方法で管理します。vLLM は、メモリ使用率とKVキャッシュの挙動を、サービング上の最重要事項として扱います。llama.cpp や Ollama 風のローカルサービングでは、コンテキストやオフロードの選択によってモデルを収められる一方で、性能面のトレードオフが発生します。

実践的なワークフローは次のとおりです:

意図した量子化でモデルを読み込みます。
デフォルトではなく、実際のコンテキスト長を設定します。
本番環境に合ったプロンプト分布で実行します。
レイテンシーまたはメモリが限界に達するまで並列度を上げます。
ピークVRAM、失敗したリクエスト、秒あたりトークン数、受理された出力の品質を記録します。

70b model vram requirements を、空のロードテストだけで見積もらないでください。実際に運用するコンテキストと並列度から見積もってください。

簡単なVRAMワークシート

容量を借りる、または確保する前に、このワークシートを使ってください。

model_family:
parameter_count: 32B | 70B | other
precision: fp16 | bf16 | int8 | 4-bit | mixed
serving_engine: Ollama | llama.cpp | vLLM | SGLang | TensorRT-LLM | other
target_context_window:
input_tokens_p50:
input_tokens_p95:
output_tokens_p50:
output_tokens_p95:
target_concurrency:
batching_policy:
fine_tuning_method: none | LoRA | QLoRA | full fine-tune
gpu_candidate:
gpu_memory:
observed_idle_load_vram:
observed_peak_vram:
oom_failures:
tokens_per_second:
accepted_outputs_per_hour:
cost_per_accepted_output:

コスト計画には、ワークシートと GPUレンタル価格ガイド、GPUクラウドの隠れコスト、GPUクラスターのTCO を組み合わせてください。

GPUを借りるよりモデルAPIのほうが適している場合

GPU容量が有効なのは、重み、量子化、デプロイ、カスタムアダプター、プライベートサービング、または継続的な稼働率を直接制御したい場合です。

次のような場合は、モデルAPIのほうが適していることがあります:

トラフィックがバースト的。
製品が頻繁にモデルを変更する。
チームがサービングインフラの運用を望まない。
GPU時間単位よりも、リクエスト単位のほうがユニットエコノミクスを管理しやすい。
1つの固定デプロイではなく、複数のモデルファミリーに素早くアクセスしたい。

Flatkey は、その判断におけるAPI側に位置します。開発者に OpenAI 互換エンドポイント、1つのキー、1つの残高、1つの請求書、そして公式モデルやツール全体にわたる使用台帳を提供します。もし 70b model vram requirements のワークシートで低い利用率、脆弱なOOM余裕、または重い運用オーバーヘッドが示された場合は、GPUレンタルに踏み切る前にモデル/APIのベースラインをベンチマークしてください。GPUクラウド vs モデルAPI のガイドが判断の枠組みを示します。

開いておくべき公式ソースとドキュメント

ソース	重要な理由
QLoRA論文と QLoRAリポジトリ	大規模モデルの低メモリなアダプタ微調整のベースライン。
Hugging Face bitsandbytes量子化ドキュメント	Transformersでの実践的な8ビットおよび4ビット読み込み挙動。
vLLMドキュメント	サービング時のメモリ、バッチ処理、KVキャッシュの挙動。
llama.cppリポジトリ	GGUF、CPU/GPUオフロード、およびローカル推論の挙動。
Ollamaモデルライブラリ	モデルタグ、量子化アーティファクトのサイズ、ローカルサービングのオプション。
NVIDIA A100、H100、H200、および DGX B200	サイズ決定で使用される公式GPUメモリ階層。

最終推奨

32Bモデルでは、4ビット実験には24GB、快適な推論には48GB、FP16/BF16、より長いコンテキスト、または微調整の余裕を求めるなら80GBから始めてください。

70Bモデルでは、48GBを制約のある4ビットの出発点、80GBを実用的な本格推論の階層、96GBから180GB、またはマルチGPUを本番向けの余裕階層として扱ってください。FP16/BF16の70Bでは、マルチGPUまたは非常に大容量のGPUを計画してください。

70b model vram requirements に対する最善の答えは、単一のGPU容量ではありません。モデル、量子化、コンテキスト長、同時実行数、サービングエンジン、微調整手法、そして受理された出力あたりのコストを踏まえた、測定に基づく構成です。

よくある質問

70BモデルにはどのくらいのVRAMが必要ですか？

70Bモデルには、FP16またはBF16の重みだけで約140GB、8ビットではオーバーヘッド前で約70GB、多くの4ビット量子化版ではおおよそ35GBから45GBが必要です。実際には、KVキャッシュ、ランタイムバッファ、コンテキスト長、同時実行数を含めると、70b model vram requirements はさらに大きくなります。