ai-llm-inference

LLM 推論の本番運用スキルハブ

最新の推論スタックの選定とチューニングに関する運用ガイダンスです。ランタイムとの適合性、ルーティング、出力保証、アダプターの読み込み、マルチモーダルサービング、負荷時に測定したパフォーマンスに重点を置いています。

バージョン、ハードウェアサポート、ベンチマーク、料金、リリース状況など、変化しやすい情報には最新の一次情報を使用してください。

このスキルを使う場面

次のような依頼には、このスキルを使用してください。

• 推論エンジンの選定やスタックの比較
• レイテンシ、TTFT、ITL、スループットの最適化
• キャッシュを考慮したルーティングやコントロールプレーンの設計
• ランタイムとハードウェアに応じた量子化戦略
• マルチ GPU またはマルチノードサービング
• サービング時の構造化出力や制約付きデコーディング
• マルチモーダルまたはエンコーダー・デコーダーのサービングパターン
• LoRA または複数アダプターのサービング
• セルフホストまたは API 推論のコスト削減
• ベンチマーク、プロファイリング、容量計画
• 複数ユーザー向け llama.cpp サーバーのサービング、またはデバイス上の NPU（テンソルごとのスケール、静的形状）。単一マシンでの CPU／エッジ／デスクトップ実行については、ai-local-model-ops を参照してください。

対象範囲の境界

• プロンプト作成 -> ai-prompt-engineering
• 評価セットと品質ゲート -> ai-evals
• ファインチューニングとその他のモデル適応 -> ai-llm
• 単一マシンでのローカル実行（GGUF 量子化の選択、VRAM への適合、CPU／エッジデバイス） -> ai-local-model-ops。CPU とエッジのチューニングについては、その edge-cpu-optimization.md を参照してください。
• RAG パイプラインの設計 -> ai-rag
• デプロイ自動化、監視、インシデント対応 -> ai-mlops
• インフラ運用 -> ops-devops-platform
• 可観測性の設計 -> qa-observability

クイックリファレンス

判断項目	主な質問	デフォルトの開始点	次の段階に進む条件
エンジン	トークンを実行するランタイムはどれですか？	汎用テキストサービングには vLLM	KV の再利用強化、マルチモーダルの分離、または NVIDIA 固有のカーネルが必要な場合
ルーター	リクエストをどのように割り当てますか？	まずはシンプルなレプリカプール	複数のレプリカ、固定プレフィックス、複数 LoRA、または混在するワークロードがある場合
出力制御	応答にスキーマへの準拠が必要ですか？	ネイティブの構造化出力を使用	JSON の有効性や文法制約が SLA の一部である場合
マルチモーダル	独立したエンコーダーパスがありますか？	まずは同じ場所に配置	エンコーダーの飽和状態がデコードの飽和状態と異なる場合
アダプター	多数の LoRA やテナントでベースモデルを共有しますか？	ネイティブの複数 LoRA サポートを使用	コールドロードのレイテンシやアダプターの頻繁な切り替えが p95 に影響する場合
量子化	このランタイムで安全に使える精度はどれですか？	ランタイムネイティブの FP8 または重みのみの方式	ハードウェアサポートやモデル品質が不確かな場合
分離	プリフィル／エンコーダー／デコードを分離すべきですか？	同じ場所に配置した場合のベースラインを確認してから	キューイングの干渉やリソースの非対称性が実証された場合

事前確認チェックリスト（必須）

変更を推奨する前に、次の情報を収集するか推定してください。

