AIPerfがマルチプロセスでLLMの性能測定を再構築、ストリーミング指標はカウント方法の確認が必要

NVIDIAは9月18日、AIPerfのアーキテクチャとデプロイ環境でのテスト方法を詳しく解説し、GenAI-Perfの後継ツールと位置付けた。主な変更点は、Perf Analyzerへの依存をなくし、複数のプロセスでリクエスト生成と結果処理を行い、ZMQを介して連携させることだ。これにより、高い同時実行数でのテストにおいて、クライアント側の処理能力が先に上限に達する可能性を抑える。[技術記事](https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf/)

この設計が関わるのは、測定の信頼性だ。負荷生成器が予定したトラフィックを継続的に送信できなければ、観測されたスループットの上限はクライアントの能力を反映している可能性がある。AIPerfは処理を独立したサービスに分散し、同時実行数やリクエストレートを指定するモード、トレースをリプレイするモードを提供する。公開リポジトリではカスタムデータやエンドポイントの拡張にも対応しており、異なる推論サービスに同じ測定手順を適用できる。[プロジェクトドキュメント](https://github.com/ai-dynamo/aiperf)

トラフィックのパターンも重要なポイントだ。一定間隔での送信に加え、Poisson分布やガンマ分布に従うリクエスト到着パターンを生成でき、バーストの度合い、段階的な負荷増加、入出力長も調整できる。既存サービスのトレースのリプレイも可能だ。エンジニアリングの観点では、バッチスケジューリング、長短のプロンプトの混在、キャッシュの競合によるテールレイテンシを明らかにするうえで役立つ。平均の毎秒トークン数という単一の値では、こうした違いは表せない。[負荷設定の説明](https://developer.nvidia.com/blog/benchmarking-llm-inference-at-scale-with-aiperf/)

指標は引き続き、その定義に沿って解釈する必要がある。最初のトークンが返るまでの遅延には、ネットワーク、キューでの待機、プロンプト処理が含まれる。一方、デフォルトのITLは、最初のチャンク以降にかかった時間を、出力長から1を引いた値で割って算出するもので、トークンごとのタイムスタンプに基づくものではない。サーバーが最初のレスポンスチャンクに複数のトークンをまとめて返す場合、単一ユーザーのスループットが過大評価される可能性がある。ドキュメントではチャンクごとの使用量に基づく補正方法を示しているが、対応するエンドポイント、ストリーミングモード、サーバーが報告するトークン数が必要となる。[指標の定義](https://github.com/ai-dynamo/aiperf/blob/main/docs/metrics-reference.md)

既存のGenAI-Perfスクリプトも確認が必要だ。移行ガイドでは、ワーカープロセスの制御に`--workers-max`を使用すること、従来のパススルー引数の区切り文字が廃止されたこと、一部の`analyze`機能がまだサポートされていないことが記されている。チームはまず、バージョンを固定し、同じデータと停止条件で比較の基準を確立してから、実際のトラフィックのリプレイを加えるべきだ。今回の記事ではツール間の測定誤差の検証は示されておらず、これを根拠に、すべてのワークロードでクライアント側のボトルネックが解消されたとは判断できない。[移行ガイド](https://github.com/ai-dynamo/aiperf/blob/main/docs/migrating.md)