TT Lab
ブログ

한국어 English 日本語 中文

はじめる
ブログ

ブログ

vLLM と SGLang の比較、そしてベンチマークを正しく行う方法

2026-10-07 · 40 分で読めます · #vLLM#SGLang#RadixAttention#벤치마크#용량 계획#토스 ML/AI Infra 준비

ステータス: ドラフト（2026-10-07更新）、一部実測値を反映。 公式ドキュメントで確認した記述をベースに執筆しており、直接測定した実測値は第4章の実験を引用した部分と、第5章の終わりの「実測：同じモデル、同じGPUでのvLLM対SGLang」（小さなモデル1つ、GPU1枚）のみです。大きなモデル、マルチGPU、異なるワークロードでの比較は未測定です。 記事の終わりの「確認したバージョンと日付」と「確認できなかったこと」を先にお読みください。 執筆ルール：実測データを基本とし、測定できなかったものは「未測定」と表記します。

目次

2つのエンジンを選ぶことは好みではなく、ワークロードの形状と測定の問題です。この記事では、vLLMとSGLangがプリフィックスキャッシュをどのように異なる設計にしたか、現在はどこまで収束しているか、ワークロードごとに何を真っ先に疑うべきかを整理し、その判断を裏付けるベンチマークをどのように設計し、読み解くかを扱います。筆者はSGLangを直接運用または測定したことがありません。2つのエンジンの優劣に関する独自の実測値はなく、公式ドキュメント、ソースコード、論文、そして筆者の実験環境でvLLMを用いて測定した経験のみを根拠に執筆します。

この記事を読んだ後に面接で説明できるようになること

  1. ブロックハッシュチェーン（vLLM）とラディックスツリー（SGLang）の違い、および現在は機能が大きく重複している点を区別して説明できること。
  2. プリフィックスの再利用、構造化出力、モデルサポートなどのワークロード形状別の選択基準とその限界を説明できること。
  3. オープンループ負荷、ポアソン到着、プリフィックスキャッシュの罠、パーセンタイルを含むベンチマークの設計と、結果をGPU台数に換算する手順を説明できること。

1. 設計哲学

vLLMはPagedAttentionの論文（SOSP 2023）に端を発する汎用高スループットエンジンです。V1構造では、APIサーバープロセスがZMQを介してエンジンコアプロセス（スケジューラーとKVマネージャー）と通信し、エンジンコアはGPUごとに1つ存在するワーカーを管理します（公式アーキテクチャドキュメント）。v0.29.0以降、Model Runner V2がデフォルトです（リリースノート、一部のROCmモデルなどは例外）。

SGLangの論文（arXiv 2312.07104）は、エンジンではなくLLMプログラムを効率的に実行するシステムとして始まります。フロントエンド言語は生成（gen, select）と並列制御（fork, join）プリミティブを提供し、ランタイムには2つの手法があります。RadixAttentionは、リクエストが終了してもプロンプトと生成結果のKVをラディックスツリーにLRUとして保持し、一致するプリフィックスが長いリクエストを優先的に処理するキャッシュ認識型スケジューリングを使用します。圧縮有限状態機械は、制約によって決定される複数のトークンを1ステップでデコードします。論文では、スループットが最大6.4倍向上し、遅延が最大3.7倍削減されると主張されています。条件は主にA10G 24GB（一部A100）、Llama-7B/70B、Mixtral-8x7Bなどで、エージェント、JSONデコディング、RAG、マルチターンなどのプリフィックス再利用が大きいワークロードであり、比較対象となったvLLMはv0.2.5です。論文では、その時点の最新のvLLMにRadixAttentionが実験的機能として部分的に統合されていたため、以前のバージョンを使用したと脚注で述べています。現在のv0.30.0と比較した数値ではありません。

