スループットを求める前に、有用な結果を定義する
対話型では、最初のトークンの待ち時間と応答全体の待ち時間を測定しましょう。オフラインのコーパスでは、期待されるすべての出力を得るまでに必要な時間を測定します。どちらの場合も、受け入れ基準を定めます。既知の回答に対する正確さ、ランキングの品質、または検証されたフィールド抽出です。構文的に有効なJSONでも、依然として誤った回答を含む可能性があります。
お使いのツールで可能であれば、キュー待ち、処理、およびクライアントが観測する全行程を分けて測定しましょう。エンジン内部の測定は、アプリケーションの測定とは同じ範囲ではありません。vLLMのメトリクスに関するドキュメントは特に、待ち時間、最初のトークン、合計時間を区別しています。採用するエンジンに関わらず、測定値ではこの区別を保ちましょう。
技術的な出典: vLLM — リクエストとレイテンシのメトリクス
リクエストを選択基準に変える
安定した識別子を使い、短い入力、通常の入力、長い入力を用意しましょう。モデル、トークナイザー、会話テンプレート、生成パラメータを保持します。履歴やアプリケーションが追加したドキュメントを含め、実際に送信されたトークンを数えましょう。要求したバッチ、送信した同時実行、実際に同時処理されたリクエストを別々に記録します。これらは必ずしも同じ数ではありません。
| 確定する入力 | 測定と単位 | 選択への影響 |
|---|---|---|
| 完全なプロンプトと出力の上限 | リクエストごとの入力トークンと出力トークン | 長いケースと上限で切れた回答を確認する |
| 同時リクエストと到着レート | アクティブ、待機中、完了したリクエスト | 要求される遅延で持続可能な負荷を決定する |
| 精度、量子化、キャッシュ | GPUごとのメモリのピーク（バイトまたはGio） | 想定負荷でメモリを超える設定を除外する |
| 品質基準と参考情報 | 許容される出力 / 期待される出力。ビジネス指標 | 同じ基準を満たすバリエーションのみを比較する |
| タイマーの範囲 | 最初のトークン、完全な応答、コーパスのいずれも秒単位 | 同じ区間の期間を比較する |
| ファイル復元までのスケジュール | 合計時間枠（時間または日単位） | 次に3日、7日、または30日のプランを選択します |
コンテキストと同時実行数でメモリを測定する
トークンを1つずつ生成する自己回帰モデルでは、KVキャッシュがアテンション状態を保持します。そのサイズはモデルと保持されるトークン数に依存します。動的キャッシュは生成中に増加する可能性があり、静的キャッシュは最大サイズを事前に確保します。一部のスライディングウィンドウ層はこの増加を制限します。したがって、実際に使用する戦略で、想定される長さと同時実行数をテストしてください。
重みの量子化とキャッシュの量子化は別々の選択です。例えば、bitsandbytesは一部の線形層を量子化されたバージョンに置き換えますが、これは実行時のすべての割り当てを表すものではありません。精度を変更した後は、ピーク全体が同じ割合で減少すると仮定せず、メモリと品質を再度確認してください。
PyTorchでは、割り当てられたテンソルのピークと、アロケータが予約したメモリのピークを別々に記録してください。これらを合計しないでください。測定したGPUと単位を明記してください。1 GiBは2³⁰バイトに相当します。これらのカウンターは、必ずしもデバイス全体の使用量を表すわけではありません。メモリに関するドキュメントでその限界を詳しく説明しています。
技術的な出典: Hugging Face Transformers 5.17 — KVキャッシュ戦略 · Hugging Face Transformers 5.17 — bitsandbytes量子化 · PyTorch 2.14 — CUDAメモリの管理とカウンター
300件のドキュメントによる測定可能な試行
許可されたコーパスで実施する例：300件のドキュメントから日付、金額、カテゴリを抽出します。期待値を確認し、欠損フィールドの扱いを明確にし、試行前に合格しきい値を設定します。ドキュメント数はプロトコルを記述するものであり、所要時間、スコア、スループットは一切想定していません。
- 300件の識別子、モデルのリビジョン、プロンプト、トークン上限、パース規則を固定します。長いドキュメントは結果レポートで識別できるようにしておきます。
- 一度に1つのリクエストでベンチマークを実行します。ロード、ウォームアップ、計測を分離し、ドキュメントごとの予測とエラーを保持します。
- 次に一度に1つのパラメータだけを増やします。バッチ処理ならbatch、リクエストエンジンなら並行度です。入力と品質基準は同じままにします。
- 各実行で、所要時間、メモリのピーク、重複なく取得できた識別子の数、受理された出力を記録します。測定を繰り返し、生の値とばらつきを保存します。
- あるバリアントが失敗した場合は、その理由（メモリ、切り捨て、フォーマット、品質）を記録します。バッチの縮小や再開は、消すべき失敗ではなく、文書化すべき決定です。
技術的な出典: IteraGPU — 同等品質での詳細な比較プロトコル
IteraGPU Lab v1 のリソースを適切な対象範囲で使用する
ノートブックとその付属スクリプトは、重みの計算と小規模な合成ネットワークでの測定を提供します。その測定コードは、ローカルの RTX 5070 上で PyTorch 2.11.0 を用い、小規模な float32 構成で実行されました。この試行はこの実行ケースを検証するものであり、LLM や KV キャッシュ、カタログ上の GPU におけるお客様のリクエストを測定するものではありません。
ノートブックを使ってカウンターの理解を深め、その後、ご自身の環境で実際の負荷を測定してください。品質プロトコルと生の表は、比較の準備に役立ちます。配布されたノートブックの出力と CSV の結果行は空のままです。この手順ではモデルもドライバーもインストールされません。実行前に README の前提条件をお読みください。
- IteraGPU Lab v1 メモリノートブック
メモリ測定を理解するための計算と小規模な合成ネットワーク。
- 補完が必要な品質プロトコル
固定入力、出力の受理、試行の比較。
- 空の生テーブル
実際の各試行につき1行で、パラメータ、測定値、判定を記載。
- IteraGPU Lab v1 の前提条件と制限
実施済みのローカル試験の手順と正確な範囲。
測定から提供へ
選択の記録には、対応環境、カードごとのメモリ、コンテキスト、同時実行数、達成した品質、実測した所要時間をまとめる必要があります。これらの基準を満たす構成を比較し、そのうえで準備、処理、評価、再実行、エクスポートという全工程のスケジュールに沿って3日、7日、30日のプランを比較します。ベンチマーク資料の計算ツールは、プラン全体と、実際に検証済みの有用なコーパスを使用します。
この記録とコードのバージョンは手元のノートに保管してください。ソフトウェアと処理を選ぶのはお客様です。IteraGPUはお客様のファイル、プロンプト、計算の内容を検査しません。注文時の環境選択はお客様の準備の必要性を表すものであり、モデルがすでにインストールまたはテスト済みであることを証明するものではありません。
実用的な質問
24GBは推論モデルに十分ですか？
モデルと負荷を知らないままでは、24GBという容量だけで答えを出すことはできません。重み、実行時の割り当て、コンテキスト、同時リクエストを合わせて確認してください。構成は、要求される品質で長いケースを最後まで処理できなければなりません。ファイルサイズや重みの推定値だけではそれを示せません。
オフラインのコーパスでは、どのスループットを比較すべきですか？
まず、同じコーパスを最後まで処理し評価するのに必要な時間を比較してください。スループットを公開する場合は、受け入れられた有用な出力の数、採用した時間、エラーを示します。応答長や品質管理を伴わないトークン毎秒のスループットだけでは、2つの構成を優劣つけるのに十分ではありません。
メモリ超過が起きたらGPUを変える必要がありますか？
メモリ超過が起きたときは、まずそれを引き起こした設定と入力を特定する必要があります。プロジェクトの目的を保ちながら、バッチ、同時実行数、長さ、精度を検討できます。処理する文書や期待する応答を変えるような削減を行う場合は、品質の再確認が必須です。これらの制約を維持する必要があるなら、より多くのメモリが必要になることがあります。
提供されたnotebookは私の推論アプリケーションを検証しますか？
提供されたnotebookはお客様のアプリケーションを検証するものではありません。小さな合成ネットワークを測定し、メモリカウンタについて説明するものです。文書化されたローカル試行は、このケースのみを対象としています。お客様のアプリケーションは、容量や性能について結論を出す前に、そのモデル、入力、環境、独自の受け入れ基準で評価する必要があります。