• モデルファミリー、サイズ、コンテキスト長、トークナイザー、モダリティ、アダプターの使用状況
• リクエストの契約：ストリーミング、ツール使用、推論モード、スキーマまたは文法の制約
• プロンプトと出力の長さの分布、同時実行数、QPS、バーストの状況
• プロンプト再利用のパターン：プレフィックスの再利用、セッションの再利用、検索結果の再利用、LoRA の再利用
• 現在のエンジン、バージョン、ルーター、オートスケーラー、キャッシュ設定
• ハードウェアとトポロジー：GPU SKU、VRAM、インターコネクト、ノード数、CPU、RAM
• SLO：TTFT、ITL、エンドツーエンドのレイテンシ、可用性、エラーバジェット
• 受け入れ基準：品質の下限、JSON の有効性、長文脈での精度、ロールバック可能期間

ワークフロー

1. 変更を推奨する前に、ワークロードの特性、ランタイムの契約、ハードウェア、SLO を把握します。
2. 推論のチューニングが主な課題でない場合は、プロンプト戦略、RAG 設計、またはプラットフォーム運用を隣接するスキルに引き継ぎます。
3. 意思決定フローに基づいて、サービングスタック、ルーティングポリシー、量子化の経路、出力制御の戦略を選択します。
4. ベースラインをベンチマークし、一度に 1 つの要素だけを変更して、受け入れ基準に照らしてスループット、レイテンシ、品質を比較します。
5. 最終的な推奨を行う前に、変動しやすいエンジン、ハードウェア、リリースに関する情報をナビゲーション用の情報源で確認します。

意思決定フロー

Need to improve inference:
    |
    |- Is the workload text-only?
    |   |- No -> evaluate multimodal runtime support and encoder separation
    |   `- Yes -> continue
    |
    |- Is schema validity or constrained decoding part of the SLA?
    |   |- Yes -> prefer runtimes with native structured outputs
    |   `- No -> continue
    |
    |- Are there multiple replicas, tenants, or adapters?
    |   |- Yes -> design routing and placement explicitly
    |   `- No -> simple replica pool may be enough
    |
    |- Is there high prefix or session reuse?
    |   |- Yes -> prefer KV-aware routing and native prefix reuse
    |   `- No -> standard load balancing is acceptable
    |
    |- Are long prompts or mixed prompt lengths hurting p95?
    |   |- Yes -> test admission control first, then prefill or encoder disaggregation
    |   `- No -> keep colocated
    |
    |- Is this a MoE model (config.json lists routed experts)?
    |   |- Yes -> size memory from TOTAL params (every expert must be resident)
    |   |         and per-token compute from ACTIVE params; then assess EP degree,
    |   |         EPLB support, and all-to-all topology
    |   |         see references/moe-expert-parallelism.md
    |   `- No -> continue
    |
    `- Does the model fit latency and cost targets at current precision?
        |- Yes -> keep the simpler stack
        `- No -> walk the lever ladder in order, cheapest and least lossy first:
            1. roofline diagnosis: memory-bandwidth-bound or compute-bound?
               (the answer decides which of the rungs below can help at all)
            2. batching / admission control      (lossless)
            3. KV-cache quantization             (lossy -> eval gate)
            4. speculative decoding              (lossless only with rejection-sampling
                                                    verification; gate Medusa-style)
            5. weight quantization               (lossy -> eval gate)
            6. pruning / distillation            (lossy -> eval gate, retrain cost)
            Each lossy rung gets its own eval gate and rollback window.
            Change one rung at a time; stacking them hides the regression.

スタックのガイダンス

vLLM

• OpenAI 互換のテキストサービング、構造化出力、LoRA サービング、幅広い量子化サポートに適したデフォルトの選択肢です。
• テキスト推論と本番環境向けのルーターパターンに、単一のランタイムを使用したいチームに適しています。
• 公式ドキュメントでは現在、構造化出力、分離型プリフィリング、分離型エンコーダーサービング、LoRA、量子化について、それぞれ別のページで説明しています。これらの機能は個別に扱い、単一の切り替えであらゆる性能の問題が解決すると考えないでください。
• 重要な注意点：分離型プリフィリングは実験的機能として説明されており、それ自体でスループットが向上するわけではありません。実際のキューイングやリソース競合を測定した後にのみ使用してください。