vLLM: 블록 해시 사슬 (블록 16 토큰)       SGLang: 라딕스 트리 (page-size 기본 1)
요청 A  [B0]-[B1]-[B2]                    root
요청 B  [B0]-[B1]-[B3]                     └ "시스템 프롬프트 ..." (공통 노드 하나)
해시 = H(부모 해시, 블록 토큰, 추가 키)           ├ "질문 A ..." -> 생성 결과
해시 맵 조회, 빈 블록 큐에서 LRU 방출              └ "질문 B ..."
                                          리프부터 방출(기본 lru), 사용 중 노드는 잠김

SGLangのドキュメントの --page-size のデフォルト値が1であるため、プリフィックスの一致がトークン単位で可能であるというのはドキュメントのデフォルト値から推測したものであり、vLLMは埋まったブロック（16トークン）単位でのみヒットします（第4章）。最近のSGLangのリリースノートには、v0.5.19で統合ラディックスツリーがすべての構成のデフォルトになり、v0.5.21でプリフィックスキャッシュがRustコアのデフォルト（サポートしていない構成はPythonにフォールバック）になり、古い実装（SWARadixCache, MambaRadixCache, HiRadixCache）が削除されたと記載されています。同時期に、vLLMはプリフィックスキャッシュをデフォルトで有効にし、構造化出力（xgrammar、guidance）をサポートしています。したがって、哲学の違いがそのまま機能の有無の違いになるわけではありません。

2. 機能比較表

ドキュメントに項目が存在することを意味し、成熟度や性能の優劣を示すものではありません。基準はvLLM v0.30.0のドキュメントとSGLang v0.5.21のドキュメントです。

領域 vLLM SGLang
プリフィックスキャッシュ ブロックハッシュ、LRU、デフォルトで有効。容量拡張は OffloadingConnector、LMCache ラディックスツリー、 --radix-eviction-policy lru、lfu、slru、priority、tlru。階層キャッシュ HiCache
リクエストの順序 --scheduling-policy fcfs（デフォルト）、priority --schedule-policy fcfs（デフォルト）、lpm（最長プリフィックス優先）、dfs-weightなど
推測デコーディング EAGLE、MTP、ドラフトモデル、n-gram、suffixなど EAGLE-2/3、MTP、独立ドラフトモデル、NGRAM
量子化 AWQ、GPTQ、FP8、INT8、bitsandbytes、ModelOpt、GGUF、KVキャッシュFP8 --quantization awq、fp8、gptq、modelopt_fp4など、 --kv-cache-dtype fp8_e4m3、fp8_e5m2
LoRA --enable-lora --lora-modules --enable-lora、1つのバッチ内で複数のアダプター（S-LoRA、Punica手法）
マルチモーダル 画像、動画、音声入力 ビジョンAPIドキュメント、マルチモーダルモデル
構造化出力 xgrammar、guidance（structured_outputs) xgrammar（デフォルト）、outlines、llguidance。JSONスキーマ、正規表現、EBNF
MoE --enable-expert-parallel （EP = TP × DP） --ep-size, --attn-dp-size
分散 TP、PP、DP。PD分離はドキュメントにexperimentalと表記 TP、DP、EP。SGLang Model Gateway（ルーター）、PD分離ドキュメント
モデルフォールバック Transformersモデリングバックエンド --model-impl transformers

vLLMのドキュメントでは、PD（プレフィル、デコード）の分離はスループットを向上させるものではないと記載されており、目的はTTFTとITLの個別調整とテールレイテンシの制御に限定されています。

3. 選択基準：ワークロードの形状別

