Intelは、Arc Graphics向けのコンテナ型ソフトウェア構成「LLM-Scaler-vLLM PV 1.5」を公開しました。vLLMの基準版を0.14から0.26へ、PyTorchを2.10から2.12へ更新し、対応モデルや量子化機能を拡充するとともに、推論性能を改善しています。

vLLMとPyTorchを更新したコンテナ構成

LLM-Scaler-vLLMは、Intel Arc Graphics上で大規模言語モデル(LLM)を動かすためのDocker構成です。IntelのProject Battlematrixから生まれたソフトウェアスタックで、Dockerイメージはintel/llm-scaler-vllm:1.5として提供されています。

中核となるvLLMは0.26.0を基準にIntel XPU向けのパッチを含み、PyTorchは2.12.0+xpuです。コンテナにはTransformers 5.8.0やTriton XPU 3.7.1なども含まれます。

vLLMはLLMの推論とサービングを行うエンジンです。モデルを実行するほか、複数の推論要求を処理する仕組みも備えています。このエンジンとIntel XPU向けソフトウェアが一つのコンテナにまとまっています。

QwenとGemmaの対応モデルを追加

新たに対応したモデルは、Qwen3.6-27B、Qwen3.8-27B、Qwen3.6-35B-A3Bと、gemma-4-26B-A4B-it、gemma-4-31B-itです。検証済みモデルは、この5モデルにMuse-Glimmer-30Bを加えた計6モデルです。

量子化は、実行時に重みなどを低精度形式で扱う技術です。今回、オンラインFP8と対称INT4量子化に対応し、Qwenの3モデルではブロックFP8チェックポイントも扱えるようになりました。

MTPとLoRAサービングも、新たに対応したQwenおよびGemmaの5モデルで利用できます。MTPは複数トークンの予測を使うデコード方式で、LoRAはモデル本体を置き換えずに追加学習分を適用する仕組みです。さらに、Qwenの3モデルとMuse-Glimmer-30BではDFlashに対応し、FP8形式のKVキャッシュも利用できます。

推論速度の改善と修正内容

Intelは、QwenおよびGemma 4で、要求を受けて最初のトークンを出力するまでの時間(Time to First Token、TTFT)を短縮したとしています。MTPデコード、LoRAサービング、FP8 KVキャッシュの性能も改善しています。

修正には、MTP利用時のプレフィックスキャッシュ、対称INT4モデルの誤出力、並行デコード中のブロックFP8出力破損への対応が含まれます。Qwenの精度とLoRAサービングに関する問題のほか、モデル読み込みや実行時の不具合も修正されました。

XPUグラフのサポートは実験的です。Muse-Glimmerのマルチモーダル推論にはTransformers 5.15.0が必要ですが、今回のイメージには5.8.0が含まれます。そのため、同梱環境ではMuse-Glimmerの画像入力を含む推論の要件を満たしません。

上流vLLMとのバージョン差

vLLMはPagedAttentionという方式で、推論中に使うキー・バリュー(KV)キャッシュを管理します。この方式ではGPUメモリを仮想メモリのように扱い、キャッシュのメモリ使用を抑えます。

また、vLLMは継続的バッチ処理を採用しています。到着する要求を固定サイズのバッチにまとめず、処理の流れに応じて動的に扱います。モデル推論・サービング用ライブラリとして、ストリーミング出力やOpenAI互換APIサーバー、複数の量子化方式も提供します。

このリリースの基準版0.26は、2026年7月の上流vLLMリリースにあたります。上流の0.26.0ではInkling対応、DeepSeek-V4の性能最適化、FP32生成ヘッド、注意機構のバックエンド選択、KVオフロードの機能成熟が記録されています。その後、上流では0.27から0.30までの版が続き、10月5日には0.31.0が公開されました。PV 1.5は上流の最新系列と同じ版ではなく、Intel向けパッチとArc GPU向けのモデル対応を含む、0.26.0基準の構成です。