ML/LLM推論エンドポイントのSLOをどう引くか — AWSが閾値をくれない時代のSLI設計

本番のML/LLM推論エンドポイントを、Webアプリと同じ「リクエストのp99レイテンシ（99パーセンタイルの応答時間）」だけで見ていないでしょうか。推論サービングでは、最初のトークンが返るまでの時間（Time to First Token、以下TTFT）、毎秒のトークン生成数、GPUの飽和、リクエストのキュー深さ、スケール時のコールドスタートといった、Webアプリにはない信号が体感品質とコストを左右します。2026年6月18日、Amazon SageMaker AIが推論エンドポイント向けの新しい可観測性（observability）機能を発表し、これらの信号を計装なしで追えるようになりました。ただし、ここに設計上の落とし穴があります。AWSは信号を見せてくれますが、「いくつを目標にすべきか」という推奨閾値は出しません。本記事は機能紹介ではなく、閾値をAWSがくれない前提で、推論エンドポイントのSLI/SLO（サービスレベル指標／目標）を自分で引く「型」に重心を置きます。客観・中立に、設計の手引きとして整理します。

SageMaker AIの新しい推論可観測性（2026-06-18・計装不要）

新機能の実体は、OpenTelemetry（可観測性データの標準規格、以下OTel）ネイティブの指標を、計装なし（no instrumentation）で集めるプリビルトのAmazon CloudWatchダッシュボードです。アプリ側にエージェントやコードを仕込む必要がなく、推論性能の指標をリアルタイムで追跡します。AWS公式によれば、Grafanaとの連携（リージョン別のPromQLエンドポイント）にも対応します。利用できるリージョンは東京（ap-northeast-1）を含みます。

つまり「信号を集める」部分の手間は大きく下がりました。問題は、集めた信号のどれをSLIにし、どの水準をSLOにするか、という設計の側に残ります。

推論サービング固有のシグナル5系統

公式が surface する（見せる）信号を、5系統に整理します。それぞれが品質・コストの何を表すのかを対応づけておくと、後段でSLIを選びやすくなります。

• トークン系: TTFT、inter-token latency（トークン間レイテンシ）、tokens per second（毎秒トークン数）。ユーザーの体感初動と、回答が出きるまでの速さを表します。
• GPU系: GPU utilization（使用率）と飽和。計算資源が逼迫していないかを表します。
• インフラ系: queue depth（キュー深さ）、inference component copy counts（推論コンポーネントの配置・コピー数）。さばききれずに待ち行列が伸びていないかを表します。
• スケール系: scaling events（スケーリングイベント）、cold start breakdowns（コールドスタートの内訳）。需要変動に追従できているかを表します。
• 可用性系: アベイラビリティーゾーン（AZ）コンプライアンスの検証。冗長配置が意図どおりかを表します。

これらはWebアプリのp99では捉えられない、推論サービング固有の信号です。

閾値はAWSが出さない — SLI/SLOを自分で引く型

ここが本記事の芯です。前述の信号について、AWSは推奨閾値・目標値・アラーム水準を提供しません。メトリクスを見せるだけで、どの水準を目標にするかは利用者が決めます。したがって、他社事例の数値を丸写しするのではなく、自分のワークロードに合わせてSLI/SLOを引く型を持つことが、設計の価値になります。型は次のように組み立てられます。

まず、5系統からSLI候補を選びます。TTFTは体感の初動を表すので最有力です。tokens per secondはスループットの下限を見る指標になります。queue depthは飽和が表面化する前に動く先行指標として有効です。コールドスタートの発生率は、スケール設計が健全かを測れます。

次に、選んだSLIをSLOへ落とし込みます。型としては、ユーザー体感に効くTTFTはp95やp99で目標を置く、スループットは下限値で目標を置く、飽和やキュー深さは先行アラート（バーンレート、エラーバジェットを消費する速度を見る方式）に回す、という組み立てが扱いやすくなります。ここで示した数値の置き方はあくまで型の例であり、AWSが推奨する値ではない点に注意してください。具体的な目標値は、自分のサービスの体感要件とトラフィックから決めます。

