推論が学習より高くつく時代
- 年のエンタープライズ AI 運用における最大の支出は、もはや学習ではなく推論だ。Anthropic のパブリックな決算コメントでも「Claude の運用コストの 7 割以上が推論インフラ」と明言されており、自社でモデルを運用する企業でも同様の傾向が観測されている。Copilot 系機能を全社員に展開する SaaS では、月間推論費用が 10 万ドルを超えることが珍しくなくなった。
推論コストの内訳は概ね「GPU 時間 × 利用率の逆数」で決まる。つまり、同じ TPS を出すにも GPU 利用率が 30% なら 70% に比べて 2.3 倍のコストがかかる。本稿では自社ホスト／マネージドの選択論から、GPU 共有、オートスケール、SLO ルーティング、そして KGA の顧客で実現した 85,000 ドル／月 → 12,000 ドル／月の削減事例までを扱う。
自社ホスト vs. マネージドの線引き
Amazon Bedrock、Google Vertex AI、Azure AI Foundry のようなマネージドサービスは、QPS が読みにくい初期フェーズでは圧倒的に楽だ。課金はトークン従量で、アイドル時に 0 円に近づく。問題は「トークン量が読めてきた後」で、自社ホストと比較して 2～4 倍の単価になる。損益分岐点は概ね以下に集約される。
- 月間入力トークン 3 億未満: マネージド一択。インフラエンジニアの工数がそのまま赤字になる。
- 月間 3 億～30 億: ハイブリッド。マネージドでピーク、自社ホストでベース。
- 月間 30 億以上: 自社ホスト主体。リザーブ型（Bedrock Provisioned Throughput、Vertex Dedicated Endpoint）も選択肢。
- レイテンシ要件 p99 < 500ms が必須: 自社ホスト＋地域近接デプロイ。マネージドの共有テナンシでは達成困難。
- オフライン／規制業界: 自社ホスト必須。金融・医療・官公庁では選択の余地なし。
KGA の顧客では「まずマネージドで走り、3 ヶ月の実トラフィックを測定してから自社ホストに段階移行する」パターンを推奨している。自社ホストで先に選択を誤ると、モデル切替コストと GPU 調達リードタイムで半年潰す。
GPU 共有戦略: MIG, Time-Slicing, MPS
- つの GPU を複数ワークロードで共有する戦略は、推論では特に効果が大きい。全てのリクエストが同時にフル帯域を使うわけではないので、多重化で利用率が劇的に上がる。
MIG (Multi-Instance GPU): H100／H200／B200 で利用可能。物理的に SM と L2 キャッシュ、メモリコントローラを分割し、ハード分離された「小さな GPU」として切り出す。H100 80GB なら最大 7 分割で、各インスタンスが 10GB HBM と独立した演算ユニットを持つ。分離が強く、ノイジー・ネイバー問題が発生しない。小型モデル（Phi-4、Gemma 3 2B、Llama 3.3 8B 量子化版）の並行ホストに最適。
Time-Slicing: CUDA の時分割スケジューリング。MIG ほど厳密な分離はないが、任意の GPU でサポートされる。1 枚の H200 に Llama 3.3 70B を 3 レプリカ同居させ、バッチングと時分割でスループットを上げる。レプリカ間のノイジー・ネイバーが p99 レイテンシに影響するため、SLO の緩いワークロードに限定するのが定石。
MPS (Multi-Process Service): CUDA MPS デーモン経由で複数プロセスの CUDA コンテキストを単一コンテキストに統合し、オーバーヘッドを削減する。同一モデルの複数インスタンスを走らせる vLLM／TGI のワーカー並列で効果的。
KGA の運用では、SLO が厳しい「対話型」系はレプリカを占有（MIG なし）、「バッチ系」「補助的な要約・抽出」系は MIG で共有、「バックグラウンドの埋め込み生成」は MPS でスループット最大化、という 3 層で分類している。これだけで全体利用率が 40% → 72% まで改善した事例がある。
オートスケールの実装: KEDA とキュー長
LLM 推論のオートスケールで HPA（CPU／メモリ）に頼るのは悪手だ。vLLM のような推論サーバーは GPU メモリを起動直後にほぼ全量確保するため、OS メトリクスではスケール判断ができない。正解はキュー長ベースのスケーリング、具体的には KEDA（Kubernetes Event-Driven Autoscaling）と Prometheus メトリクスの組み合わせだ。
実装パターンは 2 種類ある。
パターン A: キュー長直接スケール: Redis／NATS／SQS をリクエストキューとして前段に置き、キュー長が閾値を超えたらレプリカを増やす。スケール判断が単純で、トラフィック急増に強い。欠点はキュー挿入レイテンシが p50 に加算されること。
パターン B: 推論サーバーの in-flight メトリクス: vLLM の /metrics エンドポイントが公開する vllm:num_requests_waiting、vllm:gpu_cache_usage_perc をそのまま KEDA の Prometheus スケーラで監視する。キューを持たずに推論サーバーが直接バッファするため、レイテンシは最適。ただし burst 耐性は低く、スケールアウト完了前にサーバーが詰まる。
現場では両者のハイブリッドが最適で、フロントに SQS を置き「キュー長 > 50 で +1 レプリカ」「in-flight > 80% GPU cache で +1 レプリカ」の両トリガーを OR で動かす。スケールインは cooldown 10 分と慎重に。GPU ノードのコールドスタートは 3～7 分かかるため、不用意なスケールインは後続の burst で高コストになる。
マルチテナント分離と SLO ルーティング
複数プロダクト／複数顧客で 1 つの推論基盤を共有する場合、「うるさい隣人」問題をどう防ぐかが設計の中心だ。KGA では次の 3 層でテナント分離を実装している。
- 物理分離層: 規制業界顧客は専用 node pool。ラベルと taint で他テナントの Pod が載らない。
- 論理分離層: Kubernetes namespace + ResourceQuota + PriorityClass。テナントごとに GPU 時間の上限をクォータで宣言し、超過時はキューで待たせる。
- リクエスト層: API Gateway（Kong、Envoy、自作）でテナント ID を抽出し、OpenAI 互換エンドポイントにテナント別のレート制限とトークン上限を適用。
さらに賢いデプロイでは SLO ルーティング を入れる。「対話型で p99 < 2 秒」「バッチで何時間でも OK」のように同じ機能でも要件が違うリクエストを、モデル階層間で動的に振り分ける。例えば:
- 通常フロー: Claude Haiku 4.7 → 80% 解決
- 難易度高 or ユーザーが「詳しく」を押した場合: Claude Sonnet 4.7
- エンタープライズ契約の一定金額以上の顧客のみ: Claude Opus 4.7
ルーティング判断を行うのは軽量な分類器（distilbert-cls、独自 LoRA）で、これ自体は CPU で走らせる。全リクエストを Opus に通した場合と比較して、コストを 70% 削減しつつ p95 精度指標を 3% 以内の差にとどめた実装例がある。
バッチング経済学
LLM 推論のスループットは「バッチサイズが大きいほど GPU 利用率が上がる」特性を持つ。vLLM、TGI、TensorRT-LLM のようなモダンな推論サーバーは continuous batching（in-flight batching）を実装しており、リクエストが到着するたびにバッチに混ぜ込んで処理する。
しかしバッチを大きくするほど p50／p99 のレイテンシは悪化する。最適点は用途ごとに異なり、計測が必要だ。KGA の一般的な設定は以下。
- 対話型 (p99 < 2s): max_num_seqs=32, max_num_batched_tokens=8192
- 半対話（p99 < 10s）: max_num_seqs=64, max_num_batched_tokens=16384
- バッチ（SLO なし）: max_num_seqs=256, max_num_batched_tokens=65536
投機的デコード（speculative decoding）を有効化すると、小モデル（ドラフター）で複数トークンを先に生成し、大モデルで検証するため、レイテンシを 1.8～2.5 倍高速化できる。Llama 3.3 70B + Llama 3.2 1B ドラフター、Claude Haiku + Claude Nano の組み合わせが代表例。
事例: 月 85,000 ドルから 12,000 ドルへ
KGA が支援したある SaaS 顧客は、2025 年下期時点で OpenAI API に月間 85,000 ドルを支払っていた。主用途は「顧客データからの要約／質問応答」で、大半が類似したテンプレートでのリクエストだった。移行プロセスは次のとおり。
ステップ 1: 計測と分類（2 週間） Langfuse を入れて 2 週間のトラフィックを計測した結果、リクエストの 62% が 5 つのテンプレートに収斂することが判明。さらにプロンプトの 78% が同一の system prompt（3500 トークン）を持っていた。
ステップ 2: セマンティックキャッシュ導入（4 週間） 高頻度質問に対して Redis Vector Search ベースのセマンティックキャッシュを導入。完全一致ではなく埋め込み類似度 0.97 以上で cache hit とする設計で、hit 率 34%、月間コスト 85k → 56k ドル。
ステップ 3: モデル階層化（4 週間） リクエストを難易度分類し、70% を自社ホストの Llama 3.3 70B FP8 量子化版に、30% を Claude Sonnet 4.7（API）に振り分け。自社ホスト側は H200 × 8 を 3 年リザーブドで 月 18k ドル。合計 56k → 27k ドル。
ステップ 4: 投機的デコード + プロンプトキャッシュ（3 週間） vLLM で投機的デコード（ドラフター Llama 3.2 1B）を有効化、Claude 側は Anthropic の prompt caching を有効化してシステムプロンプト部分を 90% 割引。合計 27k → 12k ドル／月。
総投資は 13 週間 × エンジニア 1.5 名 = 約 35,000 ドルの人件費。投資回収期間は約 2 ヶ月で、翌年以降は年間約 88 万ドルの削減効果が続いている。
失敗しないための 5 原則
- 計測なき最適化はしない: Langfuse/Helicone を最初の 2 週間で入れる。推測で削ると必ず品質を落とす。
- マネージドを「卒業」する前にトラフィックパターンを固める: 移行後に要件が変わると自社ホストが塩漬け化する。
- 量子化は FP8 までが安全、INT4 は要評価: 品質劣化は用途依存。必ず A/B テストで比較。
- オートスケールは 10 分コールドスタートを前提に: バースト時の「あえて詰まらせる」SLO 合意を取る。
- コスト削減とレイテンシ改善は同時最適化可能: 投機的デコードとキャッシュは両立する。