DeepSeek V4 GPUの要件：VRAMとハードウェアガイド

やあ、友よ。僕の名前はドラ、君の古い友達だよ。DeepSeek V4を深掘りするつもりはなかった。でも、チャットやリポジトリで何度も話題に上るうちに、ある小さな出来事が背中を押した：友人が「デモ用に4090を2枚で動くかな？」と聞いてきたんだ。僕は一瞬止まった。分からなかった。だから数日かけて、できる範囲でテストして、ドキュメントを読み込んで、普段なら避けている計算をやってみた。V4のVRAM要件、何がどこに載るのか、小さなチームにとって現実的な構成とラボ向けの構成について、できる限り明確にまとめたのがこれだ。

V4のパラメータ数とメモリフットプリント

671B総数 / 37Bアクティブなモデル、VRAMに何が載るのか

**V4はMixture‑of‑Expertsモデルだ。**見出しの数字（671B）はすべてのエキスパートを合計したものだ。しかし推論時には、そのパラメータの一部だけがトークンごとにアクティブになる。僕が繰り返し参照していた実用的な数字：1トークンあたり約37Bのアクティブパラメータだ。

実際にはどういう意味か？

V4を「シンプルな」方法、つまりすべてのエキスパートをGPU上に常駐させて動かす場合、重みのメモリは671B全体をトラッキングする。これは膨大だ。マルチノード領域に入り、それでもギリギリになる。
サービングスタックがエキスパート並列化を正しく使って（ノード間でエキスパートをシャーディングして）、トークンごとにアクティブなエキスパートだけに触れるなら、VRAMはアクティブパス（約37B）、ルーター・エンベディングのオーバーヘッド、KVキャッシュに対して計測することになる。

どちらも有効なアプローチだ。前者は予測可能性を優先し、後者は実現可能性を優先する。H100のラックが手元にあるわけじゃないので、僕は後者に頼った。

完全精度（BF16）のメモリ要件

僕がずっと使っていた簡単なルール：

重み（BF16）≈ アクティブパラメータ数 × 2バイト
オーバーヘッド（ルーター、エンベディング、レイヤーノルム）で数GB追加
KVキャッシュはシーケンス長とバッチによっては支配的になる

37Bアクティブパスの場合：

重み ≈ 37B × 2バイト ≈ 74GB
非エキスパート部分とランタイムバッファで ~5〜10GB追加
KVキャッシュ前の時点で、すでに単一GPU上の80GBの上限に近づいている。僕の実行では、KVキャッシュに余裕を持たせるために2×80GB（テンソル並列=2）にシャーディングする方が快適だった。

671B全体を常駐させる場合：

重み ≈ 671B × 2バイト ≈ 1.34TB、重みだけで。
明らかに多数のGPU、または何らかのオフロードが必要になる。

量子化オプション：Q4、Q8、AWQ、GPTQ

ここでは量子化が予想以上に効いた。主な理由はアクティブパスが相当大きいからだ：

Q8（1バイト/パラメータ）： アクティブ重みで ~37GB。スケールとメタデータを含めると、パッカーによって実際には ~42〜46GBになるのを確認した。
Q4（0.5バイト/パラメータ）： ベースラインで ~18.5GB。グループワイズスケールを含めると ~22〜26GB程度。
AWQとGPTQはどちらもこの範囲に近かったが、僕のテストではAWQはQ8でわずかにリーンな傾向があり、GPTQは負荷下でのレイテンシがより安定していた。カーネルやバッチの形状によって結果は異なる。

最小ハードウェア構成

マルチノード：8x H100 / 8x A100（完全精度）

質問に答えようとした：英雄的なオフロードなしでBF16でV4を動かせるか？すべてのエキスパートを常駐させる場合、計算上は単一ノードではNoだ。重みだけで ~1.34TB になる。8×H100 80GB（≈640GB合計）では、以下のどちらかが必要だ：

