サーバーレスAPI
プロバイダーがモデルをホストし、トークン単位で課金します。最も早く始められ、GPUの運用はゼロで、既定で弾力的です。その代わり、提供されるモデル、上限、データの取り扱い条件、価格カーブを受け入れることになります。継続的に量が出る場合、たいていは最も高くつく道です。
AI推論ガイド
キャパシティプランニングとホスティングの選択
何かを出荷する前に決めておくことです：モデルをどうホストするか、どのモデルとGPUがワークロードに合うか、メモリの計算が成り立つか、そしてどのサービングフレームワークで動かすか。
ホスティングの選択肢の幅
セルフホストのクラウド
GPUを借りて、サービングスタック（vLLM、SGLang、TensorRT-LLM）を自分で動かします。モデル、バージョン、プレフィックスキャッシュやディスアグリゲーションといった最適化を完全に制御できる代わりに、実際のDevOps負荷を負います。キャパシティ、アップグレード、インシデント対応は自分たちの仕事です。
Bring Your Own Cloud
ベンダーが自社のサービングプラットフォームをあなたのクラウドアカウント内で運用します。コントロールプレーンはベンダー、データプレーンはあなたのものです。データを自社のVPCに留めて主権とコンプライアンスを満たし、既存のクレジットや利用コミットの割引を活かし、下り転送を減らしながら、運用の大半を外部に任せられます。
オンプレミス
自社のハードウェア、自社のデータセンター。データの制御が最も強く、設備投資も見通しやすいため、安定して量が多いワークロードや規制対象のワークロードに向きます。コストは、先行するGPU投資、調達のリードタイム、ハードウェアの陳腐化、そしてそれを回す運用体制と人材です。
判断は4つの軸で行います。データのプライバシーとコンプライアンス、実際の規模でのコスト、カスタマイズの必要性（ファインチューニング済みの重み、サービング層での最適化）、そしてチームの運用能力です。選択肢の比較は表示価格ではなく、実測したTTFT、スループット、成功タスクあたりのコストで行ってください。評価用のチェックリストは プロバイダー のページにあります。
モデルを選ぶ
- バリアント： ベースモデルはさらに学習させるためのもので、実際にサービングするのは指示チューニング版やチャット版です。小規模言語モデルは、範囲の狭いタスクをわずかなコストでこなします。
- アーキテクチャ： 密なモデルはトークンごとに全パラメータを活性化し、MoE（専門家混合）モデルは一部だけを活性化します。トークンあたりの計算量は下がる一方で、メモリ使用量は大きくなり、サービングは複雑になります。
- テキスト以外： 埋め込みモデル（検索、RAG）、リランカー、視覚言語モデル、音声モデル、画像モデル。多くの製品は、1リクエストの中でこれらをいくつも連結します。
- 重みの形式： GPUでのサービングではsafetensorsが標準です。GGUFはllama.cpp系のローカルおよびCPUランタイム向けで、たいていは量子化済み（たとえばQ4/Q5/Q8のレベル）で配布されます。
- 入手経路： モデルハブ（Hugging Face、ModelScope）が重みを配布しますが、認証付きのダウンロードを求めるライセンスゲートの背後にあることも多くあります。本番に入る前にライセンスを読んでください。
GPUを選ぶ
比較すべき項目
- VRAM：重みとKVキャッシュとオーバーヘッドを合わせた容量の絶対的な上限
- メモリ帯域：メモリ律速のフェーズであるデコードの速度を左右する
- 演算性能（テンソルコアのFLOPS）：プレフィルとバッチのスループットを左右する
- ネイティブの精度サポート：FP8などの新しい形式には比較的新しい世代が必要
- インターコネクト：モデルをシャーディングするなら、ノード内はNVLink級のリンク、ノード間はInfiniBandまたはRoCE
実務上の制約
- コンシューマー向けカードは開発に向き、データセンター向けの製品はVRAM、帯域、マルチGPUリンクを上乗せする
- ソフトウェアのエコシステム：CUDAが最も充実したツール群を持ち、ROCmの対応状況はプロジェクトとバージョンによって差がある
- 制御性、入手性、価格は互いに引っ張り合う。手に入らない最安のSKUは選択肢にならない
- モデルが載らない場合のレバーは、量子化、テンソル並列またはパイプライン並列、KVのオフロードで、いずれにも固有のコストがある
メモリの計算は成り立つか
何かを借りる前に見積もります。GPUメモリは3者で分け合います：
- 1. 重みパラメータ数×1パラメータあたりのバイト数：FP16/BF16でおよそ2バイト、FP8/INT8で1バイト、INT4で0.5バイトです。8Bのモデルは、FP16で約16 GB、INT4で約4.5 GBになります。実行時のオーバーヘッドとして10-20パーセント程度を上乗せしてください。
- 2. KVキャッシュトークンあたりおよそ2×層数×KVヘッド数×ヘッド次元×値あたりのバイト数で、これに同時実行中の全シーケンスで処理中のトークン数を掛けます。あるカード上で同時実行数とコンテキスト長を実際に縛るのはこれであり、長いコンテキストのサービングが、計算の問題である前にメモリの問題である理由でもあります。
- 3. 活性化と作業領域中間バッファ、CUDAグラフ、フレームワークの予約が残りを占めます。余裕は明示的に残してください。使用率99パーセントのアロケータは、最初の長いリクエストで失敗します。
そのうえで、実際のプロンプト長と出力長で負荷試験を行って検証してください。断片化とスケジューラの挙動によって、実用上の限界は計算上の値より下がります。
サービングフレームワークを選ぶ
フレームワークはバッチング、KVキャッシュの管理、ストリーミング、マルチGPU実行を担い、多くはOpenAI互換のAPIを公開するため、アプリケーション側は移植性を保てます。
本番のGPUサービング
vLLMとSGLangが主流のオープンソースエンジンです（連続バッチング、PagedAttention方式のメモリ管理、構造化出力のサポート）。TensorRT-LLMはNVIDIAのハードウェアで最大の性能を引き出しますが、統合の手間は大きくなります。LMDeployは量子化と高い同時実行でのサービングに重点を置いています。
ローカルとエッジ
llama.cpp（およびその上に載るOllama）はGGUFの量子化を使ってCPUと単一マシンでの利用をカバーし、MLC-LLMはスマートフォンやブラウザ向けにモデルをコンパイルします。これらは合計スループットよりも、フットプリントと移植性を優先します。
- まずモデルアーキテクチャの対応状況を確認してください。自分のモデルを動かせないエンジンは、速くても意味がありません。
- ライブラリモード（自分のプロセスに組み込む）とサーバーモード（独立したサービス）のどちらにするかを決めます。本番ではほぼ常にサーバーモードが求められます。
- 候補は自分のワークロードでベンチマークしてください。モデル、ハードウェア、シーケンスの形状が変われば順位は入れ替わります。比較は ライブラリ のページを参照してください。