大規模オープンウェイトモデルを自前ホスティングすべきか?損益分岐点の計算ガイド
Kimi K3のような2兆パラメータ級のオープンウェイトモデルが登場するたびに「自分のサーバーに載せて使えるのでは」という声が出ます。この記事では、必要なGPUメモリの見積もり方から、クラウドでの月額コスト試算、API利用との損益分岐点の計算式まで、モデルの規模によらず使える判断フレームワークとして整理します。
結論:自前ホスティングが正当化されるのは「大量・継続・特殊要件」のいずれかがある場合だけ
先に要点を言うと、多くのケースではAPI利用の方が安上がりです。自前ホスティングが経済的に見合うのは、次のいずれかに該当する場合に限られます。
- 月間のトークン消費量が非常に大きく、GPUの稼働率を高く保てる(後述の損益分岐点を超える場合)
- データを外部に一切送信できない(規制・契約上の制約でAPI利用そのものが選択肢にない)
- 独自のファインチューニングを継続的に行い、その基盤として使う
- レイテンシー要件が極端に厳しく、自社ネットワーク内での推論が必須
「話題のモデルだから」「性能で選びたいから」という理由だけで自前ホスティングを選ぶと、多くの場合コスト面で損をします。以下、その理由を数字で見ていきます。
ステップ1:必要なGPUメモリを計算する
自前ホスティングの第一関門は、モデルの重み全体をGPUメモリ(VRAM)に載せられるかどうかです。おおまかな計算式は次の通りです。
必要VRAM(GB) ≈ パラメータ数(億単位) × 1パラメータあたりのバイト数 × 1.2
# 1.2倍しているのはKVキャッシュ・アクティベーション・実行時オーバーヘッド分の余裕
# 1パラメータあたりのバイト数の目安:
# FP16(非圧縮) = 2バイト
# 8bit量子化 = 1バイト
# 4bit量子化(MXFP4等)= 0.5バイト
この式に当てはめると、代表的な規模のモデルで必要なVRAMは次のようになります。
| モデル規模 | FP16(非圧縮) | 8bit量子化 | 4bit量子化 |
|---|---|---|---|
| 70B(例:Llama 3.1 70B級) | 約168GB | 約84GB | 約42GB |
| 400B級(例:Llama 3.1 405B級) | 約972GB | 約486GB | 約243GB |
| 2.8T(Kimi K3級) | 約6.7TB | 約3.4TB | 約1.7TB |
現行世代の主要GPUのメモリ容量は、H100が80GB、H200が141GBです。必要VRAMをこの数字で割ると、最低限必要なGPU枚数が分かります。ただし多くのクラウドの大規模GPUインスタンスは8枚単位(1ノード)で提供されるため、実際に借りる枚数は8の倍数に切り上がることが多い点に注意してください。
ステップ2:GPU枚数とクラウドの月額費用を試算する
4bit量子化を前提に、必要GPU枚数とクラウドでの月額費用(24時間365日稼働・オンデマンド料金)を試算します。
| モデル規模 | 必要VRAM | H100(80GB)換算 | H200(141GB)換算 |
|---|---|---|---|
| 70B | 約42GB | 1枚で足りる | 1枚で足りる |
| 400B級 | 約243GB | 4枚(または1ノード8枚) | 2枚 |
| 2.8T | 約1.7TB | 約22枚→3ノード(24枚) | 約12枚→2ノード(16枚) |
GCPの公開オンデマンド料金(2026年5月時点、us-central1)を目安にすると、H100 8枚ノード(a3-highgpu-8g)が1時間あたり約88ドル、H200 8枚ノード(a3-ultragpu-8g)が約98ドルです。これを24時間×30日(720〜730時間)で月額換算すると、次のようになります。
| モデル規模 | 構成 | 月額(オンデマンド概算) |
|---|---|---|
| 70B | H100×1枚相当 | 約8万円〜(ノード共有 or 小規模GPUクラウドの場合) |
| 400B級 | H100×8枚(1ノード) | 約950万円/月($88×730) |
| 2.8T | H200×16枚(2ノード) | 約1,430万円/月($98×2×730) |
ストレージ(重みの保管)、ネットワーク帯域、ロードバランサー、監視・運用のエンジニア人件費は含まれていません。また、クラウド事業者によって料金は大きく異なり(同条件でもAWSの方が安く出るケースがあります)、リージョン・契約形態でも変動します。実際の予算策定時は、各クラウドの公式料金計算ツールで確認してください。
ステップ3:API利用との損益分岐点を計算する
自前ホスティングの月額費用が分かったら、同じ作業をAPI経由で行った場合の費用と比較します。損益分岐点となる月間トークン数は、次の式で概算できます。
損益分岐点(月間トークン数) = 自前ホスティングの月額費用 ÷ API単価(1トークンあたり)
# 例:月額1,430万円のホスティング費用、API単価が出力$15/100万トークン(≒2,250円/100万トークン)の場合
# 1,430万円 ÷ (2,250円 ÷ 1,000,000トークン) = 約63.5億トークン/月 が損益分岐点
月間63.5億トークンというのは、1日あたり2億トークン以上を継続的に消費する規模です。これはかなり大規模なプロダクトでないと到達しない水準で、多くの企業にとっては「自前ホスティングの方が高くつく」領域にとどまります。
自社の月間トークン消費量(API利用中なら請求書からすぐ分かります)を、この損益分岐点と比較してください。消費量が損益分岐点を大きく下回るなら、自前ホスティングを検討する経済的な理由はほぼありません。逆に、継続的に損益分岐点を超えている、あるいは今後確実に超える見込みがあるなら、自前ホスティングの検討価値が出てきます。
稼働率の影響を忘れない
この計算はGPUを24時間365日フル稼働させ続けられることが前提です。実際のトラフィックには波があり、深夜や閑散期にGPUが遊んでいる時間があれば、その分だけ実質的な損益分岐点は悪化(=より多くのトークン消費量が必要)します。オートスケーリングでGPUを増減できる構成にすれば改善しますが、大規模モデルはそもそも起動(モデルのロード)に時間がかかるため、細かいスケールイン・アウトには向きません。
自前ホスティングが実際に正当化されるケース
| ケース | 理由 |
|---|---|
| 金融・医療・行政など、データを外部に出せない業界 | コスト以前に、API利用という選択肢自体が規制上取れないことがある |
| 継続的な独自ファインチューニングの基盤 | ベースモデルを社内データで学習し続ける運用では、自前環境が前提になる |
| 超大量・定常的な推論需要を持つ自社サービス | 損益分岐点を継続的に超える規模のプロダクトでは、自前化でコストを圧縮できる |
| 厳しいレイテンシー要件(工場の制御システム等) | ネットワーク往復自体がボトルネックになる場合、オンプレ・エッジでの推論が必須 |
逆に言えば、これらに当てはまらない大多数のユースケース(社内ツール、SaaS製品への組み込み、個人開発)では、API利用の方が総コストで有利になるケースがほとんどです。
「試したい」だけならもっと安い選択肢がある
自前ホスティングにも段階があります。いきなり大規模クラウドのオンデマンド料金で24時間稼働させる必要はありません。
- Spotインスタンス:クラウド事業者の余剰GPUを大幅割引(オンデマンドの3〜6割程度)で使えますが、いつでも中断(プリエンプション)されるリスクがあり、本番の推論サービスには向きません。検証・バッチ処理用途向けです
- コミット利用割引(CUD):1〜3年の利用契約で2〜4割程度の割引が受けられますが、需要が確定していない段階では固定費リスクを負うことになります
- 専門のGPUクラウド(RunPod・Lambda等):大手クラウドより柔軟な単位(GPU1枚単位など)で借りられ、小〜中規模モデルの検証には向いています
- マネージド推論サービス:モデルのホスティングだけを代行してくれるサービスを使えば、インフラ管理の手間なく「セルフホスト相当」の柔軟性を得られる場合があります
「自前ホスティングがどういうものか体験したい」という段階なら、2.8兆パラメータ級ではなく、GPU1枚に収まる70B級の量子化モデルから始めるのが現実的です。損益分岐点の考え方はモデル規模が変わっても同じ式で計算できるので、小規模モデルでの検証がそのまま判断材料の練習になります。
よくある質問
Q. Kimi K3のような2.8兆パラメータのモデルは、結局誰が自前ホスティングするのですか?
個人や中小企業がこの規模を自前運用することは、経済的にもGPU確保の観点でも現実的ではありません。実際にメリットを得るのは、大規模GPUクラスタをすでに持つ企業・研究機関や、それをAPIとして再販するクラウドホスティング事業者です。個人にとっての恩恵は、そうした事業者間の価格競争でAPI利用料が下がる、という間接的な形になります。
Q. オンプレミス(自社データセンター)ならクラウドより安くなりますか?
GPUを長期間(3〜5年以上)高い稼働率で使い続けられるなら、初期投資込みでもクラウドより安くなる可能性はあります。ただし、GPU自体の調達コスト・電力・冷却・保守要員が必要になり、最新GPU世代への追従も自己負担になります。この記事の計算式は「クラウドで借りた場合」を前提にしていますが、オンプレの検討では減価償却も含めた別の計算が必要です。
Q. 量子化するとモデルの性能は落ちませんか?
一般に4bit量子化はFP16と比べて性能がわずかに低下しますが、多くのケースで実用上の差は小さいとされています。Kimi K3のMXFP4のように、モデル開発元が公式に量子化フォーマットを提供している場合は、その組み合わせでの精度検証も行われていることが多く、非公式な量子化より信頼性が高い傾向があります。
Q. この計算式はKimi K3以外のモデルにも使えますか?
使えます。パラメータ数と量子化方式さえ分かれば、Llama・DeepSeek・Qwenなど他のオープンウェイトモデルでも同じ式でVRAM所要量とコストを試算できます。新しい大規模モデルが発表されるたびに、この記事の式に当てはめて損益分岐点を確認する、という使い方を想定しています。
まとめ
- 必要VRAMは「パラメータ数×1パラメータのバイト数×1.2」で概算できる。4bit量子化なら2.8Tモデルでも約1.7TB
- クラウドでのGPU月額費用は、大規模モデルになるほど数百万〜数千万円/月の規模になる
- 損益分岐点は「月額ホスティング費用÷API単価」で計算できる。多くの場合、月間数十億トークン規模の消費がないと自前化は割に合わない
- 自前ホスティングが正当化されるのは、データ主権・継続的なファインチューニング・超大量の定常需要・厳しいレイテンシー要件のいずれかがある場合
- まずは自社の月間トークン消費量を損益分岐点と比較するところから始める
新しい大規模オープンウェイトモデルが話題になるたびに「自分でも動かせるのでは」と考える前に、まず自社の月間トークン消費量を確認し、この記事の式で損益分岐点と比べてみてください。多くの場合、答えは「まだAPI利用で十分」になるはずです。