複数のそのようなノード間でのエキスパート並列化、または
非常に慎重なスケジューリングを伴う部分的なCPU/NVMeオフロード

8×A100 80GBで、ノード間でエキスパートをシャーディングしてバッチを小さく保つことでBF16パスを動かすことはできたが、「シンプル」とは言えなかった。動いたが、ルーティングによるクロスノードのやり取りが発生するたびにトークンスループットが落ちた。完全精度ですべてのエキスパートを常駐させることが絶対に必要なら、KVキャッシュ・アクティベーションバッファ・実際のバッチサイズのヘッドルームを確保するために16〜24×80GB GPU（H100またはA100）を計画することをお勧めする。

重い量子化を使った単一ノード

1台の8×H100ノードでは、Q8とQ4は実用的でずっと落ち着いていた。僕の安定したセットアップはこんな感じだった：

Q8、テンソル並列2〜4、8つのGPU全体でエキスパート並列化。KVキャッシュと中程度のコンテキスト（2〜4kトークン）で8〜16の同時リクエストに十分なスペース。
Q4、テンソル並列1〜2、より長いコンテキストや大きなバッチ用のスペース。精度の小さな低下よりもコストと並行性を重視する場合に使った。

単一の4×80GBノードでは、Q8はより小さなバッチで動いた。Q4で快適になった。両者の比較では、Q8の方がコードや数学でのデコードの違和感が少なかった。

コンシューマGPUの実現可能性（4090×2、4090×4）

まず4090を2枚で試した。Q4は動いたが、バッチを極小に保ってKVキャッシュを常に監視する必要があった。短いインタラクティブなプロンプトには使えた——プロトタイピング向きで、プロダクションではない。4090を4枚にすると、Q8が合理的なバッチサイズと4〜8kコンテキストで可能になった。サーマルとPCIe帯域幅が隠れたボトルネックで：カード間のルーター移動が多い場合に小さなストールが見られた。

2×4090に顧客向けAPIを載せるか？たぶんしない。4×4090を社内ツールやオフラインバッチ生成に使うか？上記の制限内で、はい。

vLLM vs SGLang：V4のサービングに向いているのはどちらか？

各構成のスループットベンチマーク

vLLMとSGLangの両方がMoE対応のサービングパスを持つようになったので、切り替えながら試した。

vLLM：PagedAttentionを調整してバッチサイズを固定すると、持続スループットで強さを発揮した。8×H100でQ8を使うと、 ~37Bアクティブモデルに期待できる範囲内で安定していた——安定したトークン/秒で、同時接続数が16を超えてもテールレイテンシが少なかった。
SGLang：バースト負荷下でより優れたパフォーマンスを示した。短いリクエストが一度に多く来た場合、そのスケジューラーはKVを過剰に蓄積せずにGPUを維持してくれた。トラフィックが均一でない場合により予測可能なパフォーマンスが得られた。

カーネルや量子化パックによって数値は異なるので、ここでは偽の精度感は避けている。複数の実行で成立したパターン：vLLMは大きく安定したバッチを好む。SGLangはスパイクのあるトラフィックと小さなバッチをうまく処理する。

最初のトークンのレイテンシ比較

チャット系アプリでは、最初のトークンのレイテンシが予想以上に重要だった。小さなバッチと短いコンテキストでは：

SGLang は最初のトークンを少し早く返す傾向があった。特にルーティングオーバーヘッドがノイジーになりやすいQ4で顕著だった。
vLLMはストリームが始まってからの合計完了時間でしばしば追いついた——ページングとバッチングのおかげで。

KVキャッシュを量子化すると、両方ともメモリ使用量が改善したが、最初のトークンのレイテンシはわずかに悪化した。インタラクティブな用途ではKVをFP16/BF16のままにして、KV量子化はオフラインジョブ用に温存した。

量子化の品質トレードオフ

Q4 vs Q8 vs BF16のベンチマークスコア

