TL;DR
Runwayは、NVIDIA AIPerfを変更せず測定に使い、その前の実験設計と後のSLA・コスト・監査判断を分離した規制AI向け検証パイプラインです。論文は、同時実行数でエンジン順位が逆転し得ること、時間単価が高いGPUがリクエスト単価では安くなり得ること、投機的デコーディングの効き方がエンジン設定で変わることを示します。ただし各セル1回測定で信頼区間がなく、合成ワークロード中心などの限界があります。
既存手法との違い
原論文の既存実務は、合成負荷で候補をベンチマークし、最高スループットの構成を一度選び、性能劣化時だけ見直すものです。Runwayは負荷生成器を自作せず、NVIDIA AIPerfを未改変の測定器として使います。違いは、AIPerfの前段に実験設計（sweep/campaign）、後段にSLA判定・コスト試算・監査可能な保存を置く点です。また社内試作のベンチマーク harness はAIPerfと同等機能まで3エンジニア週間かかり、なお検証上の正当化が必要だったと述べています。
使える条件
OpenAI互換エンドポイントに対してAIPerfで負荷生成できるLLM推論が前提です。実装はTensorRT-LLM、vLLM、リモートエンドポイントのアダプタ、Argo Workflows on EKS、GPUテレメトリ、宣言的SLA YAML、S3またはローカルの成果物ストアを用います。論文の評価対象はQwen3-8B-FP8やQwen3.5-9B、L40S・RTX PRO 6000 Blackwell・H100などの特定構成で、他モデル・他GPU・他クラウドへの一般化や、規制要件全般への適合性は提示本文からは確認できません。品質評価は論文の対象外です。
限界と未検証の範囲
各セルはキャッシュにより原則1回の独立測定で、信頼区間がなく小差は指標程度に読むべきとされています。再測定用の–replicate=Nは計画中で未提供です。ワークロードは合成またはアップロード済みプロンプト中心で、実運用トラフィックとの一致は保証されません。品質評価は対象外です。同時実行数による順位逆転の原因は切り分けておらず、既定設定での比較です。ある1セルの逆転は実かどうか未確定で、TensorRT-LLMはpre-release、vLLMのdraft token数もモデルカード推奨と異なる可能性が注記されています。
解説
ねえ智也くん、この「規制AI向けLLM推論検証を監査可能にするAIPerf活用パイプライン」って論文、要はベンチマークの話？
ベンチマークそのものを作った話じゃない。規制産業で「この構成で契約や法規を満たす証拠」を残すために、NVIDIA AIPerfの前後に実験設計と監査判断を付けたパイプラインの話だよ。
前後に付けた、ってのがポイントなんだ。普通は一番速いエンジンを一回測って選ぶんじゃないの？
原論文の比較対象はまさにその標準実務。合成負荷で候補を測って最高スループットを一度選び、性能劣化時だけ見直すやり方。でも規制産業だと「ベンダーが速いと言った」じゃ通らない。変更前に受入基準に対して評価した文書化された証拠が要る。
じゃあRunwayは何を自作して、何を任せてるの？
負荷生成器は自作しない。測定はAIPerfを未改変で使う。Runwayがやるのは、前段のsweepやcampaignの設計、後段のSLA判定・コスト試算・監査可能な保存。結果のパスで「何を測ったか」、設定ファイルで「どう測ったか」を持たせて、キャッシュと監査を同じ仕組みにしてる。
なるほど。測定器は信頼できるNVIDIAのやつで、判断の部分だけ自分たちのものにしてるんだ。
その分離が設計の中心。OpenAI互換エンドポイントにAIPerfで負荷をかけられるLLM推論が前提で、実装はTensorRT-LLM、vLLM、リモートエンドポイントのアダプタ、Argo Workflows on EKS、S3かローカルの成果物ストア、宣言的SLAのYAMLを使ってる。
評価の結果はどんなのが出たの？
三つ。まず同時実行数でエンジン順位が逆転する。Qwen3-8B-FP8、L40Sで、同時実行1〜10ではTensorRT-LLMがスループットもp95レイテンシも勝つけど、50ではvLLMがスループットで逆転、100ではvLLMが両方勝つ。
低負荷と高負荷で正解が変わるんだ。怖いね。
二つ目は、時間単価が高いGPUがリクエスト単価では安くなり得る。g7e.2xlargeはg6e.xlargeより時間単価が1.81倍高いけど、スループットが約2倍、レイテンシが約半分で、中央値のリクエスト単価は1〜15%低い。でも1セルだけ逆転してて、1回測定だから実かどうかは未確定。
時間単価だけで選ぶと損する可能性があるんだね。三つ目は？
投機的デコーディング、ここではMTPの効き方がエンジン設定で変わる。vLLMは同時実行16くらいからMTPがネットのコストになるけど、TensorRT-LLMは全水準でプラス。同時実行64ではvLLMの最良が20.9req/sで19.3req/sのTensorRT-LLMに勝つけど、TensorRT-LLM側は非デフォルトのスケジューラ設定が必要だった。
つまりエンジン選びより設定一個の影響がデカい場合があるってこと？
原論文もそう読んでる。キャンペーンのメモでは、その設定だけで2.55倍のスループット改善があったとされてる。だから同時実行数の比較は既定設定での話で、設定を変えると絵が変わる。
意義はやっぱり監査可能ってところ？
そう。SLAの名前・バージョン・判定とコストと構成がreport.jsonに残る。キャッシュがフルヒットすればGPUなしでレポートを再生成できる。速さだけでなく「なぜその構成で出したか」を後から取り出せるのが価値。
限界は？
各セルはキャッシュにより原則1回の独立測定で、信頼区間がない。小さい差は指標程度に読むべき。再測定用の–replicate=Nは計画中で、このsweepでは使えてない。ワークロードも合成かアップロード済みプロンプト中心で、実運用トラフィックとの一致は保証されない。品質評価は論文の対象外。
他のモデルやGPU、クラウドにもそのまま当てはまるの？
提示された本文からは確認できない。評価はQwen3-8B-FP8やQwen3.5-9B、L40S・RTX PRO 6000 Blackwell・H100などの特定構成。順位逆転の原因も切り分けてないし、TensorRT-LLMはpre-release、vLLMのdraft token数もモデルカード推奨と違う可能性が注記されてる。
じゃあ高いGPUを買えばリクエスト単価が安くなるってことだから、私のPCもGPUに…
時間単価とリクエスト単価を混ぜるな。しかもその論文、各セル1回測定だぞ。