Communityコーディング&開発github.com

推論エンジニアリング

生成AIモデルを提供するためのアーキテクチャ、パフォーマンス、プロダクションに関する意思決定を行います。モデルやハードウェアの選択、レイテンシやスループットの診断、LLMまたはマルチモーダル推論の最適化、ベンチマーク、GPUサービスのスケーリング、サービングコストの見積もりに使用します。

推論エンジニアリング とは?

このスキルは、AI製品の品質、レイテンシ、信頼性、コスト要件を測定可能な推論システムに変換するための包括的なガイドです。Philip Kiely著『推論エンジニアリング』(Baseten Books、2026年)の独立した運用シンセシスに基づいており、ワークロードの特性評価、ボトルネックの診断、最適化手法(バッチ処理、量子化、投機的デコード、KVキャッシング、並列処理、カーネル最適化など)の適用、そして本番環境への準備(キャパシティ計画、信頼性、デプロイメント、オブザーバビリティ、コスト管理)までをカバーします。Claude Code、Cursor、CodexなどのAIエージェントと互換性があり、開発者がモデル選択、ハードウェアフィット、ベンチマーク、サービングコスト見積もりに関する実証的な意思決定を行うのに役立ちます。このスキルは、SKILL.mdドキュメントに定義されたワークフローに従い、推論最適化における単一メトリクスの最適化を避け、品質、パフォーマンス、コストのトレードオフを総合的に評価することに重点を置いています。

対応~Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add https://github.com/Ayaansiddiq07/Inference-skill/tree/HEAD

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

推論エンジニアリング は何をしますか?

このスキルを使用して、AI製品の品質、レイテンシ、信頼性、コスト要件を測定可能な推論システムに変換します。これはPhilip Kiely著『推論エンジニアリング』(Baseten Books、2026年)をもとにした独立した運用シンセシスであり、著者や出版社との提携や承認を受けたものではありません。ベンダーの機能、モデルのリリース、ハードウェアの可用性、ソフトウェアの動作は急速に変化します。実装を決定する前に、公式ドキュメントで最新の詳細を確認してください。

ワークロードから始める

エンジンや最適化を選択する前に、以下を確立します。

  • 製品契約: 必要な出力品質、モダリティ、コンテキスト/入力サイズ、レスポンス形状、ストリーミングの必要性、障害動作。
  • トラフィック形状: リクエストレート、同時実行性、バースト性、到着パターン、入出力長の分布、キャッシュ可能なプレフィックスの頻度。
  • サービス目標: エンドツーエンドのP50/P95/P99レイテンシ、最初のトークンまでの時間(TTFT)、トークン間レイテンシ(ITL)、スループット、可用性、復旧目標。
  • 制約: 予算、リージョン、データレジデンシ、プライバシー、ライセンス、ハードウェアアクセス、運用能力。
  • ベースライン: 代表的な品質評価と、現実的な負荷下でのエンドツーエンドのパフォーマンスおよびコスト。

プロキシメトリクスを単独で最適化しないでください。作業の単位を定義し、該当する場合はクライアント、キュー、ネットワーク、前処理、モデル、後処理時間を含めます。エージェントフローの場合、ツール呼び出しやリトライを含むタスク全体を測定します。

運用ワークフロー

  1. ワークロードを特性評価する。 インタラクティブなオンライントラフィックとオフライン/バッチ処理を分離し、レイテンシに敏感なパスとスループット指向のパスを特定します。実際の入出力分布と同時実行性を記録します。
  2. 候補モデルを選択する。 タスク固有の品質、モダリティ、コンテキスト、サービング制約、ライセンス、運用適合性で絞り込みます。公的ベンチマークは候補を絞り込むためだけに使用し、代表的な製品データと障害ケースで評価します。
  3. 予算を設定する。 エンドツーエンドの目標を、キューイング、ネットワーク、前処理、プリフィル、デコード、後処理の予算に変換します。バーストや劣化状態のためのヘッドルームを含めます。
  4. モデルをハードウェアに適合させる。 重みメモリ、ランタイム/アクティベーションのオーバーヘッド、KVキャッシュ需要、使用可能なヘッドルームを見積もります。測定されたメモリ帯域幅、計算能力、相互接続、トポロジを確認します。名目上のアクセラレータ仕様はワークロードのベンチマークではありません。
  5. 再現可能なベースラインを確立する。 モデルリビジョン、エンジン/バージョン、ハードウェア、精度、構成、プロンプトミックス、出力制限、負荷形状を固定します。ウォームアップし、十分なサンプルを実行し、同時にパーセンタイルとスループットを報告します。
  6. ボトルネックを特定する。 最初にエンドツーエンドの測定を行い、次にシステムおよびカーネルプロファイリングを行います。キューイング、プリフィル、デコード、メモリ容量/帯域幅、計算、通信、ホストのオーバーヘッドを区別します。
  7. 一度に一つの変数を変更する。 測定されたボトルネックに対処する最も複雑でない最適化を適用します。品質、テールレイテンシ、スループット、メモリ、コストを一緒に再確認します。
  8. 本番動作を検証する。 過負荷、コールドスタート、スケールイベント、障害、デプロイ、キャンセル、ストリーミング、復旧をテストします。サービス目標で使用されたのと同じメトリクスを計測します。

