ProsGrow が Qwen3 のバッチスループットを 132% 向上させた方法

課題：長いキューに対して実行中のリクエストが少なすぎる

リクエストキューが混雑していても、GPU が利用可能な能力を十分に使って有用な処理をしているとは限りません。vLLM 0.25.1 上の Qwen3-30B-A3B で、ProsGrow は初期の配信設定が短いプロンプトのバッチ内で同時に実行できる処理量を制限していることを発見しました。待機中の仕事は十分あるにもかかわらず、出力は 17,961 トークン/秒でした。

プロファイリングとスケジューリング動作の調整により、41,651 出力トークン/秒、すなわち 132% 改善、2.32 倍に達しました。GPU、ランタイム、チェックポイント、精度、リクエスト数、プロンプトと出力の仕様は固定しました。これはProsGrow の初期設定に対する実測改善であり、最適に調整された vLLM ベースラインとの比較ではありません。

ベースライン → ProsGrow 調整後

この統制された比較では、リクエスト遅延の中央値も 15.91 秒から 11.70 秒に改善しました。この結果は当該ワークロードで回復可能な処理能力を示しており、他の推論エンジンや十分に最適化された環境に対する一般的な優位性を示すものではありません。

スケジューラが重要だった理由

ProsGrow は投入された負荷とエンジンが実際に受け入れた処理を分け、同一ワークロードで完了スループットとリクエスト遅延を比較しました。証拠はスケジューリングのボトルネックを示していました。初期設定では、長いキューを十分な同時実行に変えられていませんでした。カーネル単体の高速化を切り分けた結果ではありません。

この技術検証では、配信スタックの制約箇所を特定し、統制条件下で影響を評価し、有用な運用設定を検証しました。モデルが 1 基の GPU に収まるため、独立レプリカを使えば、回復した単一 GPU の処理能力がノード全体にも反映されるかを実用的に確かめられます。

トレードオフ：同時実行数を増やすと、やがて待ち時間だけが増える

別の飽和負荷設定では、独立した 2 回の実行で 45,941 および 46,701 出力トークン/秒となり、遅延中央値は約 20 秒でした。同じパラメータ探索でさらに負荷を増やすと、スループットは 0.91%しか増えず、遅延中央値は 20.04 秒から 29.85 秒に増加しました。追加のキュー待ちは、もはや意味のある処理能力を生んでいませんでした。

メモリも選択を制約しました。配信のオーバーヘッドにより、キー・バリューキャッシュに使える容量が減るためです。短いプロンプトでは選択した設定に十分な余裕がありました。より長いコンテキストや対話向けの遅延目標には、それぞれの評価が必要です。

調整した 1 基の GPU から 8 基の GPU によるバッチサービスへ

8 個の独立レプリカでは、同期した 2 回の実行で 362,812 および 361,679 出力トークン/秒を達成しました。処理能力の推定には低い方を使います。どちらの実行も 32,768 件のリクエストと 8,388,608 個の出力トークンをすべて完了し、失敗や出力不足の応答はありませんでした。

低い方の実行は、最初のクライアント起動から最後の完了まで、共通の実時間ウィンドウ 23.19 秒で測定しました。すべての処理を共有区間内で数えることで、個別計時したレプリカのレートを足してノードの結果を過大評価することを避けています。

ローカルの 132% 改善と公開比較の 8.17% の関係

上記の 132% 改善は、キュー内の短いリクエストに対するスケジューリング調整の測定です。能力レポートの 8.17% の比較は、指定された長いリクエスト仕様で、保存済みの公開参照結果に対してローカル実行がどうだったかという別の問いに答えています。

公開仕様に基づく実行では、キューに投入する合成リクエストと TensorRT-LLM 1.3.0rc24 を使いました。保存済みの NVIDIA 参照結果は 1.1 です。長いキューの下で、平均リクエスト遅延は 173.04 秒でした。9,938 という値は、2026 年 8 月 17 日に記録した NVIDIA の参照ページが出典です。後日の出典確認では、その行は表示されなくなっていました。私たちは日付付きの比較としてこれを保存し、ワークロードは公開の性能測定手順で定義しています。

+8.17% は単一 GPU の独立実行結果です。この値も、ノードの 85,409 と 361,679 トークン/秒の差も、ソフトウェアだけの改善を切り分けたものではありません。後者はランタイムとリクエスト長が変わっています。これらはバッチ処理能力を表すレートであり、対話型サービスには固有の遅延目標が必要です。

顧客にとって何が変わるか

プライベートな生成キューや合成データ作成ジョブでは、設置済みの能力で処理を早く終えられることが利点です。ProsGrow は GPU の増設を勧める前に、回復可能な配信能力を測定できます。

選択したスループット設定は長いキューを必要とし、約 20 秒の遅延中央値を許容します。導入適格性の検証には、顧客のモデル、リクエスト長分布、品質確認、トラフィックトレースを使う必要があります。対話型アシスタントには独自の遅延目標が必要です。

測定方法と制約

• ハードウェアとソフトウェア：テストは 2026 年 8 月 18 日、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU 8 基のノードで行いました。統制されたパラメータ探索では 1 基を使用しました。ランタイムは vllm/vllm-openai:v0.25.1、重みは ModelOpt NVFP4、キー・バリューキャッシュは FP8 です。
• モデルとリクエスト：固定した NVIDIA Qwen3-30B-A3B-FP4 チェックポイントは、リビジョン 2538ded2a4edb247b4d2b4a8ba24e44bd4c017c3を使用しました。技術ガイドのプロンプトを繰り返し、リクエスト識別子だけを変え、API の報告で入力は 63–66 トークンでした。温度はゼロ、思考は無効にし、すべての応答が上限の 256 トークンに達しました。
• 測定：スループットは完了した出力トークン数をクライアントが観測した経過時間で割ったもので、プロンプト処理とローカル HTTP のオーバーヘッドを含みます。132% の比較は設定ごとに 1 回の測定です。選択した飽和設定は、独立した反復 2 回と同期ノード反復 2 回があり、後者はそれぞれ約 23 秒にすぎません。
• 品質と運用：固定出力長は生成した仕事量の検証であり、タスク品質の検証ではありません。これらは古い Qwen3 チェックポイントを使ったローカルの飽和測定であり、長時間の本番耐久試験、顧客 SLA、品質同等性テストではありません。代表的なプロンプト、p95/p99 遅延、ネットワーク負荷、失敗、分野固有の品質は、本番採用の判定項目として残ります。

過去の vLLM 0.23 との比較も、元の生のプロンプトリクエストが保存されていないため、見出しの改善率には含めていません。同一バージョンのローカル比較が統制されたベースラインになります。

プライベート Qwen3 導入と vLLM バッチ推論

プライベート Qwen3 導入を計画するチームは、このベンチマークを使い、バッチ推論能力、GPU 利用率、許容できるキュー待ち時間を検討できます。1 秒あたりの出力トークン数は完了した生成のスループットを測り、リクエスト遅延はジョブの待機と実行にかかる時間を示します。vLLM の導入規模は、顧客のリクエスト構成と納期目標に合わせて決める必要があります。