第15章 — サーバーレスAPI vs 専用インフラ
LLM Primer VI: AIシステムのスケーリング を章ごとに紹介していくウォークスルー、第15回。損益分岐算術をテーブルに載せ、多くのチームにとって答えを傾けるプラットフォームエンジニアリングの行に名前をつける章です。
なぜこの章があるのか
第14章はチームに、API請求書が何でできているかの綺麗な絵と、もっと安くできるという密かな疑いを残しました。次の自然な問いは、そもそもトークン単位で払うべきかどうか。代替は推論を内製化し、前章まで書いてきたスタック上でオープンウェイトモデルを走らせ、代わりにGPU時間単位で払うこと。トレードには明快な損益分岐点があります。あまり明快でなく大半のチームが甘く見るのは、GPU請求書に載らない専用側の全て — プラットフォームエンジニアリング、セキュリティパッチ、モデルアップグレードの振付、ノードが艦隊から落ちる午前3時のページ。第15章は両側を真剣に扱い、セルフホストがいつ正しい答えかを導きます。
15.1 損益分岐の公式は明快で、大半は目くらまし
GPUは スループット × 利用率 × 3,600 出力トークンを毎時間生む。100万トークンあたりのコストは (gpu_hourly / tokens_per_hour) × 1,000,000。APIとの損益分岐はその数字がAPIの100万あたり価格と一致する場所。$3/時のH100上でFP8の70Bモデル、集約毎秒800トークン、利用率60パーセントで、100万出力トークンあたりおおよそ$1に着地。フロンティアAPIは$15を請求します。見かけの節約は14倍 — 財務が愛し、第二の、より大きな行を欠く、セルフホストの議論です。損益分岐は利用率にも依存する。20〜30パーセント未満の利用率では、セルフホストコストの100万あたり価格はAPIレートを超え、GPUは置き換えるはずだった代替より高い。利用率は今度は、トラフィック形状、オートスケーリング品質、チームが同じ艦隊に複数のワークロードをパックできるかの関数です。
15.2 プラットフォームエンジニアリングは取引を決める行
GPU請求書は小さい方の半分です。大きい方の半分は艦隊を走らせ続けるチーム。エンジン、ドライバ、オーケストレーション、オートスケーリング、可観測性、セキュリティ。APIチームはこのコストをトークン単価を通じて暗黙に支払う。セルフホストチームは頭数で支払う。役立つ経験則。単一のサービングGPU艦隊 — 1〜2のモデル変種、オートスケーリング、可観測性、オンコール、四半期アップグレード — はおおよそ1名の常勤プラットフォームエンジニアプラス何割かのSREを必要とする。より多様な艦隊 — 複数エンジン、複数モデル、マルチテナントスケジューリング — は2〜4名を必要とします。エンジニア1名あたり完全負担$300kとして、年間プラットフォーム請求は$300k〜$1.2M。セルフホストが元を取る月次トラフィックの損益分岐はおよそ月2億から10億出力トークンの間。それより下ならエンジニアリングオーバーヘッドがトークン節約を超え、チームはAPIに留まるべき。それより上なら節約が支配。プラットフォームエンジニアリングは滑らかな曲線ではなくステップ関数でも来る。1人目のヒットで艦隊が立ち上がり、2人目は1人目が週末オンコールをカバーできないから発生し、3人目は艦隊がマルチリージョンに広がると発生する。
15.3 現実的な姿勢はハイブリッドで、ルーターが荷重を担う
最も綺麗な決断 — 全部APIか全部専用か — は、本番運用1年以上のチームで正解であることは稀。定常状態の予測可能ワークロード(夜間バッチ、スケジュールドレポート、分類キュー)は計画された専用容量に上手くパックできる。バースト的ワークロード(バイラルスパイク、チケット洪水、新コホートローンチ)はAPI弾力性を必要とする。厳格なレイテンシワークロード(対話型補完、音声)は同置される専用配備の恩恵を受ける。無レイテンシワークロード(夜間エンリッチメント、再インデックス)は半額のバッチAPIの恩恵を受ける。ハイブリッドを支えるアーキテクチャは、アプリケーション境界のルーターで、各リクエストをレイテンシ予算、複雑さ、現在のバックエンド利用率で分類し、SLAを満たす最安バックエンドに配送する。洗練されたルーターはAPI内モデルルーティング(単純なクエリには安いモデル、複雑にはフロンティア、必要なものには推論階層)も行う。副次的な利益はオプション性。ワークロードはアプリケーションコードを変えずにルーターポリシーを変えることで境界を移動できる。そして専用ケースはしばしば、第二のワークロード — さもなくばAPIに行っていたはずのもの — がすでに支払い済みのGPUに便乗するときにのみ元を取ります。専用を単一ワークロードで評価するチームはたいてい移らず、ワークロードポートフォリオで考えるチームは移り、節約する。
第15章が敷いたもの
第15章はエージェントが導入した「API呼び出し」にも「モデルサービング」にも合わないワークロードのクラス — LLM生成コードの実行環境、エージェントが必要とする分離とパッケージ柔軟性次第でサーバーレス関数、マイクロVM(Firecracker、gVisor)、あるいはWASMサンドボックス上に生きる — に名前をつけました。第16章は姿勢線のどちら側にも適用されるコスト削減の打ち手のカタログでこの巻を閉じます。インテリジェントなモデルルーティング、アプリケーションレベルのコンテキスト圧縮、バッチAPI、セマンティックキャッシュ — 前月の請求書の3分の1か半分に効いてくる打ち手です。
次回 — 第16章: 本番環境でのコスト削減戦略。 前月の請求書を来月の節約に変える効いてくる打ち手。
SelfHostProfile と PlatformOverhead データクラス、breakeven_utilization と breakeven_monthly_tokens 関数、動くハイブリッド姿勢の例、そしてエージェント生成コード実行のためのマイクロVMサンドボックススケッチが収録されています。Amazonで『LLM Primer VI』を見る →