ワークロード まず確認すべき点
プリフィックスがほとんど重複しない単発のリクエスト プリフィックスキャッシュのメリットがないため、エンジンの違いはカーネルとスケジューラーのオーバーヘッドのみです。実際に測定する必要があります。
長い共通システムプロンプト、RAGドキュメントの繰り返し プリフィックスキャッシュが鍵となります。どちらのエンジンもサポートしており、容量が不足している場合はオフローディング（vLLM）またはHiCache（SGLang）を検討します。第4章の実験がこのケースに該当します。
エージェント、マルチターン（ターンごとに履歴が増加する） 直前のターンのKV再利用が鍵となります。SGLangが設計の中心に据えており、ドキュメントにはセッション認識型ラディックスキャッシュと agentic-trace のベンチマークデータセットがあります。vLLMでもプリフィックスキャッシュで可能ですが、同じワークロードでの優劣は測定していません。
構造化出力が大部分を占める 両方のエンジンが同じxgrammarをサポートしているため、エンジンよりもスキーマの複雑さとバックエンドを確認します。
最新の大規模MoEモデルを素早く試したい モデルごとのクックブックや検証済みの実行レシピがあるかを確認します。
Kubernetes上での運用 vLLMのドキュメントにはllm-d、production-stack、KServe、KubeRay、AIBrix、Dynamoの統合項目があり、SGLangにはModel GatewayとKubernetes PDデプロイのドキュメントがあります。

モデルのサポート速度は定量的に確認できていません。リリースノートから見えた事例は以下の通りです。Qwen3.8-Flash-NextとHy4-previewは、vLLM v0.29.0（2026-09-09）の方がSGLang v0.5.20（09-18）よりも先に追加され、GLM-5.3-Flash、K2-Horizon、Nanbeige4.2は、SGLang v0.5.20の方がvLLM v0.30.0（09-22）よりも先でした。リリースに含まれたタイミングに過ぎず、day-0サポートであるかどうかも不明なため、どちらが速いかの根拠にはなりません。両方のエンジンにTransformersベースのフォールバックがあるため、ネイティブ実装のないモデルでも一応起動することは可能です。

4. サーバーを立ち上げてOpenAI互換APIで呼び出す

vllm serve Qwen/Qwen2.5-1.5B-Instruct --max-model-len 8192            # 기본 포트 8000
sglang serve Qwen/Qwen3-0.6B --host 0.0.0.0 --port 30000              # 문서 quickstart (기본 host 127.0.0.1)
curl http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" \
  -d '{"model":"Qwen/Qwen2.5-1.5B-Instruct","messages":[{"role":"user","content":"안녕"}],"max_tokens":32}'

運用前に知っておくべき内容です。vLLMの --api-key は /v1, /v2, /inference のパスのみを認証し、 /invocations などの他のパスは認証しないため、これだけでセキュリティを担保しないよう公式ドキュメントが警告しています。vLLMサーバーはデフォルトでモデルリポジトリの generation_config.json を適用するため、サンプリングのデフォルト値がモデルごとに異なる場合があります（--generation-config vllm で無効化）。SGLangは --enable-metrics を有効にしないとPrometheusのメトリクスを出力せず、 --enable-cache-report でレスポンスの prompt_tokens_details にキャッシュヒットトークン数を受け取ることができます。

5. ベンチマークを正しく行う方法

ワークロードの形状を決定することから始めます。 入力および出力長の分布、プリフィックスの共有率と人気の分布、到着パターン、遵守すべきSLOです。可能であれば実際のログから取得し、ない場合は仮定を記述して感度を確認します。

クローズドループとオープンループ。 クローズドループは同時ユーザー数を固定し、レスポンスを受け取った後に次のリクエストを送信します（--max-concurrency）。サーバーの処理が遅くなると負荷も同様に減少し、過負荷が表面化しません。オープンループはサーバーの状態に関係なく、定められた到着率でリクエストを送信します（--request-rate）。以下のモデル（説明用のシミュレーションであり実測値ではない）は、リクエストあたり0.25秒（容量4 req/s）の単一サーバーを対象としています。

열린 루프 3 req/s     평균   0.64s  p99   2.26s
열린 루프 4.5 req/s   평균  57.43s  p99 114.55s   <- 용량 초과, 시간이 갈수록 대기열 증가
닫힌 루프 동시 4      평균   1.00s  p99   1.00s    <- 사용자 수만큼의 대기만 보임

