自社でLLM（大規模言語モデル）推論基盤を構築する際、GPUのVRAM（GPU上の高速メモリ）見積もりを誤って本番障害を起こすケースが報告されています。
対象になるのは、MoE（Mixture of Experts、複数の専門家ネットワークを切り替えて使うアーキテクチャ）型の大規模モデルを自社GPUクラスタにデプロイしようとしているSRE・インフラ担当者です。特にDeepSeek-V4.1-FlashやKimi K2.5のような2026年世代の巨大MoEモデルを検討している場合、見積もり段階でのつまずきが本番のOOM（Out Of Memory、メモリ不足によるプロセス停止）に直結します。この記事では、その計算式と確認手順を整理します。
よくある見積もりミスの構造
MoEモデルは「トークンごとに使われるパラメータ（アクティブパラメータ）」が総パラメータよりずっと小さいのが特徴です。
たとえばDeepSeek-V4.1-Flashは総パラメータ552B（MoE部分）+196B（Engramと呼ばれる補助コンポーネント）という巨大な構成ですが、1トークンあたりに実際に計算で使われるのは8B〜16Bほどです。
ここで多くのインフラチームが「アクティブパラメータ分だけVRAMを確保すればいい」と考えてしまいます。しかし推論サーバーはリクエストごとにどの専門家（Expert）が呼ばれるか動的に変わるため、全エキスパートを常にGPUメモリ上に待機させる必要があります。結果として、アクティブパラメータ基準で小さく見積もったクラスタは、vLLM（LLM推論を高速化するOSSサーバー）の起動時点でOOMを起こすか、同時接続のマルチターンエージェントリクエストのたびにKVキャッシュ（会話の文脈を保持するための中間データ）が強制退避される事態に陥ります。
VRAM見積もりの3要素と計算式
本番運用に必要な総VRAMは、同時実行ストリーム数Cと32kコンテキスト長を前提に、3つの要素の合算に6%以上の断片化バッファを掛けた値として表せます。
VRAM_total = (VRAM_weights + VRAM_KV(C) + VRAM_CUDA) × 1.06- VRAM_weights: ルーティングされる全エキスパート+共有エキスパートの重み。Tensor Parallel（
--tensor-parallel-size）やExpert Parallel（--enable-expert-parallel）のグループ全体でGPUメモリに常駐させる必要があります - VRAM_KV(C): PagedAttention（KVキャッシュをページ単位で効率管理する仕組み）によるKVキャッシュ。同時接続数とコンテキスト長に比例して線形に増加します
- VRAM_CUDA: PyTorchのアクティベーション用スクラッチパッド、NCCL（GPU間通信ライブラリ）のAllReduceリングバッファ、CUDA Graphキャプチャに使われるオーバーヘッドで、重みメモリの約3.5%（ノードあたり最低6GB〜20GB）です
未検証領域にも触れておくと、MLA（Multi-Head Latent Attention、KV状態を圧縮する注意機構）を採用したモデルはKVキャッシュを大幅に圧縮できます。DeepSeek-V4.1-FlashはFP8 KVで32kストリームあたり約2.4GBまで圧縮されますが、MLAを使わない幅広アーキテクチャでは同条件で3.0GB〜3.8GBかかります。この差は同時接続数が増えるほど効いてくるため、見積もり時に採用モデルのアテンション方式を確認する価値があります。
参考値で見るモデル間の差
40同時ストリーム・32kコンテキストという条件で、代表的なモデルのVRAM要件を比べると規模感がつかみやすくなります。
| モデル | 総パラメータ/アクティブ | FP8重み | 推奨クラスタ |
|---|---|---|---|
| DeepSeek-V4.1-Flash | 552B+196B / 8-16B | 590GB | 8×H200 SXM (1,128GB) |
| Kimi K2.5 | 1.04T / 32B | 1,050GB | 8×H200/8×B200 |
| GLM-5.3-Flash | 320B / 18B | 185GB | 4×H100 SXM (320GB) |
| GLM-4.5-Air | 106B / 12B | 64GB | 4×L40S/4×H100 |
FP8量子化（重みを8bit浮動小数点に圧縮する手法）でもKimi K2.5は1TB超、BF16では2TBを超えます。総パラメータの規模がそのままクラスタ規模に跳ね返る点が、アクティブパラメータだけを見て判断する危うさを示しています。
クラウドAPIと自前クラスタのコスト比較で見落としがちな点
GPT-5やClaude 4.5 Sonnetのような商用API利用は1Mトークンあたり4.60〜7.20ドルの混合単価で課金されます。一方、8×H100ノードの自前クラスタは36ヶ月リース換算で月額13,500ドル、8×H200ノードは17,800ドル程度という水準が参照されています。
ここで注意したいのは、ノードレンタル料金に何が含まれていて何が含まれていないかです。含まれるのは通常、デュアルソケットのAMD EPYC 9654/9754クラスのホストCPU、2〜4TBのDDR5 ECCメモリ、30TB超のNVMe Gen5ストレージ、900GB/s〜1.8TB/sのNVLink/NVSwitchバックプレーンといったシャーシ内部のBOM（部品構成）です。
一方で、自社のTier-3/Tier-4コロケーション施設に持ち込む場合は、ラックスペース、DLC（Direct Liquid Cooling、液冷設備）、継続的な電力契約が別予算になります。クラウドの「GPU時間課金」とベアメタルの「月額固定+電力別」は会計上の扱いが違うため、FinOps（クラウドコスト最適化の実践）観点でTCO（総所有コスト）を比較する際はこの境界線を明示しておく必要があります。
今日確認できること
実際に自社でMoEモデルのデプロイを検討しているなら、まず手元の推論サーバー設定を点検するところから始められます。
# vLLMの起動オプションでTensor ParallelとExpert Parallelの設定を確認
vllm serve <model_path> \
--tensor-parallel-size 8 \
--enable-expert-parallel \
--max-model-len 32768 \
--gpu-memory-utilization 0.92- 採用予定モデルの「総パラメータ」と「アクティブパラメータ」を公式モデルカードで確認する
- アテンション方式（MLAかどうか）を確認し、KVキャッシュのGB/ストリーム値を見積もりに反映する
--gpu-memory-utilizationの設定値がCUDAバッファ分の余白（重みの3.5%程度）を確保しているか確認する- 想定する同時接続数Cと32kコンテキスト換算でのKVキャッシュ総量を計算式に当てはめる
- クラウドAPI課金とベアメタルリースを比較する際は、電力・冷却・ラック費用を別枠で積む
精密な見積もりには稼働予定モデルのモデルカード記載値とvLLMやSGLangなど利用予定の推論エンジンのドキュメントで、量子化方式ごとのメモリ使用量を照合するのが確実です。
まとめ
MoEモデルのVRAM見積もりは、アクティブパラメータではなく全エキスパートの常駐重みとKVキャッシュの合算で判断する必要があります。
計算式「(重み+KVキャッシュ+CUDAオーバーヘッド)×1.06」を基準に、採用モデルのアテンション方式と量子化レベルを公式情報で確認するところから始めてみてください。
クラウドAPIとベアメタル自前クラスタのコスト比較では、電力・冷却・ラックといった見えにくいコストも含めたTCOで判断することが、本番障害を避けるための現実的な一歩になります。