AI推論とは、学習済みのAIモデルに新しい入力を与え、分類、予測、埋め込み、画像、トークンストリーム、または意思決定といった出力を生成することです。学習ではモデルの学習済みパラメータを変更しますが、推論ではそのパラメータを使って有用な処理を行います。LLMの場合、実務上の役割は、プロンプトを生成トークンへと迅速かつ確実に変換し、ワークロードに見合うコストで提供することです。
この定義はシンプルです。しかし、本番環境で推論を運用することはそうではありません。リクエストは認証、ルーティング、キューイング、トークン化、ハードウェア上でのスケジューリング、モデルでの実行、結果のストリーミング、計測、障害発生時の復旧を経る必要があります。このガイドでは、運用上の意味でのAI推論の意味、つまりアプリケーションリクエストから有用な応答までの間に何が起こるのか、実際に重要な計測値は何か、そしてデモを本番システムと混同せずにクラウドGPU上へワークロードをデプロイする方法を解説します。
AI推論の意味を一文で言うと
AI推論は機械学習の実行フェーズです。学習済みモデルが学習したパラメータを新しいデータに適用し、出力を返します。NVIDIAは、推論を学習済みモデルが新しいデータから出力を生成する段階と説明しており、学習は学習データに基づいてモデルの重みを反復的に調整するプロセスです。両者の違いについては、NVIDIAのAI推論の概要が有用な一次資料です。
AI推論の意味を検索した方は、次のメンタルモデルを覚えておいてください。
学習はモデルに教えること。推論は学習済みモデルを実際に働かせることです。
チャットアプリケーションでは、その作業は生成的です。プロンプトを処理し、次のトークンを1つずつ予測し、停止条件に達するまでストリームを返します。分類器では単一のスコアになる場合があります。埋め込みモデルではベクトルになる場合があります。核心となる考え方は変わりません。新しい入力が入り、結果が出力され、そのリクエスト中は学習済みの重みが固定されたままです。
AI推論と学習、ファインチューニング、サービングの違い
これらの用語は関連していますが、それぞれ異なる役割を解決します。混同すると、チームは誤ったインフラを購入したり、誤った指標を測定したりすることになります。
| 用語 | 何が変わるか？ | 典型的な出力 | 主な運用上の懸念 |
|---|---|---|---|
| 学習 | 多くの例にわたってモデルの重みが更新される。 | 新しいモデルチェックポイント。 | データ、分散コンピューティング、収束、チェックポイント保存。 |
| ファインチューニング | より限定的なタスクに向けて、モデルの重みの一部または全部が更新される。 | 特化したチェックポイントまたはアダプター。 | データセットの品質、評価、バージョニング、回帰リスク。 |
| 推論 | 学習済みモデルが新しい入力に対して実行される。リクエストによって重みが更新されることはない。 | 予測、トークン列、ベクトル、画像、またはその他の結果。 | レイテンシ、スループット、キャパシティ、可用性、コスト。 |
| サービング | アプリケーションに推論を公開するシステム層。 | 信頼性の高いエンドポイント、キュー、スケジューラ、オブザーバビリティ基盤。 | ルーティング、バッチ処理、デプロイ、認証、ロールアウト、復旧。 |
言い換えると、AI推論の意味は「プラットフォーム全体」ではありません。これはモデル実行のステップです。推論サービングとは、そのステップを他のソフトウェアから利用可能にする周辺の本番システムを指します。
この枠組みにより、AI推論の意味は単なる用語の質問から運用上の判断へと変わります。まずモデル実行のステップを特定し、その後、それを信頼できるものにするためのすべての要素について責任者を割り当てます。
LLMにおけるAI推論の仕組み
正確な実装はモデルファミリーごとに異なりますが、本番環境のLLMリクエストは通常、次の経路をたどります。
- アプリケーションがリクエストを送信します。クライアントは、メッセージまたはプロンプト、生成制限、およびIDまたはテナントのコンテキストを提供します。
- エッジまたはAPIレイヤーが検証してルーティングします。通常、認証、クォータ、モデル選択、安全性チェック、リクエストログはここに置かれます。
- サーバーが入力をトークン化します。テキストはモデルが読み取れるトークンIDに変換されます。画像、音声、構造化入力には、それぞれのモダリティに固有の前処理が必要です。
- Prefillがプロンプトを処理します。モデルは、大規模な最初のパスでプロンプトのコンテキストを計算します。NVIDIAのLLM推論概要では、これをdecodeと区別し、どちらもエンドツーエンドのリクエストレイテンシを構成する要素として扱っています。prefill/decodeの説明を見る。
- サーバーが利用可能なアテンション状態を保持します。Transformerサービングシステムでは一般に、アクティブなシーケンスのキー/値（KV）状態を保持するため、次の各トークンでそれまでのコンテキスト全体を再計算する必要がありません。TensorRTでは、KVキャッシュを後付けの要素ではなく、アプリケーションまたはフレームワークが管理するメモリリソースとして文書化しています。TensorRTのKVキャッシュリファレンスを読む。
- Decodeがトークン単位で出力を生成します。モデルは次のトークンを繰り返し予測し、状態を更新し、部分的な応答をストリーミングするか、完了まで待機します。
- プラットフォームが結果を計測・監視します。本番の応答には、システムが必要とする以上の顧客コンテンツを保存せずに、レイテンシ、エラー、飽和状態、使用量を調査できる十分な証跡を残す必要があります。
これが、AI推論の意味という短い定義の背後にあるアーキテクチャです。モデル単体は低レイテンシのサービスではありません。リクエスト、コンピューティング、状態、フィードバックのための経路が必要です。
デプロイ前に描くべきクラウド推論アーキテクチャ
GPUの種類やサービングエンジンを選ぶ前に、リクエストの処理経路を概略設計しましょう。以下のリファレンスアーキテクチャは、クラウドGPU上でセルフホストするLLMまたはマルチモーダルモデルのエンドポイントに適用できます。
Client / application
│
▼
API edge: auth · limits · request IDs · routing
│
▼
Queue / scheduler ──► admission controls and timeouts
│
▼
Inference server: tokenizer → prefill → KV cache → decode / stream
│ │
▼ ▼
GPU worker pool cache-capacity signals
│
▼
Metrics, traces, logs, alerts, and deployment controls
各レイヤーは、それぞれ異なる障害要因を担当します。
- APIエッジ：無効な認証情報、クォータの枯渇、不正なモデルパラメータ、テナントの分離、リクエストの相関付け。
- キューおよびアドミッション制御レイヤー：バックプレッシャー、優先順位の決定、タイムアウトポリシー、過負荷の連鎖に対する保護。
- 推論サーバー：モデルの読み込み、トークン化、バッチ処理、メモリ割り当て、プロンプトの処理、トークン生成、ストリーミング。
- GPUワーカープール：ハードウェアの可用性、ドライバーとランタイムの互換性、GPUメモリの余裕、ネットワークトポロジー、レプリカの健全性。
- オブザーバビリティ：遅いリクエストが待機中だったのか、プリフィル中だったのか、デコード中だったのか、再試行中だったのか、あるいはGPUに到達する前に失敗していたのかを把握します。
大規模な導入では、この構成にモデルレジストリ、アーティファクトストレージ、独立したプリフィル層、独立したデコード層、またはキャッシュを考慮するルーターを追加する場合があります。ただし、最初からそこを目指す必要はありません。まず観測可能で再現性のある単一の処理経路から始め、よりシンプルなトポロジーではサービス目標を達成できないことが測定によって示された場合にのみ、分離を進めましょう。
重要な4つのパフォーマンス指標
チームはよく「モデルはどのくらい速いのか」と尋ねます。しかし、それだけでは曖昧すぎて、推論環境の導入判断には役立ちません。有用なパフォーマンス評価では、4つの指標を分けて考えます。
| 指標 | 何を示すか | 導入判断に影響する理由 |
|---|---|---|
| 最初のトークンまでの時間（TTFT） | リクエストの受け付けから、最初のトークンがストリーミングされるまでの時間。 | チャットユーザーが何らかの反応を得るまでに感じる待ち時間を表します。プロンプトの長さ、キュー待ち、プリフィルの処理能力、コールドスタートが支配的な要因になり得ます。 |
| 出力トークンあたりの時間（TPOT）／トークン間レイテンシ | 最初のトークン以降に生成されるトークン間の平均時間。 | ストリーミング回答が始まった後の応答性を示します。ここではデコードの処理能力と実行中の同時リクエスト数が重要です。 |
| エンドツーエンドレイテンシ | キュー待ち、処理、ストリーミング、レスポンスの完了までを含む、リクエスト全体の所要時間。 | 同期型ワークフロー、ツール呼び出し、部分的な出力を利用できないジョブで重要です。 |
| スループットとグッドプット | 単位時間あたりに完了した処理量。グッドプットは、実際に約束したレイテンシ目標を満たすものに限定されます。 | トークン／秒の数値が高くても、キューによってユーザーに約束した期限を守れていない状況を見逃さずに済みます。 |
現在のvLLMドキュメントでは、メトリクスエンドポイントを通じて、キュー待ち時間、プリフィル時間、デコード時間、TTFT、リクエストレイテンシ、出力トークンあたりの時間のヒストグラムが公開されています。本番環境向けメトリクスの一覧を、計測実装の具体的なチェックリストとして活用してください。
ここで重要なのは、AI推論のパフォーマンスを単一の数値では表せないという点です。環境全体では毎秒の生成トークン数が優れていても、対話型ユーザーにとってのTTFTが悪い場合があります。また、最初のトークンは速く返せても、長い出力では大幅に遅くなることもあります。ハードウェアを変更したり、チューニング用フラグを調整したりする前に、リクエスト経路を段階ごとに測定しましょう。
バッチ処理がスループットを高める一方で、レイテンシ目標の達成を妨げる理由
クラウドGPUはアイドル状態でもコストがかかるため、推論サーバーでは通常、互換性のあるリクエストをバッチにまとめます。NVIDIA Tritonの動的バッチャーはリクエストを組み合わせ、スケジューラーがより大きなバッチを形成するために待機する時間の上限を運用担当者が設定できるようにします。これにより、トレードオフが明確になります。待機時間を長くすると使用率とスループットが向上する可能性がありますが、キュー待ちによる遅延が増えます。Tritonのバッチャーに関するドキュメントでは、これらの制御項目が説明されています。
LLMでは、「continuous」「inflight」「iteration-level」と呼ばれるバッチ処理によって、このスケジューリングをより柔軟にできます。サーバーは、既存のバッチ内のすべてのシーケンスが完了するのを待つのではなく、生成ステップを進めるたびに、空いたスロットを新規または処理継続中のリクエストで埋めることができます。NVIDIAは、このアプローチを反復処理中に新規リクエストと処理中のリクエストを混在させる方法として説明しています。Tritonの継続的バッチ処理に関する説明をご覧ください。
バッチ処理を単なる設定のオン・オフとして扱ってはいけません。文書化したレイテンシ予算に照らしてテストしましょう。
- 対話型チャットやIDEでの支援では、通常、TTFTと出力のテンポが特に重視されます。
- バッチ要約、埋め込み生成、オフラインでのデータ拡充では、完了する処理のスループットを高める代わりに、より長いキュー待ち時間を許容できる場合があります。
- 長いコンテキストを扱う処理では、プリフィルとキャッシュ容量への負荷がより大きくなります。
- 長い出力を生成する処理では、デコードリソースがより長時間占有されるため、公平なキューイングやキャンセルの挙動に影響します。
このトレードオフは、実務におけるAI推論の意味の中核です。サービスは単に順伝播を実行するだけでなく、有限のコンピューティングリソースをどのように共有するかを決めなければなりません。
クラウドGPUへの導入：マネージドAPIとセルフホスト型推論のどちらを選ぶか
すべてのケースに当てはまる「正しい」導入モデルはありません。ワークロードに本当に必要な制御範囲に基づいて選択しましょう。
| マネージドモデルAPIを選ぶ場合 | クラウドGPU上でのセルフホスト推論を選ぶ場合 |
|---|---|
| モデルインフラを運用する必要が生じる前に、機能をリリースする必要がある。 | サービングスタック、モデルアーティファクト、ハードウェアトポロジー、またはランタイム構成を制御する必要がある。 |
| プロバイダーが管理するキャパシティ、モデル更新、エンドポイント運用がワークロードに適している。 | キャパシティ、デプロイ、オブザーバビリティ、インシデント対応の責任を定義し、運用できる。 |
| GPU設定への直接アクセスよりも、安定したAPI契約が連携に必要である。 | 負荷のパターン、データ境界、モデルのカスタマイズ、または最適化作業に、より低レベルの制御が必要である。 |
| モデルごとに個別のサービング経路を立ち上げることなく、複数のモデルをテストしたい。 | 実測されたワークロードがあり、推論経路を自ら管理する明確な理由がある。 |
成熟したシステムの多くはハイブリッドです。チームは、安定した大量処理向けのモデルをセルフホストする一方で、利用頻度の低いモデル、実験的なモダリティ、バースト時のキャパシティ、またはフォールバック経路にはマネージドAPIを利用することがあります。重要なのは「クラウドGPUかAPIか」ではなく、「リクエスト経路のどの部分を自ら管理する必要があるか」という問いです。
コストと運用に関する、より詳しい意思決定のフレームワークについては、GPUクラウドとモデルAPIの比較をご覧ください。サービングエンドポイントを自ら管理する場合は、OpenAI互換推論サーバーガイドで、vLLMを中心とした実践的な実装手順を紹介しています。
本番運用を見据えたクラウドGPUデプロイの実践ガイド
デプロイチームにとって、AI推論の意味は、責任範囲を明確にすることにあります。リクエストの各フェーズを特定し、それぞれが満たすべき目標を定義し、担当者と障害を示すシグナルを可視化します。
1. リソースをプロビジョニングする前に受け入れ条件を文書化する
ワークロードをテスト可能な形で文書化します。
- ライセンスとアーティファクトの取得元を含む、モデルとバージョン。
- 入力モダリティ、プロンプト長の分布、想定される出力長。
- ピーク時および定常時の同時リクエスト数。
- TTFT、TPOT、エンドツーエンドのレイテンシ、エラー率、可用性の目標。
- ストリーミング、キャンセル、データ保持、リージョンに関する要件。
- 負荷ジェネレーターだけでなく、出力品質を評価するための代表的な評価セット。
この受け入れ条件がなければ、「もっと高速なGPUが必要だ」というのは意思決定ではなく、推測にすぎません。
2. 単一レプリカのベースラインを構築する
非本番環境でモデルのレプリカを1つ実行し、短い入力と長い入力を実際の利用状況に即して組み合わせた条件下で、フェーズごとのメトリクスを収集します。モデルサーバーのバージョン、ドライバー／ランタイムのバージョン、モデルとトークナイザーのリビジョン、バッチ処理ポリシー、同時実行数を記録します。再現可能なベースラインがあれば、その後のキャパシティ分析やインシデント分析が可能になります。
サービングエンジンを選定するチーム向けに、vLLMとSGLangの比較では、一方が常に優れていると断定するのではなく、ワークロードに焦点を当てて比較しています。
3. モデルサイズだけでなく、重みとランタイム状態を合わせてメモリを計画する
GPUメモリには、チェックポイント以外の領域も必要です。ランタイムバッファーや、KVキャッシュなどのアクティブなシーケンス状態を保持する余地も確保しなければなりません。TensorRTのドキュメントでは、メモリ割り当ての境界が明示されています。キャッシュ容量はTransformerレイヤー自体の外部で管理されます。つまり、モデルの読み込みが成功しても、実際の同時トラフィックによってキャッシュの逼迫が生じる可能性があります。
実際のコンテキスト長と出力上限を用いて、実測に基づくキャパシティテストを行います。キャッシュ使用率、サーバーが公開している場合はプリエンプションやエビクション、そしてリクエスト受け入れの限界における障害時の挙動を追跡します。GPUメモリの計画に関する関連フレームワークについては、LLMのGPUメモリ要件をお読みください。
4. GPUスケジューリングを明示的に設定する
KubernetesはGPU向けのベンダー提供デバイスプラグインをサポートし、GPUをスケジューリング可能なリソースとして公開します。GPUスケジューリングのガイダンスでは、カスタムGPUリソースをコンテナーのlimitsに指定し、requestsは省略するか、制限値と同じにするよう定めています。以下のマニフェストを変更して使用する前に、KubernetesのGPUスケジューリングに関するドキュメントを確認してください。
apiVersion: apps/v1
kind: Deployment
metadata:
name: inference-server
spec:
replicas: 1
selector:
matchLabels:
app: inference-server
template:
metadata:
labels:
app: inference-server
spec:
containers:
- name: server
image: registry.example.com/inference-server:immutable-tag
resources:
limits:
nvidia.com/gpu: 1
cpu: "4"
memory: 32Gi
nvidia.com/gpuは、NVIDIAデバイスプラグインをインストールした環境におけるリソース名の例です。デプロイ前に、自分のクラスターでリソース名、ノードラベル、ランタイム、配置ポリシーを確認してください。この最小限のマニフェストを完全な本番構成として使用しないでください。シークレット、プローブ、ネットワークポリシー、ストレージ、オートスケーリング、ロールアウト制御は意図的に省略されています。
5. SLOに照らしてキューイングとバッチ処理を調整する
余裕を持たせたキュー上限と、明示的なタイムアウトから始めます。バッチサイズやバッチ処理の待機時間は、対象のパーセンタイルが受け入れ条件の範囲内に収まる間に限って増やします。以下のケースごとに個別の負荷テストを行います。
- 短いプロンプトと短い出力。
- 長いプロンプトと短い出力。
- 短いプロンプトと長い出力。
- 優先度の異なるテナントが混在するケース。
- ストリームの読み取りを停止する低速なクライアント。
- キャンセル、再試行、ワーカー障害の各経路。
ある変更によって一方のプロファイルが改善され、別のプロファイルが悪化する場合、それらを平均化して見えなくしてはいけません。ワークロードを分割するか、受付ポリシーを見直すか、サービス階層を正直に明示してください。
6. モデルだけでなく、各レイヤーを計測する
少なくとも、リクエストID、ステータスコード、モデル/バージョン、キュー待機時間、プリフィル時間、最初のトークンまでの時間、デコード時間、出力トークンあたりの時間、生成トークン数、キャンセル率、GPU/サーバーの健全性を記録します。クライアントから見えるレイテンシーを、サーバーのフェーズ別メトリクスと関連付けてください。これにより、オンコール担当エンジニアは基本的でありながら重要な問いに答えられます。このリクエストは待機したのか、計算したのか、失敗したのか、それとも切断されたのか。
7. 段階的にロールアウトし、障害をリハーサルする
不変のアーティファクト、モデルの準備完了をテストするヘルスチェック、カナリアトラフィックの一部、そして容易なロールバック経路を使用します。そのうえで、発生してほしくない障害をテストしてください。モデル読み込みの失敗、利用不能なGPUワーカー、飽和したキュー、依存先のタイムアウト、無効なモデル設定、ストリーミング中のクライアント切断などです。
単一のモデルではワークロードの信頼性目標を満たせない場合、フォールバックを別のセルフホスト型レプリカにするのか、別のモデルにするのか、あるいはマネージドAPI経路にするのかを事前に決めておきます。このモデルフォールバック戦略ガイドは、その判断の整理に役立ちます。
チームがAI推論を初めて導入する際によくある間違い
成功したデモをキャパシティ計画と見なす
1人のユーザーによるプロンプトは、モデルが起動できることを示すだけです。本番環境の同時実行数、可変長のプロンプト、ストリーミングクライアント、またはワーカー障害の状況で、エンドポイントがレイテンシー目標を満たすことの証明にはなりません。
レイテンシーの約束を定義する前にスループットを最適化する
バッチを大きくするとハードウェア利用率は改善できますが、インタラクティブな製品はユーザーの待ち時間で評価されます。まずパーセンタイル目標を定義し、その目標を満たすシステムをチューニングしてください。
平均レイテンシーだけを測定する
平均値では、キューの急増、ロングテールのプロンプト、コールドスタート、テナント間の干渉が隠れてしまいます。パーセンタイルとフェーズ別メトリクスを使用してください。平均が速いことは、最も遅いユーザー体験が許容可能である証拠にはなりません。
KVキャッシュの挙動を無視する
トークン生成はシーケンス全体で状態を持ちます。キャッシュ使用量、コンテキスト長、同時実行数、再利用ポリシー、退避動作は、重みのみのメモリ見積もりに余裕があった場合でも、実際の負荷を成立させるか失敗させるかを左右します。
ハードウェアを最初の判断にする
ハードウェアは重要ですが、モデル形式、サービングエンジン、リクエスト分布、バッチ処理ポリシー、トポロジー、オブザーバビリティによって結果は変わります。GPU構成を「十分に高速」と判断する前に、ワークロードを測定してください。
AI推論に関するよくある質問
AI推論はAIモデルAPIと同じですか？
いいえ。AI推論とは、モデルが新しい入力に対して実行されることです。AIモデルAPIは、推論にアクセスする1つの方法です。APIプロバイダーがサービングインフラを運用することもあれば、自身の推論サーバーをAPIの背後に公開することもできます。
推論によってモデルは変化しますか？
通常の推論では、モデルの重みは更新されません。更新するのはトレーニングとファインチューニングです。システムが後続の評価やトレーニングのために推論結果をログに記録する場合もありますが、これは独自のデータおよびガバナンス上の選択を伴う別のワークフローです。
LLM推論がプリフィルとデコードに分かれるのはなぜですか？
プリフィルはプロンプトコンテキストを処理し、デコードは出力トークンを順番に生成します。これらのフェーズはサービングシステムに異なる負荷をかけるため、TTFTと出力トークンの生成間隔は分けて測定すべきです。
AI推論にはクラウドGPUが必要ですか？
常に必要とは限りません。CPU、エッジアクセラレーター、またはマネージドモデルAPIで実行できるワークロードもあります。モデル、レイテンシー目標、スループット要件、またはサービング構成でGPUアクセラレーションが必要で、そのインフラを運用したい場合に、クラウドGPUが適切です。
最初に何を監視すべきですか？
成功したリクエスト、エラー、キュー時間、TTFT、出力トークンあたりの時間、エンドツーエンドレイテンシー、生成トークン数、GPU/サーバーの健全性から始めてください。サービングエンジンで利用可能になれば、モデル固有のキャッシュおよびスケジューラメトリクスを追加します。
定義を実践に活かす
実践的なAI推論の意味は明快です。トレーニング済みモデルが新しい入力に対して実行され、出力を生成します。エンジニアリングの仕事は、その出力を実際のトラフィック下でもタイムリーで、可観測で、経済的かつ回復力のあるものにすることです。
まず、リクエストプロファイルと受け入れ基準のメトリクスを書き出してください。マネージドAPIがワークロードに必要な制御レベルを提供する場合はそれを選び、サービング経路を所有すべき測定済みの理由がある場合はクラウドGPU推論を選びます。その後、最適化する前に、プリフィル、デコード、キューイング、キャッシュ状態、障害処理を可視化してください。
一部のワークロードがセルフホスト型GPUよりもAPI経由で提供するほうが適している場合は、Flatkeyのモデルカタログを確認するか、GPUクラウドとモデルAPIの比較ガイドでアーキテクチャの選択肢を比較してください。