両方のツールで --request-rate のデフォルト値が inf であるため、すべてのリクエストを時刻0に送信します（ソースコードで確認）。最大スループットはわかりますが、TTFTに待機時間が混ざるため、遅延の測定には使用できません。有限の値を指定するとポアソン過程で到着が生成され、vLLMの --burstiness は1.0がポアソン、小さくなるほどリクエストが一気に集中するガンマ分布になります。 --ramp-up-strategy でリクエストレートを徐々に上げることができます。

長さの分布。 vLLMの random データセットは --random-range-ratio のデフォルトが0.0であるため、長さが固定されます。実際の分布にはShareGPTや独自のログを使用します。モデルがEOSによって早期に終了すると出力長が変わるため、長さを固定するにはvLLMでは --ignore-eos を使用します（SGLangはデフォルトでEOSを無視し、 --disable-ignore-eos でオフにします）。 ウォームアップ。 vLLMは --num-warmups のデフォルトが0、SGLangは --warmup-requests のデフォルトが1です。最初のリクエストにはコンパイルとCUDAグラフのコストが混ざります。

最もよくある罠：プリフィックスキャッシュ。 vLLMのベンチマークドキュメントは、同じサーバーに vllm bench serve を繰り返すと、前回の実行のプロンプトがプレフィックスキャッシュに残ってスループットが水増しされる可能性があり、固定シードの合成データセットでも同様であると警告されています。第4回の実験はその規模を示しています。同じ文書を再度読み込んだ2回目のパスで、TTFTのp50が575.5msから48.6msに減少しました（LMCache、同時実行数1、1.5Bモデルの一度きりの測定値）。繰り返しが生み出す差は、エンジンの差よりも大きい場合があります。その対策は次のとおりです。

平均ではなく分位数。 デフォルトの出力として、vLLMは --metric-percentiles のデフォルト 99（平均と中央値を含む）、SGLangは平均、中央値、p99を出力します。p95が必要な場合は --metric-percentiles 50,95,99 のように指定します。サンプル数も確認します。リクエストが100件の場合、p99は上位1、2件の値で決まり、第4回の実験ではパスあたり10件だったためp50が最大値になっていました。TTFT、TPOT、ITLの定義はツールによって異なる場合があるとvLLMのドキュメントに記載されているため、同じクライアントで両方のエンジンを測定する方が公平です。SGLangの bench_serving は --backend vllm を使ってvLLMサーバーを呼び出すことができます。負荷ジェネレーターがボトルネックにならないよう、サーバーとは別のマシンで実行し、 --max-concurrency を使用する場合はクライアントの待ち時間（client_queue_time）を個別に確認します。vLLMのドキュメントでは、本番サービスのベンチマークにはGuideLLMが推奨されています。

ツール名が変更されました。 SGLang v0.5.21のソースでは、 sglang.bench_serving は非推奨の警告を出し、 sglang.benchmark.serving に移動しました（ドキュメントの例はまだ古い名前です）。vLLMは vllm bench serve です。

キャパシティプランニングにつなげます。 1）SLOを決定します（例：p99 TTFT 2秒、p99 TPOT 50ms）。2）リクエストレートを上げながら定常状態区間のp99を測定します。3）SLOを満たす最大リクエストレートが1インスタンスの容量（goodput基準）です。4）インスタンス数 ＝ ピークリクエストレート ÷ （容量 × 目標使用率）に障害用の余裕を持たせます。説明用の数値としてピークが20 req/s、容量が4 req/s、目標使用率が0.7の場合、20 ÷ 2.8 = 7.1となり、8台に予備1台を追加して9台となります。曲線の形状はPagedAttention論文の記述と同じです。リクエストレートが上がると遅延が緩やかに増加し、容量を超えた瞬間にキューが延び続けて遅延が急激に大きくなります。

