vLLM、ハードウェア非依存層の進展を公表　複数のアクセラレーターに対応するコンパイル経路を維持

vLLMの開発者は9月22日、ハードウェア非依存のモデル層の開発状況とH100でのテスト結果を公表した。推論エンジンがハードウェア固有の最適化へと移行する中で生じる互換性の問題に対応するものだ。最初の基盤コードは8月13日にマージ済みだが、すべてのモデルの移植は完了していない。[公式説明](https://pytorch.org/blog/hardware-agnostic-models-in-vllm/)と[マージ記録](https://github.com/vllm-project/vllm/pull/49458)には、それぞれ異なる段階の時点が示されている。

問題は、特定のモデルやアクセラレーター向けに融合演算を手書きする「flat models」が、共通層の設計を徐々に変えつつあることだ。外部アクセラレーター向けプラグインが計算グラフ全体のコンパイルに依存している場合、モデル実装を独自に保守する必要が生じる可能性がある。利用頻度の低いモデルにもポータブルな実行経路が必要だ。このため[設計提案](https://github.com/vllm-project/vllm/issues/44219)では、グラフ全体に対する`torch.compile`のサポートと演算子を置き換えられるインターフェースを維持し、汎用実装をハードウェア固有の分岐から分離することを求めている。

外部アクセラレーターにとって、グラフ全体のコンパイルは、バックエンドがモデル全体の演算構造を取得し、対象ハードウェアで実行可能な形式へ変換することを可能にする。プラグインは個々のレイヤーを置き換え、メモリレイアウトを調整することもできる。こうしたインターフェースを共通コードベースに残すことで、各ベンダーがモデルの更新に追随し、同じロジックを書き直す保守負担の軽減につながる。[アーキテクチャの説明](https://pytorch.org/blog/hardware-agnostic-models-in-vllm/)

マージ済みの初期実装はTransformersバックエンドに接続され、RMSNormやSiluAndMulなどのコンポーネントを追加している。レイヤーリゾルバーはハードウェア非依存版を優先して探し、まだ移植されていないレイヤーに遭遇すると従来のvLLM実装にフォールバックしてログを記録する。そのため、サービスの起動に成功しても、モデル全体がポータブルな実行経路を利用しているとは限らない。[実装記録](https://github.com/vllm-project/vllm/pull/49458)、[レイヤー解決のドキュメント](https://docs.vllm.ai/en/stable/api/vllm/model_executor/models/transformers/layers/)

設定名も確認が必要だ。ブログの例では`USE_HW_AGNOSTIC=1`と記載されている一方、コードのドキュメントでは`VLLM_USE_HW_AGNOSTIC=1`を`--model-impl=transformers`と組み合わせて使用している。現在のレイヤー解決コードに従うなら、エンジニアは後者を使用し、ログを調べて実際に置き換えられたコンポーネントを確認すべきだ。[設定とフォールバックのロジック](https://docs.vllm.ai/en/stable/api/vllm/model_executor/models/transformers/layers/)

著者によると、最近の3つのモデルについてH100上で測定した総トークンスループットの幾何平均は、比較対象の経路との差が3.4%以内だった。記事で比較しているのは、Transformersバックエンドでこの機能を有効または無効にした場合の結果であり、すべてのハードウェアやモデルに対する性能保証へと一般化することはできない。[テストの説明](https://pytorch.org/blog/hardware-agnostic-models-in-vllm/)

DeepSeek V4の汎用実装は引き続きレビュー中だ。代替アクセラレーターをサポートするチームにとって、今後注目すべき点はレイヤーのカバー率、プラグインインターフェース、継続的インテグレーションのテストとなる。導入時にはバージョンを固定し、出力の数値、最初のトークンが出力されるまでのレイテンシ、スループットをそれぞれ検証すべきだ。[レビュー中の実装](https://github.com/vllm-project/vllm/pull/45470)