メトリクスと診断

  • TTFT: 明確に定義された開始イベント(例:クライアント送信またはサーバー受け入れ)から最初の生成トークンまでの時間。比較時にその境界を一貫させます。キューイング、プロンプト長、プリフィル、起動効果に敏感です。
  • ITL: 生成されたトークン間の時間。デコードの応答性を反映します。リクエストごとの分布を報告し、トークンレートの集約のみを行わないでください。
  • エンドツーエンドレイテンシ: クライアントが観測する完了時間。ネットワークおよびアプリケーションの作業を含みます。
  • スループット: 指定されたワークロードとレイテンシ/品質エンベロープにおける、単位時間あたりの完了リクエストまたはトークン数。トークン/秒がユーザーあたりかシステム全体かを明記します。
  • パーセンタイル: P50とP95/P99などのテール目標を報告します。平均値は遅いリクエストを隠す可能性があります。
  • グッドプット: 関連するレイテンシと品質目標を満たしながら完了した作業。速度と品質またはテール動作をトレードオフする構成を比較するためにこれを使用します。

症状を仮説として解釈し、トレース/プロファイルで検証します。

症状測定すべき可能性のある領域
TTFTが高い、ITLは正常キュー待機、長いプロンプト、プリフィル計算、コールドスタート、前処理
TTFTが正常、ITLが悪いデコード帯域幅、バッチ競合、KVキャッシュプレッシャー、カーネル効率
同時実行性が上がると両方が悪化キューイング、メモリ容量、バッチポリシー、アドミッションコントロール、飽和
GPU使用率が低く、レイテンシが高いCPU/トークナイゼーション、データ転送、同期、ネットワーク、スケジューリング
スループットは上がるがテールレイテンシがSLOに違反バッチング/同時実行性ポリシー、キュー制限、ワークロード分離

これらは診断の手がかりであり、結論ではありません。構成を変更する前にアクティブなボトルネックを確認してください。

モデルとハードウェアの決定

  • 製品の品質評価を許容可能なマージンで通過する、最小/最もコストのかからないモデルを優先します。評価が特定のギャップを特定し、ライフサイクルコストが正当化される場合にのみ、プロンプティング、検索、ファインチューニング、または蒸留を検討します。
  • レイテンシ、バッチング、または可用性の目標が競合し、測定されたトラフィックが運用オーバーヘッドを正当化する場合、オンラインとオフラインのデプロイメントを分離します。
  • モデルとランタイム状態をアクセラレータメモリに適合させ、KVキャッシュ、アクティベーション、フラグメンテーション、同時実行性のための明示的なヘッドルームを確保します。重みの適合だけでは不十分です。
  • 自己回帰LLMの場合、プリフィルとデコードはハードウェアに異なる負荷をかけます。プリフィルは通常計算負荷が高く、デコードはメモリ帯域幅がボトルネックになることがよくあります。実際のシーケンスとバッチ混合の両方を測定します。
  • マルチGPUの選択は、メモリ/レイテンシ/スループットと通信/複雑さをトレードオフします。テンソル並列処理は分割モデルのリクエストあたりのレイテンシを削減できます。エキスパート並列処理は疎なエキスパートを大規模にサービスできます。相互接続と同期コストを検証します。マルチノード実行には特に注意深い通信測定が必要です。
  • 画像、動画、音声、埋め込み、視覚言語ワークロードには、モダリティ固有のパイプラインとメトリクスを使用します。前処理、チャンク分割、エンコーダ/デコーダ、後処理コストを含め、LLMトークンメトリクスを盲目的に適用しないでください。
  • モデルとデータセットのライセンス、および関連するセキュリティ、プライバシー、規制要件をデプロイ前に確認します。