p99 TTFT
   │                              /
SLO ┼ - - - - - - - - - - - - - -/- -    <- 이 교점의 요청률이 용량
   │                       _____/
   │  ____________________/   (이 지점부터 급증)
   └────────────────────────────── 요청률

実測：同一モデル、同一GPUでのvLLM対SGLang

同一モデル（Qwen3-1.7B、bf16）、同一GPU（8GBクラス1枚）、同一クライアント（リクエストごとに異なるランダムな入力、出力128トークン、ストリーミングによるTTFTとITLの測定）で両方のエンジンを測定しました。vLLM 0.31.0は --gpu-memory-utilization 0.85 --max-num-seqs 64、SGLang 0.5.21は --mem-fraction-static 0.8 --max-running-requests 64であり、コンテキスト長はどちらも4,096です。2つのオプションの意味が異なるため、 メモリ設定は同一ではありません。 以下の入力512の表は サーバーを3回再起動して測定し、値は3回の中央値です。初回測定値と3回繰り返した値は1%以内で同じでしたが、下のvLLM同時実行数64のみ例外でした。入力2,048の表は繰り返していない1回分の値です。

入力512、出力128 同時実行数1 同時実行数8 同時実行数32 同時実行数64
スループット (tok/s) vLLM / SGLang 66 / 66 384 / 386 831 / 809 842 / 836
TTFT中央値 vLLM / SGLang 73 / 89ms 349 / 454ms 669 / 1,093ms 2.2 / 4.0s
ITL p99 vLLM / SGLang 16 / 15ms 19 / 19ms 224 / 33ms 231 / 101ms

同時実行数64のvLLMの列は、サーバーを起動するたびに異なっていました。 3つのサーバーでのスループットは792、842、843 tok/s、TTFT中央値は5.7、2.1、2.2秒でした。最初に起動したサーバーのみが遅く、サーバーログのKVキャッシュは22,048トークンでした（残りの2つは26,560トークン）。同じオプションであるにもかかわらず、vLLMはメモリを測定してKVの領域を決定するため、サーバーを起動するたびに容量が異なり（22,048から27,504トークン）、同時64リクエストが640トークンずつキャッシュをほぼ満たすこの時点では、20%の容量の差によってTTFTが2.7倍に変化しました（第14回）。SGLangは3回すべて25,282トークンであり、値も1%以内で同じでした。上表のvLLM同時64は3回の中央値であり、この1つのセルは試行ごとの誤差が大きいです。

入力2,048、出力128 同時実行数4 同時実行数16 同時実行数32
スループット (tok/s) vLLM / SGLang 151 / 150 207 / 219 213 / 212
TTFT中央値 vLLM / SGLang 0.73 / 0.83s 4.0 / 2.5s 12.5 / 12.9s

大きなモデル（Qwen3-4B-FP8）での違い

1.7B bf16の約2.4倍大きなQwen3-4B-FP8（8GBに収まるようにfp8量子化された重み）を用いて、サーバーを2回起動して同じテストを繰り返しました。精度が異なるため、1.7Bとの直接的な比較ではなく「同一モデルにおける2つのエンジン」として読み取る必要があります。両方のエンジンともコンテキスト長は4,096、最大同時実行数は64であり、サーバーログのKVキャッシュは、vLLMが8,880トークンと13,232トークン、SGLangが2回とも13,036トークンでした。

入力512、出力128 同時実行数1 同時実行数8 同時実行数32
スループット (tok/s) vLLM / SGLang 49 / 49 251 / 278 323·365 / 450
TTFT中央値 vLLM / SGLang 166・168 / 113ms 911 / 720ms 7.2・3.4 / 3.6s
ITL p99 vLLM / SGLang 21 / 20ms 24〜27 / 25ms 548・583 / 138ms

構造化出力（JSONスキーマ制約）のコスト

