AI・信頼性・評価

AIPerfでLLM推論を測る：同時数と到着率で遅延が変わる仕組み

2026/10/14

🤖 AIを使用して執筆

同時数を固定すると、遅延は同時数とスループットの比で決まる

同時数を固定したときに遅延が同時数 ÷ スループットで決まるのは、待ち行列の理論でリトルの法則と呼ばれる関係の一つの場合である。リトルの法則は、系の中にある要求の平均件数 L が、要求が系に入る速さ λ と、一件が系にとどまる平均時間 W の積に等しいという関係 L = λW である³。NVIDIA の NIM の LLM ベンチマークの手引きは、同時数 N を、それぞれ一つの要求を出している N 個のクライアントと定義し、各要求が応答を受け取り終えると次の要求が送られるので、システムには常に N 件の要求が出ていると書く⁴。この送り方では L が N に固定され、要求が系に入る速さはサーバーが終える速さ（スループット X）に等しい。したがって、平均の遅延 W は N ÷ X で決まる。ここでのスループットは毎秒のトークン数ではなく毎秒の完了件数であり、この関係が決めるのは要求全体の平均であって、TTFT や上位 1% の遅延ではない。

この関係から、同時数を固定した測定で何が分かるかが決まる。スループットが頭打ちになるまでは、同時数を増やすとスループットが伸びる。頭打ちになった後に同時数を増やすと、X は変わらず N だけが増えるので、遅延は同時数に比例して伸びる。NIM の手引きも、推論エンジンが同時に処理できる要求の最大数を最大バッチサイズと呼び、同時数が最大バッチサイズとレプリカ（同じモデルを動かすサーバーの複製）の数の積を超えると一部の要求が待ち行列で待つこと、スループットは一般に最大バッチサイズの近くで頭打ちになり、遅延は伸び続けることを書く⁴。手引きは、同時数を 1 から最大バッチサイズを少し超える値まで変えて測るよう求め、大半のベンチマークで到着率より同時数を使うよう勧める⁴。AIPerf の文書も、同時数だけを指定する送り方（--concurrency）を、飽和とスループットの試験に当てる⁵。

頭打ちの後の遅延は、ツールに指定した N で決まる値である。利用者がどれだけの速さで来るかは、この値に入っていない。

利用者がスループットより速く来ると、待ちが同時数の測定値から抜け落ちる

1 秒に 4 件を終えるサーバーを同時数 8 で測る場合を考える。ツールは 1 件が返るまで次を送らないので、1 秒に 4 件しか送らない。仮に利用者が 1 秒に 6 人来るとすると、残りの 2 人分の要求は、サーバーに届く前にツールの中で順番を待つ。サーバーで測る遅延は 2 秒のままだが、利用者から見た遅延には、このツールの中での待ちが加わり、試験が長いほど伸びる。同じサーバーに到着率 6 件/秒で 10 秒間送ると、最後の要求の遅延は約 5.7 秒になり、これが利用者の側から見た値に当たる。

この現象は coordinated omission と呼ばれる。負荷生成ツール wrk2 の README は、多くの負荷生成ツールが要求の遅延を、要求の最初のバイトを送った時刻から応答を受け取り終えた時刻までとして測ると書く⁶。各接続は応答を受け取ってから次の要求を送るので、遅い応答が出ている間、ツールはサーバーに合わせて送るのを控え、遅延の大きい期間を測らずに済ませてしまう⁶。wrk2 はこれを避けるため、一定の到着率で送り、遅延を実際に送った時刻からではなく、到着率に従えば送るはずだった時刻から測る⁶。

AIPerf の文書も同じ問題を扱う。AIPerf には、プリフィル（入力を処理する段階）にある要求の数をツールの側で制限する指定（--prefill-concurrency）がある。文書は、要求がその枠を待つとベンチマークは閉ループ（送る速さがサーバーの終える速さで決まる送り方）として動き、サーバーの処理能力に合わせて送る速さを自ら下げると書く⁷。文書はこれを coordinated omission と呼び、測った遅延は、要求が元の到着率で届き続けた場合に利用者が見る遅延より低くなると書き、正確な遅延の測定には、この制限を付けずに到着率で送る開ループ（応答を待たずに予定の時刻に送る送り方）を使うよう勧める⁷。

AIPerf は、送る許可をツールの中で出した時刻から応答の終わりまでを effective_latency として記録する⁸。サーバー側の時刻だけで測る遅延（request_latency）は、ツールの中での待ちを含まない。文書は、effective_latency が request_latency を大きく上回るときは飽和の領域に入っており、利用者が見る遅延は effective_latency のほうだと書く⁸。ただし、AIPerf のコードは同時数の上限に空きができてから許可を出すので⁹、ツールが送らなかった要求や上限で止まっていた時間は effective_latency にも入らない。1 秒に 6 人来る例でツールの中で順番を待つ 2 人分の待ちは、同時数を固定した試験ではどの指標にも現れない。

閉じた送り方と開いた送り方の差は、LLM に限らない。Schroeder らの論文は、新しい要求が前の要求の完了によってだけ生じるモデルを閉じたモデル、完了と無関係に到着するモデルを開いたモデルと定義し、負荷をそろえても、開いたモデルの平均応答時間は閉じたモデルの 1 桁以上大きくなりうると書く¹⁰。論文が測った対象は 2006 年の Web サーバーなどで、LLM の推論サーバーではない¹⁰。論文は、閉じたモデルも開いたモデルも完全には現実的でなく、多くの用途は中間のモデル（partly-open）で表すのがよいと書く¹⁰。このモデルでは利用者が外から来て、応答を受け取るたびに一定の確率で次の要求を送る¹⁰。論文は、純粋に閉じたツールか開いたツールしか選べないときに、どちらが近いかを選ぶ指針も示している¹⁰。決まった数のクライアントがそれぞれ応答を待ってから次を送る用途（たとえば一定数のバッチ処理のワーカー）では、同時数を固定した測定がそのまま当てはまる。

