Baseten、LLM推論の観測可能性確保手法を解説

推論処理が遅延すると、その下流のすべての機能が影響を受けます。エージェントがタスク途中で停止したり、AI チャットの応答に遅れが生じたり、リクエストがタイムアウトし始めたりします。

観測性（observability）を活用すれば、ユーザーが問題に気づく前に検知でき、本番環境でのモデルの稼働状況を可視化できます。

モデルが稼働中であれば、メトリクス、ログ、トレースを使用して、異常が発生したタイミングを検出し、修正し、何が起きたのかを特定し、再発防止策を検討できます。この記事では、これらのツールと、遅い応答やエラー、ビルドやデプロイの失敗といった課題を検知・デバッグするためにどのように連携するかについて解説します。

主要メトリクス：TTFT、TPOT、TPS、レイテンシ、キャッシュヒット率

メトリクスの追跡は、ユーザーから報告が来る前に異常を把握するのに役立ちます。LLM 推論の観測性において特に重要なメトリクスは以下の通りです：

LLM 推論における主要なプラットフォームがどのように観測性を確保しているかについて、以下の指標が重要です。

• TTFT (Time to First Token): ユーザーがリクエストを送信してから最初のトークンが表示されるまでの時間を計測します。この値が高いと、アプリがフリーズしたり反応しないように感じられます。
• TPOT (Time Per Output Token): 生成された各トークンの平均所要時間を計測します。この値が高いと、テキストが途切れながら trickle（滴り落ちる）ように出力され、スムーズな流れになりません。
• Throughput (tokens/sec): システム全体で1秒間に生成されるトークン数を計測します。これは個々の応答速度ではなく、システム全体のキャパシティを示す指標です。この値が低いと、より多くのユーザーに対応するためにスケールできません。
• End-to-end latency: 単一のリクエストに対してレスポンスを取得するまでの所要時間です。これは最も重要な SLA（サービスレベルアグリーメント）メトリクスであり、アプリが速度要件を満たしているかを判断する基準となります。

• KV cache hit rate: キャッシュに既に KV ペアとして保存されている入力トークンの割合を指します。これは、新しいリクエストの先頭部分が、モデルが直近で処理したリクエストと同じテキスト（プレフィックス）から始まる場合に発生します。モデルはこれらのトークンに対する KV ペアをすでに計算してキャッシュに格納しているため、再計算せずにキャッシュから取得できます。ヒット率が高いほど、計算の重複が減るため、より高速かつ低コストでレスポンスが得られます。逆にヒット率が低いと、多くのトークンを新たに計算する必要があり、処理が遅くコストも高くなります。

KV（キーバリュー）キャッシュとは？

"Key"はモデルがどの単語に注目すべきかを判断する役割を果たし、"Value"は文脈に基づいて単語の意味に付加される情報を決定します。これらをまとめて「KV キャッシュ」として保存します。

KV キャッシュの管理は、TTFT（First Token Time）の短縮に寄与します。リクエストを必要なコンテキストがキャッシュされたレプリカへ自動的にルーティングすることで、冗長な事前計算（prefill compute）を不要にします。これはシステムメッセージや few-shot 例文など、共有されるプロンプトがある場合に特に有効です。

ログ

メトリクスで問題を検知したら、次に確認すべきはログです。モデルのライフサイクルには「ビルド」「デプロイ」「サービス提供」の3段階があり、それぞれに対応するログが用意されています。

✕

モデルのライフサイクル：ビルド、デプロイ、サービス提供

ビルドログ

ビルドログは、コンテナイメージを構築するプロセスを追跡します。このコンテナには、モデルを実行するために必要なすべての要素が含まれています。具体的には、モデルの重み（weights）、依存ライブラリ（コードが実行するために必要な外部ライブラリ）、そしてリクエストを処理してモデルに渡すためのコードそのものです。コンテナはデプロイされてリクエストを受け付ける前に正しく構築されている必要があるため、ビルドログはデプロイ前の問題発見に役立ちます。

ビルドログで検出される最も一般的な失敗例：

コンテナイメージのビルド時に、以下のエラーが発生することがあります。

• パッケージの欠落: コード内で参照されているライブラリが、コンテナに追加されていない場合です。
• システム要件の不整合: コンテナイメージはベースイメージを基盤として構築されますが、このベースには通常 CUDA の特定バージョンが既にインストールされています。ビルド時に追加するパッケージが期待する CUDA バージョンと、ベースイメージに含まれるバージョンが一致しない場合、エラーが発生してビルドに失敗します。
• ネットワークエラー: 接続が切断されると、パッケージやモデルの重み（weights）のダウンロード中に失敗することがあります。

