構想自体は魅力的です。アクセラレーターを借りるか所有し、オープンウェイトモデルを自社で提供すれば、変動するAPI料金を置き換えられます。しかし、モデル同士の品質が自動的に同等になるわけではなく、GPUを常に使い切れるとも限りません。さらに、サービングスタックのセキュリティと信頼性は自社の責任になります。
この記事はコストモデルの作り方を説明するものであり、ベンチマーク結果ではありません。サーバーを選ぶ前に、最新のvLLMドキュメント、vLLMのセキュリティガイダンス、SGLangドキュメント、Hugging Face TGIドキュメントを確認してください。対象ハードウェア上で、サポート対象のバージョンをベンチマークしてください。
実際の判断はもっと複雑です。一定の規模では自社運用が本当に有利になりますが、そうでなければ運用コストが推論コストの削減額を大きく上回ります。損益分岐点は、ワークロード、モデルサイズ、レイテンシー要件、チームの能力によって変わります。
この記事では、コスト計算、運用上の現実、そして自社運用に向くチームとそうでないチームを分ける条件を詳しく見ていきます。自社運用を本格的に検討し、具体的な数値で判断したい読者を想定しています。
自社運用が適切な場合
自社運用が有利になりやすい条件は次のとおりです。
規模と利用率。 継続的で予測可能な需要があれば、確保したキャパシティの費用を利用量全体に配分できます。実測した時間ごとの負荷分布を使ってください。月間API料金だけでは、損益分岐点を判断できません。
予測可能なワークロード。 利用量が安定し、予測できることです。自社運用にはキャパシティ計画が必要です。負荷が急増すると、平常時にはキャパシティが余り、ピーク時には飽和して処理できなくなる可能性があります。
プライバシー／コンプライアンス要件。 クラウドプロバイダーに送信できないデータがある場合です。規制対象業界、特定の政府契約、社内限定データなどが該当します。
カスタムモデル。 マネージドサービスでは提供されていない、ファインチューニング済みモデル、カスタムアーキテクチャ、特殊な派生モデルが必要な場合です。
レイテンシー制御。 ユーザーに近い場所でのホスティングやバッチ処理の制御は、レイテンシー改善に役立ちますが、ネットワーク、キューイング、モデルサイズ、プロンプト長、負荷が依然として支配的な要因となります。対象となるパーセンタイルでベンチマークを実施してください。
呼び出し単価が損益分岐点を下回る。 実際に計算すると、自社運用のほうが有利になる場合です。
これらの条件の大部分が満たされている場合、自社運用は真剣に検討する価値があります。
自社運用が適さない場合
一方、次の条件ではマネージドAPIが有利になりやすくなります。
小規模、または変動の大きい利用量。 遊休キャパシティとピーク対応の設備費によって、見かけ上のトークン単価削減が相殺される可能性があります。マネージド推論のほうが適する場合もありますが、両方のコストモデルを計算してください。
スパイクの多いワークロード。 ピーク時と閑散期の差が大きいと、確保済みのキャパシティが遊休するか、高コストなピーク対応のプロビジョニングが必要になります。
クローズドモデル固有の機能が必要。 現在提供されているモデル、モダリティ、安全対策、ホスト型ツールの一部は、プロバイダーのサービス経由でしか利用できません。ワークロード評価でそれらが必要と判明した場合は、未評価のオープンモデルに置き換えず、プロバイダーを利用する構成とその契約上の制約を比較対象に含めてください。
小規模チーム。 推論基盤の自社運用には専門知識が必要です。運用を担う人員や時間を確保できなければ、問題が起きたときに対処できません。
迅速な反復。 多数のモデル、構成、プロバイダーを試す必要がある場合です。APIなら切り替えやすい一方、自社運用では変更のたびにデプロイ作業が発生します。
マルチリージョン／グローバルユーザー。 自社運用では、リージョンごとのキャパシティ、ルーティング、データ転送、復旧対応が必要になる場合があります。マネージドAPIはインフラストラクチャに対する責任の一部を減らせますが、リージョンごとの提供状況、データ所在地、フェイルオーバー、ネットワークレイテンシーは依然として確認が必要です。
これらのケースでは、直接の利用コストが高くても、マネージドAPIのほうがリスクや自社の責任範囲を抑えられる場合があります。
コスト計算（慎重に）
現時点で品質が同等な三つのシナリオを作ります。クローズドモデルAPI、マネージド型のオープンウェイト推論、自社運用です。同じタスク評価に合格していないモデル同士を比較してはいけません。
各シナリオについて、次の合計を計算します。
monthly total = metered inference or dedicated capacity + storage + network + observability + support + security/compliance + engineering + expected incident loss
従量課金APIでは、キャッシュされていない入力、キャッシュの書き込みと読み取り、出力トークンと推論トークン、ツール、バッチ、再試行が推論料金の内訳になります。自社運用またはマネージド型の専用キャパシティでは、アクセラレーターの費用プールに、稼働分、遊休分、余裕分、ロールアウト用、障害時またはフォールバック用のキャパシティを含めます。契約に別枠かつ重複しない課金項目がない限り、「推論」料金を二重に加算してはいけません。必要なレイテンシーと可用性を満たす条件で測定したアクセラレーター時間当たりのリクエスト数を使い、キャパシティ費用をワークロード単位に配賦します。ベンダーが示す最大スループットをそのまま使ってはいけません。
処理量、ピーク時と平均時の比率、モデル品質、アクセラレーター価格、利用率、担当者の作業時間、移行コストについて感度分析を行います。損益分岐点は、妥当な仮定の範囲内で、品質が同等なシナリオの正味費用が交差する地点です。
運用コスト
推論そのものの費用に加え、自社運用には次の運用費用がかかります。
初期セットアップ：
- 適切な推論サーバー（vLLM、TGI、SGLang）の選択。
- モデルとハードウェアに合わせた設定。
- GPUインフラストラクチャ（クラウドまたは自社所有）のセットアップ。
- ネットワーク、セキュリティ、可観測性。
- 量子化と最適化。
範囲を定めた作業分解、ハードウェア／プロバイダーのリードタイム、セキュリティレビュー、ベンチマーク項目、可用性設計、チームの実績として確認できる作業速度を基に、初期導入の納期を見積もります。本記事は、他の組織にも当てはまるエンジニア週数を示すものではありません。
継続的な運用：
- モニタリング（レイテンシー、スループット、エラー、GPU利用率）。
- キャパシティプランニング。
- アップグレード（新しいモデルバージョン、推論サーバーの更新、セキュリティパッチ）。
- インシデント対応（GPU障害、OOMクラッシュ、ソフトウェアバグ）。
- スケーリング（負荷の増加に伴うGPU数の拡張）。
プラットフォーム、ML、セキュリティ、オンコールの各業務を実際に誰が担うのか記録します。一部稼働相当のFTEという仮定を、そのまま別の組織に当てはめることはできません。
見えないコスト：
- GPU価格の変動。
- ハイブリッド構成におけるクラウドからのデータ転送費用。
- 専門的な知識（CUDA、量子化、最適化）。
- 所有するハードウェアの交換費用と故障時の費用。
福利厚生費や間接費を含む組織の人件費単価と機会費用を使ってください。運用上の責任と費用まで含めなければ、トークン単価の差額は純粋な節約額にはなりません。
推論サーバー
自社運用する場合の主な選択肢は次のとおりです。
vLLM。 継続的バッチ処理に対応し、バージョンごとに幅広いモデルをサポートするオープンソースのサービングエンジンです。セキュリティガイダンスは必ず確認してください。
TGI（Text Generation Inference）。 Hugging Faceのサービングプロジェクトです。この記事の情報だけに頼らず、現在の保守状況とモデル対応を確認してください。
SGLang。 活発に開発されているサービング兼プログラミングスタックです。必要なモデル、構造化出力の処理経路、運用ツールをベンチマークしてください。
LMDeploy。 対応するモデル、量子化方式、ハードウェアがバージョンによって変わる、もう一つのサービング候補です。同じ受け入れテストでベンチマークしてください。
llama.cpp / Ollama。 ローカル環境や一部のサーバーワークロードでの候補です。対応ハードウェア、同時実行性能、セキュリティ境界、運用管理機能、本番環境への適合性をテストする必要があります。プロジェクト名だけを見て、スループットが低いとも本番運用に適しているとも判断できません。
マネージド専用エンドポイント。 Hugging Faceなどのプロバイダーは、マネージド型のエンドポイント製品を提供しています。採用するエンジン、課金方式、分離方式、運用分担は時間とともに変わります。TGIが使われている、あるいは特定の課金方式が採用されていると決めつけず、現在のサービス内容を確認してください。
マネージドGPUまたは推論プラットフォーム。 キャパシティ管理とサービングの作業を一部減らせますが、統合、セキュリティ、評価、プロバイダーへの依存は残ります。現在の見積もりと責任分界を比較し、自社運用との価格差が一定だと仮定しないでください。
使用するモデル、アクセラレーター、量子化方式、API仕様、セキュリティ制御を正確にサポートするプロジェクトだけを候補に残します。最終的な選択は、再現可能な負荷テストに基づいて行います。
ハードウェアの選択
GPUについては、次の点を検討します。
アクセラレーターの世代、メモリ容量、レンタル料金は急速に変わります。必要なリージョンと契約期間に応じた最新の見積もりを取得してください。
メモリ容量と帯域幅、対応する数値形式、インターコネクト、ソフトウェア互換性、クォータ、リージョンごとの提供状況、障害時の挙動、価格を比較します。スポットまたはプリエンプティブルなキャパシティをコストモデルに含めてよいのは、中断への対処方法と実測済みの復旧経路がある場合に限られます。
量子化
量子化は、キャパシティと性能を調整する選択肢の一つです。そのトレードオフは、モデル、形式、カーネル、ハードウェア、タスクによって異なります。
FP16/BF16クラスの参照精度。 対応するモデルやハードウェアの比較基準としてよく使われますが、必ずしもモデル本来の形式や、品質を完全に保持する形式という意味ではありません。
INT8 / FP8（8ビット）。 重みのメモリ使用量を減らしたり、対応する実行経路の性能を改善したりできる場合があります。品質と速度への影響は構成ごとに異なります。
INT4（4ビット）。 重みのメモリ使用量をさらに減らせます。実際に使うモデル成果物を用いて、品質とカーネル性能を測定してください。
AWQ、GPTQ、GGUF。 異なるトレードオフを持つさまざまな量子化フォーマットです。
パラメーター数だけで求めた値は、必要メモリの下限にすぎません。実行時のメモリには、KVキャッシュ、活性化値、ワークスペース、断片化、レプリカも含まれます。サービングエンジンのプロファイラーと負荷テストを使ってください。出力品質は一般的なベンチマークだけでなく、実際の本番タスクでも評価します。
スループットとキャパシティプランニング
キャパシティ計画で重要なのは、毎秒何トークンを処理する必要があるかという問いです。
プロンプト／出力の長さと同時実行数を変えながら、最初のトークンまでの時間、トークン間レイテンシー、エンドツーエンドのレイテンシー、スループット、キュー待機時間、エラー率、メモリの余裕を測定します。
キャパシティ計画では、次の値を求めます。
- ピーク時の同時リクエスト数を推定する。
- 平均リクエスト長を推定する。
- 必要な合計トークン数／秒を計算する。
- バースト、障害、ロールアウトの各要件から必要な余裕分を求めて追加する。
信頼性とフォールバック
自社運用を選ぶと、信頼性にも自社で責任を負うことになります。
ヘルスチェック。 正常性を継続的に監視し、異常なインスタンスを再起動します。
過負荷時の動作。 上限付きキュー、アドミッションコントロール、バックプレッシャー、テスト済みの縮退動作または拒否ポリシーを使います。リクエストを無期限に待機させると、過負荷が悪化し、レイテンシー目標を満たせなくなる可能性があります。
APIへのフォールバック。 マネージドサービスへのフォールバックで障害やピークの一部を吸収できるのは、モデル品質、データポリシー、契約、レート制限、状態、フェイルオーバー動作に互換性があり、テストも済んでいる場合に限られます。構成が複雑になり、両方が同時に失敗する可能性もあります。
障害対応用キャパシティ。 可用性目標とテスト済みの障害モードに基づき、予備キャパシティまたは代替経路の規模を決めます。どのアクセラレーターも故障する可能性はありますが、専用の待機ハードウェアだけが選択肢ではありません。
マルチリージョン。 世界各地のユーザーに対応するなら、複数リージョンに複製します。離れたリージョンではマネージドAPIを使う方法もあります。
更新戦略。 新しいモデルバージョンやサーバーのアップグレードに備えます。ダウンタイムを避けるには、ブルーグリーンデプロイメントを使います。
これらはすべて、マネージドAPIではプロバイダー側が吸収するエンジニアリング作業です。
二つの意思決定記録を作成する
匿名化した架空の結果を作らず、現在の見積もりとベンチマーク成果物を基に、監査可能な意思決定記録を作ってください。
自社運用の候補記録：
- モデル成果物、リビジョン、ライセンス、量子化、サービングバージョン、アクセラレーター、リージョン、デプロイ構成、
- ワークロード分布と、現在のマネージド型ベースラインに対する品質評価、
- 負荷テストのコマンド、データセット、レイテンシーとスループットの結果、飽和点、復旧時の動作、
- 設備投資額または賃借料、利用率、エンジニアリング工数、セキュリティ対応、予想インシデント費用、
- 感度分析と撤退基準を含む損益分岐点の範囲。
マネージド型の候補記録：
- プロバイダー、モデル／リビジョンの挙動、リージョン、価格表の日付、クォータ、契約条件、
- 同等の品質、レイテンシー、レート制限、障害、データ境界に関する証拠、
- 移行工数と特定ベンダーへの集中リスク、
- 自社運用を再評価する条件。
意思決定を見直すタイミング
この決定は恒久的なものではありません。定期的に見直してください。
利用量の変化。 大幅に増えれば自社運用の魅力が高まり、大幅に減れば低下します。
価格の変化。 クローズドAPIの値下げまたは値上げ、マネージド型オープンウェイト推論の値下げ、ハードウェアの値下げです。
モデルの改善。 ワークロードの目標を満たす新しいオープンウェイトモデルやソース利用可能モデル、または品質比較を変える新しいクローズドモデルが登場した場合です。ライセンスと実際の提供状況を確認してください。
運用能力。 チームのML／運用能力が増えた、または減った場合です。
プライバシーやコンプライアンス要件の変化。 自社運用を義務付ける新たな要件が加わった場合です。
契約、価格、モデル、ワークロード、セキュリティ、キャパシティの変動度に応じて見直しの頻度を設定し、イベント発生時にも見直せる条件を追加します。四半期ごとの見直しは一例であり、普遍的な標準ではありません。
よくある間違い
自社運用の意思決定でよく見られる誤りは次のとおりです。
誤り1：運用費用を含めないコスト計算。 トークン料金やアクセラレーター費用の削減額だけを示し、エンジニアリング、オンコール、セキュリティ、インシデント対応の費用を除外しています。
誤り2：早すぎる自社運用。 ワークロードが小さい段階で、自社運用にエンジニアリング工数を費やします。時期尚早な最適化です。
誤り3：品質が同等でないモデルの比較。 ワークロードの品質、安全性、レイテンシー要件を満たす証拠がないまま、安価なモデルを選びます。
誤り4：障害対応計画がない。 自社運用環境が停止しても、テスト済みの縮退動作、キュー、拒否、フォールバックの経路がありません。マネージドAPIも障害を起こし得るため、両方のアーキテクチャを同じ可用性目標で比較してください。
誤り5：最初のサービング構成が効率的だと仮定する。 対応する量子化、バッチ処理、同時実行数、プロンプト長、サーバー設定を再現可能な方法で網羅的に試していないため、キャパシティモデルが未検証の構成に基づいています。
誤り6：品質の変化を無視する。 自社運用モデルが現在のクローズドモデルより見劣りするようになっても、顧客だけが気づき、チームは把握していません。
誤り7：再評価しない。 自社運用を始めた後、判断を見直しません。二年前には正しかった選択が、今は不適切になっている可能性があります。
誤り8：中断を適切に処理できないスポット／プリエンプティブルインスタンス。 割引キャパシティを、中断頻度、復旧時間、重複作業、フォールバック費用を考慮せずにモデル化しています。
判断基準チェックリスト
十分な根拠を持って判断するために、次を確認します。
- 品質が同等のマネージド型候補と自社運用候補をベンチマークしましたか？
- ワークロードは安定しており、予測可能ですか？
- チームにMLOpsや推論の専門知識があるか、必要な人材を採用できますか？
- 適切なライセンスを持つオープンウェイトモデルまたはソース利用可能モデルがあり、ワークロードの品質と安全性の目標を満たしていますか？
- レイテンシー要件を自社運用で満たせますか？
- 詳細なコスト計算（運用コストを含む）を行いましたか？
- フォールバックプランはありますか？
- コンプライアンスやプライバシーの要件によって、特定の方式が必須になっていませんか？
- モデル、価格、契約、ワークロード、セキュリティ、キャパシティに重大な変更があったときの見直し条件と、定期レビューの頻度を文書化していますか？
チェックした項目の数だけで判断してはいけません。すべての財務条件が好都合に見えても、セキュリティ、モデル品質、運用責任のいずれかが採用を見送る決定要因になり得ます。
ハイブリッドパターン
すべてを二者択一にする必要はありません。次のようなハイブリッド構成も候補になります。
大部分は自社運用し、難しいケースにはAPIを使う。 分類や単純な生成は自社運用で行い、複雑な推論にはクローズドモデルのAPIを使います。
平常時は自社運用し、ピーク時はAPIを使う。 ベースロードは自社運用で処理し、負荷のピークをAPIで吸収します。
機密情報は自社運用し、一般用途にはAPIを使う。 機密データは自社運用環境で処理し、一般的なクエリはAPI経由で処理します。
ファインチューニング済みモデルは自社運用し、ベースモデルにはAPIを使う。 カスタムモデルは自社で動かし、既製モデルはAPIから利用します。
ハイブリッド方式では、ルーティング、データポリシー、評価、可観測性、契約、障害対応が複雑になります。処理経路を分けることで、明示した目標が改善するとテストで確認できた場合にだけ採用してください。
現在の証拠に基づいて判断する
サポート対象のモデルがワークロードの品質目標を満たし、組織がサービングのライフサイクル全体に責任を持てるなら、自社運用は有力なアーキテクチャです。
損益分岐点を一律の月間支出額で示すことはできません。モデル品質、需要の形状、利用率、アクセラレーターとプロバイダーの価格、可用性、データ境界の要件、人件費によって変わります。
自社運用を支持する証拠には、次の内容が必要です。
- 運用費用を含め、コストを慎重に計算している。
- MLOps能力があるか、構築できる。
- 投資を正当化できる十分な規模がある。
- ワークロードが安定している。
- 最先端モデルでしか得られない機能は必要ない。
- 信頼性、監視、更新の計画がある。
マネージドサービスを支持する証拠として、次の条件が考えられます。
- 規模が小さい。
- スパイクの多いワークロード。
- 迅速な反復が必要である。
- 運用リソースのない小規模チーム。
- 最先端のクローズドモデル固有の機能が必要である。
適切な答えはワークロードごとに異なります。品質、負荷、障害、セキュリティ、コストを比較し、運用能力を評価してください。必須要件を満たす選択肢のうち、自社が負う運用責任を最も小さくできる方式を選びます。マネージド型、自社運用、ハイブリッドのいずれになる場合もあります。
自社運用を選んだ場合は、実測した効果、前提、責任者、撤退基準、次回見直しの条件を記録します。マネージド推論を選んだ場合も、同じ情報を残してください。現在の証拠がなければ、どちらが正しいとも判断できません。