SGLang

• チャット、エージェント、繰り返し使われるプレフィックス、マルチモーダルサービング、アダプターを多用するワークロードに適しています。
• 現行のドキュメントでは、RadixAttention、HiCache、PD および EPD の分離、Model Gateway、DP Router、推論モデル向けの構造化出力、LoRA サービングを重視しています。
• 主なボトルネックがカーネルの速度だけでなく、プロンプトの再利用、マルチモーダルエンコーダーへの負荷、またはアダプターの頻繁な切り替えである場合は、SGLang を優先してください。

TensorRT-LLM

• 移植性よりも、明示的な精度制御、KV キャッシュの再利用、低レイテンシの GPU 実行が重視される NVIDIA 専用デプロイに適しています。
• 現行のドキュメントでは、精度別のガイダンス、KV キャッシュの再利用、分離型サービング、trtllm-serve について説明しています。
• 精度に関する推奨事項は、ランタイムごとに適用されるものとして扱ってください。TensorRT-LLM のドキュメントでは、ハードウェアだけを基準とする一律のルールが示唆するよりも多くの INT8 および低ビットの経路が説明されています。

ルーターとコントロールプレーン

• 単一のマシンまたは単一のレプリカを超える規模になったら、トークン生成とリクエストの配置を分離します。
• キャッシュを考慮したルーティング、配置の固定、複数 LoRA に対するリクエストの振り分け、コントロールプレーンの選定には、routing-and-control-planes.md を使用してください。
• vLLM 中心のクラスター：vLLM Router または vLLM Production Stack から始めてください。
• Kubernetes とキャッシュを考慮したスケールアウト：llm-d を評価してください。
• SGLang 中心のクラスター：Model Gateway または DP Router のパターンを使用してください。
• マルチクラウドまたはオンプレミスのデータセンター環境：Dynamo（オープンソース）を検討してください。現在のプラットフォームおよびハードウェアのサポート状況は、リポジトリで確認してください。

量子化のルール

• 汎用的なハードウェア表ではなく、実際にデプロイするランタイム内で量子化方式を選択してください。
• vLLM では、まずランタイムネイティブの方式を優先してください。現在のドキュメントでは、FP8、INT4 W4A16、AWQ、GPTQ、INT8 W8A8 が公開されています。vLLM のドキュメントでは、INT8 W8A8 は Blackwell（コンピュートケイパビリティ >= 10.0）を明示的に除外しており、FP8 がドキュメントに記載された Blackwell 向けの代替方式です。
• TensorRT-LLM では、そのスタック向けにエンジンのドキュメントで説明されている精度モードから選択してください。FP8、INT8 SmoothQuant、重みのみの INT4 または INT8、GPTQ または AWQ、そして対応する Blackwell のワークフロー向けの NVFP4 が選択肢です。
• SGLang では、FP4、FP8、AWQ、GPTQ、量子化 KV キャッシュのいずれかを採用する前に、最新のドキュメントでモデル固有の量子化ツールの対応状況を確認してください。
• CPU またはエッジにデプロイする場合は、llama.cpp で GGUF を使用し、量子化レベル、スレッド数、n_gpu_layers を明示的に調整してください（ai-local-model-ops edge-cpu-optimization.md を参照）。
• デバイス上の NPU は CPU／エッジとは異なります。多くの NPU ランタイムでは、グループスケーリング形式ではなく、テンソルごとのスケールと静的な形状を持つ INT8／INT4 が求められます。references/quantization-patterns.md の NPU の行を参照してください。
• 量子化を変更した後は、ロールアウト前にレイテンシ、長文脈、構造化出力の検証を再実施してください。

専門家の判断：量子化が品質を損なう場合