コンテナイメージのビルドログは、Baseten がモデルコンテナを展開する前にどのように準備し検証するかを示しています。

Deploy / promotion logs

これらのログは、ビルドからサービス開始までの間に展開で何が起こったかを追跡します。展開ライフサイクルにおける重要な変更点（レプリカの起動、スケールアップやスケールダウンなど）がすべて記録されます。

モデルのバージョンが環境間を移動する際、プロモーションと呼ばれる変更が発生します。具体的には、開発環境からステージング環境、そして本番環境へと移行されるプロセスです。

開発環境は、進行中のコードを作成・テストするための場所です。ステージング環境は本番環境とほぼ同一に構成されており、ユーザーが利用する前に変更内容を検証するために使用されます。一方、本番環境とは、顧客が実際に利用している稼働中のバージョンを指します。

エラー数が急増した場合は、そのタイミングがプロモーションやスケーリングイベント直後であったかどうかを確認しましょう。デプロイやプロモーションのログと、サービス提供（サービング）のログを比較することで、問題の原因がデプロイによる変更なのか、それ以外の要因なのかを切り分けることができます。

Serving logs

Serving logs は、モデルが実行中に出力するすべての情報を記録します。これには、エラーや警告といった自動生成されたシステムメッセージが含まれるほか、コード側でログ出力を指示した内容もすべて記録されます。さらに、推論（インフェレンス）中のいくつかのステップ（リクエスト受信時、生成開始時、エラー発生や再試行の有無など）も追跡できるため、リクエストが正常に届いているかを確認し、モデル実行時の状況を把握するのに役立ちます。

Serving logs で検出される主な障害は以下の通りです。

モデルの読み込みエラー：起動時にモデルが正常に読み込まれない（依存関係の不整合、ファイルの欠落、メモリ制限など）。

ランタイム例外：リクエストが到来するも、処理中に何らかの問題が発生する（入力データ形式が誤っている場合など）。

GPU/ハードウェアエラー：GPU メモリ不足 (OOM) やハードウェアレベルでのクラッシュなどの問題。

すべてのログには request_id が付与されているため、特定の 1 つのリクエストに絞ってフィルタリングできます。例えば、ある推論リクエストが失敗した場合、その request_id を用いて関連するすべてのログイベントを特定し、何が起こったかを再構築することが可能です。これが Baseten で採用されている、リクエストレベルでのログ調査の仕組みです。

トレース

サービングログは、時間経過とともにすべてのリクエストで発生したイベントやエラーを時系列で記録した継続的なフィードです。一方、トレースは「1 つのリクエスト」に焦点を当てた、タイムスタンプ付きのステップバイステップな物語です。どの段階で時間を要し、どこで失敗したのかを可視化します。

トレースでは、リクエストがモデルに到達する前のプロセスも確認できます： （原文の技術表記: request_id,）

API Gateway では、リクエストがサービングパス（Istio → Activator → Queue → Server）に入る前に、呼び出し元の認証とモデル呼び出しの権限を確認します。また、どのクラスターで処理するかを決定し、Baseten が利用可能な容量があるクラスター間でモデルをシャード化できるようにしています。

Service mesh では、選択されたクラスター内でリクエストを準備完了したモデルレプリカへルーティングします。もしレプリカが存在しない場合は、Activator へ転送されます。

Activator は、実行中のレプリカがゼロの場合にリクエストを受け取り、レプリカの起動を開始し、準備ができ次第リクエストを転送します。

Queue は、レプリカは存在するがすべてビジー状態にある場合にリクエストを保持し、いずれかが空きになるまで待ちます。

Server では、モデルを実行してレスポンスを生成します。

The request path before it reaches the model

トレース情報からは、リクエストの開始時刻と終了時刻、そして正常に完了したのかエラーが発生したかがわかります。

実際の運用環境での遅延は、モデルへの到達前のこれらのステップで発生することが多く、トレースを活用することで原因を特定できます。以下に、トレースが検出できる一般的な障害例をいくつか挙げます。

「コールドスタートレイテンシ（Activator）」：レプリカがゼロから起動するのを待たされることで生じる遅延。

