vLLMはTenstorrentのMesh構成にどう対応するのか

導入

vLLMは、Tenstorrentアクセラレーターをサービング基盤に接続するTT Pluginを公開しました。プラグインをインストールし、TT-Metalのttnnをインポートできる環境で起動すると、TenstorrentハードウェアがvLLMのプラットフォームとして登録されます。利用者側のAPIは大きく変わりません。OpenAI互換API、リクエスト形式、既存クライアントをそのまま使える設計です。

この取り組みの本質は、対応ハードウェアが増えたことだけではありません。Tenstorrentは、コアとチップをネットワークで結んだMeshを実行単位とし、チップ間のデータ移動をホストが都度発行するGPU型の集合通信ではなく、コンパイル済みプログラムの一部として処理します。そのため、GPUを前提にした推論スタックの設計をいくつか組み替える必要がありました。

主な設計ポイント

• 外部プラグインとして統合。 プラットフォーム、ワーカー、スケジューラー、モデルアーキテクチャは、vLLMが提供する拡張ポイントを通じて登録されます。Tenstorrent固有の設定は、専用のコアCLIではなくadditional-config名前空間に置かれます。
• ランクではなくMesh全体で実行。 モデルは対象Mesh向けにコンパイルとトレースが行われます。デバイス構成はMESH_DEVICEで指定し、従来の-tpや-ppは受け付けません。並列化の方法は、モデル実装とMesh形状の組み合わせで決まります。
• フェーズを分けたスケジューリング。 各ステップはprefillのみ、decodeのみ、または空のいずれかです。両者を同じバッチに混在させません。長いプロンプトは複数のprefillステップに分割でき、途中にdecodeを挟むことで、処理中のリクエストを止めずに進められます。
• 形状の安定性を重視。 デバイス実行は、固定されたバッチ形状のトレースを再生する方式に大きく依存します。そのため、ばらつきの大きいバッチより、同質で形状が安定したバッチの方が設計に適しています。
• サンプリングをデバイス側で実行可能。 Meshプログラムの末尾までサンプリングを含められるため、モードによっては完全なlogitsをホストへ戻さず、選択済みトークンを返せます。ホスト側のフォールバックも用意されています。
• テキスト以外にも対応。 Llama、Qwen、Mistral、Gemma、DeepSeek、GPT-OSSなどに加え、いくつかのVisionおよびマルチモーダルアーキテクチャが対象です。外部ディレクトリからモデルバンドルを登録でき、プラグインのソース変更も不要です。

意義と影響

この事例は、vLLMのプラグイン境界が本当にハードウェア非依存かを試すものです。TenstorrentのMeshをGPUプロセスの集合として見せかけるのではなく、Meshコンパイル、フェーズ制約、サンプリング方式をプラグインとTT-Metal側のモデル実装に閉じ込めています。その結果、vLLMのAPIやエコシステムを利用しながら、コアへの変更を抑えられます。

一方、GPU向けの設定をそのまま移植できるわけではありません。運用者はテンソル並列の指定方法を見直し、prefillとdecodeを分けるバッチ運用にも対応する必要があります。それでも、ハードウェアベンダーにとっては、長期的なフォークを維持せず、拡張インターフェースを通じてvLLMの更新に追随できる点が大きな利点です。

推論フレームワークの拡張性とは、新しいチップを認識できることだけではありません。異なる実行モデルを、GPU型の前提に押し込めず表現できることが、より重要になっています。

出典：vLLM Blog