• 品質へのリスクは、形式によって均等ではありません。重みのみの形式（AWQ、GPTQ、INT4 W4A16）は、一般的なチャット／指示追従の評価ではタスク精度を 1、2 ポイント以上低下させることはまれですが、長文脈の検索（干し草の山から針を探すようなタスク）、複数ステップの算術処理やコード、リソースの少ない言語では、影響が不釣り合いに大きくなります。汎用的な評価の平均だけでなく、これらを個別にテストしてください。
• W8A8 などのアクティベーション量子化方式には、重みのみの方式にはない外れ値のリスクがあります。少数の隠れ状態チャネルが誤差予算の大部分を占めることがあります（architecture-and-attention-serving.md §6 の SmoothQuant キャリブレーションを参照）。キャリブレーションセットが本番トラフィックと一致していない場合、W8A8 はベンチマークでは問題なく見えても、本番環境のロングテール入力では失敗することがあります。汎用コーパスではなく、本番環境を代表するサンプルでキャリブレーションしてください。
• KV キャッシュの量子化（FP8／INT8 KV）は、モデルのパラメーターではなく中間アクティベーションを圧縮するため、品質の面では通常、重みの量子化より安全です。ただし、投機的デコーディングや長文脈の RoPE スケーリングとの相互作用はランタイム固有です。それぞれを個別にではなく、組み合わせて検証してください。
• 構造化出力やツール呼び出しの妥当性は、汎用的な品質指標に変化が現れる前に、強い量子化で最初に低下することがよくあります。スキーマ適合率を後回しにせず、先行指標として扱ってください。
• 量子化の変更（重み形式 + KV のデータ型 + 投機的デコーディング）をひとつのロールアウトで重ねると、回帰の根本原因を特定することがほぼ不可能になります。設定をひとつ変更して測定し、その後に重ねてください。
• 品質の低下が全般的ではなく、コード、英語以外の言語、長い文書などの限られたタスク群でのみ起きる場合、解決策は通常、完全な精度への一括ロールバックではなく、混合精度方式またはレイヤーごとの方式です。特定のレイヤーや LM ヘッドを高い精度のまま保持できるか、ランタイムが対応しているかを確認してください。

専門家の判断：バッチ処理とレイテンシ

• 継続的バッチ処理では、GPUがメモリ帯域幅律速から計算律速のデコードへ移行するまでは、ほぼコストをかけずにスループットを向上できます（architecture-and-attention-serving.md §3 のルーフラインモデルを参照）。この移行点より前は、並行性を高めてもトークンあたりのレイテンシはほとんど変わりませんが、移行点を超えると、リクエストはメモリ帯域幅だけでなく計算リソースを待つようになるため、並行性を高めるほど TTFT とトークン間レイテンシが直接増加します。
• 実務上の目安：負荷の増加に伴い p50 レイテンシは横ばいのまま p95／p99 が上昇する場合、バッチスケジューラーが目標レイテンシの SLO で処理できる計算予算を超えて、同時シーケンスを受け入れています。まずカーネルを調整するのではなく、max_num_seqs／同時リクエスト数の上限を設定してください。
• レイテンシ予算を定めずにバッチ数や同時実行数の上限を引き上げてスループットを追求しないでください。スループットを最大化する運用点とレイテンシを最適化する運用点は、同じ曲線上の異なる点です。「最適な」バッチサイズはハードウェアを最大限に活用するための判断ではなく、SLO に基づく判断です。
• 1つのキューに短いプロンプトと長いプロンプトのトラフィックが混在することは、バッチ処理の不具合に見えて、実際にはスケジューリング／アドミッション制御の不足である p99 の崩壊の最も一般的な原因です。エンジンの設定ミスだと結論付ける前に、プロンプト長のクラスごとにグループ化するか、チャンク化プリフィルを追加してください。
• 関係者から、同時実行数の上限を設けずに「レイテンシを下げてスループットを上げたい」と求められた場合は、異議を唱えてください。計算律速への移行点を超えると、この2つの目標はトレードオフになります。境界をどこに置くかはエンジンではなく、SLO が決める必要があります。

