llm-serving-auto-benchmark

LLM サービングの自動ベンチマーク

概要

このスキルを使用すると、同じモデルとワークロードに対して、SGLang、vLLM、TensorRT-LLM、TokenSpeed などの LLM サービングフレームワークを比較できます。

設定駆動のワークフローを使用します。

• 起動時のみ使用する容量関連の選択肢は、各フレームワークの base_server_flags に設定します
• 検索するパラメーターは search_space に設定します
• すべてのフレームワークで同じデータセットシナリオを実行します
• search_space から上限付きの候補リストを生成し、ベースライン候補を最初に含めます
• 失敗した候補も結果ファイルに残します
• 結果を正規化してから、SLA を満たす候補の中で最良のものを選びます

モデル別の出発点には、同梱されている configs/cookbook-llm/ の設定を優先してください。これらはフレームワークに依存しない LLM サービングのクックブック用モデルセットを定義し、各項目を SGLang、vLLM、TensorRT-LLM、TokenSpeed の各フレームワーク固有のサーバーフラグに変換します。実際に実行する前に、これらの設定を検証してください。

python skills/llm-serving-auto-benchmark/scripts/validate_cookbook_configs.py \
  skills/llm-serving-auto-benchmark/configs/cookbook-llm/*.yaml

対象環境の --help ファイルを取得済みの場合は、--help-dir <artifact-help-dir> を追加してください。このチェックでは設定を読み込み、サーバーフラグ名を検証し、候補コマンドを出力するだけで、モデルサーバーは起動しません。

より広範囲をカバーできる場合は、ネイティブツールを優先してください。

• SGLang：現在の公開クックブックでは sglang serve を使用します。python -m sglang.launch_server も引き続き使用できます。python -m sglang.benchmark.serving を優先してください
• vLLM：サーバーパラメーターのスイープには vllm bench sweep serve を使用し、それ以外の場合は vllm serve と vllm bench serve を組み合わせます
• TensorRT-LLM：OpenAI 互換サーバーには trtllm-serve を使用し、TensorRT-LLM サービングベンチマーククライアント、または共通の OpenAI 互換ベンチマーククライアントを組み合わせます
• TokenSpeed：OpenAI 互換サーバーには tokenspeed serve を使用し、vllm bench serve --backend openai-chat、または他のフレームワークで使用しているものと同じ OpenAI 互換ベンチマーククライアントを組み合わせます

このスキルでは、TensorRT-LLM に適用される厳格な適用範囲のルールがあります。現在のサーバーは PyTorch 専用です。古いイメージでは pytorch を選択する必要があります。TensorRT-LLM のバックエンド選択は検索しないでください。リクエスト、設定、候補で trt、エンジンバックエンド、またはその他の PyTorch 以外の TensorRT-LLM サーバーバックエンドが指定された場合、このスキルではサポート対象外として候補を却下し、その理由を記録してください。このルールはベンチマーククライアントのバックエンドには適用されません。TensorRT-LLM のベンチマーククライアントでは、引き続き --backend openai や --backend openai-chat などの OpenAI 互換モードを使用します。

各フレームワークで主要なサービングパラメーターを調整してから、最適な候補を選んでください。

使用するフレームワークは呼び出し側が指定します。呼び出し側がフレームワークのリストを明示的に指定した場合は、有効化されたフレームワークのみをベンチマークしてください。クックブックの設定や履歴ドキュメントが存在するという理由だけで、TensorRT-LLM や TokenSpeed を暗黙に追加しないでください。除外したフレームワークは、サポート対象外ではなく、ユーザーによる除外として記録してください。

このスキル内のパラメーター一覧は、互換性を保証するものではありません。バージョンに左右される候補パラメーター群を示しています。実際に実行する前に、正確なフレームワークのバージョンまたは git commit を記録し、対象環境で --help を使用して、実際の CLI フラグ名を確認してください。

既定の検索スタイルはフレームワークに依存しません。まずはほぼ純粋な TP のベースラインから始め、影響の大きいランタイムパラメーターを少数スイープし、初回パスでは各フレームワークの候補を約 10 件までに抑えてください。既定ではメモリ使用率を検索しないでください。

ソースおよび実験に関する契約

現在のプロファイラー API、ブランチ固有の既定値、KV サイズのセマンティクスについては、2026-09-18 ソース契約を参照してください。PR を組み合わせる場合や、カーネル性能／精度の同等性を主張する場合は、paired-validation.mdを参照してください。このドキュメントでは、コードのみの A/B テストとデプロイのチューニング、実測による合格とシミュレーションによる合格、インタラクティビティと集約出力スループットを区別しています。候補のバックエンドが実際に動作したことを証明するため、計測後にプロファイリングを行ってください。

検証環境

このスキルは特定の環境を対象としません。以下のいずれかが利用可能であることを前提とし、それ以上は前提としません。

• Docker/Podman があり、対象フレームワークのイメージがプル済みのローカル GPU ホスト
• ssh <host> 経由で接続でき、フレームワークのイメージがコンテナ内ですでに実行されているリモート GPU ホスト
• 各フレームワーク用のビルド済みイメージに対して exec できる CI ランナー

このスキル独自のワークフローでは、特定のオペレーターホスト名を前提としないでください。特定のマシン用の具体的な SSH 接続設定、コンテナ名、ワークスペースのパス、HF トークンの受け渡しは、オペレーター側のホスト別スキルで管理します。このスキルで必要なのは、呼び出し元が要求されたフレームワークのインストール済みコンテナ内のシェルにアクセスできることだけです。

参照ファイルは任意であり、バージョンによって異なります。過去のフラグに関する注記は、あるイメージで得られた証拠として扱い、次回の実行でも互換性が保証されるものとは見なさないでください。

2026-05-01（H100）と2026-06-27（B200）に実施した過去のスモーク検証では、小規模なサービング／検索ワークロードを試しました。B200 イメージで利用できたのは SGLang のみで、vLLM／TRT-LLM／TokenSpeed の CLI が見つからなかったのは環境上の不足でした。これらの実行結果は、現在のフレームワーク横断の速度や精度の結果ではありません。9 月のソース更新ではオフラインのツールのみを実行し、新たな GPU の検証マトリクスは実施していません。

スキルの範囲

このスキルはプレイブックと設定・検証ツールチェーンであり、すぐに使えるオーケストレーターではありません。オペレーターは引き続きサーバーを起動し、ワークロードを実行して、候補ごとに正規化された JSONL の行を 1 行ずつ作成します。

​​scripts/ ディレクトリには、次の 2 つのツールのみが含まれています。

• validate_cookbook_configs.py：クックブックの YAML を読み込み、範囲を限定した候補サーバーコマンドを生成し、サーバーを起動せずにフラグ名を取得済みの --help スナップショットと照合します。
• compare_benchmark_results.py：候補ごとに正規化された JSONL を、出力仕様で説明されている Markdown と、任意の CSV の表に変換します。

configs/cookbook-llm/ 以下のクックブック設定は、検証ツールを通過する必要があります。より短い references/example-plan.yaml は、単発のランタイムプランのひな形であり、そのまま検証を通過することは想定されていません。SLA キー名の唯一の正しい参照元として、references/result-schema.md を使用してください。

必要な入力

長時間の実行を開始する前に、以下を収集してください。

• モデルとトークナイザーのパス、対象フレームワーク、GPU のモデル／台数、マルチノードの許可条件、精度、量子化の制約
• エンドポイントの形式、ワークロードのソース、データセットのシナリオ、SLA の目標、探索予算、アーティファクトの出力ディレクトリ
• バージョンマニフェスト：フレームワークのパッケージバージョンまたは Git コミット、コンテナ／Python 環境、--help のスナップショット、および各探索パラメーターがその特定の CLI で受け付けられたかどうか

実際の本番トラフィックを対象とする場合は、実際のリクエスト分布を使用してください。合成ワークロードは立ち上げや初回の比較には適していますが、本番環境での選択には不十分です。

各シナリオの入力／出力長の分布を、正規化された結果の各行に記録してください。これはプロファイラーへの引き継ぎ仕様の一部です。あるフレームワークの速度が遅く、追加調査で llm-torch-profiler-analysis を実行する場合、プロファイラのワークロードには遅かったベンチマークシナリオの長さを再利用してください。汎用のデフォルト値であるプリフィル 4090->1 とデコード 1->2048 にフォールバックしないでください。

バージョン依存のデプロイ確認

• 正確な調査対象リビジョンについては、ソースコントラクトを参照してください。インストール済みイメージの --help と実効環境変数の値を保持し、過去のリリースのデフォルト値をそのまま引き継がないでください。
• 調査対象のコミットでは、SGLang main と dsv4.1 で FlashInfer の fused finalize が異なります。数値のデフォルト値の変更は実験の一部であり、ノイズではありません。現在のカーネルルートは python/sglang/kernels/{aot,jit,ops} です。
• SGLang のネイティブな /generate と OpenAI 互換パスは、ベンチマークで別々のレーンです。フレームワークを比較するときは、共通のエンドポイント／クライアントを使用してください。ネイティブクライアントの結果は別途明記してください。
• アテンション／GEMM バックエンドのサポートを、GPU アーキテクチャとデータ型に合わせてください。「Blackwell」には異なる SM ターゲットが含まれます。B200／GB300／RTX 5090 は、相互に置き換え可能な単一のバックエンド契約ではありません。インストール済みコードでサポートを確認してください。
• vLLM の DBO は、サポート対象の all-to-all バックエンドに依存します。コンパイル時の融合は、プラットフォーム、グラフ分割、データ型ガードに依存します。融合リファレンスを参照してディスパッチを確認してください。
• 現在の TensorRT-LLM レーンでは trtllm-serve serve <model> を使用します。古いイメージでは --backend pytorch が必要な場合があります。サーバーバックエンドは OpenAI ベンチマーククライアントのバックエンドとは別です。選択した CLI で、モデル形式、KV メモリフラグの表記、ランダムデータセットのサンプリングオプションを確認してください。別のデータセットへ暗黙にフォールバックしないでください。
• TokenSpeed は tokenspeed serve <model> と共通の OpenAI 互換クライアントを使用します。TP／アテンション TP／MoE TP／EP とメモリの各フラグは、それぞれ個別に解釈する必要があります。同じ名前の SGLang／vLLM オプションが同等であるとは限りません。
• すべての最大コンテキスト候補は、ベースラインだけでなく、全シナリオにおける max(input_len + output_len) をカバーする必要があります。クックブックバリデーターでこれを確認します。
• 計測後にプロファイリングしてください。シミュレートした受け入れ率曲線を固定して使う場合は、その旨を明記してください。モデル精度のテストでは、実際の受け入れモードで再起動してください。エンドツーエンドのスコアが偶然一致したという理由で、未使用の置換カーネルを採用しないでください。

シークレットの取り扱い

• HF_TOKEN、HUGGINGFACE_HUB_TOKEN、上流の API キーを、保存する成果物に決して出力しないでください。コンテナーの -e VAR を通じて渡し（右辺は引用符で囲まず、ホストの値を引き継ぎます）、結果 JSONL に書き込まれる server_command と benchmark_command の各フィールドには含めないでください。
• フレームワークが起動時に argv 全体を出力する場合は、ログをサニタイズするか、成果物をアップロードする前にトークン形式の文字列を伏せてください。

公平性のルール

ベンチマーク全体を通して、次のルールに従ってください。

• すべてのフレームワークを、同じ GPU の種類と数、モデルの重み、トークナイザー、精度、量子化ポリシー、プロンプト分布、出力長の目標、サンプリング設定で実行してください。
• フレームワークのバージョン、git コミット、コンテナーイメージ、CUDA／NCCL のバージョン、GPU ドライバー、可視 GPU ID、起動コマンド、ベンチマークコマンドを記録してください。
• 計測前にサーバーをウォームアップしてください。キャッシュの影響によって比較に偏りが生じる場合は、候補構成の間で再起動するか、状態をクリアしてください。
• 定常状態の固定 QPS 実行と、バーストスループット実行は分けて比較してください。
• 失敗した候補も、失敗理由とともに最終結果に含めてください。
• 生のスループットと SLA を満たすスループットの両方を報告してください。最速でも失敗する候補は、最適なデプロイコマンドではありません。

ワークフロー

1. 事前確認

検索を開始する前に、SGLang と、比較対象として指定されたすべてのフレームワークを確認します。 指定されたフレームワークのコマンドだけを実行します。

sglang serve --help
python -m sglang.launch_server --help
python -m sglang.benchmark.serving --help
vllm serve --help
vllm serve --help=all
vllm bench serve --help
vllm bench serve --help=all
vllm bench sweep serve --help=all
trtllm-serve serve --help
python -m tensorrt_llm.serve.scripts.benchmark_serving --help
tokenspeed serve --help
vllm bench serve --help

対象環境でのフレームワーク固有の --help 出力を、信頼できる情報源として使用します。古いメモに記載されているという理由だけで、古い起動フラグを使い続けないでください。

vLLM 0.19 以降では、ヘルプがグループ化されています。通常の vllm serve --help にはグループのみが表示されるため、検索用のオプションがあるかを判断する前に --help=all を保存してください。

これらの --help 出力は、実行アーティファクトのディレクトリに保存します。記載されている検索用オプションが現在の CLI にない場合は、ベンチマークの実行前にそのオプションを削除するか、別のオプションに置き換えてください。不明なフラグを黙って渡してはいけません。

trtllm-serve serve --help の出力を記録してください。現在の main は PyTorch 専用のため、非推奨のバックエンドオプションは省略してください。複数のバックエンドが記載されている古いイメージでは、--backend pytorch を選択します。

TokenSpeed では、サーバーとベンチマークの両方のエントリーポイントを確認してください。インストールによっては、バイナリが ts という名前にエイリアスされている場合があります。server_command には、実際に使用したバイナリを正確に記録してください。

各フレームワークについて、最小構成のサーバーを起動し、/v1/models またはネイティブのモデル情報エンドポイントを確認し、ストリーミングリクエストを1件送信してから、リクエスト数が5件以上の小規模なベンチマークを1回実行します。その後、起動コマンド、ベンチマークコマンド、サーバーログ、ベンチマーク出力を保存してください。

GPU を使用するスモークテストの前に、nvidia-smi で指定された GPU ID を直接確認してください。指定された GPU がすでに使用中の場合は、停止してその事実を記録してください。性能比較のために、GPU 数を黙って変更してはいけません。結果がスループットの公平な比較ではなく、フロー確認であると明確に表示する場合に限り、GPU 1基で規模を縮小したスモークテストを実行できます。

対象環境がコンテナ経由で動作する場合は、references/container-runbook.md に従い、イメージタグ、プルコマンド、起動・ベンチマークのログ、クリーンアップコマンドを保存してください。

2. ワークロードの正規化

すべてのフレームワークで、共通のワークロードを使用します。推奨する JSONL 行の形式は次のとおりです。

{"prompt": [{"role": "user", "content": "Summarize this text."}], "output_len": 256}
{"prompt": "Write a short explanation of CUDA graphs.", "output_len": 128}

省略可能なフィールド：

{
  "prompt": [{"role": "user", "content": "Use low temperature."}],
  "output_len": 256,
  "extra_request_body": {"temperature": 0.0, "top_p": 0.95},
  "metadata": {"source": "prod-sample"}
}

ユーザーデータを変換する場合：

• 変換前に、少なくとも3行を確認します
• リクエスト単位のサンプリングオプションは extra_request_body に保持します
• 最終的なアシスタントの回答が生成対象の場合、その回答をプロンプトに含めないでください
• 選択したエンドポイント形式を指定されたすべてのフレームワークがサポートする場合に限り、マルチモーダルまたはツール呼び出しのペイロードを保持します

合成ワークロードでの起動確認には、付属の2シナリオ形式を使用します。

dataset:
  kind: random
  num_prompts: 80
  scenario_names: [chat, summarization]
  input_len: [1000, 8000]
  output_len: [1000, 1000]

対応する各 input_len / output_len の組み合わせが、1つのシナリオです。ユーザーから要求されていない限り、直積を取らないでください。 各シナリオに名前を付け、対応する組み合わせをアーティファクトに記録してください。カスタムデータセットでは、代表的な input_len と output_len のバケットを算出または記録します。可能であれば少なくとも p50 と p95 を記録し、後続のプロファイラー実行で、無関係な合成データの形状ではなく、低速なバケットに合わせられるようにしてください。

シーケンス長の上限を調べる前に、データセット内の input_len + output_len の最大値を計算してください。すべてのシナリオを実行する候補では、SGLang の context_length、vLLM の max_model_len、TensorRT-LLM の max_seq_len、TokenSpeed の max_model_len を、その値以上に設定する必要があります。

3. 検索ティアを選ぶ

ユーザーの質問に答えられる範囲で、最も小さいティアを使用します。

• Tier 1：スモークテストと基本確認。ベースラインを1つと、影響の大きい設定をいくつか試します。
• Tier 2：デフォルト。可能性の高いサーバー設定を対象に、範囲を限定してスイープします。
• Tier 3：網羅的な検索。検索空間がすでに絞り込まれており、ユーザーが長時間の実行を許容する場合に限ります。

デフォルトの予算：

• デフォルトのフレームワーク横断比較では num_prompts: 80 を使用します。スモークテストやフロー確認では、シナリオごとに num_prompts: 20 でも問題ありません。その場合は、アーティファクト内でその旨を明記してください（性能結果として扱わないでください）。
• 最初の有用な試行では search.max_candidates_per_framework: 10 を使用します。
• 候補の生成：まずベースラインを設定し、次に search_space から範囲を限定した積集合、または順序付きの候補リストを使用します。
• ユーザーから追加の指定がない限り、QPS の検索ラウンドは最大5回とします。
• あるフレームワークの候補がすべて明らかに OOM になる、または基本的なヘルスチェックに失敗した場合は、早めに終了します。

ユーザーが容量またはメモリの調査を特に希望しない限り、以下は base_server_flags に固定します。

• SGLang の mem_fraction_static
• SGLang の schedule_policy
• vLLM の gpu_memory_utilization
• TensorRT-LLM の kv_cache_free_gpu_memory_fraction
• TokenSpeed の gpu_memory_utilization

これらは実際の設定項目ですが、検索範囲が急速に広がり、サービングの比較がメモリ制限の調査になってしまうこともよくあります。

4. SGLang を調整する

各 SGLang 候補は手動で起動します。自動ベンチマークモジュールは #31941 で削除されました。

現在のサービングクライアントでベンチマークを実行します。

python -m sglang.benchmark.serving \
  --backend sglang \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 256 \
  --num-prompts 80 \
  --request-rate 8 \
  --output-file /path/to/sglang/results.json \
  --output-details

バージョン依存の SGLang 設定項目のファミリーを確認します。

• tp_size、pp_size、dp_size（レプリカ）、attn_dp_size、ep_size
• attention_backend、prefill_attention_backend、decode_attention_backend
• sampling_backend
• max_running_requests、max_queued_requests
• chunked_prefill_size、prefill_max_requests、max_prefill_tokens
• max_total_tokens、page_size
• フェーズ固有の CUDA グラフ設定
• 投機的デコードまたは EAGLE の設定は、非投機的なベースラインを調整してからにします。

デフォルトの試行では、共有クックブックの設定スタイルに合わせて、mem_fraction_static と schedule_policy を固定します。

スモークテストをすばやく実行する場合、目的がフレームワークの動作フローの確認のみであれば、--cuda-graph-backend-decode disabled と --cuda-graph-backend-prefill disabled を使用します。これらのフラグをアーティファクトに記録してください。ユーザーが Eager モードのサービング調整を依頼していない限り、このスモークテスト用の設定を性能面での最良候補には引き継がないでください。

5. vLLM を調整する

利用可能な場合は、vLLM のスイープランナーを使用します。

vllm bench sweep serve \
  --serve-cmd 'vllm serve <model> --port 8000' \
  --bench-cmd 'vllm bench serve --backend vllm --model <model> --port 8000 --dataset-name random --num-prompts 80' \
  --serve-params /path/to/vllm_serve_params.json \
  --bench-params /path/to/vllm_bench_params.json \
  --output-dir /path/to/vllm_results

スイープ機能が利用できない場合は、候補ごとに vllm serve を実行し、vllm bench serve で測定します。

バージョン依存の vLLM 設定項目のファミリーを確認します。

• テンソル、パイプライン、データ、デコードコンテキスト、エキスパートの並列化
• gpu_memory_utilization
• max_num_seqs
• max_num_batched_tokens
• max_model_len
• enable_chunked_prefill、long_prefill_token_threshold、DBO のしきい値
• KV キャッシュのデータ型とブロックサイズ
• データ型と量子化の設定
• 関連する場合は、CUDA グラフのキャプチャサイズまたは Eager モードの切り替え設定
• プレフィックスキャッシュと投機的デコードの設定は、ワークロードでこれらの機能が必要な場合に限ります。

vLLM では、ベースラインコマンドを1つ実行するだけでなく、通常のスイープを行ってください。ネイティブコマンドのテンプレートとフレームワーク横断の設定項目のファミリーについては、references/framework-reference.md を参照してください。実行前に、対象イメージの --help で各フラグを確認してください。

デフォルトの試行では、ベースラインに gpu_memory_utilization を含めます。モデルの実行可能性や、容量とスループットのトレードオフが明示的な質問の場合に限り、この設定を検索対象にします。

対象の vLLM 環境が DBO と all2all バックエンド用にすでに設定されている場合を除き、デフォルトの試行では DBO と all2all バックエンドの設定を含めないでください。これらは実際の調整項目ですが、必要な all2all バックエンドが利用できないと、候補の起動に失敗することがあります。検索に long_prefill_token_threshold を追加する前に、実際の vllm serve --help=all で利用可能であることを確認してください。

6. TensorRT-LLM を調整する

対象環境が対応している場合は、サーバーのエントリーポイントとして trtllm-serve serve を使用します。

trtllm-serve serve <model> \
  --tp_size <tp> \
  --pp_size <pp> \
  --kv_cache_free_gpu_memory_fraction 0.75 \
  --host 0.0.0.0 \
  --port 8000

次に、TensorRT-LLM のサービングベンチマーククライアント、または他のフレームワークで使用したものと同じ OpenAI 互換クライアントで、OpenAI 互換エンドポイントをベンチマークします。

過去の TensorRT-LLM 1.0.0 検証イメージでは、--download-path または --random-ids のいずれかを渡さない限り、benchmark_serving --dataset-name random は ShareGPT からサンプルを取得していました。合成データを使った高速なスモークテストには --random-ids を渡し、その後、対象の TensorRT-LLM イメージでの動作を確認してください。

TensorRT-LLM のフラグ名は、特にバージョンによる違いが大きいため注意が必要です。過去の検証済み TensorRT-LLM 1.0.0 イメージでは、trtllm-serve serve が受け付ける KV キャッシュメモリーのフラグは --free_gpu_memory_fraction ではなく --kv_cache_free_gpu_memory_fraction でした。現在の mainline は、2026-10-05 に bb367fc8c1adf6e2c28c88cb1a8b46e1742a9d60 で再確認済みです。GPU ターゲットで探索を実行する前に、必ず trtllm-serve serve --help でフラグを確認してください。

このスキルにおける TensorRT-LLM のバックエンドポリシーは次のとおりです。

• 非推奨のバックエンドオプションを付けずに、PyTorch 専用の現行サーバーを起動する
• backend: pytorch は、古いイメージとの互換性設定としてのみ使用する
• backend を search_space に追加しない
• trt、エンジンベースのサービング、その他の PyTorch 以外の TensorRT-LLM サーバーバックエンドは、このスキルではサポート対象外として扱う

バージョンによる違いが大きいため、確認が必要な TensorRT-LLM のノブ群は次のとおりです。

• tp_size、pp_size、ep_size
• 最大バッチサイズ、最大シーケンス長、最大トークン数、KV キャッシュの予算
• インフライトバッチ処理とスケジューラーのオプション
• PyTorch バックエンドで trtllm-serve が使用する、追加の LLM API オプション YAML

trtllm-serve serve CLI が直接公開するランタイムノブは、SGLang や vLLM より少なくなっています。直接指定できるフラグがある場合はそれを使用し、トップレベルの CLI フラグではない PyTorch バックエンドの設定には --extra_llm_api_options を使用します。サポート対象外のバックエンドやエンジンの要求は、変換せずに失敗テーブルに残してください。

デフォルトのパスでは、ベースラインに kv_cache_free_gpu_memory_fraction を残してください。まず max_batch_size、max_num_tokens、max_seq_len、および検証済みの PyTorch バックエンド設定オプションを探索します。サーバーバックエンドは pytorch に固定します。

7. TokenSpeed を調整する

TokenSpeed は、特にエージェント型またはマルチターンのワークロードで、SGLang 以外のベースラインとして最も有力になる可能性がある場合に、主要な比較対象フレームワークとして使用します。

tokenspeed serve <model> \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size <tp> \
  --gpu-memory-utilization 0.90 \
  --max-model-len 12288 \
  --max-num-seqs 64 \
  --chunked-prefill-size 8192 \
  --kv-cache-dtype auto \
  --trust-remote-code

共通の OpenAI 互換ベンチマーククライアントを使ってベンチマークする方法：

vllm bench serve --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --model <model> \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 256 \
  --num-prompts 80

または、他のフレームワークで使用したものと同じ OpenAI 互換クライアントを使用します。TokenSpeed が有力候補で、プロファイラーへの引き継ぎが必要になる場合は、制御サーバーで同じリクエスト形状の torch プロファイリングを開始できます（CONTROL_PORT のデフォルトはサービングポート + 1 です。--control-port で変更できます）。

curl -X POST "http://127.0.0.1:${CONTROL_PORT}/start_profile" \
  -H 'Content-Type: application/json' \
  -d '{"output_dir":"/artifacts/tokenspeed_profile","num_steps":5,"activities":["CPU","GPU"],"with_stack":true,"profile_id":"ts-bench"}'
# Drive the same workload with the common client, then POST /stop_profile if needed.

output_dir が指定されていない場合、TokenSpeed は TOKENSPEED_PROFILER_DIR の下に出力します。デフォルトは /tmp です。

大規模な MoE またはエージェント型のチェックポイントでは、次の TokenSpeed ノブを探索に追加する前に検証してください。

• tensor_parallel_size、attn_tp_size、moe_tp_size、enable_expert_parallel
• attention_backend、drafter_attention_backend、moe_backend、draft_moe_backend
• max_num_seqs、chunked_prefill_size、max_prefill_tokens、max_total_tokens
• kv_cache_dtype、quantization、プレフィックスキャッシュの制御
• speculative_algorithm、speculative_num_steps、speculative_num_draft_tokens などの投機的デコーディングのフラグ
• comm_fusion_max_num_tokens、enable_allreduce_fusion、および関連する通信フュージョンのフラグ。ただし、対象イメージでスモークテストを実行してから使用してください

同じモデルファミリーに対応する TokenSpeed ネイティブのエージェント型設定がある場合は、共通のフレームワーク横断シナリオを置き換えるのではなく、追加のワークロードレーンとして実行してください。結果の行は同じスキーマに正規化し、workload.kind に応じてマークしてください。

デフォルトのパスでは gpu_memory_utilization を固定してください。ユーザーが明示的に容量調査を希望する場合に限り、これを探索対象にします。

8. 結果を正規化する

references/result-schema.md のスキーマに従って、候補ごとに 1 行の JSONL を記述します。その後、次を実行します。

python skills/llm-serving-auto-benchmark/scripts/compare_benchmark_results.py \
  --input /path/to/candidates.jsonl \
  --output /path/to/summary.md

候補は次の順序で順位付けします。

1. SLA を満たしている
2. リクエストスループットまたはグッドプットが最も高い
3. 出力トークンスループットが最も高い
4. p50 TTFT が低い
5. p50 TPOT/ITL が低い
6. パフォーマンスが同程度の場合は、GPU 数が少ない、またはデプロイがシンプルである

SLA の判定基準自体は変更しないでください。クックブックの設定と正規化された結果スキーマでは、TTFT SLA は引き続き max_p50_ttft_ms を使用し、TPOT SLA は引き続き max_p50_tpot_ms を使用します。変更されるのは、候補間の既定の比較順序を p50 TTFT、p50 TPOT にする点だけです。

出力仕様

ワークロード／SLA、ハードウェアとフレームワークのバージョン、フレームワーク／シナリオごとに最適なデプロイコマンドをまとめた表、フレームワーク横断の比較表を 1 つ、採用候補の正確な起動コマンドとベンチマークコマンド、ならびにワークロード、未加工／正規化済みの結果、CSV または Markdown のサマリー、サーバーログの各成果物のパスを含む簡潔なレポートを返します。

SGLang が勝者ではない場合は、遅い SGLang のシナリオ名と、llm-torch-profiler-analysis に渡す正確な入力／出力長またはパーセンタイル区分を記載したプロファイラへの引き継ぎメモを含めます。

候補が投機的デコーディング、プレフィックスキャッシュ、オフロード、またはエージェント型ワークロードを使用する場合は、受け入れ長、スケジューラー前の時間、キャッシュヒット率、メモリー常駐率の任意の正規化フィールドを記録します。サマリースクリプトは、これらの列がある場合に表示します。

失敗した候補や除外した候補について、理由とともに記載します。この表は選定されなかった、試行済みの設定を記録したものです。つまり、失敗した候補、ポリシーによりスキップされた候補、または処理は完了したものの SLA を満たさなかった候補を含めます。合成ワークロード、公平な探索の未完了、またはフレームワーク固有のパラメーター置換に関する注意事項も追加します。

コマンドテンプレート、ソースリンク、またはノブファミリーの対応関係が必要な場合は、references/framework-reference.md を使用します。フレームワーク横断の実行計画を作成する際は、references/example-plan.yaml を出発点として使用します。

インターフェースの監査 — 2026-10-05

SGLang の標準クライアントは python -m sglang.benchmark.serving です。bench_serving は非推奨の互換ラッパーで、自動ベンチマークモジュールは削除されています（#31941）。対象イメージから sglang serve --help とクライアントのヘルプを取得してください。現在のイメージには CUDA 13 と互換性のあるホストドライバーが 必要です（#38404）。最後の CUDA 12 タグは v0.5.19-cu129 でした。MiniMax-M3 には lmsysorg/sglang:dev-minimax-m3 が必要です。 Qwen3.8-Flash-Next の H200/B200 には lmsysorg/sglang:qwen38flashnext が必要です。

現在の SGLang では、フェーズ別のグラフフラグを使用します（#38375）。 --cuda-graph-backend-decode / --cuda-graph-backend-prefill が受け付ける値は full、breakable、tc_piecewise、disabled です。キャプチャサイズには --cuda-graph-bs-decode / --cuda-graph-bs-prefill と --cuda-graph-max-bs-decode / --cuda-graph-max-bs-prefill を使用します。スモークテストの eager モードは --cuda-graph-backend-decode disabled --cuda-graph-backend-prefill disabled です。 古いサイズのエイリアスは削除され、--disable-cuda-graph は非推奨になりました。 main では、--attn-dp-size が旧式の attention-DP ペアに置き換わっています（#41818）。 --dp-size はレプリカ DP のままです。v0.5.21 はこの表記より前のバージョンのため、イメージのヘルプを確認してください。 --attn-cp-size、--dcp-size、--moe-dp-size および --ep エイリアスも確認してください。

#19028 以降、bb367fc8 の TensorRT-LLM は PyTorch のみです。--backend pytorch は互換性のための非推奨オプションです。現在の main では省略し、ヘルプに他のバックエンドが記載されている古いイメージでのみ 指定してください。--free_gpu_memory_fraction（主オプション）と --kv_cache_free_gpu_memory_fraction（エイリアス）の両方が機能します。1.0.0 イメージに関する注記は過去のものです。--cluster_size は非推奨で、 サポートされていません。--set PATH=YAML_VALUE を使うと、--config の後に設定パスを上書きできます。

TokenSpeed のベンチマークサブコマンドは #1236 で削除されました。ワークロードをそろえるには、共通クライアント vllm bench serve --backend openai-chat を使用してください。ts は引き続き tokenspeed のエイリアスです。プレフィックスキャッシュを無効にするオプションは --disable-prefix-caching です。エンジンフラグの --api-key、--enable-cache-report、 --skip-server-warmup、--warmups は削除されました。--tool-call-parser と --chat-template はゲートウェイのフラグです。並列処理を調整する際は、 --pipeline-parallel-size、--prefill-context-parallel-size、 --decode-context-parallel-size、--lm-head-tp-size、--dense-gemm-backend を確認してください。

vLLM の --block-size 16 を強制しないでください。推奨される MLA/DSA バックエンドが除外されます。 バックエンドにブロックサイズを選択させ、起動時のディスパッチ行を記録してください。 比較する行では、同じクライアントバージョンを使用してください。vLLM #55508 ではチャットの TTFT/E2E のチャンク計上方法が変更され、SGLang #39889 ではテンプレートのトークンを含むサーバーのプロンプトトークン使用量が報告されます。 クライアントのキュー待ち時間を計測する場合は、別途記録してください。 SGLang のデフォルトスケジューラーは FCFS です。以前の cookbook の YAML では、ランダムなプロンプトに対する LPM が強制されなくなっています。 デフォルトで有効なブール値を False にするには、明示的な無効化フラグが必要です。また、ベースラインと同じ設定が重複して適用されないようにしてください。 YAML バリデーターには Python 3.10 以降が必要です。

根拠となるソース：SGLang のグラフフラグ、 SGLang の並列処理フラグ、 vLLM のバックエンドのサイズ設定、 TensorRT-LLM の serve、 TokenSpeed CLI。