「キューのバックアップ（Queue）」：すべてのレプリカがビジー状態となり、リクエストが順番待ちで溜まってしまう現象。

「ルーティング失敗（Istio）」：リクエストがモデルに到達する前にドロップされたり、誤って転送されたりすること。

これが、1 つのリクエストがエンドツーエンドで 240ms かかった場合のウォーターフォール図です。

✕

ウォーターフォール図

この例では、時間の大半が「Server」ステップに費やされています。これは当然のことです。ここが実際のモデル計算を行っている場所だからです。しかし、API ゲートウェイ、サービスメッシュ、またはキューがより大きな割合を占めるようになった場合、それは問題がモデルよりも上流側にあるサインとなります。

リクエストが最も時間を要している箇所によって、対策も異なります。例えば、キューでの待ち時間が長い場合は、最小レプリカ数の引き上げや並行処理の調整が必要になるかもしれません。一方、サーバー側の処理に時間がかかる場合は、ハードウェアの変更、モデルやランタイムの最適化、バッチ処理の見直しなどが検討されます。

観測に使うべきツールは？

ログ、デプロイやリリースの記録、サービス提供時のログ、そしてトレースは、それぞれが本番環境でのモデルの異なる側面を物語っています。メトリクスは「何が」「いつ」問題を起こしたかを教えてくれます。ログからは「何が」「どこで（ビルド、デプロイ、あるいはサービス提供のどの段階で）」問題が発生したかがわかります。一方、トレースではリクエストパス上のどこに遅延が生じたのかを特定できます。

本番環境でのデプロイ問題に直面したら、その課題に適したツールを確認し、データが本当に何を伝えているのかを理解することが重要です。

Baseten の製品ダッシュボードには、ビルトインの観測機能（Observability）が搭載されており、デプロイメントの健全性やリクエスト量、レイテンシ、エラー、モデルパフォーマンスなどを監視できます。

また、Prometheus 互換のエンドポイントを通じてメトリクスを自社のスタックへエクスポートしたり、OTLP を介してログを Honeycomb、Datadog、Grafana Cloud、Sentry、または任意の OTLP/HTTP リシーバーへストリーミングすることも可能です。

メトリクスについては、Prometheus、Datadog、Grafana Cloud、New Relic 向けのガイドに加え、対応メトリクスのサポートマトリックスも用意されています。

多くのチームは、推論を単独で実行しているわけではありません。それはより大きなアプリケーション内の一つのサービスに過ぎません。モデルの応答が止まると製品の動作が正しくなくなる場合、推論はミッションクリティカルな要素となります。そのような状況では、モデルのメトリクスはアプリケーションの他のメトリクスと同じ場所に配置すべきです。そうでなければ、何かが遅延するたびに、問題の原因を特定するために別のタブで推論プラットフォームを確認し、もう一つのタブで自社の監視ツールをチェックする必要が生じます。

FAQ

LLM 推論における観測性（Observability）とは何ですか？

観測性とは、本番環境でのモデルを監視する方法のことです。メトリクスはパフォーマンスの良し悪しを、ログは発生した事象とその理由を、トレースは単一のリクエスト内で時間がどこに使われたかを示します。

ログとトレースの違いは何ですか？

ログは、時間経過とともにすべてのリクエストで発生するイベントの継続的なフィードです。一方、トレースは特定のリクエストに関する段階的なストーリーであり、開始時刻、終了時刻、およびどのステップで失敗または遅延したかを示します。

トークン生成までの時間（TTFT）が高くなる原因は何ですか？

高い TTFT は通常、コールドスタート、キューのバックアップ、または KV キャッシュのヒット率低下が原因です。キャッシュミスが発生すると、モデルは既に保存されているデータを再利用できず、プレフィックスを再計算する必要が生じるため、最初のトークンが表示されるまでの時間が追加されます。

KV キャッシュヒット率とは何で、なぜ重要なのか？

KV キャッシュヒット率は、トークンがゼロから再計算されるのではなく、事前にキャッシュされたキー・バリューペアを再利用する割合を示します。この値が高いほど、計算処理の重複が減るため、応答速度が向上し、コストも低下します。

LLM 推論におけるコールドスタート遅延の原因は何か？

コールドスタート遅延は、実行中のレプリカがゼロの状態から、新しいリクエストを受け付けるために新たなレプリカを起動する必要がある際に発生します。このプロセスは「Activator」によって処理され、レプリカが準備されるまでリクエストを一時的に保持します。