この「目標を置いてエラーバジェットで運用する」という思想そのものは、推論に固有のものではありません。汎用のSLO/エラーバジェット設計はSLOとエラーバジェットで運用するに整理しているので、土台はそちらを参照し、本記事はその思想を推論サービングのSLIに適用する、という関係で読んでください。

GPU飽和とコストの綱引き — SLOを満たす最小キャパ

SLOを引いたら、次はコストとの綱引きが待っています。GPU飽和を下げて余裕を持たせれば体感は安定しますが、それは過剰プロビジョニング（使わない計算資源を抱えること）に近づき、コストが膨らみます。逆に資源を絞りすぎると飽和とキュー深さが上がり、TTFTが悪化してSLOを割ります。

実務的なゴールは、「SLOを満たす最小キャパ」をスケーリング方針で探ることです。スケーリングイベントやコールドスタートの信号を見ながら、SLOを割らない範囲で資源を下げていく、という探索になります。

なお、推論のコスト設計をさらに掘り下げたい場合はBedrockの推論コスト最適化が参考になります。ただし注意点として、そちらはAmazon Bedrock（マネージド）の推論コストを扱っており、本記事で扱うGPU飽和はSageMaker（自前のエンドポイントを持つ構成）の話です。対象サービスは異なりますが、「推論コストは品質と表裏で、SLOを満たす最小コストを探す」という考え方は共通します。同一サービスの設定手順として読まないよう、線引きをしておきます。

採用前に知る落とし穴

設計に入る前に、3つの落とし穴を押さえます。

第一に、公式の推奨値がない点です。前述のとおりAWSは閾値を出しません。他社の数値をそのまま目標にするのではなく、型で自分の値を決める前提で進めます。

第二に、エンドポイント種別の扱いです。推論にはリアルタイム・非同期（async）・バッチといった種別がありますが、今回の発表は「推論エンドポイント／推論ワークロード」と総称で書かれており、どの種別にどこまで適用されるかは公式に明示されていません。種別ごとの適用範囲は断定せず、最新のドキュメントで確認してください。本記事で示すSLI/SLO設計の型自体は、種別に依存せず使えます。

第三に、ダッシュボードの料金です。CloudWatchの標準的な課金の範囲と読める書き方ですが、無料か従量かは公式に明示されていません。費用は断定せず、SageMakerおよびCloudWatchの料金ページで時点確認してください。

自分の推論基盤にどう当てるか（チェックリスト）

ここまでの型を、自分のエンドポイントへの当てはめとして整理します。

確認ポイント	見るもの	SLI/SLOの引き方
体感の初動	TTFT	p95/p99で目標を置く（値は自分の体感要件から）
スループット	tokens per second	下限値で目標を置く
飽和の予兆	queue depth・GPU飽和	先行アラート（バーンレート）に回す
スケール健全性	コールドスタート率・スケーリングイベント	発生率を監視し、SLO割れの前に手当て
コスト	GPU使用率	SLOを満たす最小キャパを探索する

迷ったときは、まずTTFTとキュー深さの2つをSLIに据えると、体感と飽和の両面を最小構成で押さえられます。そこからスループットやコールドスタートを足していくのが、無理のない始め方です。

まとめ — 次に読む

推論エンドポイントのSLOは、Webアプリのp99とは別の信号から引きます。SageMakerの新しい可観測性で信号は計装なしに集まるようになりましたが、AWSは推奨閾値を出しません。だからこそ、TTFT・トークンスループット・GPU飽和・キュー深さ・コールドスタートのどれをSLIにし、どの水準をSLOにするかの型を自分で持つことが要になります。そしてGPU飽和はコストと表裏であり、SLOを満たす最小キャパを探すのが運用のゴールです。

SLO/エラーバジェットの思想そのものはSLOとエラーバジェットで運用するに、推論コストの設計は（サービスは異なりますが考え方の参考として）Bedrockの推論コスト最適化に整理しています。エージェントの本番運用全体は本番運用のための生成AIエージェント運用も参考になります。

出典

• Amazon SageMaker AI Announces New observability capability For Inference Endpoints（What’s New・2026-06-18）
• Amazon SageMaker pricing（ダッシュボード料金は時点確認）
• Amazon CloudWatch pricing（メトリクス・ダッシュボードの課金は時点確認）