AIモデルをAWSで自前運用すべきか、コストで判断する基準

AIの利用料が四半期で急増し、社内から「OpenAIやAnthropicのAPIをやめて、オープンモデルを自前運用したらどれくらい安くなるのか」と聞かれる場面が増えています。オープンモデルとは、モデルの重み（学習済みのパラメータファイル）が公開されていて、自社のサーバーやクラウド上で動かせるモデルのことです。API利用料を払う代わりに、自分でGPUを用意して動かす必要があります。

この記事は、AWS上でオープンモデルを自前運用（セルフホスト）するかどうかを判断したいエンジニアやテックリードに向けたものです。実際にどんな構成が必要で、どれくらいのコストがかかるのか、判断の材料を整理しました。

候補となるオープンモデルには、MetaのLlama 4、DeepSeek V4、ZhipuのGLM-5.2、MoonshotのKimi K3、AlibabaのQwen 3.5、GoogleのGemma 4などがあります。OpenRouter（複数のLLMをまとめて呼び出せるAPIゲートウェイサービス）の利用実績では、中国発のオープンモデルが企業向けトラフィックの30%以上を占めるようになりました。2025年初頭の4.5%から1年足らずで急増した数字です。ベンチマーク上でも、これらのモデルはフロンティアモデル（GPT-5やClaudeのような最先端の商用モデル）と競える水準に達しています。

判断が必要になる場面

API課金型のLLMを使い続けると、利用量に比例してコストが増えます。チームの利用が増えるほど「固定費のGPUサーバーに切り替えた方が安いのでは」という疑問が出てくるタイミングが来ます。ここで必要になるのが、単純な料金比較ではなく、運用体制まで含めた総合的な判断です。

判断軸を整理する

判断すべき軸は大きく4つあります。

利用規模が最初の軸です。個人利用なら小型モデルをCPUで動かすことも可能ですが、10人規模のチームが同時にアクセスすると、CPU推論では応答待ちが30〜60秒に伸びて実用に耐えません。GPUメモリに全パラメータを載せて並列処理する必要があります。GPUの計算コアが数千個の「レーン」を持つ高速道路のようなもので、CPUは1車線の道路に近いイメージです。トークン生成（応答を1語ずつ作る処理）は速度の問題ではなく、渡り切れる車線数の問題だと考えると分かりやすいです。

稼働時間帯が2つ目の軸です。営業時間内（例えば平日10時間）だけ動かすのか、24時間365日常時起動しておくのかで、月額コストは3倍近く変わります。EventBridgeやLambdaでインスタンスの起動・停止をスケジューリングすれば、営業時間外は課金を止められます。

モデルサイズと量子化レベルが3つ目の軸です。量子化とは、モデルの精度を落として容量を圧縮する技術です。4bit量子化版は元のモデルより概ね4分の1のサイズになり、精度低下はわずかに抑えられます。GPUメモリの制約が厳しいなら、量子化版を選ぶのが実務的な選択です。

運用体制の有無が4つ目の軸です。Linuxサーバーの運用に慣れた担当者がいるか、GPUインスタンスのモニタリングや障害対応を継続できる体制があるかどうかで、自前運用の現実的な難易度が変わります。

構成要素と選択肢の比較

自前運用のスタックは3層に分かれます。推論エンジンにはvLLMが業界標準です。モデルを読み込み、複数リクエストを同時処理し、GPU利用率を最適化してOpenAI互換のAPIを提供します。OpenAI互換とは、既存のOpenAI用のコードやツールをエンドポイントのURLだけ変更してそのまま使えることを意味します。フロントエンドにはOpen WebUIがあり、ChatGPTに近いブラウザ画面をユーザーごとのアカウント・会話履歴付きで提供します。手前にnginxやCaddyを置いて認証やTLS終端、レート制限を行う構成が一般的です。

AWSのGPUインスタンスにも複数の選択肢があります。以下は10人規模のチーム利用を想定した比較です（2026年8月時点のオンデマンド料金ベース）。

Llama 4 Maverickは400Bパラメータのモデルですが、MoE（Mixture of Experts、リクエストごとに一部の専門家ネットワークだけを使う構造）のため、実際に動くのは約17Bパラメータ分だけです。この仕組みのおかげで、400Bクラスのモデルでも4GPU構成のノード1台で動かせます。

ケース別の推奨

社内の技術検証やRAG（検索拡張生成）のプロトタイプ段階で、利用者が数名以内なら、Qwen 3.5-27Bをg5.2xlargeで営業時間帯だけ動かす構成が現実的です。月額440ドル程度で試せます。

チームで日常的に使う開発支援ツールとして展開するなら、Llama 4 Maverickをg5.12xlargeで動かす構成が妥当です。営業時間だけの運用でも月1,250ドル前後で、API課金型サービスの利用量が多いチームなら比較検討する価値があります。

24時間稼働が前提で、1年以上の利用が確定しているなら、リザーブドインスタンス（1年または3年の利用契約で単価を下げる購入方式）の検討に進むべきです。オンデマンドの24時間稼働(約4,100ドル)よりRI(約2,900ドル)の方が安くなります。

フロンティアモデル級の性能が必須で、かつ機密情報を外部APIに渡せない事情がある場合のみ、Kimi K3クラスの自前運用が候補になります。ただし月額数万ドル規模のコストと、B300のような最新GPUクラスの調達難易度を織り込む必要があります。

あえて見送るべき条件

チームの利用量がAPI課金型サービスの範囲で十分収まっているなら、自前運用への移行は見送るべきです。GPUインスタンスは使っていない時間も課金対象になり、利用量が少ないうちは固定費が割高になります。

LinuxサーバーやGPUインフラの運用担当者を確保できないなら、稼働率やセキュリティパッチの管理が滞るリスクがあります。運用が止まった時に、API課金型サービスのような可用性の保証は自分たちで作る必要があります。

短期的な検証やPoC（概念実証）の段階で、まだ利用パターンが固まっていないなら、まずはAPI課金型サービスで利用量の傾向を掴んでから、自前運用の投資判断をする方が無駄が少なくなります。

導入前に確認すること

自前運用を検討する際は、まず社内のLLM利用ログを見て、月間のトークン数とAPI課金額を数字で確認するところから始めてください。

次に、営業時間帯だけの利用で足りるか、24時間稼働が必須かを整理し、上記の比較表に当てはめてみると、月額コストの規模感が見えてきます。

最後に、Linux運用やGPUインフラの保守を担える人員がいるかどうかが、コスト以上に重要な判断材料になります。数字だけでなく運用体制も含めて検討することが、後悔しない選択につながります。