MoE大規模モデルは自前運用かAPIか？2026年の損益分岐点
MoE大規模モデルは自前運用かAPIかで迷う場合、利用率が低い、需要の波が大きい、またはモデル検証が終わっていないなら、APIか短期レンタルを選ぶべきです。長期の自前運用は、負荷が安定し、データ管理上の理由が明確で、分散推論を保守できるチームに限って成立します。
この記事は、AIスタートアップやAgent製品チーム、MLOps担当者、GPU予算を管理する技術責任者向けです。重みを載せられるかだけでなく、実際のリクエストを安定して処理できるかまで判断したい場合に役立ちます。
1. 容量比較では、アクティブパラメータより完全常駐を先に見る
MoEモデルのアクティブパラメータは、1トークンの計算で選ばれる専門家の規模を示します。しかし、これをそのまま推論時のGPUメモリ容量として扱うことはできません。専門家を分散配置する場合でも、重みの配置、共有層、ルーター、量子化スケール、通信バッファを実行環境に載せる必要があります。
推論用の必要容量は、少なくとも次の4項目に分けて計算します。
必要GPUメモリ
＝ 重み本体 ＋ 量子化メタデータ
＋ 実行時ワークスペース ＋ KV Cache ＋ 安全余白
ここで重要なのは、次の3段階を分けることです。
- ロード可能：モデルファイルをメモリに配置できる状態です。
- 生成可能：少数の入力を受けて、エラーなく出力できる状態です。
- 業務負荷対応可能：指定した同時実行数、入力長、出力長、遅延目標を維持できる状態です。
例えば、公式ファイル一覧でDeepSeek V4系のリポジトリ容量が865 GBと示されている場合、それは保存領域の目安にはなります。しかし、保存容量とGPUメモリは同じではありません。展開方式、量子化形式、KV Cache、実行時の一時領域を別に確認する必要があります。公式ファイル一覧
| 判定 | 確認するもの | 購入・契約判断 |
|---|---|---|
| 容量成立 | 重み、量子化情報、共有層が収まるか | 収まらなければ即時中止 |
| 生成成立 | 1リクエストを最後まで処理できるか | 低同時実行の検証へ進む |
| 業務成立 | 実際の入力長、出力長、同時数、遅延 | 本番候補として比較 |
| 余白成立 | KV Cacheと障害時の再配置余地 | 長期自前運用の条件 |
DeepSeek V4の公式設定では、最大位置長が1,048,576、ルーティング専門家が384、1トークンあたりの選択数が6と記載されています。これらはモデル構造を確認するための情報であり、必要GPU枚数を直接意味しません。公式設定ファイル
2. 実行環境では、ファイルの有無より互換性を確認する
大規模モデルでは、ダウンロードできたことが稼働確認にはなりません。量子化形式、カーネル、GPU世代、ドライバー、推論フレームワークの対応がそろって初めて、実行可能な構成になります。
確認対象は次の通りです。
- モデルカードが指定する推論ライブラリとバージョン
- FP8、FP4、BF16などの重み・活性値形式
- GPUごとの対応命令とカーネル
- Tensor Parallel、Pipeline Parallel、Expert Parallelの組み合わせ
- ノード間通信の帯域とトポロジー
- 起動時に自動設定された最大コンテキスト長
- KV Cacheの予約量とメモリ使用率
MoEでは、Expert Parallelを使うと専門家層を複数デバイスへ分散できます。一方で、専門家間のAll-to-All通信が発生するため、GPU枚数だけ増やしても処理効率が比例するとは限りません。Expert Parallelの公式設計資料
Tensor ParallelとPipeline Parallelを組み合わせれば、単一ノードに入らないモデルも分散できます。ただし、レイヤー分割による待ち時間、ノード間通信、再起動時の復旧手順が増えます。分散サービングの公式資料
Kimi K3とQwen3.8 Maxは、未確認の容量を購入根拠にしない
Kimi K3やQwen3.8 Maxについて、コミュニティ投稿や報道記事に記載されたパラメータ数、量子化形式、必要GPU構成を、そのまま本番の見積もりに使うのは危険です。公式モデルカード、重みファイル一覧、設定ファイル、対応ランタイムがそろった版だけを確定情報として扱います。
公式資料が確認できない項目は、比較表では「待填」として残します。予測値でGPU台数を決めるより、モデル公開後に同じ起動ログと負荷条件で再計算した方が、調達ミスを防げます。
| モデル | 公式資料で確認する項目 | 現時点の扱い |
|---|---|---|
| Kimi K3 | モデルカード、重み一覧、量子化形式、推論手順 | 確認できた版のみ容量計算 |
| DeepSeek V4 | 設定、ファイル一覧、推論コード、対応手順 | 公式資料を基準に計算 |
| Qwen3.8 Max | 公式モデル名、重み、設定、ライセンス | 未確認項目は待填 |
| Qwen3.8-2.4T-A95B | 公式リポジトリと実行方法 | 伝聞値は採用しない |
3. 利用率で見ると、APIと自前運用の比較結果が変わる
自前運用の費用をGPUの占有時間だけで割ると、実態より安く見えます。実際には、ピークに備えた待機容量、夜間のアイドル時間、失敗リクエスト、再試行、監視、アップデート時間も負担になります。
比較対象を同じ業務負荷にそろえ、次の値を1週間以上の実ログから集計します。
- 1日あたりの入力トークンと出力トークン
- リクエスト数と同時実行数
- 入力・出力の長さの分布
- ピーク時間帯と低負荷時間帯
- 目標レイテンシー
- タイムアウト、失敗、再試行の件数
- ツール呼び出しやAgentループによる追加推論
「毎日何回呼び出せば自前運用が得か」という問いに、共通の回数を答えることはできません。1回あたりのトークン量、許容遅延、ピーク待機容量、運用工数が違うためです。比較すべき分母は呼び出し回数ではなく、サービス目標を満たして完了したリクエストまたはトークンです。
自前運用の総費用
自前運用費
＝ GPU占有・減価償却費
＋ ストレージ・転送費
＋ 監視・障害復旧費
＋ エンジニア工数
＋ 予備容量・アイドル費
＋ リスク準備費
APIの総費用
API費
＝ 入力トークン費
＋ 出力トークン費
＋ 推論モードの追加費
＋ ツール呼び出し費
＋ 失敗・再試行分
APIの料金表は、入力と出力、キャッシュ、推論モードなどで分かれることがあります。自前運用と比べる際は、単価だけでなく、同じ入力長・出力長・成功率・遅延目標にそろえます。
注意：APIの月額見積もりを、そのままGPU購入費と比較してはいけません。自前側には、未使用時間、保守担当者、障害時の二重化、モデル更新の検証時間が含まれるためです。
4. 短期レンタルは、未知の変数を埋めるために使う
モデルの重みや実行方法が変わる時期に、いきなり長期契約や固定クラスターを組むと、誤った前提を長期間抱えることになります。短期レンタルは、単なる費用削減ではなく、次の変数を実測するための検証枠として使うのが適切です。
- 公式モデルファイルを取得し、ハッシュと容量を記録します。
- 推論ランタイムとドライバーの組み合わせを固定します。
- 起動ログから、使用メモリ、KV Cache予約量、並列設定を保存します。
- 実際の業務ログから代表的な入力長、出力長、同時数を再現します。
- 低負荷、通常負荷、ピーク負荷で有効スループットを測定します。
- タイムアウト、再試行、OOM、プロセス再起動を記録します。
- 完了リクエストまたは完了トークン単位で費用を割り直します。
vLLMの公式資料でも、GPUメモリ使用率は重み、活性値、KV Cacheの予約に関係し、最大モデル長によって必要容量が変わると説明されています。したがって、起動直後のメモリ表示だけで本番容量を決めることはできません。KV Cache容量計算の公式資料
5. 損益分岐点は、三つのルートを同じ条件で並べる
API、自前運用、短期レンタルを比較する際は、次の式で同じ期間と同じサービス目標にそろえます。
損益分岐点
＝ 自前運用の総費用 ＝ APIの総費用
ただし、実務では一つの境界線ではなく、三つの条件を同時に確認します。
- 容量条件：重み、実行時領域、KV Cache、安全余白が成立しているか。
- 利用率条件：予約した容量を、実際の完了リクエストで十分に回収できるか。
- 運用条件：障害復旧、更新、監視、ロールバックを担当できるか。
次のチェック項目を満たせない場合、長期自前運用の比較から一度離れます。
- [ ] 公式ファイル一覧と設定ファイルを保存した
- [ ] 量子化形式と推論ランタイムの対応を確認した
- [ ] ロード、生成、業務負荷対応を別々に検証した
- [ ] KV Cacheを含むピークメモリを記録した
- [ ] 1週間分の入力・出力トークンを集計した
- [ ] 失敗、再試行、タイムアウトを費用に加えた
- [ ] 予備容量とアイドル時間を見積もった
- [ ] 障害時の再起動とロールバックを実行した
- [ ] モデル更新時の再検証時間を予算化した
API、短期レンタル、自前運用の放棄線
APIを選ぶ条件
- 需要が短期的で、ピークと平常時の差が大きい場合
- モデルを頻繁に変更する場合
- GPU障害や分散通信を担当できる人員がいない場合
- セキュリティ要件上、外部APIが許容される場合
短期レンタルを選ぶ条件
- 重みは確定したが、実効スループットが未知の場合
- APIでは確認できないレイテンシーや同時実行数を測りたい場合
- モデルを数週間単位で比較したい場合
- 長期契約前に容量と復旧手順を検証したい場合
自前運用を選ぶ条件
- 業務負荷が継続し、利用率を安定して確保できる場合
- データ管理、監査、レイテンシーなどの制御要求が明確な場合
- Expert Parallelを含む分散推論を保守できる場合
- 失敗時の切り戻しとモデル更新を運用手順にできる場合
容量が成立しないなら、GPUの価格交渉を始める前に止めるべきです。業務負荷が不足するなら、長期自前運用へ進む前にAPIか短期レンタルへ戻します。復旧責任を負えない場合は、生成できたという事実だけで本番合格にしてはいけません。
現在のAPI運用は、GPU管理や障害復旧を省ける一方で、データ経路、モデル変更、単価改定、レイテンシーを完全には制御できません。自社GPUは制御性が高い反面、アイドル容量、分散通信、保守工数、モデル更新の再検証が発生します。モデルが変わり続ける段階なら、固定設備よりも、停止や構成変更がしやすいProxyMacの短期レンタルで検証する方が、判断を誤った際の撤退コストを抑えやすくなります。
まずは一週間分の実リクエストを整理し、短期レンタルの利用方法と容量検証の条件を照合してください。利用期間や契約条件を確認する場合は料金案内、稼働中の環境を管理する場合は管理コンソールから、検証期間を必要以上に固定しない形で進めるのが安全です。
