vLLMがハードウェア非依存レイヤーを導入、性能と移植性を両立へ

はじめに

vLLMはこれまで、モデル定義とアクセラレーターの間をつなぐ抽象化レイヤーとして発展してきました。Attention、線形射影、正規化、活性化などの共通部品をモデル間で共有し、torch.compile によるグラフ取得や融合、バックエンド向けの変換を組み合わせることで、NVIDIA、AMD、Intelなど複数のハードウェアを支えてきました。

しかし、最先端モデルの設計は急速に多様化しています。専用レイヤーや最適化カーネル、従来と異なるAttention機構が増え、モデルごとの実装差が大きくなっています。さらに、新世代GPUやラック規模のシステムで性能を引き出すには、計算と通信の重なりまで含めた個別のカーネル設計が必要です。そこでvLLMは、完全グラフコンパイルを前提にしない「フラット」なモデル実装を拡大しています。

主なポイント

• 共通抽象化に負荷がかかっている。 vLLMには新しいモデル、従来型モデル、Transformersバックエンドという複数の入口がありますが、多くは同じ共通レイヤーを利用します。新モデルを完全グラフコンパイルに対応させるには、Dynamoで追跡可能なコードやTorchライブラリ演算子の登録、フェイク実装、ミューテーション情報などが必要です。
• フラットモデルは最先端性能を優先する。 モデルとハードウェアに特化した融合やカーネルを採用すれば、新しい機能をより自由に利用できます。その反面、完全グラフコンパイルや既存の CustomOp 拡張機構と互換性を保てない可能性があります。
• 外部アクセラレーターへの影響が大きい。 IBM SpyreのようなプラグインはTorchDynamoとTorchInductorを利用し、独自のメモリレイアウトやレイヤー置換を組み込む場合があります。共通レイヤーのコンパイル性や拡張性が失われれば、プラグイン側がモデルとレイヤーを重複して保守する必要が生じます。
• ハードウェア非依存レイヤーが分離策になる。 vLLMは、旧世代GPU、コンシューマー向けハードウェア、ツリー外アクセラレーターを対象としたレイヤーをリポジトリ内に整備しています。記事によれば、H100では3つの最近のモデルによる幾何平均で、総トークンスループットはネイティブ実装から3.4%以内でした。

意味と影響

この方針は、単一の実装ですべてを最適化するのではなく、「最新システムでの最大性能」と「幅広いハードウェアへの対応」を二つの経路に分けるものです。モデル開発者は共通抽象化に合わせる負担を減らせ、利用者は主流ではないアクセラレーターでも新モデルを使える可能性を維持できます。

一方で、vLLMの構造はより複雑になります。開発者はフラットモデルとハードウェア非依存レイヤーの役割を理解する必要があり、コミュニティには複数実装の保守負担が残ります。移植性を保ちながらネイティブに近い性能を維持できれば、この二層構造は、急速な最適化と長期的なエコシステムをつなぐ基盤になりそうです。

出典：PyTorch Blog