SGLang 0.5.21のJSONスキーマ制約デコード（response_format の json_schema、文法バックエンドのデフォルトはxgrammar）を有効にしたリクエストと、プロンプトのみでJSONを要求したリクエストを同じサーバーで比較しました（Qwen3-1.7B、思考プロセス無効、出力約74トークン、リクエストごとに異なる入力）。

同時実行数 制約なしのスループット 制約ありのスループット 有効なJSON（スキーマを満たす） 制約なし / 制約あり
1 69 tok/s 67 tok/s (-3%) 4/4 / 4/4
8 482 tok/s 486 tok/s 32/32 / 32/32
32 1,577 tok/s 1,654 tok/s (+5%) 128/128 / 128/128

重みをfp8に縮小した場合：両方のエンジンで同じ方向性

同じサーバー設定で SGLang に --quantization fp8 を追加しただけです（bf16 の重み 3.28GB がほぼ半分に）。

入力 512、出力 128 同時実行 1 同時実行 8 同時実行 32 同時実行 64
SGLang bf16 スループット (tok/s) 66 382 808 837
SGLang fp8 スループット (tok/s) 100 567 1,122 1,250
増加 +52% +48% +39% +49%
fp8 の ITL 中央値 (ms) 9 11 19 27

同時実行 1 で 66 から 100 tok/s に増加したことは、1 つのトークンを生成する際に読み込む重みのバイト数が減少した効果であると解釈されます（第 21 回の帯域幅上限の式）。第 21 回で vLLM により測定された 1.7B fp8 の 105.7 tok/s と同等レベルであるため、この利得はエンジンの特性ではなく精度の特性です。品質（精度）はこのテストでは測定していません（未測定）。

長い入力が割り込む場合：デフォルトの動作が異なる

デコード中の 1 つのリクエストに対し、3,500 トークンの入力リクエスト 3 件を割り込ませ、割り込ませた区間の最大トークン間隔（ITL）を測定しました。

サーバー設定 割り込み区間の最大 ITL チャンクサイズのログ
vLLM、 --max-num-batched-tokens 512 69ms 512
vLLM、デフォルト 227ms 確認できず
vLLM、8192 445ms 8192
SGLang、デフォルト（初回テスト 3 回：459、457、464ms、サーバーの再テスト 3 回：462、462、462ms） 約 460ms 2048（ログ）
SGLang、 --chunked-prefill-size 512 472ms 512
SGLang、 --enable-mixed-chunk 228ms 2048
SGLang、 --enable-mixed-chunk --chunked-prefill-size 512 69ms 512

このテストが示している最も実用的な点は、 エンジン名よりもデフォルト設定が異なるという点です。同じ名前のオプションでもデフォルト値が違うため、比較を行うにはチャンクサイズ、ミックスドチャンク、メモリ設定、プレフィックスキャッシュをログで確認し、一致させてから計測し直す必要があります。この記事の第5節の前半（正しくベンチマークを行う方法）で述べている「条件を合わせる」が、このテストにおいて具体的な数値として現れました。

6. 自分で試してみる

すべて読み取り専用またはローカル計算です。

curl -sL https://raw.githubusercontent.com/vllm-project/vllm/v0.30.0/vllm/benchmarks/serve.py \
  | grep -n -E '"--(request-rate|burstiness|max-concurrency|num-warmups|goodput|metric-percentiles)"'
curl -sL https://raw.githubusercontent.com/sgl-project/sglang/v0.5.21/python/sglang/benchmark/serving.py \
  | grep -n -E '"--(request-rate|max-concurrency|warmup-requests|flush-cache)"'

第5節のオープンループとクローズドループの比較は、以下のコードの出力を表しています（実測値ではなく説明用のシミュレーションであり、リクエスト数を増えると容量超過区間のレイテンシも一緒に増大します）。

import random, statistics as st
random.seed(1)
S, N = 0.25, 4000                       # 요청 하나에 0.25초 = 용량 4 req/s, 요청 4000개

