vLLM量子化により、モデルをより少ないGPUメモリに収められる場合がありますが、万能の高速化スイッチではありません。チェックポイントが小さくなると、KVキャッシュや同時リクエストのための余地をより多く確保できる可能性があります。実際のスループットは、モデル、量子化形式、GPUアーキテクチャ、カーネル、プロンプト長、出力長、トラフィックパターンに依存します。適切な判断は、サポートされている形式を選び、代表的なワークロードを非量子化ベースラインと比較して測定することです。
このvLLM量子化ガイドでは、実用的な選定およびテストのプロセスを説明します。テストしていないGPUやモデルについて、ベンチマーク結果を主張するものではありません。
vLLM量子化で変わること
量子化では、一般的なFP16またはBF16チェックポイントよりも少ないビット数で一部のモデル値を保存します。最も明確な一次効果は、重みメモリの削減です。重みメモリがモデルを収められない原因である場合、互換性のある量子化済みチェックポイントによって、より小さいGPUで実行したり、リクエスト用のメモリをより多く残したりできる可能性があります。GPUには、アクティベーション、KVキャッシュ、ランタイムオーバーヘッド、並列ワーカーのためのメモリも必要です。したがって、パラメータ数を重み当たりのビット数で割る計算は、大まかな下限にすぎず、デプロイ可能なメモリ見積もりではありません。
vLLM量子化には一般的に2つの方法があります。事前に量子化されたチェックポイントを読み込むか、ロード時にサポートされているオンライン量子化パスを使用します。どちらの場合も、形式を選ぶ前にモデルカードと最新のvLLM互換性マトリックスを確認してください。vLLM量子化ドキュメントは、手法およびハードウェアサポートの正確な情報源です。サポートの進化に伴いマトリックスが変更されることが明示的に警告されています。
チェックポイントとGPUに基づいて形式を選ぶ
| 選択肢 | 実用的な出発点 | デプロイ前に確認すること |
|---|---|---|
| AWQ | AWQチェックポイントとして配布されているモデルと互換性のあるGPU | モデル品質、カーネルの選択、プロンプト長、実際のレイテンシ。 |
| GPTQ | GPTQチェックポイントとして配布されているモデル | 正確なチェックポイント構成、vLLMバージョン、GPUサポート、品質劣化。 |
| FP8 | 互換性のあるチェックポイントと、FP8実行をサポートするGPU | 選択したvLLM実装がアーキテクチャとモデルレイヤーをサポートしているか。 |
| GGUF | すでにGGUF形式で配布されているモデル | 特定のアーキテクチャとvLLM機能のサポート。Ollamaの動作が一対一で対応すると想定しないこと。 |
| BitsAndBytesまたは圧縮テンソル | これらを明示的に必要とするチェックポイントとデプロイパス | ランタイム依存関係、ロード時の動作、サポートされるカーネル、スループット。 |
現在のvLLMマトリックスでは、Ampere、Ada、Hopper向けにAWQとGPTQが記載されています。FP8はllm-compressorを介してAda、Hopper、および一部のAMD GPUパスで記載されている一方、GGUFは異なるサポートパターンです。A100はAmpere GPU、H100はHopper GPUですが、サポートは手法ごとに異なります。ファミリー内のすべてのカードで、すべてのFP8、FP4、またはMarlinバリアントが動作すると推測しないでください。ハードウェア互換性テーブルの正確な行と、チェックポイント自体のメタデータを確認してください。
まだモデルを選定していない場合は、同じベースモデルと評価セットを使用する2つの候補チェックポイントを比較してください。あるファミリーのAWQモデルと別のファミリーの非量子化モデルを比較すると、vLLM量子化とモデル品質が交絡します。
見かけ上の成果を避けるデプロイワークフロー
- サービス目標を定義します。 モデル、コンテキスト長、想定される入力および出力長、同時リクエスト数、p95レイテンシ目標、品質テストを記録します。チャットボット、バッチ分類器、長コンテキストエージェントでは、ボトルネックが異なります。
- ベースラインを記録します。 同じGPUとvLLMバージョンで非量子化チェックポイントを実行します。GPUメモリのピーク使用量、最初のトークンまでの時間、出力トークンのスループット、エンドツーエンドのp50/p95レイテンシ、エラー、許容結果率を取得します。
- 互換性のある量子化済みチェックポイントを選択します。 そのモデルカードとvLLMの最新手法マトリックスを確認します。テスト記録には、チェックポイントのリビジョン、vLLMバージョン、CUDA/ドライバスタック、ハードウェアSKUを固定して記録します。
- 小規模なカナリアから開始します。 トラフィックを適用する前に、モデルがロードされ、必要なエンドポイントと生成設定を提供でき、もっともらしい出力を生成することを確認します。
- 複数の同時実行レベルでベンチマークします。 実際のプロンプト長と応答長で測定します。単一リクエストでは、継続的なサービス提供とは異なる構成が有利になることがあります。
- 同じ品質スイートを実行します。 量子化によって出力が変わる可能性があります。パープレキシティだけを信頼するのではなく、ドメイン固有の正確性、形式への準拠、拒否、安全性に関わるケースを評価します。
- 許容結果あたりのコストを算出します。 量子化モデルで失敗するタスクが増えたり再試行が必要になったりする場合、GPU時間単価を生トークン毎秒で割るだけでは不十分です。
サービングベンチマークについては、vLLMはvllm bench serve、そのデータセット、およびエンドポイントオプションを公式ベンチマークCLIガイドで文書化しています。アプリケーションに合致するトラフィックデータセットを使用してください。合成ランダムプロンプトは制御された比較には有用ですが、本番環境のパフォーマンスとして提示すべきではありません。
メモリ計画：重みは項目の一つにすぎない
単純な計画ワークシートでは、4つのバケットを分けます。
必要なGPUメモリ総量 ≈ モデル重み + KVキャッシュ + ランタイム/アクティベーションのオーバーヘッド + 安全余裕
量子化形式が主に変えるのはモデル重みの項です。KV キャッシュの負荷は、コンテキスト長とアクティブなシーケンス数に応じて増加します。1件のリクエストではかろうじて収まるモデルでも、長いコンテキストを伴う同時トラフィック下では失敗したり、大幅に遅くなったりする可能性があります。マルチGPU構成では、テンソル並列化によってカードあたりのメモリと通信オーバーヘッドの両方が変わります。可能な限り小さいチェックポイントが、必ずしも最も低コストなデプロイではありません。
GPUをレンタルする前に、より大きなモデルを1つ収める必要があるのか、小さなモデルの同時実行数を増やす必要があるのか、あるいは品質を維持しながらコストを削減する必要があるのかを検討してください。その答えによって、重要となるメモリとスループットのトレードオフが決まります。FlatkeyのCloud GPU ComputeではGPUレンタルの選択肢を掲載しており、顧客に構成、リージョン、容量、レンタル条件の確認を求めています。ライブの可用性と価格は、ベンチマーク記事内の固定値ではなく、見積もり時点の入力情報として扱ってください。
vLLM量子化を公平にベンチマークする
ベースモデル、生成パラメータ、プロンプトセット、出力上限、キャッシュ状態、GPUを固定してください。少なくとも3つの負荷を測定します。応答性を測る単一リクエスト、代表的な本番同時実行数、そしてレイテンシが低下し始めるストレスポイントです。総スループットとp95レイテンシの両方を報告してください。飽和時の毎秒トークン数だけを報告しても、インタラクティブなリクエストが許容可能なままであるかをユーザーは判断できません。
スコアカードにはモデル品質も含めてください。
| 指標 | 重要な理由 |
|---|---|
| GPUメモリ使用量のピーク | 量子化によって実際に利用可能な余裕が生まれるかを示します。 |
| 最初のトークンまでの時間 | ストリーミングインターフェースで重要です。 |
| 出力トークン数/秒 | 生成スループットを示しますが、タスク品質は示しません。 |
| p95エンドツーエンドレイテンシ | 負荷時のテール挙動を明らかにします。 |
| エラー率とOOM率 | リクエストが成功した場合にのみ高速に見える構成を検出します。 |
| 許容結果率 | 生の速度を有用な作業量に換算します。 |
vLLM量子化における重要な比較は、抽象的な「量子化済み対非量子化」ではありません。「このGPU、このワークロードにおける、このチェックポイントとカーネル対ベースライン」です。結果には必ず条件を添えて公開してください。テストに品質チェックがない場合は、パフォーマンスのみの実験と明記してください。
よくある障害モード
モデルをロードできない。 チェックポイントのメタデータ、量子化方式、vLLMバージョン、GPU機能、およびその方式がアーキテクチャで使用されるすべてのレイヤーをサポートしているかを確認してください。コマンドフラグを手当たり次第に変更する前に、vLLM method matrixを確認する必要があります。
メモリ削減でレイテンシが改善しなかった。 重みのフットプリントが小さくなっても、カーネルが高速になる保証はありません。目標の同時実行数でテストし、最初のトークンまでの時間、デコード速度、GPU使用率を確認してください。KVキャッシュの余裕増加こそが真のメリットかもしれません。
低ビットのチェックポイントは高速に見えるが、品質テストに失敗する。 本番用の受け入れセットを維持し、アプリケーションの基準を満たす出力の割合を測定してください。ロールバックのしきい値はカナリア導入前に設定しておく必要があります。
ベンチマークを再現できない。 モデルとチェックポイントのリビジョン、vLLMとドライバーのバージョン、GPU SKU、データセット、同時実行数、プロンプト長、出力長、コマンド引数を記録してください。これらがなければ、スループットの数値はエンジニアリング上の証拠ではなくマーケティングにすぎません。
Flatkey Cloud GPUを使用する場合
独自のvLLMサーバーを実行して量子化済みチェックポイントを比較する必要がある場合は、測定済みのメモリ要件と同時実行要件に基づいてGPU容量を選択してください。Flatkeyは、Cloud GPU Computeを通じてNVIDIA GPUレンタルの選択肢を提供しています。契約前に、利用可能なSKU、デプロイリージョン、容量、料金、サービス条件を確認してください。vLLM量子化テストは、実際にレンタルする予定の構成で行うべきです。vLLMを運用する代わりにマネージドモデルAPIが必要な場合は、FlatkeyのAPI route and model directoryを別途評価してください。これは異なる運用モデルです。
関連するデプロイ判断については、vLLMデプロイメント guide、vLLMマルチGPU 推論ガイド、およびvLLMとOllamaの 比較をご覧ください。
FAQ
vLLM 量子化により推論は常に高速になりますか？
いいえ。重みメモリを削減できる場合がありますが、レイテンシとスループットはチェックポイント、カーネル、GPU、シーケンス長、リクエスト負荷に依存します。実際のワークロードをベースラインと比較してベンチマークしてください。
A100または H100でAWQを使用できますか？
現在のvLLM互換性マトリクスでは、A100およびH100を含むAmpereとHopperでのAWQサポートが示されています。デプロイ前に、正確なチェックポイント、現在のvLLMバージョン、モデルアーキテクチャを確認してください。
FP8はすべての NVIDIA GPUでサポートされていますか？
いいえ。サポートは量子化実装とアーキテクチャによって異なります。現在のマトリクスでは、llm-compressor FP8やMarlinなどの方式が区別されています。ご使用のハードウェアに該当する正確な行を確認してください。
GPUを選択する前と後のどちらで 量子化すべきですか？
まずワークロードと品質目標を見積もり、その後、互換性のあるGPUで候補チェックポイントをテストします。形式とハードウェアの選択は、併せて評価する必要があります。