これらの選択の背後にある理論的根拠については、モデルとハードウェアの基礎を参照してください。フレームワーク、フォーマット、サービングエンジンの互換性については、ソフトウェアスタックの選択を参照してください。これらのリファレンスは意思決定方法を提供しますが、時代を超越したランキングではありません。正確なモデル、アクセラレータ、ランタイムバージョン、機能セットのサポートを確認してください。

最適化プレイブック

ベースラインを確立し、互換性のあるボトルネックを特定した後にのみ適用します。

バッチ処理とスケジューリング

バッチ処理はアクセラレータの利用率を向上させ、オーバーヘッドを償却できますが、キューイングとリクエストあたりのレイテンシが増加します。同時実行性、バッチ制限、待機ウィンドウ、アドミッションコントロールを現実的な到着パターンに合わせて調整します。目標が競合する場合、インタラクティブトラフィックをバッチ処理から保護します。

量子化

量子化はバイナリ設定ではなく、品質/パフォーマンスのスペクトルとして扱います。測定されたメモリ、帯域幅、計算、品質の制約に基づいて、変更するコンポーネントと精度を選択します。各変更後に代表的なタスク品質、エッジケース、回帰セットを評価します。エンジンが許可する場合は、重み、アクティベーション、アテンション、KVキャッシュの効果を個別に観察します。製品の品質基準または信頼性目標を満たさない場合はロールバックします。

投機的デコード

ドラフト/提案メカニズムは、その提案コストと受理動作がターゲットワークロードに対して純利益を生み出す場合にのみ使用します。受理率、メモリオーバーヘッド、バッチサイズの影響、ユーザーあたりのITL、総スループット、コストを測定します。利点は、同時実行性が高い場合や受理率が低い場合に減少または逆転する可能性があります。

KVキャッシュとプレフィックスキャッシュ

プレフィックスが繰り返し発生し、正当性/分離要件が許す場合に、キャッシュされた状態を再利用します。ヒット率、節約されたプリフィル作業、ストレージ/メモリコスト、エビクション動作、ルーティングの局所性を測定します。キャッシュキーとテナント/セキュリティ境界を定義して、あるリクエストが別のテナントのプライベートコンテキストを再利用できないようにします。長いコンテキストと高い同時実行性はKVプレッシャーを増加させます。配置と転送コストを考慮します。

並列処理と分離

モデル適合、レイテンシ、またはスループットの測定が通信オーバーヘッドを正当化する場合に並列処理を導入します。プリフィルとデコードを分離するのは、ワークロードが十分に大きく安定しており、独立したリソース割り当ての恩恵を受け、システムがKV転送/ルーティングを管理できる場合のみです。比較にネットワーク帯域幅、転送レイテンシ、障害モード、運用複雑性を含めます。

カーネルとランタイムの最適化

特殊なカーネルを作成または選択する前にプロファイリングを行います。カーネル融合はメモリトラフィックと起動オーバーヘッドを削減できますが、互換性と数値動作が重要です。同じモデルリビジョン、ハードウェア、プロンプトミックス、出力長、負荷、品質チェックを使用して、フレームワーク/ランタイム/エンジンの候補を比較します。

量子化方法、投機的デコードファミリー、キャッシュ配置、長コンテキストサービング、分散実行の詳細な比較については、最適化プレイブックを参照してください。