専門家の判断：キャパシティプランニングのヒューリスティクス

• 生のパラメーター数だけを基準に GPU の台数を決めないでください。次の3つの数値を合わせて判断してください。目標精度での重みメモリ、目標最大コンテキスト長 × 最大同時実行数での KV キャッシュメモリ、そしてアクティベーションとフレームワークのオーバーヘッドに対する余裕（合計のおよそ10～20％。実際のランタイムの使用量を確認してください）。実際の同時実行数と長いコンテキストでは、通常、重みよりも先に KV キャッシュが不足します。
• 「必要な GPU 数」はピークスループットで割る問題ではなく、待ち行列の問題として扱ってください。平均ではなくテールに合わせて規模を決めるには、リトルの法則と想定されるバースト挙動（queueing-theory-applied.md を参照）を使ってください。そうしないと、平均負荷時の SLO は満たせても、バーストのたびに処理に失敗することになります。
• 正しく規模を決めた同居構成のベースラインは、推測で規模を決めた分離トポロジーに勝ります。まずシンプルなデプロイからキャパシティの数値を把握し、そのうえで処理フェーズの分離が実際に余裕を生み出すかどうかを判断してください。
• コールドスタートやアダプター読み込み時のイベント（オートスケーリングの遅延、LoRA のコールドロード、MoE の重み読み込み）に備え、明示的なキャパシティの余裕を確保してください。こうしたイベントを考慮しない定常状態の使用率目標では、実際の p99 の挙動に対してプロビジョニングが不足します。

運用ルール

実施すること

• 現実的な負荷のもとで、TTFT、ITL、エンドツーエンドレイテンシ、キューイング遅延、トークン毎秒、スキーマ有効率を測定します。
• API 境界でキューの深さと同時実行数に上限を設定します。
• プレフィックスの再利用やアダプターの局所性が重要になったら、ルーティングロジックを明示的にします。
• マルチモーダルエンコーダーの飽和は、デコードの飽和とは分けて扱います。
• リクエスト ID、モデル ID、精度、キャッシュヒットのデータ、過負荷の理由をログに記録します。

避けること

• ワークロードのプロファイルなしに、「最適な」エンジンについて一般論を述べないでください。
• 古いベンチマーク比率をアーキテクチャの根拠として使わないでください。
• 同居時の干渉を確認する前に、処理を分離しないでください。
• ロールバック計画と評価用データセットなしに、精度を切り替えないでください。
• プレフィックスやアダプターの局所性がコストの大部分を左右する場合に、汎用的なラウンドロビン方式を使わないでください。

容量昇格ゲート

定常負荷とバーストの両方で、実際のプロンプト長、出力長、プレフィックス再利用、アダプター、到着分布をベンチマークします。p50、p95、p99、キューによる拒否、再試行、持続可能な有効スループットを報告します。サービングの変更を次の段階に進めるのは、タスク品質のゲートを維持し、宣言されたすべてのSLOとリグレッション予算を満たし、制約となっている目標を改善した場合に限ります。制約となっていないパーセンタイルでの限定的なリグレッションは、事前に宣言されており、目標SLO、有効スループット、品質、拒否、再試行、復旧の各上限を満たしている場合は許容されます。実行には、コールドスタート、過負荷時の受付制御、ワーカー喪失、OOMからの復旧、ドレイン時の動作を含めます。トークン毎秒の生値は補足的な根拠として扱います。

既知の落とし穴

• 本番環境のプレフィックス再利用、出力長、スキーマ有効性の要件、同時実行のバーストに合わない合成プロンプトでベンチマークすること。
• 同一配置のベースラインでキュー上限、受付制御、配置ポリシーを引き締める前に、プリフィルまたはエンコーダーの分離を導入すること。
• tokens/secだけを最適化し、TTFT、構造化出力の有効性、または長文脈品質を悪化させること。
• エンジンやトークナイザースタックを入れ替える際に、停止条件、関数／ツールの契約、スキーマ制約付きデコードとの互換性を検証しないこと。
• 量子化を、品質や機能に関する注意点を伴うランタイム固有の機能ではなく、単なるハードウェアの選択として扱うこと。