def open_loop(rate):                    # 포아송 도착: 서버가 느려도 요청은 제 시간에 온다
    t = free_at = 0.0; lat = []
    for _ in range(N):
        t += random.expovariate(rate)
        free_at = max(t, free_at) + S
        lat.append(free_at - t)
    return lat

def closed_loop(users):                 # 사용자 고정: 응답을 받아야 다음 요청을 보낸다
    ready, free_at, lat = [0.0] * users, 0.0, []
    for _ in range(N):
        i = ready.index(min(ready)); t = ready[i]
        free_at = max(t, free_at) + S
        lat.append(free_at - t); ready[i] = free_at
    return lat

def row(name, lat):
    s = sorted(lat)
    print(f"{name:<14} 평균 {st.mean(lat):6.2f}s  p99 {s[int(.99 * (N - 1))]:6.2f}s")

for r in (3, 4.5, 5): row(f"열린 {r} req/s", open_loop(r))
for u in (4, 16):     row(f"닫힌 동시 {u}", closed_loop(u))

第04話の実験をこの記事基準で評価し、弱点を探してみてください。同時実行数1、固定ドキュメント、同じドキュメントの再利用、ドキュメント10個という理由でp95が最大値になるという点がすべて引っかかります。改善課題は、同時実行数4（実験設定の --max-num-seqs=4）、ポアソン到着、長さ分布、プレフィックスヒット率の記録です。この実験は一時的なPodで実行され、この記事では再実行していません。リスクは同じノード上の他のワークロードとのメモリ競合およびGPU占有であり、Podは --rm によって削除され、残った場合は1時間後に終了します。

7. 面接で出そうな質問

  1. vLLMとSGLangのプレフィックスキャッシュはどう違いますか？ vLLMはブロック16トークンごとに親ハッシュを繋げたハッシュチェインをマップで照会し、空きブロックキューからLRUで追い出します。SGLangはトークン列をラディックスツリーに保存し、リーフから追い出します。デフォルトのpage-sizeは1です。現在はvLLMもデフォルトで有効になるため、違いは機能の有無よりも粒度、スケジューリングポリシー、エビクションポリシーにあります。
  2. エージェントワークロードにおいてSGLangの方が優れているという主張をどうやって検証しますか？ 同じハードウェア、モデル、精度において、同じクライアントで実際のターン構造のトレースをオープンループで送信します。プレフィックスヒット率を一緒に記録し、p99 TTFTとSLOを満たすスループットを比較します。論文の数値はvLLM v0.2.5と比較したものであるため、現在のバージョンにはそのまま適用できません。
  3. オープンループとクローズドループはそれぞれいつ使いますか？ 容量とSLOを把握するためには、オープンループでリクエスト率を上げながら急増地点を探します。クローズドループは上位システムが同時実行数を制限する環境を模倣するときに使用し、過負荷時にレイテンシが増加しないように見える限界を把握します。
  4. ベンチマーク結果が異常に良好です。何を疑うべきですか？ 同じプロンプトの繰り返しによりプレフィックスキャッシュがヒットしたか、ウォームアップを除外したか、出力がEOSで早期終了したか、リクエスト率が inf であるためTTFTに待機が混ざっていないかを確認します。ヒット率の指標と、入力・出力トークン分布をあわせて確認します。
  5. ベンチマーク結果をGPU台数にどう換算しますか？ SLOを遵守する最大リクエスト率をインスタンス容量とみなし、ピークリクエスト率を容量と目標使用率の積で割った後、障害への備えを加えます。平均スループットではなくp99基準である必要があり、ワークロードの形状が変わった場合は再計測する必要があります。

8. よくある誤解

参考文献

実際に中身を確認したものだけを記載しています。

確認したバージョンと日付、確認できなかったこと

ログインするといいねできます

コメント

まだコメントはありません。

ログインするとコメントできます