到着率で送ると、処理能力を超えた分だけ待ちが伸び続ける

到着率が処理能力を超えると待ちが試験の長さに比例して伸びることは、NIM の手引きが同時数を勧める理由でもある。手引きは、到着率で送ると、到着率がシステムのスループットを超えたときに未処理の要求が際限なく増えうることを挙げる⁴。本稿は、この増加を、利用者が処理能力を超えて来たときに待つ時間そのものと考える。そのため、処理能力を超える到着率で測った遅延は、試験の長さとともに報告しなければ比べられない。

1 秒に 4 件を終えるサーバーに到着率 4 件/秒で送っても、要求の間隔が等しければ待ちは 0 秒である。現実の利用者は等しい間隔では来ない。AIPerf は到着率を指定したときの到着の間隔の既定をポアソン過程（間隔が指数分布に従う到着）にしている⁵。間隔がばらつくと、平均の到着率が処理能力を下回っていても、要求が一時的に 4 件を超えて重なり、待ちが生じる。Schroeder らは、一件の処理の大きさのばらつきが、開いたモデルでは応答時間に大きく効き、閉じたモデルではそれほど効かないとも書く¹⁰。LLM では出力のトークン数が要求ごとに違い、一件の処理時間がばらつくので、本稿はこの性質が LLM の推論サーバーにも当てはまると考える。この当てはめは本稿の推論であり、論文は LLM で測っていない。

到着率で測った値は、ツールが予定の時刻に送れたときだけ利用者の待ちを表す

ツールが予定の時刻に送れないと、サーバーに届く到着率は指定より低くなり、到着率で測った値は低い到着率の値になる。NVIDIA は、AIPerf を GenAI-Perf の後継として一から書き直し、負荷を生むワーカーのプロセスと結果を処理するプロセスを分けて、AIPerf 自体が測定のボトルネックにならないようにしたと書く¹。

それでも、ツールが予定より少なく送る場面はある。AIPerf の文書によれば、毎秒 500 件以上の到着率では、非同期の処理を進める仕組み（イベントループ）のタイマーが 1 ミリ秒未満の待ちを約 1 ミリ秒の刻みに丸め、AIPerf は目標の到着率より少なく送り、そのことを知らせない⁵。AIPerf は到着率を指定すると既定で、Linux では約 50 マイクロ秒の精度のカーネルのタイマーを使う送出に切り替えてこれを避ける⁵。文書は、高精度の送出が有効でも、タイマーが起きてから要求を送るまでの間にイベントループが止まると送り不足が起きうると書き、測った到着率が指定を下回り続けるときに確かめる手順を示している⁵。

到着率と同時数の上限を一緒に指定したときも、送る量は指定より少なくなる。AIPerf は上限に空きがなければ要求を止め、空きができても遅れを取り戻すために速く送ることはせず、予定は指定した到着率のまま進む¹¹。vLLM に付属するベンチマーク vllm bench serve のヘルプも、同時数の上限を一緒に指定すると、サーバーが処理に追いつかない場合に実際の到着率が指定より低くなりうると書く¹²。どちらの場合も、上限に達している間は、指定より低い到着率の値を測っている。

測り方の手順：飽和点を同時数で探し、利用者の待ちを到着率で測る

ここまでの仕組みから、本稿は次の順で測ることを勧める。各段の根拠は、先の節で挙げた手引きと文書である。

1. 同時数を 1 から最大バッチサイズを少し超える値まで変え、スループットが頭打ちになる同時数を探す⁴。この範囲の遅延は同時数 ÷ スループットで決まるので、利用者の待ちとしては報告しない。
2. 到着率を決めて送り（--request-rate）、到着率ごとに遅延を測る。 到着の間隔はポアソン過程にし（--request-rate の既定）、頭打ちのスループットを超える到着率では遅延が試験の長さで変わるので、試験の長さも記録する。AIPerf は、TTFT などの上限（サービスレベル目標、--goodput で指定）を満たして終わった要求の毎秒件数を goodput として出す¹³。たとえば TTFT 100 ミリ秒以下を上限にすると、TTFT が 100 ミリ秒を超えた要求は goodput に数えない。goodput だけでは、上限を満たした要求が全体の何割かは分からないので、AIPerf はその割合を good_request_fraction として別に出す¹³。文書は、この割合で目標（たとえば 95%）を満たしたかを判定する使い方を示している¹³。この手順では到着率ごとにこの判定をし、目標を満たす最大の到着率を、その上限のもとで受け持てる到着率とみなす。
3. 指定した到着率と測った到着率を並べ、effective_latency と request_latency を比べる。 測った到着率が指定を下回れば、その値はツールが送れた低い到着率のものである⁵。effective_latency が request_latency を大きく上回れば、要求がツールの中で送り出しを待っており、利用者が見る遅延は effective_latency のほうである⁸。同時数の上限を一緒に付けた場合、上限で止まった分は二つの遅延の差には現れず、測った到着率の低下としてだけ現れる⁹¹¹。

ほかのツールの数値を読むときも、同じ三つを問えばよい。同時数と到着率のどちらで送ったか、試験は何秒か、指定した到着率どおりに送れていたか、である。たとえば MLPerf Inference は、一件返るたびに次を送るシナリオとポアソン到着で送るシナリオを分け、後者は少なくとも 600 秒の試験で、遅延の上限を満たす最大の到着率を報告する¹⁴。同時数だけが書かれた遅延は、同時数 ÷ スループットで決まる値であり、利用者がその遅延で応答を受け取れることは示していない。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。