よくあるアンチパターン

• ベンチマークの目立つ改善値が、異なるワークロード形状にもそのまま当てはまるかのように追い求めること。
• プレフィックス負荷の高いワークロードやマルチLoRAワークロードで、局所性がレイテンシとコストの大部分を左右するにもかかわらず、ラウンドロビンルーティングを使用すること。
• 受付制御ポリシーを設けずに、さまざまなプロンプト長のクラスを1つのキューに混在させ、その後ランタイムのせいにしてp95の崩壊を説明すること。
• スキーマ有効性テストスイート、長文脈の確認、明示的なロールバック期間を設けずに、新しい精度やカーネルの経路を展開すること。

正確性プロトコル（必須）

• 現行の一次情報源があり、条件も比較可能な場合を除き、ベンチマーク比率は特定のワークロードに限ったものとして扱います。
• ハードウェアや精度の変更を推奨する際は、ランタイムの前提を明示します。
• 実験的機能やベータ機能には、その旨を明記します。
• 公式ドキュメントとリリースノートがある場合は、二次的なブログより優先します。

ナビゲーション

主要なリファレンス

• サービングアーキテクチャ - エンジンの選択とサービングパターン
• ルーティングとコントロールプレーン - 配置、スティッキネス、キャッシュを考慮したルーティング
• 分離推論 - プリフィル、エンコーダー、デコードを分割する場合
• 量子化パターン - ランタイムごとの精度の選択、NVFP4 と MXFP4
• プルーニングとスパース性 - 非構造化／N:M／構造化プルーニング（SparseGPT、Wanda、Minitron）、2:4 のハードウェア上の実情、アクティベーションのスパース性、プルーニングと蒸留と小規模モデルのトレーニングの比較、ランタイムサポートの表
• KV キャッシュの最適化 - ページング、再利用、キャッシュのデータ型、再利用パターン
• アーキテクチャとアテンションのサービング - アテンションの各種方式（MHA/MQA/GQA/MLA の KV フットプリント）におけるサービング時の制約と回避策、SSM／ハイブリッドサービング、ルーフライン／演算強度、長文コンテキスト（StreamingLLM／スライディングウィンドウ／リング）、サービング時の RoPE スケーリングの落とし穴、SmoothQuant の外れ値、ドラフト不要の投機的デコード、FlashAttention のデコードとプリフィル
• MoE とエキスパート並列処理 - 並列化より先に精度を検討すること、EP の次数、all-to-all 通信量の閉形式、EPLB、ルーティングの健全性指標（MaxVio、負荷 CV、ルーティングエントロピー）、all-to-all のトポロジー
• 投機的デコードガイド - EAGLE、MTP、ドラフトモデル、Medusa のアルゴリズムファミリーとデプロイのチェックリスト
• 並列化パターン - TP、PP、DP、EP のトレードオフ
• GPU 最適化チェックリスト - ハードウェア適合性と本番環境でのチューニング
• GPU ノードとクラスターのチューニング - NUMA アフィニティ、THP、MPS と MIG、CUDA／ドライバーの互換性と PTX-JIT、NVLink ドメインを考慮した Kubernetes の割り当て、QoS とジッターの判断基準
• プロファイリングとキャパシティプランニング - ベンチマークの設計とサイジング
• ストリーミングパターン - SSE、WebSocket、クライアントストリーミング
• コスト最適化パターン - ルーティング、キャッシュ、バッチ処理、FinOps
• バッチ処理とスケジューリング - 継続的バッチ処理、チャンク化プリフィル、スケジューリングポリシーの負荷チューニング時に読み込む
• マルチモデルルーティング - カスケードルーティングの設計や、モデル間のキャッシュを考慮した配置時に読み込む
• インフラストラクチャのチューニング - ホストまたは GPU の設定をチューニングする際に読み込む。NUMA、THP、MPS／MIG、ドライバー、インターコネクト設定のコマンドレベルのチェックリスト
• 最適化戦略 - 複数の最適化手段を組み合わせる際に読み込む。量子化、バッチ処理、キャッシュを組み合わせるための横断的な判断フレームワーク
• LLM サービングのレジリエンスと HA - フェイルオーバー、マルチリージョン、縮退モードでのサービングを設計する際に読み込む。モデルサーバーのプローブ、ウォームアップ、KV を考慮したオートスケーリング信号、トークン単位の過負荷制御、KV／バージョンの調整。汎用 HA は qa-resilience、ロールアウトは ai-mlops を参照