僕が信頼している軽いテストセットを実行した——MMLUスタイルの知識問題、いくつかのコーディングプロンプト、小さな数学セクション（GSM8K風）。正式なリーダーボードではない。エッジを感じるには十分だった。

観察したこと：

BF16：ベースライン。
Q8：知識タスクでBF16から通常1〜2ポイント以内。コード生成はほとんどの場合同じに見えた。温度を少し下げないと、長い思考の連鎖が必要な数学でまれな退行が現れた。
Q4：知識タスクで3〜6ポイントの低下。数学と構造的な推論でより顕著なブレ。コードでは、Q4は編集スタイルのタスクには問題なかったが、長い関数をゼロから書くのには向いていなかった。

これらのギャップは思っていたよりも小さく、それは良いサプライズだった。しかし難しいプロンプトを重ねると顕在化する。

量子化損失を許容できるタスク

Q4で問題ないと感じた用途：

コンテンツの下書き、要約、製品説明。
事実性がソースから来る短い検索ベースの回答。
精度より速度が重要な素早いアイデア出し。

Q8またはBF16を好んだ用途：

正確さが厳しく求められる多段階の推論や数学。
クリーンアップなしでコンパイルが通る必要がある長いコード生成。
決定論性を求めていて、小さな変化が連鎖するプロンプト。

迷っているならQ8から始めよう。より安定したデフォルトだ。実際のプロンプトが1週間安定していることを確認してからQ4に下げるといい。

API vs セルフホスト：損益分岐点計算機

異なるボリュームでのGPUレンタルコスト vs APIコスト

自分用にシンプルなシートを作った。重要だった入力値は：

GPU時間単価（使ったオンデマンドH100は $2.0〜$3.5/時。A100は $1.5〜$2.5/時。コンシューマGPUは安いが気難しい）。
選んだ精度での1GPU当たりの実効トークン/秒（約37Bアクティブなモデルに保守的な範囲を使用：快適なバッチサイズで1GPU当たり数十トークン/秒。量子化とバッチングでより多く）。
稼働率（実際にGPUをどれだけ使い続けているか）。
API価格（100万トークン当たりの金額）（プロバイダーによって大きく異なるため、$1、$3、$5/1Mトークンのシナリオをテストした）。

僕が実行した2つの簡単な例：

軽い社内利用：月500万トークン

API $3/1M ≈ 月$15。H100を数時間でも自己ホストするとそれを超える。APIの勝ち。

より重い利用：月5億トークン

API $3/1M ≈ 月$1,500。
H100 1台 $3/時、24/7稼働で ≈ 月$2,160。しかし量子化した4090が2台でスループットをカバーできて、オンプレミスで動かせるなら、限界コストは低くなるかもしれない（電力費＋償却費）、時間単位のレンタルではなく。ここでスプレッドシートが重要になる。

自分に言い聞かせる必要があった隠れたコスト：エンジニアリング時間（サービング、アップデート、障害対応）、オブザーバビリティ、そして「もう1つのモデルを追加するだけ」が必ずやってくるという現実。

何トークン/月でセルフホストが有利になるか

上記の前提の下では、セルフホストが合理的に見えてきたのは月3億〜8億トークン前後だった。条件は：

GPUを50%以上稼働させられるかどうか、
Q4/Q8で品質が許容できるかどうか、
そして既に運用体制が整っているかどうか。

利用がバースト的で少量なら、APIがほぼ常に有利だ。そちらの方向に傾いているなら、**DeepSeek V4をAPIで使う方法**に関するこの実践ガイドが、GPUインフラに触れることなくセットアップと使い方のパターンを解説してくれる。

安定したジョブ（バッチ生成、ファインチューニングされたプロンプト、社内ツール）を実行していて、GPUを常に動かしておけるなら、セルフホストの損益分岐点は早く来る。V4だけのためにハードウェアを買うのは、少なくとも四半期にわたって月に数億トークンを供給できると分かっている場合を除き、お勧めしない。