社内で機械学習モデルを本番投入する段階になり、推論用のインフラをどう選ぶか悩んでいる開発者やSREに向けた内容です。GPU（画像処理向けに設計された演算装置で、行列計算が得意なため機械学習の推論・学習にも使われます）を自前で用意するのか、クラウドのAPIサービスに任せるのか、この判断は一度決めたら終わりではなく、運用コストと障害対応の両面で継続的な見直しが必要になります。
2020年、ある金融サービス企業の不正検知モデルが、開発環境では99.2%の精度を出していたにもかかわらず、本番投入から1週間で誤検知が300%増加し、正当な取引を大量にブロックする事態が起きました。原因はモデルの不具合ではなく、コロナ禍による消費行動の急変で、学習データの分布と現実がずれてしまったことでした。これはデータドリフト（学習時と本番運用時でデータの傾向が変化する現象）と呼ばれる問題で、従来型ソフトウェアのバグとは性質が異なります。バグは「ある」か「ない」かですが、モデルの劣化は静かに進行し、監視していなければ顧客からの苦情で初めて気づくことになります。
この手の障害を防ぐには、モデルを動かす基盤の設計段階から運用を見据えた判断が必要です。ここでは推論インフラの選定を、GPU購入・クラウドGPUインスタンス・クラウドAPIサービスの3択として整理し、判断軸を示します。
どんな場面でこの判断が必要になるか
Jupyter Notebook（対話的にコードを実行しながら分析できる開発環境）で作ったモデルを、実際にAPIとして外部に公開するタイミングで、この選定は避けて通れません。
開発時はローカルのノートPCやワークステーションで十分でも、本番では常時稼働・高可用性・スケーラビリティが求められます。
さらに厄介なのは、モデルは一度デプロイして終わりではない点です。データドリフトやモデルドリフト（モデルの予測精度が時間とともに劣化する現象）が起きれば再学習が必要になり、そのたびに計算資源が必要になります。つまりインフラ選定は「初期コスト」だけでなく「継続的な運用コスト」まで見込んで判断する必要があります。
判断軸1: VRAM要件とモデルサイズ
GPUを使う場合、最初に確認すべきは VRAM（GPU上でモデルの重みや中間計算結果を保持するメモリ）の容量です。
目安として、70億パラメータ（7B）のモデルを16bit精度で動かす場合、重みだけで約14GB、活性化やKVキャッシュを含めると16〜20GB程度のVRAMが必要になります。700億パラメータ（70B）クラスになると140〜160GB規模となり、高性能GPUを複数枚組み合わせる構成が前提になります。
量子化（モデルの重みの精度を落として必要メモリを削減する手法）を使えば、8bit量子化でメモリ要件はおよそ半分、4bit量子化では4分の1程度まで圧縮できます。代わりに精度がわずかに落ちますが、推論タスクでは体感できないほどの劣化にとどまることも珍しくありません。
手元のモデルがどの程度のVRAMを必要とするかは、モデルサイズ・精度・シーケンス長から見積もるツール（LLM Hardware Requirements Calculatorなど）で事前に確認しておくと、ハードウェア選定のミスマッチを防げます。
判断軸2: 初期投資とランニングコストのバランス
GPUを自前で調達する場合、価格帯は用途によって大きく変わります。
| 選択肢 | 初期費用感 | 向いている規模 | 運用の手間 |
|---|---|---|---|
| コンシューマー向けGPU(RTX 5060〜5090) | 約3万円〜30万円 | 7B〜30B級、検証・小規模運用 | 電源・冷却・保守を自前で対応 |
| データセンター向けGPU(A100/H100) | 約150万円〜450万円 | 70B級以上、大規模バッチ処理 | ラック設置・電力・専任運用体制が必要 |
| クラウドGPUインスタンス | 初期費用ゼロ、従量課金 | 負荷変動がある本番運用 | スケーリング設定と監視の設計が必要 |
| クラウドAPIサービス(推論のみ利用) | 初期費用ゼロ、リクエスト課金 | 自社でモデル運用したくない場合 | ベンダー依存・レイテンシは相手任せ |
ここで重要なのは、GPUを自前で買う判断は「初期費用が安く見える」ことと「稼働率が低いと割高になる」ことが表裏一体という点です。データセンター向けの高性能GPUは数百万円規模の初期投資になりますが、24時間フル稼働させ続けられるなら1推論あたりの単価は下がります。逆に、夜間や週末に負荷が落ちる業務用途では、遊休時間分の投資が無駄になります。
判断軸3: 監視設計のしやすさ
推論基盤は「動いているかどうか」だけでなく、「劣化していないか」を継続監視できる構成かどうかも判断材料になります。
自前のGPUサーバーであれば、nvidia-smiやdcgm-exporterのようなツールでGPU使用率・温度・メモリ使用量を細かく取得でき、Prometheus・Grafanaのような既存の監視スタックにそのまま組み込みやすい利点があります。
一方、クラウドAPIサービスは推論の中身がブラックボックスになりがちで、レイテンシやエラーレートは取得できても、GPUレベルの詳細な指標は見えないことが多くあります。加えて、予測精度の劣化(モデルドリフト)を検知するには、入力データの分布と予測結果を自前でログに残し、定期的に統計的な差分をチェックする仕組みが結局のところ別途必要です。つまりインフラをどこに置くかに関わらず、ドリフト監視の設計は自社で用意する前提で考えておくのが安全です。
判断軸4: 障害発生時の切り分けやすさ
本番で誤検知や精度劣化が起きたとき、原因がインフラなのか、データなのか、モデルなのかを切り分ける速さもインフラ選定に影響します。
自前運用ならログ・メトリクス・モデルバージョンをすべて自社で保持しているため、根本原因分析（インシデントの真因を特定する作業）を自社のペースで進められます。反対にクラウドAPIに全面依存していると、ベンダー側の障害なのか自社のデータ品質の問題なのか切り分けに時間がかかる場面が出てきます。冒頭の不正検知モデルの事例のように、原因が「モデルの不具合」ではなく「データの変質」だったケースでは、入力データのログが手元に残っているかどうかが調査スピードを大きく左右します。
ケース別の推奨
- 7B〜13B級モデルを社内検証や小規模運用で使うなら、RTX 5070〜5080クラスのコンシューマーGPUを自前用意する選択で十分間に合います
- 負荷変動が大きい本番サービスで、常時フル稼働ではないなら、クラウドGPUインスタンスの従量課金構成が無駄なコストを抑えやすい選択です
- 70B級以上の大規模モデルを24時間稼働させる前提があるなら、A100/H100クラスの自社保有または長期予約インスタンスがコスト効率で有利になります
- 推論の中身を自社で細かく監視・チューニングする必要がなく、まずスピーディに機能を出したいなら、クラウドAPIサービスから始めるのが妥当です
あえて見送るべき条件
次のような場合は、自前GPU運用を見送ったほうが無難です。
- モデルの利用頻度が低く、稼働率が低いままハイエンドGPUの初期投資だけがかさむ場合
- GPUの保守・冷却・電源管理を担当できる運用体制が社内にない場合
- ドリフト監視やログ基盤の設計にまだ着手できておらず、インフラより先にやるべきことが残っている場合
逆に、クラウドAPIサービス一本化を見送ったほうがよいのは、規制業界でデータを外部に出せない制約がある場合や、推論のレイテンシがミリ秒単位でシビアに求められる場合です。
まとめ
インフラ選定は、モデルサイズに応じたVRAM要件の確認から始めるのが確実な一歩です。
次に、稼働率の見込みを立てて初期投資と従量課金のどちらが有利かを試算し、GPUレベルの詳細指標を監視スタックに組み込めるかどうかを確認してください。
最後に、障害時にデータ・モデル・インフラのどこに原因があるかを切り分けられるログ設計になっているか、デプロイ前に見直しておくと安心です。
選定は一度きりの意思決定ではなく、負荷やコストの変化に応じて定期的に見直す運用項目として扱うのが現実的です。