応用基礎

診断対象のキャパシティまたは障害に関する問いに対してのみ応用基礎を読み込み、通常のモデルセットアップでは読み込まないでください。平均キュー待ち時間から p99 TTFT を保証することはできません。

• 数理最適化 — 実測キャパシティ、コスト目標、メモリ制約、レイテンシ制約を明示した、実質的なレプリカ／プール割り当ての場合に読み込みます。変数、目的関数、制約、実行可能性、ソルバー／証明書の限界を返してください。実測レイテンシの制約は負荷テストによる検証が必要です。連続 LP の証明書では、整数配置や本番環境の SLO を証明できません。単一の実行可能な選択肢で済む簡単なサイジングでは読み込みません。

• 応用待ち行列理論 - 連続バッチ処理、KV キャッシュのサイジング、アドミッション制御、分離アーキテクチャ、マルチテナント分離、トークン予算によるバックプレッシャー — foundations-queueing-theory の基礎概念（リトルの法則、M/M/c、Erlang-C、Kingman、P-K）に基づきます

• 応用信頼性理論 - カスケード接続されたモデル間での SLO 予算配分、ヘッジリクエスト、プロバイダーのフェイルオーバー、連鎖障害の防止、KV キャッシュ破損時のロールバック、スペキュレーティブデコーディングのロールバックセマンティクス — foundations-reliability-theory の基礎概念（MTBF/MTTR、エラーバジェット、FTA、冗長化の数学）に基づきます

テンプレート

• vLLM Configuration
• TensorRT-LLM Configuration
• DeepSpeed Inference
• LLM API Server
• High-Throughput Setup
• Disaggregated Serving
• GGUF Format
• AWQ Quantization
• GPTQ Quantization
• Batching Configuration
• Prefix Caching
• Latency & Throughput Testing
• Inference Performance Review Checklist

スクリプト

スクリプト	目的
scripts/latency_benchmark.py	OpenAI 互換の /v1/chat/completions エンドポイントに N 件の同時リクエストを送信し、p50/p95/p99 レイテンシとスループットを報告します。標準ライブラリのみを使用します（urllib + threading）。

データ

• data/sources.json - 現在の主要な情報源と基礎論文

関連スキル

• ai-llm
• ai-rag
• ai-mlops
• qa-observability
• ops-devops-platform
• huggingface-skills: プラグイン（外部）— inspect-ai と lighteval を使用した HF モデル評価

学習のループ

過去の判断や落とし穴が関連する場合は、learnings.consolidated.md があれば参照してください。必要な履歴を確認する場合、または利用可能な代替手段としてのみ learnings.md を使用してください。それ以外の場合は、どちらも参照しないでください。

適用後、記憶しておく価値のあるパターン、防止すべきミス、または意外だったドメイン知識に遭遇した場合は、agents-skills-feedback-loop/scripts/append_learning.py を使って learnings.md に日付付きの箇条書きを 1 つ追記してください。SKILL.md 自体は変更しないでください。