【ITニュース解説】Qwen3-8B on workstation Blackwell: vLLM vs SGLang vs llama.cpp, plus an FP8 pass

大規模言語モデル（LLM）のような高度な人工知能（AI）を実用的なサービスとして提供するためには、その性能を最大限に引き出す技術が不可欠である。特に、AIがユーザーからの問い合わせに答える「推論」の速度と効率は、サービスの品質に直結する。今回の検証では、特定のAIモデルと最新のGPUを組み合わせた環境で、どのソフトウェアが最も効率的にAIを動かせるか、そしてさらなる高速化のためにどのような技術が有効かを探った。

この検証の舞台となったのは、NVIDIAの最新GPUである「RTX PRO 6000 Blackwell」だ。これは高性能なワークステーション向けのGPUで、96GBという大容量のメモリを搭載している。しかし、データセンターで使われるようなサーバー向けのBlackwell GPUとは細かな仕様が異なる点があるため、ソフトウェアの互換性や最適化が課題となる場合がある。このGPU上で動作させるAIモデルは「Qwen3-8B」という、80億個のパラメータを持つ比較的大きな言語モデルを用いた。これは、私たちが日常的に利用するチャットAIのような対話システムを支える「脳」のような役割を果たす。

Qwen3-8BモデルをGPU上で動かすためのソフトウェアとしては、主に三つの「推論エンジン」が比較された。これらはそれぞれ異なる技術を用いてAIモデルの処理を高速化しようとするもので、「vLLM 0.27.1」「SGLang 0.5.9」「llama.cpp（CUDAビルド）」が今回の検証対象となった。これらのエンジンは、AIモデルが言葉を生成するプロセスを効率的に管理し、応答速度を高める役割を担う。

検証は非常に厳密な方法で行われた。まず、すべてのエンジンに対して全く同じ質問（プロンプト）のセットと、AIが次の言葉を選ぶ際の設定（サンプリング設定）が使われた。また、AIが生成する文章の長さ（出力トークン数）も、それぞれのエンジンで正確に一致させた。これは、もし生成される文章の長さに違いがあれば、処理速度の比較が不正確になってしまうため、非常に重要な工夫である。AIが最も確実と判断した言葉を選ぶ「Greedy decoding」という方式を採用し、安定した性能を測定するため、AIが本格的な処理を開始する前の「ウォームアップ」期間も設けた。さらに、複数のユーザーが同時にAIを利用する状況を想定し、32人のユーザーが同時に問い合わせを行う「同時実行数32」という高負荷な条件で性能を測定した。

まず、AIが通常使う数値の精度である「BF16」という形式で各エンジンを比較した結果を見てみよう。AIの処理速度を示す指標である「aggregate tok/s（1秒あたりに生成されるトークンの総数）」では、vLLMが1,725 tok/sと圧倒的な性能を発揮した。SGLangは1,327 tok/sでそれに続き、llama.cppは428 tok/sと大きく劣る結果となった。これは、同じAIモデルを同じGPUで動かしても、どのエンジンを使うかで処理速度に最大で約4倍もの差が出ることを意味している。

ユーザーがAIの応答を「速い」と感じるかどうかは、「TTFT p50（Time To First Tokenの50パーセンタイル、つまり最初の言葉が生成されるまでの中央値時間）」が重要だ。vLLMが39ミリ秒、SGLangが42ミリ秒と非常に速い応答を見せたのに対し、llama.cppは316ミリ秒と約8倍も遅かった。チャットアプリケーションのように即座の応答が求められる場面では、このTTFTの差がユーザー体験を大きく左右することになる。また、質問を始めてからAIがすべての応答を終えるまでの「e2e p99（End-to-End latencyの99パーセンタイル、上位1%の遅い応答時間）」でも、vLLMが3.4秒であるのに対し、llama.cppは16.3秒と、ここでも大きな差が見られた。

次に、最も性能の高かったvLLMに対して、さらなる高速化技術である「FP8」を適用した場合の効果が検証された。FP8とは、AIが内部で計算に使う数字の「細かさ」（精度）を、通常のBF16よりも低い8ビットの形式に落とす技術だ。これは、人間の目には気づかない程度に画質を落とすことで写真のファイルサイズを小さくするようなイメージに近いが、AIの文脈では、計算の負荷を減らして処理を高速化することを目的としている。

FP8を適用した結果、処理速度は劇的に向上した。同時実行数32での「batch tok/s」は、BF16の1,725 tok/sからFP8では2,597 tok/sへと、約1.5倍に高速化された。単一ユーザーの場合の処理速度「single-stream tok/s」も、86 tok/sから130 tok/sへと同様に約1.5倍向上した。応答時間の中央値「latency p50」も0.74秒から0.49秒へと短縮され、約3分の1改善された。さらに重要なのは、FP8を使ってもAIが生成する文章の品質に問題がなかったことだ。96GBという大容量メモリを持つGPUでは、FP8によるメモリ使用量の削減効果は限定的であったが、純粋な処理速度の向上が大きな利点となった。

これらの結果から、いくつかの重要な知見が得られる。まず、もしAIサービスを単一のユーザーしか使わないのであれば、どの推論エンジンを選んでも性能に大きな差はない。この場合、運用や開発のしやすさを重視してエンジンを選ぶのが賢明だ。しかし、同時に多くのユーザーが利用する高負荷なサービスを構築する場合、推論エンジンの選択は非常に重要になる。今回の検証では、最も性能の良いvLLMと最も性能の悪いllama.cppの間で、処理速度に最大4倍もの差が生まれた。特に、最初の応答が返ってくるまでの速度は、チャットのようなリアルタイム性の高いサービスではユーザー体験を大きく左右するため、この差は致命的になりかねない。また、FP8のような低精度化技術は、AIモデルの性能を落とさずに処理速度を大幅に向上させる強力な手段であることも明らかになった。

今回の検証では、ワークステーション向けのBlackwell GPU (sm_120) を使ったことで、データセンター向けのGPUとは異なる課題も浮上した。データセンター向けに最適化されたソフトウェア設定が、ワークステーション向けGPUではそのまま動かない場合があるのだ。例えば、FP8を有効にする際に、特定の高速計算カーネルがワークステーション向けGPUでエラーを吐き、別のカーネルに切り替える必要があった。また、別のケースでは、GPUの共有メモリの容量制限によって、一部の処理が正しく行えない問題も報告されている。これは、最新のGPUでAIを動かすシステムを構築する際に、単に高性能なハードウェアを用意するだけでなく、そのハードウェアの特性を深く理解し、ソフトウェアの細かい設定や互換性の問題を自力で解決するエンジニアリング能力が求められることを示している。

結論として、AIモデルの推論性能は、GPUのようなハードウェアだけでなく、それを動かす「推論エンジン」と呼ばれるソフトウェアや、FP8のような計算精度を調整する技術、さらには細かな設定によって大きく変化することが明確になった。特に多くのユーザーが同時に利用するサービスにおいては、適切なソフトウェアの選択と、ハードウェアの特性に合わせた設定調整が、システムの応答速度と処理能力を決定する極めて重要な要素となる。最新のAI技術を実用化するシステムエンジニアにとって、これらの知識と問題解決能力は今後ますます不可欠となるだろう。