ベンチマークとプロファイリング

  • リクエストサイズ、到着パターン、キャッシュ特性を保持する、本番トレースまたはプライバシーセーフなワークロードを使用します。合成テストは制御された実験に有用ですが、その限界を明記します。
  • コールドとウォームの動作を別々に記録します。ウォームアップ、適切な期間/サンプル数、繰り返し実行、分散、ハードウェア/ソフトウェアのバージョンを含めます。
  • 負荷をスイープして、飽和点とSLO下での最大グッドプットの両方を見つけます。軽負荷の実行と過負荷の実行を比較しないでください。
  • 原因を特定するために一度に一つの要素を変更します。チューニング後、最適化が相互作用する可能性があるため、結合したエンドツーエンドテストを実行します。
  • システムベンチマークとタスク品質評価をペアにします。製品のしきい値を超えて出力を劣化させるパフォーマンス改善は勝利ではありません。
  • ベンチマークは何が遅いかを示し、プロファイリングはなぜ遅いかを説明するのに役立ちます。アクティブなボトルネックを分離できる最小限の侵入的なプロファイラを使用し、新しいベンチマークで提案された修正を検証します。

本番環境への準備

  • キャパシティとオートスケーリング: 完了した作業だけでなく、先行指標(キューの深さ、使用率、メモリ/KVプレッシャー、到着率)に基づいてスケーリングします。プロビジョニングとモデルロード時間を考慮し、コールドスタートが目標に違反する場合は十分なキャパシティを維持するか、優雅に劣化させます。
  • キューイングと過負荷: キューとリクエストサイズに制限を設け、タイムアウト/キャンセルを設定し、アドミッションコントロールを使用し、明示的な過負荷応答を定義します。無制限のキューイングは飽和をテールレイテンシ障害に変換します。
  • 信頼性: ヘルスチェック、リトライ(制限付き)、必要な場合のべき等性、インスタンス損失、リージョン/プロバイダ障害、ロールアウト、ロールバック、キャパシティ枯渇をテストします。リトライは過負荷を増幅させる可能性があります。
  • デプロイメント: モデルアーティファクトと依存関係を固定し、起動/準備状況を検証し、変更をカナリアし、品質とサービスのメトリクスを比較し、テスト済みのロールバックパスを保持します。イメージ、ログ、ベンチマークアーティファクトに機密情報を公開しないでください。
  • オブザーバビリティ: リクエストトレースをモデル、エンジン、ハードウェア、構成バージョンと関連付けます。TTFT、ITL、エンドツーエンドパーセンタイル、キュータイム、スループット/グッドプット、エラー、キャッシュヒット率、使用率、メモリ、コールドスタート、コストを追跡します。
  • コスト: 必要な品質とSLOでの成功リクエストあたりまたは有用な出力あたりのコストを比較します。アイドルキャパシティ、レプリケーション、ネットワーキング、ストレージ、エンジニアリング/運用負担を含めます。スケール・トゥ・ゼロはアイドルコストを削減できますが、コールドスタートレイテンシが追加されます。
  • セキュリティとコンプライアンス: モデルとデータへのアクセスを制御し、テナントを分離し、ログ内のプロンプトと出力を保護し、保持期間を定義し、依存関係とアーティファクトを検証し、該当するデータレジデンシと規制要件を満たします。

コンテナの再現性、キャパシティとルーティング、マルチリージョン運用、クライアントプロトコル、ロールアウトプラクティスについては、本番運用を参照してください。モダリティ別の測定については、モダリティ固有の推論考慮事項を参照してください。

リファレンスルーティング

タスク読むべきもの
ワークロードカードの作成、ベースラインの確立、ボトルネックの特定このファイル、次に最適化プレイブック
モデル実行、アクセラレータ適合、ハードウェアトレードオフを理解するモデルとハードウェアの基礎
フレームワーク、モデルフォーマット、カーネルパス、サービングエンジンの選択ソフトウェアスタックの選択
量子化、投機、キャッシュ、並列処理、分離の調整最適化プレイブック
ビジョン、埋め込み、音声、画像、動画ワークロードのサービングモダリティ固有の考慮事項
オートスケーリング、デプロイメント、信頼性、API/クライアント動作、コストの計画本番運用

推論タスクのレスポンス形式

アドバイスや実装を行う場合、以下を提供します。

  1. ワークロードの前提と欠落している測定値。
  2. 目標とベースラインメトリクス。
  3. 主要なボトルネック仮説とその証明方法。
  4. 期待されるトレードオフを含むランク付けされた実験計画。
  5. 品質、テールレイテンシ、信頼性、セキュリティ、コストの受入基準。
  6. 推奨に影響を与える場合の、現在のベンダー/モデル/ランタイムの事実と公式ソースへのリンク。

関連スキル